. In DICTIOUS you will not only get to know all the dictionary meanings for the word
, but we will also tell you about its etymology, its characteristics and you will know how to say
in singular and plural. Everything you need to know about the word
you have here. The definition of the word
will help you to be more precise and correct when speaking or writing your texts. Knowing the definition of
, as well as those of other words, enriches your vocabulary and provides you with more and better linguistic resources.
Thanks for creating the vote. I don't like that synonyms and antonyms will display by default, but I like that you specify that everything else will be hidden. I also really don't like having two systems for listing synonyms, but I guess I'll have to bear with the formalized inconsistency until consensus shifts to doing it one way or the other. Andrew Sheedy (talk) 03:06, 27 November 2018 (UTC)Reply
- I agree on both counts; we should have a single format, and should hide the semantic relations by default for all users who have javascript enabled. - TheDaveRoss 13:37, 27 November 2018 (UTC)Reply
- @Andrew Sheedy, TheDaveRoss: Yes, ideally we should have only one system, but it's difficult to shift everything at once, and unlikely to reach consensus. However I don't understand why synonyms/antonyms should be hidden by default: I installed Ungoliant's script and find the experience very limiting: you lose a lot of information which could be glanced quickly otherwise, you have to manually expand all the definitions, it's a terrible user experience. Synonyms are especially useful in non-English entries, where they often help to figure out the right meaning for ambiguous definitions or missing glosses. That's why I think they should be visible by default for all users. Let's not bury useful information. – Jberkel 17:46, 27 November 2018 (UTC)Reply
- My main problem with it, which was my initial objection to having -nyms under the definition, is that it creates a lot of clutter underneath the definition, which can make entries really hard to read. But I think your point is valid, and as long as I have the option of hiding them, I'm happy. Also, I'm pretty sure there's an option in the sidebar to show these sorts of things, and I think they're also visible on mobile anyway. Andrew Sheedy (talk) 18:31, 27 November 2018 (UTC)Reply
- My preference is for replacing everything, I find the new format superior in every way. It's difficult to shift everything at once, but if we remove mention of the old format, then that automatically deprecates it. There is one point that hasn't been addressed yet: what should be done to Thesaurus links, if the Synonyms section is removed? —Rua (mew) 18:32, 27 November 2018 (UTC)Reply
- I am also for hiding the synonyms and antonyms too by default, including in foreign languages (which could have different settings, but I don’t want to open this can). It is less intrusive for anyone who doesn’t want to see synonyms and antonyms on that place. (Example: so пере́ть (perétʹ) is easier to read, when one only sees the synonyms if one wants too. Anyone can be of such a mind, you too, Rua, since every internet user is flooded with information.) There is also the possibility of letting editors change the default in individual cases, how about that @Rua? (Because while I prefer to hide generally I think that for terms like се́тка (sétka, “reticulum”) anyone asks himself “So what are the other compartments of the ruminant stomach?” – such things where terms are defined by their being distinct from certain other terms), so I would show them.) Fay Freak (talk) 11:59, 28 November 2018 (UTC)Reply
- I think the idea of a configurable option was already settled, but I like the vote as it is currently written, with synonyms and antonyms showing at least one row by default and the rest entirely collapsed. —Rua (mew) 13:52, 28 November 2018 (UTC)Reply
I would have to oppose the wording the way it stands currently. It seems to suggest that you should normally use {{sense}}
, and only use the nym templates in certain specific cases. This does not reflect how the templates have been used by those who have adopted them: they use the templates in all cases, to completely replace {{sense}}
. Therefore, if we even want to keep mention of the old method, the two formats should be presented as functionally equivalent. —Rua (mew) 18:26, 27 November 2018 (UTC)Reply
- Agreed. Andrew Sheedy (talk) 18:31, 27 November 2018 (UTC)Reply
- Agreed. I'm trying to think of cases where the current method might be preferable or necessary: when synonyms apply to all senses and would have to be repeated under the definitions. Or for links to the Thesaurus namespace, which are currently not possible with the nym templates. Should this be addressed as well? – Jberkel 18:41, 27 November 2018 (UTC)Reply
- I would include them under the definitions even if it's the same synonyms each time. Someone might come up with new synonyms that only apply to some of the senses. Someone may add a new sense that those synonyms don't apply to. They may have the same synonyms but different other nyms, and then listing synonyms under Synonyms and other nyms under the definition is weird. And even if it is exactly the same nyms repeated, then that gives positive reinforcement that someone considered each sense individually and found this nym fitting for all of them. With the Synonyms section, you can't assume from the lack of
{{sense}}
that the synonyms apply to every sense, there are lots of cases where there should be {{sense}}
but it's missing. The new format avoids that. —Rua (mew) 18:45, 27 November 2018 (UTC)Reply
Given that some people want consistency, I suggest splitting the vote into two parts. The first one would allow the placement of -nyms directly under senses, the second part would deprecate the old way of doing it and would replace the ELE text you propose with a text that only explains the new format and omits any mention of the old one (or explains that it is deprecated). They wouldn't be mutually exclusive, so people could still vote for the first part in case the second one failed. If both passed, then the second one would obviously take precedent. Andrew Sheedy (talk) 20:39, 27 November 2018 (UTC)Reply
- Given how many are opposed to the new format I don’t expect the second to pass anyhow; plus if you talk already this way some could block the first vote out of spite. And I would even vote against it as it stands because I recognize that sometimes the old format is more pleasant. It must be of the editors’ discretion when which format is used. Though you who drafted the vote (@Jberkel, right?) tried to formulate friendly for new users by “suggesting”, now people mistake this as having regulatory effect. One can reject the vote in such a formulation only because of this in connection with terms of not definitely always clear application like “for many senses”. I suggest you to add something like: These suggestions do not have regulatory effect; the choice between the two formats is subject to editorial discretion. (I assume then editors won’t be so foolish as to fight in individual cases which layout has to be chosen.) Fay Freak (talk) 11:59, 28 November 2018 (UTC)Reply
- @Andrew Sheedy, Fay Freak: I'd like to avoid a vote with several parts and changed the wording to present the two options as equal, as suggested above. – Jberkel 00:03, 2 December 2018 (UTC)Reply
This vote suggests the use of the text "See also Thesaurus:apex" even where nothing else is given. The "also" is meaningless. I see many existing entries that have "also" like this, too. It should just be "See". Equinox ◑ 13:48, 8 December 2018 (UTC)Reply
- It depends on whether the reference to the Thesaurus is preceded by a selection of synonyms, like "* grimalkin, housecat, kitten; see also Thesaurus:cat". I admit that the "also" seems pointless when there is no selection of synonyms preceding. --Dan Polansky (talk) 14:06, 8 December 2018 (UTC)Reply
- I agree. — SGconlaw (talk) 14:30, 8 December 2018 (UTC)Reply
- It mentions only a common formulation that has been much used thus far. The mention of the Thesaurus is declaratory (to remind people who read WT:EL that the Thesaurus exists and can be linked to), since as long as the Thesaurus is not abolished it must be assumed that linking it from the mainspace is commended. There is no reason to assume that the vote prescribes certain formulation in which the Thesaurus is referred to, precisely because the example has this meaningless word. The lacking explicit provision for Thesaurus entries is an intentional regulatory gap to be filled by future development of usage that can be found to accord with the analogy of the manners wherewith semantic relations are directly given. Fay Freak (talk) 21:40, 8 December 2018 (UTC)Reply
- The vote does seem to prescribe "See also"; rereading the vote should help. WT:EL#Flexibility gives us leeway where we needed; indeed, the very use of
{{synonyms}}
and its ilk ahead of the vote is an example of that leeway. Therefore, we can use "See" instead of "See also" where we see fit. That said, it would be preferable to fix WL:EL in a future vote so that we do not need to use the flexibility provision. --Dan Polansky (talk) 22:14, 8 December 2018 (UTC)Reply
- Do you write that way on purpose? I find you quite difficult to read. It's a bit like legalese. Equinox ◑ 01:55, 9 December 2018 (UTC)Reply
- Sorry about this oversight. There is also
{{seeSynonyms}}
which just outputs "See ...". Maybe this should have been suggested instead. – Jberkel 10:50, 9 December 2018 (UTC)Reply
- I for one prefer a markup without a template; the template does not really add any value. The template is still in Wiktionary:Requests for deletion/Others#Template:seeSynonyms. --Dan Polansky (talk) 12:27, 9 December 2018 (UTC)Reply
- By making it an implementation detail of the template we could avoid putting the exact wording in WT:EL. Templates are easy to change, WT:EL isn't. – Jberkel 16:27, 9 December 2018 (UTC)Reply
- Before the proposed change to WT:EL made in this vote, there was not an exact wording in ELE. Therefore, we do not need a template to have EL flexible. --Dan Polansky (talk) 08:07, 15 December 2018 (UTC)Reply
- True, but WT:EL currently unhelpfully links to other pages as example entries, and one of those (body) incidentally uses "See also" to link the thesaurus; that's probably where I copied the wording from. The other linked entry (corpse) makes use of
{{seeSynonyms}}
, a template you requested to be deleted. - Jberkel 08:48, 15 December 2018 (UTC)Reply
- Fair enough. "See also" is the overwhelming practice as per "insource:/See also...Thesaurus/" (3210 hits), and your entering it into WT EL modification proposal is a good thing in that it lead to the concern we are dealing with, and which can be addressed in another vote. Changing EL is not so hard. Furthermore, since the placement of the synonym lists directly under definitions is now passing, the links to the thesaurus should now ideally be directly under senses, and therefore,
{{synonyms}}
should ideally be extended to support linking to the thesaurus as the last item, like "grimalkin, housecat, kitten; see also Thesaurus:cat" or "grimalkin, housecat, kitten; → Thesaurus:cat" --Dan Polansky (talk) 10:15, 15 December 2018 (UTC)Reply
I have found another regulatory gap created by this vote that is apparently rather unintentional (though the resulting anarchy is not too bad and possibly advantageous).
While WT:Entry layout states example sentences should “be placed immediately after the applicable numbered definition, and before any quotations associated with that specific definition”, I cannot derive if the semantical relations follow or precede example sentences and quotations. Technically the semantical relations can now even be between usage examples and quotations, deeming that this prescript of immediately following placement is materially derogated by this vote 2018-11/Allow semantic relations under definition lines (since the layout example sentences–semantic relations–quotations makes sense too). No, the wording “directly under definition lines” does not suggest that the semantic relations are the first, it rather means an opposition to “under the definition lines in a new section”. Fay Freak (talk) 14:00, 24 December 2018 (UTC)Reply
- We should clarify this. At the moment, in the absence of a specific policy, I have been placing the semantic relations first, followed by the usage examples, and then the quotations, the theory being that usage examples and quotations are similar and so should go together. — SGconlaw (talk) 15:58, 24 December 2018 (UTC)Reply
- That's what the documentation of
{{syn}}
itself suggests, too. —Rua (mew) 16:57, 24 December 2018 (UTC)Reply
- No, SGconlaw says ”I have been placing the semantic relations first”, the documentation says “It's intended to be used below each definition, after any usage examples or quotes”. 🙃 Fay Freak (talk) 17:03, 24 December 2018 (UTC)Reply
- Oh, that’s going to look weird. — SGconlaw (talk) 21:19, 24 December 2018 (UTC)Reply
- I have also been putting them before the examples, like SGconlaw. I can try to stop doing this if we don't like it that way. Equinox ◑ 22:20, 24 December 2018 (UTC)Reply
- The documentation of
{{syn}}
has said how to format it from the very beginning, so those of you doing it differently either haven't read the documentation or have read it and decided another format would make more sense. The arguments for the latter case would be good to post here. —Rua (mew) 22:51, 24 December 2018 (UTC)Reply
- I think it's better to put them right below the definition. There might be more than one
{{ux}}
, and that would push the semantic relations down to the point where it's difficult to associate them with a sense, which is one the main concerns of{{syn}}
et al. – Jberkel 10:34, 25 December 2018 (UTC)Reply
- Except it might not be better if the usage examples are important to illustrate the meaning, doing a better job than synonyms, so instantly after the gloss one wants to read usage examples. Fay Freak (talk) 18:43, 25 December 2018 (UTC)Reply
- I think in general, links to other terms should come after information pertaining to the current term. The order of headings seems to follow this principle as well. —Rua (mew) 18:51, 25 December 2018 (UTC)Reply
- I agree with Jberkel. I find that putting them after the quotations means they are difficult to associate with senses once the quotations are fully displayed. (I didn't know that the documentation at
{{synonyms}}
called for them to be placed after quotations.) — SGconlaw (talk) 21:47, 25 December 2018 (UTC)Reply
- Agreed with the above. I also think that because synonyms usually only take up one line, they would be separated from the definition considerably more than usexes and quotations would be if they were placed after synonyms. Andrew Sheedy (talk) 18:58, 27 December 2018 (UTC)Reply
- I am still putting them above the citations because it seems so much better and it will only take a bot a few minutes to fix them all if little-endianism is ultimately toppled. Equinox ◑ 17:23, 28 January 2019 (UTC)Reply
Musing in regard to the recent addition of Wiktionary:Beer parlour/2019/January § Inline "Imperfective:" and "Perfective:", similar to inline "Synonym:" etc. @Benwing2 had the not iningenious insight for, I noticed that consequently thought there are many lexical aspects left over since this imperfective/perfective distinction is coined upon Slavic. I thought maybe we’d need an {{aspect}}
template? Anyway I am not conscious of other languages with lexical aspect. But this thought can be even more generalized, since why {{syn}}
and {{hypo}}
when we can have {{sr|syn}}
and {{sr|hypo}}
? It would of course enable anyone to use the formatting for anything that can be meaningfully grouped under a definition, which is a bit out of scope of what this vote was intended to ratify, but I want to point out the analogy to {{lb}}
: Oldbies will know that there was quite some profusion in templates that were used where {{lb}}
is used now. Just in August 2013 {{figurative}}
and {{colloquial}}
have been deleted, just in March 2014 {{cooking}}
and {{basketball}}
. What do you think? Should we consequently put down all those relations under definition lines in an {{sr}}
template, leaving it open to the reasonable editor’s notion of meaningfulness what kinds of relations are to be stated under definition lines? We did not intend an effective numerus clausus or Typenzwang, eh? I’d reckon that coming editors of various African and Amerindian languages most cannot imagine would attain high fecundity with such an open template setup. Else it is a question of formatting stringency. Fay Freak (talk) 03:18, 28 January 2019 (UTC)Reply
- This could be a good idea, I'm interested in what others have to say. It might not be necessary since the number of semantic relations is somewhat limited in comparison with the number of labels, although I grant you I wouldn't have guessed there would be 8 relations similar to synonyms (
{{synonyms}}
, {{antonyms}}
, {{hypernyms}}
, {{hyponyms}}
, {{meronyms}}
, {{holonyms}}
, {{troponyms}}
, {{coordinate terms}}
), not to mention things like abbreviations, anagrams, etc. Benwing2 (talk) 14:22, 28 January 2019 (UTC)Reply
- I might agree with the idea if the module could show multiple semantic relations on the same line if there aren't that many. For example synonyms and antonyms side by side. But other than that, I don't think it's worth bothering. —Rua (mew) 17:19, 28 January 2019 (UTC)Reply
- Seems like a good idea since the templates essentially all do the same thing. — SGconlaw (talk) 01:52, 29 January 2019 (UTC)Reply
- I don't think it's worth doing this for semantic relations. Yes, there are 8 templates, but in practice only 3 or 4 will be used on a regular basis. – Jberkel 09:15, 29 January 2019 (UTC)Reply
- I'll leave it to the editors who work on Module:nyms to comment on whether the work is justified, but it seems to me that it would be easier to keep one template and one template description page up to date than a whole series of them (even if it is only four). — SGconlaw (talk) 10:03, 29 January 2019 (UTC)Reply
- The logic is already centralized, the templates just delegate to the module. I find separate documentation pages more helpful, but yes, there's some overhead. – Jberkel 12:02, 29 January 2019 (UTC)Reply