Our current practice is to recognize apostrophes as part of the spelling of a word (e.g. fo’c’s’le), except when used to form the possessive of a noun (so father’s is not an entry), with an exception to that exception when that possessive itself forms part of an idiomatic phrase or (part of) a proper name (e.g. men’s room and McDonald’s). We similarly recognize capitalization and hyphens as part of the spelling. We aim at being descriptive. As long as apostrophes are in widespread use, we are not going to abolish them. We do have an entry for anapostrophic aint because it is attestable but label it as a misspelling because that is how it is generally considered today. Whether or not we see apostrophes or hyphens as letters seems irrelevant. Do you feel we should take a position? In that case, please give some argument indicating the relevance. --Lambiam12:34, 1 November 2018 (UTC)[reply]
For every word, someone must have been the first to use it. Apart from my dislike of Greek–Latin chimeras like tele- + vision – why not teleopsis? – I feel that the Greek prefix an- carries a connotation of lacking and not merely negation. For example, since one cannot reasonably say that the word “sock” is lacking an apostrophe, one should not label it as anapostrophic. In fact, since it is not lacking an apostrophe, it is non-anapostrophic :). --Lambiam23:39, 1 November 2018 (UTC)[reply]
@Lambiam: Everyone is free to make up words, but it's important that those who read them can understand them. Simple prose is often best, and "without an apostrophe" would have been understood by everyone. — Paul G (talk) 07:51, 3 November 2018 (UTC)[reply]
Dictionary-only diacritics need to be documented better
Currently, where we do document dictionary-only diacritics, it's usually on the WT:About (language) page. But those pages seem to be primarily aimed at editors for a particular language, and are probably rather hard to read for people who merely read Wiktionary. I therefore think that these concerns should be separated more clearly: one page to document the reader-facing parts of Wiktionary, and another to document what editors need to know in addition. A paper dictionary would usually document its conventions somewhere in the prologue, so we should have something equivalent. Given that our namespace convention so far is to use Wiktionary: for editors and Appendix: for readers, Appendix: seems like the logical choice. However, Help: is also a good candidate, and is not used as much as it should be currently. —Rua (mew) 14:12, 1 November 2018 (UTC)[reply]
I would like to suggest that we have a User's Guide for each language (shortcut U+language code), giving the kind of information that one would find in the introduction to an English-language dictionary or lexicon for that language. That would be a good place for explaining practices like which form is the lemma, what we don't cover (things like forms with clitics like 's or Latin -que) and other features that need to be understood to use the entries, like the difference between attributive nouns and adjectives in English. We would need to develop a standard format and some ground rules to keep them from turning into reference grammars or verbose essays, but I think it would be worth the effort. Chuck Entz (talk) 04:21, 4 November 2018 (UTC)[reply]
I think something like Help:English would be a good name. Alternative names for the language can be redirects, and ambiguous names can be "disambiguation" pages. —Rua (mew) 11:49, 6 November 2018 (UTC)[reply]
Adding information about historical inflections for Japanese entries
For verbs (conjugations, more specifically than inflections), I believe the {{ja-verb}} template already supports type=yo for yodan verbs, as well as ni, kami ni, and shimo ni for the nidan verbs. Granted, this isn't yet documented anywhere besides the module code itself, which is not ideal. I've added or edited a few verb entries where I've used these type values; see the relevant subcategories at Category:Japanese_verbs.
I'm not sure what you mean by "ra, na, ka and sa inflection". What part of speech are you referencing? I'm used to さ(sa) as the nominalizing adjective suffix that is a rough equivalent of English-ness, but I suspect you're talking about something else?
Re: -ku and -shiku adjective types, we haven't had occasion yet to build out those paradigms -- these are largely gone from modern Japanese, although they are widely known and occasionally used to deliberately archaic effect. See, for instance, that scene in the Ghibli movie Spirited Away when Sen saves the "stink god" who turns out to be the god of a polluted river -- at the end of his big reveal, he says, 良きかな (yoki ka na, “that's better, isn't it”) and disappears.
Re: せず, that form is already accounted for -- see する#Conjugation, in particular the Negative continuative row. Granted, the ず ending is also used as a terminal form in formal modern Japanese; however, I'm not sure if a per-entry conjugation table is the best place to treat such stylistic and usage information...
More broadly, we (Wiktionary JA editors) are collectively still in a bit of a muddle about what to do with these aspects of the language -- as you note, many of these constructions are still productive in limited fashion, and thus don't really belong to a wholly different stage of the language in quite the same way that Middle English is differentiated from modern English. We've batted around ideas of setting up "Classical Japanese" or some such as a new L2 "language". But there's no lang code, we're unclear on how to differentiate, and there's potential for tons of duplication -- some verbs are no longer in common use and linger on as yodan paradigms, while others are modern godan verbs that evolved regularly from earlier yodan forms → would we have "Classical Japanese" entries for both? Or only for the yodan-only verbs? Etc. etc.
Setting aside the bigger issue of our overall approach to earlier Japanese grammar, it'd be helpful for starters if you could explain what you mean by "ra, na, ka and sa inflection". ‑‑ Eiríkr Útlendi │Tala við mig00:15, 7 November 2018 (UTC)[reply]
I mainly suggest we give two inflection tables, one modern and one archaic/classical, for every Japanese entry, e.g. 燃える: 燃え 燃え 燃える 燃える 燃えれ 燃えよ and 燃え 燃え 燃ゆ 燃ゆる 燃ゆれ 燃えよ. I think this is not hard.
"ra, na, ka and sa inflection" are archaic/classical irregular inflections, e.g. 死ぬ: 死な 死に 死ぬ 死ぬる 死ぬれ 死ね.
@Huhu9001 -- Re: the irregulars, ah, yes, now I've got you. For 死ぬ, for instance, that's more formally called called the ナ行変格活用(na-gyō henkaku katsuyō, “na-row irregular conjugation”). Only two verbs exhibited that pattern, 死ぬ(shinu, “to die”) and 往ぬ / 去ぬ(inu, “to go away”, obsolete), with scholars apparently undecided on whether shinu might derive from inu, thus suggesting only one underlying verb with this paradigm.
Re: adding two inflection tables to all modern verbs, I'm not sure I can agree with that. For instance, the classical terminal (i.e. dictionary) form of modern terminal-form 燃える(moeru) is 燃ゆ(moyu): the lemma form is different for certain verb classes. Additionally, various verbs spelled -える in the modern language, such as 変える(kaeru, “to change something”), were spelled -へる before the spelling reforms of the 20th century, tracing back to terminal (lemma) forms ending in -ふ. Wiktionary practice, as I've understood it, is for conjugation tables and other detailed information to go in the entry for the lemma form of a word.
We don't seem to have any consensus at present for building out a whole new L2 language as "Classical Japanese" or something along those lines. As such, it seems to me more like the conjugation tables for the older paradigms should go collectively on the WT:AJA page, or somewhere similar, rather than on each entry page. Would that be acceptable? ‑‑ Eiríkr Útlendi │Tala við mig20:03, 7 November 2018 (UTC)[reply]
Putting the classical form in {{ja-pron}} seems really weird -- the pronunciation template is intended to show the pronunciation of the headword. The example above ... hides the pronunciation, which seems confusing and poor usability. Also, /moju/ is not a pronunciation of 燃える(moeru, “to burn”, intransitive). Likewise, conjugation type, historical kana spellings, and romanization schemes do not belong in this template. I'd be fine if some other template were created for this purpose, but {{ja-pron}} is not the place for this.
(Separately, I'm confused by the comment, "what about dropping the inflection templates", since the example above ... includes the inflection templates?)
I'm resistant to the idea of conjugating 燃ゆ in the 燃える entry. The Ancient Greek example does not seem germane here; τελῶ(telô) appears to be simply a contemporaneous contraction of τελέω(teléō), and it looks like the editors collapsed the information about the former into the entry for the latter as an exceptional case. For classical Japanese, we're talking instead about every verb in sizable verb classes.
That said, I'd like to survey other dictionaries, get a handle on their approaches. Let me chew on this a bit (where to put classical conjugations).
@Eirikr: Thank you for your reply. By "what about dropping the inflection templates", I meant to make {{ja-pron}} generate the inflection tables, thus eliminating individual inflection templates such as {{ja-ichi}}. Here are some considerations.
Putting the historical kana spellings and the romanization schemes in headword templates might seem good at first, but when there are more than one parts of speech, they have to be duplicated, which is not ideal. The Korean pronunciation template {{ko-IPA}} includes romanizations, and the Chinese {{zh-pron}} includes not only romanizations but also Middle and Old Chinese, which can be comparable to historical kana spellings. Therefore I find it convenient for Japanese to follow the model of Korean and Chinese, which means putting the historical kana spellings and the romanizations in the pronunciation template.
As for inflection tables, I have no objection to having a separate "Inflection/Conjugation" section and templates, but making {{ja-pron}} take over that functionality is more convenient for editors, isn't it? Moreover, by doing so, phonetic information such as もえる (for 燃える), き.いろい, or |acc=0 can be directly used when generating the inflected forms, eliminating the need to copy them to the inflection templates.
燃ゆ and 燃える are pretty much the same lexeme if you consider what linguistics call the stem or the base: the former is /moje-/, and the latter is /moe-/, clearly regular development. The reason the dictionary form look different is because the modern 終止形 comes from the classical 連体形 and 二段動詞の一段化, both of which concern morphology only. Even in the traditional Japanese analysis, も・える（ア下一） is a direct reflex of classical も・ゆ（ヤ下二） too. Larger dictionaries such as 広辞苑, 大辞林, and 国語大辞典 are all diachronic and treat 上代 も古事記では甲ゆ, 中古 もゆ, and 中世 もゆる in the same entry as modern もえる, and I think we can follow the same approach too. --Dine2016 (talk) 16:04, 8 November 2018 (UTC)[reply]
I agree that ja-pron is not the appropriate place for such information. I can sympathize with the desire to include as much information as possible as readily as possible. But there is no direct link between historical inflection and pronunciation as such. I also keep thinking about a comment left some time ago at 'Feedback' where a user complained about having Etymology at the top of the entry because the user was not interested in Etymology. I think that there probably are a lot of users interested in pronunciation of Japanese lemmas, but probably far fewer interested in historical forms. In that case, putting those pieces of information together at the top of an entry may be frustrating. Furthermore, as others have pointed out, although there are reflexes of historical forms in the conjugation of some words, this is not the case for all words. In short, ja-pron is the wrong place for this information, if it is even desirable for all entries. Cnilep (talk) 04:05, 9 November 2018 (UTC)[reply]
Ok, thanks, I agree with the idea to limit the pronunciation section to the modern lemma form only and put inflections in a separate section below the definitions. What about creating a unified interface, for example {{ja-infl|もえる|v1|acc=0}} (for modern Japanese) and {{ltj-infl|もゆ|v2s}} (for Classical Japanese) and code the inflection rules in a module, instead of having a separate template for each inflection type? That will be easier to program and come with better extensibility, I think. --Dine2016 (talk) 06:17, 9 November 2018 (UTC)[reply]
@Eirikr: Putting the classical form (e.g. 燃ゆ for 燃える) in {{ja-pron}} was actually an idea from 日本国語大辞典, which has a 発音 section of entries that looked like this:
As can be seen, the classical 終止形 also has relevance in modern Japanese, with modern pronunciation, Tokyo accent, and Kyoto accent. A Reference Grammar of Japanese even identifies more conjugated forms borrowed from the literary language such as V-uru and V-uréba and give them modern accentuation, indicating their relevance to modern Japanese.
Since the pronunciation section already deals with two different forms: classical 終止形 (≒ modern 連体形) and the modern 終止形, I concluded that it would be convenient to deal with other forms there together. However, if the pronunciation deals with only these two forms, or better yet, only the modern 終止形, and other conjugated forms are listed in a “Conjugation”/“Inflection” section below the definitions with their pronunciation dealt with on their perspective entries, I'm totally fine with that, and it would be more logical as each entry deals with its own pronunciation.
@TAKASUGI Shinji On the other hand, I also agree that separating Ancient Japanese and Modern Japanese has advantages. The current entry ない has three lexemes; the first (suffix in 切ない、幼けない、ぎこちない) is no longer productive in Modern Japanese and is likely to confuse learners. Putting the first lexeme under the Ancient Japanese L2 header would surely be an improvement. --Dine2016 (talk) 11:33, 12 November 2018 (UTC)[reply]
This month is Wikipedia Asian Month and Tofeiku suggested we, wiktionarians, take part of this. So, we discussed in Meta about it, and we ends up with the proposal of working on traditional asian games such as go, hanafuda, xiangqi, shogi, mahjong. There is a lot of games but no category here, and we may also look at the vocabulary used in the game, such as the famous atari in go. So, it's part of LexiSession initiative, and we aim at showing interproject short term projects can be cool, so I hope you like the suggestion, and let us know what you improve around it! Noé15:40, 1 November 2018 (UTC)[reply]
I see that color has synonyms given immediately after each sense rather than in a separate section. Is this how we are doing synonyms now, or is this a permissible alternative method? Or should they be moved to the "Synonyms" section that is also on that page? — Paul G (talk) 07:47, 3 November 2018 (UTC)[reply]
In Northern Sami, there is technically no passive inflection, but many verbs have an accompanying passive verb. This passive verb is a full verb in every respect, and has its own infinitive, participles and can also have words derived from it. Moreover, the meaning can sometimes be somewhat idiosyncratic, and there is more than one way a passive verb could be formed. This makes it seem like it is a lemma in its own right. On the other hand, passive verbs are used very much productively to form passive sentences, and I've often found them missing from other dictionaries, which suggests they are also somewhat inflectional in nature like the North Germanic passive.
I'd like to know how to best treat these. Should they be given a full definition, as if they were a true lemma, or should they be defined with {{passive of}}? Should they appear in the inflection tables of verbs, or the "derived terms" section? —Rua (mew) 13:11, 5 November 2018 (UTC)[reply]
In Mongolian I use {{passive of}}/{{causative of}} but also add definitions below that if they don't obviously follow from the verb it is derived from. I use the usual verb lemma headword and they of course don't have an etymology section, but I stopped listing them in derived terms, with a possible exception for passives that have many derived forms themselves. Crom daba (talk) 21:44, 12 November 2018 (UTC)[reply]
Just curious whether anyone else has noticed the periodic vandalism (it looks like ignorance rather than malice) where the edit summaries strangely begin with "by", along the lines of "by adding it" or "by writing my name". What could be the cause of this odd grammar? Possibly some kind of automated translation? Equinox◑14:00, 5 November 2018 (UTC)[reply]
Greetings! The Project Grants program is accepting proposals until November 30 to fund both experimental and proven ideas such as research, offline outreach (including editathon series, workshops, etc), online organizing (including contests), or providing other support for community building for Wikimedia projects.
We offer the following resources to help you plan your project and complete a grant proposal:
It's strange that {{quote-meta}} accepts a |transliteration= param but doesn't auto-transliterate the way that {{ux}} does. Unless someone objects, I'll fix this and make it auto-transliterate. Benwing2 (talk) 02:47, 6 November 2018 (UTC)[reply]
Oppose - I think we should get away from having templates do this sort of thing. Any result which is unlikely to change often should be static text, which is better for the servers and better for anyone who might wish to use the underlying data in any context other than this wiki. If we could make the template subst in the transliteration automatically I would support that. - TheDaveRoss14:41, 6 November 2018 (UTC)[reply]
One would hope that such activity would be rare. And when it was required it can be done through via a bot just as easily as through module editing. - TheDaveRoss19:10, 6 November 2018 (UTC)[reply]
@TheDaveRoss: I don't understand your opposition. subst is always a preferred functionality for long transliterations but manual transliteration is also always an option for languages, which don't transliterate automatically or occasionally need it. It shouldn't be a showstopper for not implementing the auto-transliteration. Can you give an example where it's a bad idea?
Note that automatic transliteration for usage examples in Chinese, Japanese, Thai and Khmer exists but it's implementation is different from other non-Roman languages for known reasons. There's also an implementation for Korean with a few tricks, which make it different from the automated Korean transliteration. It would be hard or impossible to merge these three five into the common citation templates. --Anatoli T.(обсудить/вклад)22:34, 6 November 2018 (UTC)[reply]
I don't remember where I got the idea, but I use the quotation templates w/o giving them the actual text + templates like {{ja-usex}}. Perhaps doing this all the time would be more simple, and would avoid duplication of {{usex}} and {{quote}} functionality. —Suzukaze-c◇◇02:33, 7 November 2018 (UTC)[reply]
@Suzukaze-c: Well, that's what I mentioned in the side comments. These language-specific templates are far-more advanced and do a lot of great work but they don't necessarily have all the bits and pieces present in the other generic templates, such as categorisations of e.g. citations by language or parameters like year, URL, page number, etc. --Anatoli T.(обсудить/вклад)23:57, 7 November 2018 (UTC)[reply]
Right now this template has only one parameter, which is just plain text. This means that there is no actual standard format, the text could be written in any number of ways, which makes Wiktionary harder to parse for automated processes. I therefore propose to introduce a second parameter, so that the first and second give the start and end dates of use respectively. The second argument would be left empty if the sense is still in use. The format of these parameters would still need further standardisation, but it's a start. —Rua (mew) 13:20, 6 November 2018 (UTC)[reply]
I think that is a good idea. I am not sure it will ensure the values are standardized or machine readable, but it is a step in the right direction. Oh, and I think it should show still in use if the second argument is empty or missing. - TheDaveRoss14:44, 6 November 2018 (UTC)[reply]
Introducing a second parameter has no effect on whether the values are standardized. Sure, let's add a second parameter as a first step though. DTLHS (talk) 16:14, 6 November 2018 (UTC)[reply]
Splitting it into a from and a to date makes that part at least readable. You know, then, that each parameter only contains a single time description, rather than a range between two. My plan is to automatically add "from" before the first argument if there is no second, like the template's talk page suggests that people enter manually. The next step would be to make a module that parses each date and throws an error for a format it doesn't understand. —Rua (mew) 18:46, 6 November 2018 (UTC)[reply]
I vehemently oppose this effort as at best premature and probably wrong-headed.
We don't have the information to support the changes proposed, nor is such information likely to be forthcoming, especially not without risking COPYVIO.
At the very least could someone take the trouble to take a census of the information currently in {{defdate}}?. I have never understood how such proposals can be made without a fact base.
If we are to attempt to standardize the use of {{defdate}}, shouldn't we begin by agreeing on what is acceptable data.
I think "we don't have the information" is the main problem. If we lack it for most senses of most words, there seems little point in making things more complex than they are. Equinox◑19:51, 6 November 2018 (UTC)[reply]
Splitting it into from and to parameters might be good, but parsing dates and throwing errors for strange formats would essentially make this template useless for some ancient languages (I am thinking particularly of Egyptian here), as chronologies are uncertain and dates can usually only be narrowed down to specific dynasties, reigns, bodies of religious texts, etc. rather than centuries or years. Such usages need to be taken into account somehow. — Vorziblix (talk · contribs) 02:28, 7 November 2018 (UTC)[reply]
I have no objection on the face of it. When I created {{defdate}} it was really just to force the font size and square brackets, the actual text bit was always a more-or-less stopgap decision. I do think we are safer continuing to use centuries rather than specific years (in most languages – ancient extinct languages will have to do things differently), partly from lack of information and partly to avoid COPYVIO issues. Ƿidsiþ07:44, 7 November 2018 (UTC)[reply]
Tentative support. I quite like the idea (it bugs me that we vary between "c." and "century" and "Century", or "from" and "From", etc.). However, I'm hesitant about being too restrictive with this. Usually we give dates in terms of centuries, but occasionally we know the exact date something was coined, and it can be useful to give the specific date. We need to make sure that one can use "early", "mid-", "late" in descriptions, and it should be possible to add other notes as well, in case there is more complex information. Andrew Sheedy (talk) 18:51, 8 November 2018 (UTC)[reply]
Some format standardization seems appropriate, but will it be the same for English, Middle English, Old English, Torre Straits Creole, and Ancient Egyptian? DCDuring (talk) 18:57, 8 November 2018 (UTC)[reply]
I see no reason why the format itself wouldn't be the same most of the time (the meaning might be different (e.g. an Old English word might be marked as "from 10th century", meaning that it survived into Middle English, but not necessarily that it is used today). Ancient Egyptian, I suppose, might mention dynasties rather than centuries, or have more speculative dates, so I'm not sure if it could be forced into a regular format. It might be preferable to vote on a preferred format, rather than imposing it via a template. Andrew Sheedy (talk) 19:10, 8 November 2018 (UTC)[reply]
In the past, "Alternative forms" was allowed to be entered as a level 4 header under the lemma/part-of-speech header, instead of at level 3 above everything else. I want to do this with the Etymology header as well. It makes no sense to me that the etymology is structurally disconnected from the lemma it belongs to (both on level 3) or even that the lemma is subsumed under the etymology. Assigning etymology to lemma instead of lemma to etymology is much more sensible, and it's the structure that Wikidata's lexemes follow as well. My ultimate desire is to entirely abolish level 3 etymology sections, and especially numbered etymologies, but I think in the meantime the two formats can be allowed as alternatives like we already do with "Alternative forms". That way, there is no immediate need to change any entries, and those who want to can experiment with the new format.
For those who think etymology should be visually the first thing to appear in a lemma, before senses, keep in mind that this proposal is about the logical structure of the entries, not the visual ordering. If you want to preserve the ordering, then the only option that also has a sensible logical structure is to have senses under their own L4 header with the etymology L4 header immediately above, both with the lemma's L3 header as their parent. I'm open to this option, but I think senses should come before etymology, those are what users are mostly looking for and not etymologies. —Rua (mew) 19:42, 9 November 2018 (UTC)[reply]
So for the English entry set, for example, we would have the level 3 headers Verb, Noun, Adjective, Noun (2), Verb (2), each with potentially their own etymology and no possibility to group them? DTLHS (talk) 21:31, 9 November 2018 (UTC)[reply]
I agree with the idea. I just think we should do it all at once and not introduce a 3rd layout possibility that will probably stick around with the others for years. DTLHS (talk) 22:29, 9 November 2018 (UTC)[reply]
I was looking at leave as an example of how this would work out. @Rua, might you be inclined to create a trial page demonstrating the proposed new look for our perusal? (BTW, what is the point of the repeated use of heading in the labels for the first leave#Verb?) The proposal makes sense to me; it is also what is promised by the inscrutable passage in WT:ELE that states that “[a] key principle in ordering the headings and indentation levels is nesting”. As an aside, if we had a more structured way of marking up the entries, along the lines of {{entry|lemma=...|language=...|part_of_speech=...|...}}, somewhat similar to many of the citation templates, such sweeping changes could be effected in one swell foop. (See also the (much more modest) suggestion in Wiktionary:Beer parlour/2018/October#What about uniformise a little bit all Wiktionaries?.) --Lambiam08:22, 10 November 2018 (UTC)[reply]
I'm not opposed to this, but I don't like that closely related nouns and verbs will be no more closely grouped than completely unrelated homographs. I think if we make a change like this, there should be some way of linking them together (especially when one POS comes from another POS in English, and their etymologies are no more distinct than the etymologies of different senses under the same POS). Andrew Sheedy (talk) 18:49, 12 November 2018 (UTC)[reply]
Well, how do other dictionaries do it? I don't remember ever seeing a dictionary that gives special treatment to etymologically related words. —Rua (mew) 18:42, 13 November 2018 (UTC)[reply]
@Rua I don't use online dictionaries other than Wiktionary very much, but the way I usually see it in print dictionaries is that for different etymologies, the headword will be listed again (usually with a number, like a superscript 1, 2, etc.). Each headword is then followed by its various definitions, further grouped by part of speech. This is especially common with more inflected languages, I find, where homographs might have different genders. Andrew Sheedy (talk) 23:29, 13 November 2018 (UTC)[reply]
Even so, paper dictionaries don't normally give any etymology at all, so the idea of being "somewhat" related (e.g. from the same PIE root) is enough to justify a grouping. But on Wiktionary, we do give proper etymologies, and words that are related will still each have their own etymology. The verb sleep and the homographic noun have separate histories that each deserve their own etymology section. This is the same whether the history of the words is long or short (if the noun had been derived from the verb only in modern English, for example). My experience is that when multiple lemmas are grouped under a common etymology, this is almost always an error of omission and each one could be given its own etymology. One of them is always the older, and the other derived from the first, or something similar. So in a future situation where every lemma indeed does have its own proper etymology, each etymology section will have at most one lemma. What is there to gain from that layout then? —Rua (mew) 00:23, 14 November 2018 (UTC)[reply]
I definitely agree that it would be an improvement to give etymological information for each part of speech (as well as to better indicate the development of different senses over time). I still don't like that the first verb and noun sections of lay would be no more closely connected than they would be to any other senses. However, one possible compromise would be to adopt the same style as the French Wiktionary, and have only one etymology section, and have "Noun 1", "Verb 2", etc. headers. (See botte for an example of what I mean.)
I oppose etymologies following the definitions for the folowing reasons:
There's enough clutter as it is with all the -nyms, translations, derived terms, references, usage notes, etc. following the defs;
Many dictionaries begin with the etymology. Every print dictionary I've seen with etymological information has it before the defs;
Etyms are currently at the beginning of entries, and it would be far, far more work to place them all below defs than it would be to make the modification I am suggesting;
As has been mentioned, it's very easy to skip over information one doesn't care about, and far more confusing if there is inconsistency in the way information is presented, as there would be for some time if we tried to move etyms from where they are;
And finally, if all etymological information were to be put under one header, as I am suggesting, putting it at the very bottom of an entry would make it hard to find and not very clear. Andrew Sheedy (talk) 03:58, 14 November 2018 (UTC)[reply]
As I said in my first post, this proposal is about rectifying the logical structure of the entries. If you want the etymology to appear first, then it should still be nested under a header of some sort, so that it's clear that the etymology belongs to some word and doesn't stand entirely on its own. However, I think both that and the current structure are less desirable than the one I proposed, which simply nests etymology below part of speech and definitions. Definitions are primary, so they should come first.
I'm also opposed to the French structure, which is essentially what we used to do for synonyms and antonyms using the {{sense}} template. Each lemma has its own etymology, just like each sense has its own synonyms and antonyms, so separating them out makes no sense for the logical structure of an entry. —Rua (mew) 13:37, 14 November 2018 (UTC)[reply]
I like what you are trying to accomplish, but I think that not having etymologies as headers at all is the way to go. Page ordering and layout is currently logical, but has nothing to do with usability (except, perhaps, that English is the first language presented). While etymologies are very interesting, they are, at best, secondary information for most users. The fact that etymology is present before, and with more prominence, than definitions and translations is downright silly. I would have etymologies live in their own namespace, and transclude them at each relevant definition. I would have them displayed in the same manner as usage examples, hidden by default with a small link indicating their existence. Obviously that is not an easy transition to make. To be clear, I like what Rua is proposing more that the status quo and would support pursuing it further. - TheDaveRoss19:01, 13 November 2018 (UTC)[reply]
Why, heavy language learners sort the words by etymology. Older dictionaries mingle unrelated words to safe space in a confusing manner. I would still separate unrelated words spelled (with all diacritical marks, if applicable) the same as different lemmas even if they aren’t nested under etymologies. عقار looks totally fine. Not knowing the relation of the meanings of كُور(kūr) makes me uncomfortable. And as a dictionary aiming at depicting historical beginning with the etymology as the root of all things is obvious anyway. I can’t follow @Rua’s argument “It makes no sense to me (…) that the lemma is subsumed under the etymology.” – Umm that’s the way I imagine the words, so it makes sense to me?
If one uses this dictionary often, the consistent structure allows to learn where to put the eyes to get only the information one wants, so abundant etymologies can be overlooked with resolve (your own fault then if you read too much). People don’t care what is under what, they only care that things are always in the same order. Fay Freak (talk) 23:14, 13 November 2018 (UTC)[reply]
That last point is of course an argument for the change as well as against it. However, I made arguments in favour of a logical nesting structure as well, and that is not achieved with the current layout, but is with my proposal. So if all else is equal, logical nesting wins out. —Rua (mew) 00:11, 14 November 2018 (UTC)[reply]
Not sure how it’s for it, it seemed to me that you wanted to introduce a new order. However I do remove splitups into numbered etymology sections, often they are really nasty as on حرس, in this example even containing the identical references under each section, which I have lamentably perceived to be the “Benwing layout”. Sectioning needs more discretion. Notably, I have now put that pronunciation file between a lemma template and its header because somebody recording a pronunciation file does not lead me into banjaxing the whole layout based on this file. By the way the pronunciation section layout believed to be standard is too much based on “inflectionless languages” – there is no point in having such sections when words have many permutations and the lemma form is just one, particularly when the pronunciation in a language is certain based on spelling or transcription. Instead the tables should convert the Latin spellings to IPA with a click (like tables resort) and allow inclusion of audio files in parameters. @RuaFay Freak (talk) 16:27, 14 November 2018 (UTC)[reply]
@Fay Freak A problem I see with the current version of that Arabic entry, is that it's not possible to see how each of the words was formed. Surely, Arabic has well-developed methods of deriving words from roots, and it's not just a matter of "fill in some random vowels"? This is the kind of information that I would want to see in an etymology, and it's currently lacking. —Rua (mew) 12:44, 16 November 2018 (UTC)[reply]
I support the proposal. The "lateness" with which our entries get around to providing definitions is a recurring complaint from new and experienced users alike, on WT:FEED, entry talk pages, and even in other sections of this very subpage. I sympathise with the sentiment that this should be done all at once, though also with the original suggestion of allowing either format, like with alternative forms: most entries have only one POS and etymology, but for the few that have several etymologies, maybe the current setup is better. (Still, even switching all entries to nested/L4 etymologies would be better than the current setup, I think, if it were a choice between those two options.) Other online dictionaries I can think of also put etymologies after pronunciations and definitions. - -sche(discuss)17:02, 14 November 2018 (UTC)[reply]
I was ambivalent at first, but having thought some more, I also support the proposal. For words with multiple etymology headers, currently the POS is L4, while all its subheadings are L5 — but L4 is visually indistinguishable from L5, rendering the hierarchy confusing and unclear. While I think the loss of closer grouping for multiple headwords with similar etymologies is regrettable, it’s not that great a loss: those headwords will still directly follow each other, and their individual etymology sections will still indicate their close relation. While most print dictionaries have etymologies before definitions, most online dictionaries seem to have it the other way, so either choice seems find as far as precedent (and thus new users’ expectations) goes. I am, however, opposed to hiding etymologies in small links like usage examples, as they’re one of Wiktionary’s greatest strengths — from what I’ve read elsewhere, many users come to Wiktionary specifically to find etymological information — and also as etymologies don’t generally correspond to specific senses but to the whole headword. — Vorziblix (talk · contribs) 19:02, 14 November 2018 (UTC)[reply]
Can’t the distinguishability of L4 and L5 be tweaked in some CSS?
The rest I rather harmonize with, particularly the emphasis about similar etymologies: But what’s with leave’s different etymologies for noun and verb if the headwords are even more riven by translation sections? @Rua, you have not mentioned this. Fay Freak (talk) 19:11, 14 November 2018 (UTC)[reply]
That has been suggested before, and I would support it in principle. It would make the wikicode very hard to navigate though. —Rua (mew) 20:32, 14 November 2018 (UTC)[reply]
The problem is that ideally (in my head, and in all historical dictionaries), the definitions flow on from the etymology and so should come after it. But I do agree that it's normal to see at least some indication of the lemma and part of speech before any of that. In an ideal world, the inflection line would itself be the L3, with etymology and definitions coming below, but I realise this is probably unfeasible at this point. Ƿidsiþ08:47, 15 November 2018 (UTC)[reply]
I'm sorry, I have TLDR'd this, but just in case my point is relevant, I would like to say that I am strongly opposed to having top-level etymology heading splits for words (esp. parts of speech) that are closely etymologically related. I think this is immensely confusing for users, and that these splits should be reserved for words that are etymologically unrelated. If this is not on-topic, apologies, and please ignore. Mihia (talk) 17:34, 19 November 2018 (UTC)[reply]
But for what reasoning? As I mentioned to Benwing below, what if these words weren't spelled the same, and therefore were placed on different pages? Would it be equally confusing? —Rua (mew) 13:19, 20 November 2018 (UTC)[reply]
@Rua I am a bit late to this discussion, but IMO it's extremely important to be able to group etymologically related terms with different POS's under a given etymology. Print dictionaries do this, too; see for example https://books.google.com/books/about/Webster_s_New_World_Dictionary.html?id=wSISgTZ7xrQC&printsec=frontcover&source=kp_read_button#v=onepage&q&f=false on page 223 (for the word "fine") or pages 261-262 (for the word "ground"). For example, there are two entries for "fine", labeled "fine1" (= good, well) and "fine2" (= penalty); "fine1" has two POS's under it (adj. and adv.) and "fine2" also has two POS's under it (n. and vt.). I also distinctly remember there being four etymological entries for "flag", each with its own etymology and multiple POS's at least under "flag1". In Russian entries we also rely on this, even though it's less common to have multiple related POS's under the same lemma; see хвата́ть(xvatátʹ) for an example. Benwing2 (talk) 02:12, 20 November 2018 (UTC)[reply]
But under what conditions do both parts of speech have the same etymology? If they both existed in Middle English, then one of them derives from each Middle English part of speech, so the etymologies are different. If they were both formed in modern English, then did they both pop into existence at the same time, or was one of them first, and the second derived from the first? Once you start looking at such details you realise that two different parts of speech never have the exact, word-for-word same etymology. And given that assumption, it means that every etymology section will only have one part of speech, in which case my proposal makes more sense anyway. —Rua (mew) 12:59, 20 November 2018 (UTC)[reply]
Also, consider the case where all those different parts of speech on fine all had different lemma forms, too. What would their etymologies be then? I am a strong supporter of the principle that entries should be independent of the chosen lemma form and independent of the existence of other entries that happen to be spelled the same. So I would write the etymologies for each part of speech of fine the same way I would if they were all on different pages instead. I don't think we should be omitting etymological information just because certain words are homographs. Each lemma should stand on its own. —Rua (mew) 13:18, 20 November 2018 (UTC)[reply]
To give a case in point for my argument that homography of lemma forms should not affect etymologies: In Dutch there is the noun adem(“breath”) and the verb ademen(“to breathe”). Both of these have a form in common, namely the singular of the noun is homographic with the first-person singular present indicative and the imperative of the verb. This means that, given a different course of history, the lemma form of both could have been adem and it is just a historical accident that the lemma forms are different. Yet, as you can see, these two lemmas have different etymologies. If the lemma forms were the same, would you keep the two etymologies split, like they are now, or would you merge them like some people do now for English, thereby omitting information that is currently present in Wiktionary, just because the lemmas are homographs? This is why I'm strongly opposed to merging etymologies of related words. The etymologies aren't the same, you're just pretending they are by omitting the information that makes them different. —Rua (mew) 13:31, 20 November 2018 (UTC)[reply]
Although I am not technically knowledgeable about etymologies, I can see that different POS of the "same word" might (and probably do) need different, or at least slightly diverging, etymology explanations, and I absolutely agree that these should be included (given that etymologies are potentially long and technical, and the detail may not be of interest to all users, whether they need to be so prominent at the top of articles is a different question). However, I think this can be readily achieved within one top-level section. For words that are "sufficiently closely related" I advocate this kind of approach:
Etymology
Noun from ... blah blah ... ; Verb from ... blah blah ...
There are two languages that are currently sharing the tag K'iche', the modern variety spelled "K'iche'", and the Classical variety, "Quiché". The Classical Variety is written in documents from the 1600's, and differs from the modern variety; for example: the Classical Quiche word for food is tioh, and its modern descendant is ti'ij. I have created the category "Classical K'iche'" to sort the Classical words from the Modern. We should change the tag "quc" tag or change the word headings to Classical K'iche' to avoid confusion. Aearthrise (𓂀) 14:19, 10 November 2018 (UTC)[reply]
Would it be possible to trace some notion similar to etymology for phrasal verbs? Otherwise, what relevant lexicographic information could be added? --Backinstadiums (talk) 18:10, 10 November 2018 (UTC)[reply]
I've made a few etymologies for phrasal verbs (I can't seem to actually find an example at the moment though...) where it was possible that the verb + adverb was derived from an inflected or imperative form of an earlier separable-prefix type verb (similar in Dutch and German) in Middle English, like come up from upcomen. We still have upcome however which is fading away in favour of its replacement, and it's possible that the adjective upcoming may be a relic of the earlier verb's present participle. I'll keep looking for an example I've actually worked. Additionally, there may also be the kind mentioned by Backinstadiums where the verb has been supplemented (translated?) from an earlier synonymous verb with a different structure. Those are more difficult to prove a connection to IMO, but is possible that a move from for- + verb to verb + up (compare also for be- + verb to verb + about) was made across multiple verbs at one time. I haven't really read anything (yet) stating that was the case. Leasnam (talk) 21:30, 10 November 2018 (UTC)[reply]
There's nothing in that article that says that phrasal verbs are direct descendants in an etymological sense of anything in Old English. They're a different construction that replaced the prefixed-verb construction and filled in the same "slots", just as the gerund replaced many uses of the infinitive. Referring to one as the "ancestor" of the other seems to be strictly a metaphor, and not something to be cited in an etymology. I would say that the replacement of Old Englishforbrecan with Englishbreak up is just applying a different, but equivalent construction to the same verb- Englishup and Old Englishfor- aren't related in any etymological sense, and one isn't a descendant of the other. Chuck Entz (talk) 01:29, 11 November 2018 (UTC)[reply]
@Chuck Entz, I would agree with you...there is no etymological connection between forbrecan and break up. Break up simply replaces OE forbrecan/ME forbreken/ModE forbreak with a newly constructed word: break upLeasnam (talk) 08:21, 11 November 2018 (UTC)[reply]
@Backinstadiums I suppose then the answer is simply: not much. You could list the Middle English or Old English word for comparison, but that does little except show that those languages had a synonymous term for whatever the new English term is. In cases where the change-over is regular, like a note showing break up replacing earlier forbreak might be interesting (and we do this often when a French word displaces a native word)...but it also can add unnecessary clutter. Leasnam (talk) 18:50, 11 November 2018 (UTC)[reply]
As far as I can tell, Proto-Germanic had no phrasal verbs. All it had were verbs prefixed by various (unstressed!) adverbs, and verb+adverb phrases like they still exist in English. This is the situation that's found in Gothic. The prefixed verbs have become relics in modern English, and the verb+adverb combinations have taken over. The separable verbs of Dutch and German arose from those same verb+adverb combinations, but the quirks of OV+V2 word order in those languages mean that the verb is sometimes after the adverb (OV) and sometimes before (V2). English has VO word order, so there is no need for separable verbs; the same situation is found in other Germanic languages with VO order, such as Swedish. —Rua (mew) 22:53, 10 November 2018 (UTC)[reply]
Change coming to how certain templates will appear on the mobile web
Change coming to how certain templates will appear on the mobile web
Please help translate to your language
Example of improvements
Hello,
In a few weeks the Readers web team will be changing how some templates look on the mobile web site. We will make these templates more noticeable when viewing the article. We ask for your help in updating any templates that don't look correct.
What kind of templates? Specifically templates that notify readers and contributors about issues with the content of an article – the text and information in the article. Examples like Template:Unreferenced or Template:More citations needed. Right now these notifications are hidden behind a link under the title of an article. We will format templates like these (mostly those that use Template:Ambox or message box templates in general) to show a short summary under the page title. You can tap on the "Learn more" link to get more information.
Please take a look at policy and imagine this is your first time here.
Our article layout makes (especially but not only longer pages in) our dictionary very user unfriendly or even unusable for most people because we don't have the policy of listing the rare and obsolete meanings last, as most or all other good modern dictionaries now do.
In addition, we need a better UI that puts meanings with different etymologies close to each other. Most people never find the only other common meaning of the noun "policy" because it's physically so far away, and confusingly after the verb with the first etymology.
Etymologies are wonderful and one of the strengths of this dictionary, but they should be folded away (like the quotations are now) instead of confusing users and preventing them from finding what they're looking for (or, in fact, ever coming back). --Espoo (talk) 05:57, 14 November 2018 (UTC)[reply]
I disagree that etymologies should be hidden by default, but I do think that we should organized definitions by how common they are, and/or by their relation to each other, and include information about historical development in the etymology. Andrew Sheedy (talk) 12:56, 14 November 2018 (UTC)[reply]
I definitely agree that an obsolete sense should never be the first sense listed, unless there are only obsolete senses. —Rua (mew) 13:31, 14 November 2018 (UTC)[reply]
I disagree. I think earliest senses should be first, including when they're obsolete, as in any historical dictionary (which Wiktionary is, like it or not). Ƿidsiþ14:42, 14 November 2018 (UTC)[reply]
Currently entries have a chronological logic, hence first the origin, then the (known or presumed) first or original senses. That’s useful for historical reading. Often one can also group meanings in abstract formulation (so field) to make pages more readable. Frequency is also a criterion however, and it does not exclude counting historical usage. One just has to look if one thinks the result looks best. On policy one may perhaps try grouping. Fay Freak (talk) 14:50, 14 November 2018 (UTC)[reply]
I have no objections to a historical ordering of definitions, personally, but if we're going to do it, we should do it consistently, and recognize that mainstream users are not our target audience. I doubt Wiktionary will ever be a truly valuable resource for the average person, unless other dictionaries go out of business or something. We're much better off tailoring ourselves towards people with an interest in language. Andrew Sheedy (talk) 18:34, 14 November 2018 (UTC)[reply]
To be honest I agree. Serious dictionaries are not really ideal for casual users looking up common meanings of slightly uncommon words. On the other hand, there are ways that could be tried. For instance, we could order things historically but slightly "grey out" the obsolete senses, and/or perhaps "highlight" or "star" in some way the most common ones. Ƿidsiþ08:37, 15 November 2018 (UTC)[reply]
"Currently entries have a chronological logic" They certainly do not- that is promulgated by certain users but by no means universal in practice or required. DTLHS (talk) 18:36, 14 November 2018 (UTC)[reply]
Aye that’s what I said. They just have it. Not exclusively. Also frequential and topical or abstract grouping is done and of course no or arbitrary grouping in many entries. This dictionary is driven by fancy. Fay Freak (talk) 18:49, 14 November 2018 (UTC)[reply]
Apropos of one or two of the comments above, I would be disappointed if Wiktionary did not aspire to be accessible to mainstream users, or at least "upper mainstream" users. I would consider myself a upper-ish mainstream dictionary user, certainly not a linguist or language expert, and I find myself increasingly using Wiktionary as a go-to dictionary for practical purposes. Partly this is because of the absence of ads and extraneous crap, and partly because of its breadth of coverage and the pretty good quality of a large part (not all) of its content. Personally I disagree with the chronological order approach, and the consequent risk of obsolete senses appearing first, though I understand the reasons why some people advocate this approach. In an ideal world, in my opinion, definitions should by default appear with common modern senses first and/or in "logical" order, but each definition would have a "first recorded use" date attached, and there would be a function for users to sort by that if they desired. Obviously it would be a huge task to implement that across the project. Mihia (talk) 23:05, 17 November 2018 (UTC)[reply]
I've suggested that before, but I think it's a distant dream at this point... Maybe in 20 years, when people have nothing better to do here than adding {{defdate}} to entries. Andrew Sheedy (talk) 23:53, 17 November 2018 (UTC)[reply]
It just doesn't work for entries with dozens or hundreds of senses, and besides, having "common modern" senses first is not the same as a "logical" order. The most common use of "mouse" for most people now is a piece of computer technology, but it would surely seem bizarre to list it first. Historical ordering is the only system that has any data-based logic to it, and it also helps explain the sense-development of a word, which should be one of the main jobs of a dictionary – see something like bead for a simple example. But I agree it would be nice if, for instance, obsolete senses could be "greyed-out" or something, or maybe if very common senses could be highlighted somehow. Ƿidsiþ08:44, 19 November 2018 (UTC)[reply]
When you say "it just doesn't work", "it" refers to putting "common modern senses first and/or in "logical" order", right? (I initially replied thinking that it referred to the idea of having a user sort function.) Mihia (talk) 17:50, 19 November 2018 (UTC)[reply]
I do not see why "common modern senses first and/or logical order" does not work for long entries. Of course, unlike chronological order, it does not provide a unique ordering. It is to some extent a matter of opinion how senses are grouped and ordered. However, I don't think, in my somewhat limited experience here, that I can recall any serious dispute between people about this issue (I mean, assuming that "common modern senses first and/or logical order" is to be followed, a dispute about how entries should be ordered under that scheme). I think in the majority of cases there will be broad acceptance across a moderately flexible spectrum of orderings. By the way, I did not intend to suggest that "common modern senses first" and "logical order" were always the same thing. In fact, "and/or" was supposed to indicate exactly the opposite. For example, if a long entry is split into subgroupings A, B, C, etc., and A contains common senses, but a less common one should also "logically" go in that grouping, rather than further down the list, then fine, that can be accommodated. Mihia (talk) 22:56, 20 November 2018 (UTC)[reply]
Well, what's the commonest meaning of set? Or put? How do you quantify it? As for logical groupings using subsenses, I see what you mean and yes, that is also done with historical ordering too – each main logical "group" is organised chronologically but related senses are then kept together. See for instance mark, Etymology 1. Ƿidsiþ09:20, 21 November 2018 (UTC)[reply]
Finding the single commonest meaning of a highly polysemous word may be difficult, but there is no difficulty in putting all archaic/obsolete senses after all those that are not. Equinox◑11:23, 21 November 2018 (UTC)[reply]
I don't personally think that "common modern meanings first and/or logical order" requires us to exactly quantify "commonest". My feeling, as I say, is that there is a fair degree of flexibility. I think that, under this scheme, most people would be happy most of the time with anything that seems "sensible". Mihia (talk) 18:41, 21 November 2018 (UTC)[reply]
I originally supported ordering senses by date, and I appreciate that this helps show how senses developed, but I now agree that putting obsolete senses first is unhelpful to people who turn to the dictionary for the unlikely</sarcasam> purpose of learning what the word means (present tense). (It also precisely doesn't show how senses developed, whenever a 'bridging' sense obviously must have existed between two senses but doesn't have surviving attestations until later.) On polysemous entries I've overhauled like take or know or absolute, I've used a "logical order", and this is indeed (as Mihia says) easier to do a de-facto-acceptable job of than some people think: I haven't tried to ascertain which common sense is exactly most common, just started with a common basic sense and ordered other common senses after it "logically" based on (synchronic) semantic similarity/development, which people have found acceptable and indeed liked enough that they've asked me to overhaul other entries. Greying-out obsolete senses is an interesting idea, and I'd like to see it mocked up; perhaps it wold help, though it might be tricky to make the greying-out sufficiently noticeable without making it so light as to make the text hard to read; or, if grey background/highlighting were used, it might perversely highlight those senses (but maybe that wouldn't actually be a problem / confuse anyone). Also, as someone (Ruakh?) pointed out about an earlier idea in that vein, editors' decision of whether to mark something as obsolete vs archaic vs dated might then be influenced by whether or not they thought it was important enough to deserve 'full' display (although that seems entirely manageable / relatively easy to fight/fix). - -sche(discuss)17:12, 21 November 2018 (UTC)[reply]
Yes, this seems like the right approach to me. Don't worry about precisely which sense is most common, but in principle do put the "common sense" current uses early in the list. Other senses can be ordered "logically", whether that be by synchronic similarity or diachronic evolution. This will, of course, always be imperfect and controversial, as people don't all share one idea of "common sense" or "logic" in this sense, but the difficulties seem workable. Also, I would support making etymologies collapsible. I don't have a strong preference for whether they should be collapsed by default – whether showing them should be opt-in or opt-out – but whichever version is the default, the other should be readily opt-able. Cnilep (talk)
According to the present policy, Pinyin romanisations of monosyllables and polysyllables for Standard Mandarin (aka Putonghua), such as "yī" and "bùguò" are allowed. However, for Standard Cantonese, only Jyutping romanisations of monosyllables of monosyllables are allowed (e.g. jyut6, ping3), while those of polysyllables are disallowed. Why is there such unequal treatments for the two languages? I believe that Jyutping romanisations of polysyllables should be allowed and massly created, as Pinyin romanisations of polysyllables are allowed and exist in a large quantity. Jonashtand (talk) 15:59, 16 November 2018 (UTC)[reply]
According to WT:EL, the "Further reading" heading should be level 3, placed below all the lemmas. But there is always further reading about something. I doubt you'll find many cases where you find further reading material about all words spelled X, but instead you would find material about a particular lemma. To me, it therefore makes more sense to treat this as a level 4 header, and nest it underneath the lemma to which it applies. This is also useful in the interest of machine readability, because a bot can't tell which information belongs to which lemma if it's all put together under the same section. —Rua (mew) 11:57, 17 November 2018 (UTC)[reply]
I agree this makes more sense. In those cases where there are several lemmas for a given language and the further reading happens to apply to all, it should remain at the L3 level, though. --Lambiam07:45, 18 November 2018 (UTC)[reply]
Probably we should, in general, attach extra info to the deepest common node of all lemmas to which it applies, so as to avoid duplication while remaining otherwise as specific as possible. But there may always be exceptions to the general rule, based on considerations of common sense. --Lambiam06:28, 19 November 2018 (UTC)[reply]
I suppose the same should apply to References, Derived terms, Related terms, See also. Perhaps we should follow the example of Synonyms and place the items under appropriate senses and/or subsenses. DCDuring (talk) 16:36, 18 November 2018 (UTC)[reply]
If the “Further reading” section is on L3 it apparently applies to the whole language section – the machine-readability part is a strawman. And indeed in many cases one finds reading material about words spelled X, like general Arabic dictionaries include words spelled a certain way. And in general my impression is that the links and references are detached from the lemmata and I have an aesthetical aversion to “further reading” placed on L4; it clutters. When I prefer a layout it is to make it palatable to the eyes and not because it is most logical. Like with map projection you must bid farewell to the notion that you could project the reality of language in a truest way into the two-dimensional space of a reference work. Fay Freak (talk) 01:40, 19 November 2018 (UTC)[reply]
I prefer Further reading at L3 rather than L4; it makes the page less cluttered and makes it easier for me to find the further reading since it is at a predictable location at the end of a language section. --Dan Polansky (talk) 09:31, 25 November 2018 (UTC)[reply]
Stumbled across the layouts of zenith and nadir just now (see synonyms and antonyms specifically). This is not the WT:ELE standard layout, but I do like it. Has this been discussed before? Especially if the synonyms and antonyms become collapsible this would be my strong preference. @Jberkel as the editor in question. - TheDaveRoss15:25, 19 November 2018 (UTC)[reply]
Thanks for sharing that. While I appreciate being able to have a better personal experience, I also think that it this would be a better experience for the 24 million other people who will view the site this month. I appreciate the thought Rua has been putting into the user experience tweaks, it would be great if we could collectively put some additional thought and effort into that front. - TheDaveRoss13:11, 20 November 2018 (UTC)[reply]
The general practice among dictionaries of these old languages is to use k and never c, when spelling normalisation is applied. Our own entries mostly follow that practice. But when you look at how these languages are actually written, you find that c is the norm, and k is only used before e or i. This is the standard that's used for Middle Dutch normalisation on Wiktionary, but not for Old Dutch, which is a bit strange. For example, look at the various attested spellings of drinkan, fisk, folk, kraft, kuning and sprekan. There are some forms with k, but c is definitely in the majority. In the case of kwethan, there's not a single attestation with a k. So I think it would make more sense to use the forms with c as the lemmas on Wiktionary, at least for Old Dutch. What is the situation for Old Saxon and Old High German? —Rua (mew) 20:30, 19 November 2018 (UTC)[reply]
Personally, I would say whatever form is most commonly attested for each individual word should be the form used for the wikt entry. I'm not a fan of fabricating standardized forms that never actually existed. --Victar (talk) 05:42, 21 November 2018 (UTC)[reply]
But what if the fabricated form itself is standard in the field? Grammars of these languages, Old Norse in particular, use only normalised spellings. We'd be doing a disservice to people studying these languages if we included them in an orthography that's incomprehensible to them. —Rua (mew) 12:19, 21 November 2018 (UTC)[reply]
I agree... and therefore also think that, iff we did move words to c, we would probably need to leave soft redirects from the "normal normalization" (if it is indeed widespread in literature, and thus the form someone would see and look up), as Widsith suggests. - -sche(discuss)17:02, 23 November 2018 (UTC)[reply]
The study of these languages isn't as widespread as, say, Old Norse or Old English. It's probably mostly confined to people in the Netherlands and Germany who want to learn about the history of their language. This means that the norms are less firmly established overall. Philippa's Dutch etymological dictionary gives this: "Onl. kuning ‘heerser, vorst’ in cuninga tharsis in alende geuon bringon sulun ‘de koningen van Tarsis en de eilanden zullen geschenken brengen’", with the lemma cited with k, but then c in the actual citation. Personally, I find normalisation invaluable, because it helps people studying the grammar and vocabulary by getting rid of variations that don't actually matter. At the same time, the use of normalisation into spellings that aren't used in texts is strange, because then you have to include all actually attested forms as alternative spellings. I suppose if these spellings with k are standard in reference works, then we have to stick with them, even if I wish they'd chosen a different normalisation scheme. For Old Dutch, it gives the impression that Old Dutch writers followed different spelling norms regarding the use of c, k and q than Middle Dutch writers, when that isn't actually the case. —Rua (mew) 11:33, 24 November 2018 (UTC)[reply]
Generally it's better to have the best-attested form as the lemma, but there may be conventions with some languages which make this undesirable, especially if a language is not well attested overall. If all reference works cite "kwethan" then there is a logic to lemmatising it here. But in the end it doesn't really matter, as long as C-forms and K-forms are both here and one of them acts as a soft redirect to the other. Ƿidsiþ07:48, 23 November 2018 (UTC)[reply]
@Rua, I see you moved over a dozen or so Old Dutch entries to c-normalized forms, but without redirects. I'm with @-sche and @Widsith, and think if dictionaries list a k-normalized form, we should have a redirect from it. --Victar (talk) 20:22, 26 November 2018 (UTC)[reply]
I'd like to recommend changing the inline formatting of {{usex}} from:
वृषणं धीभिर अप्तुरं सोमम ऋतस्य धारया । मती विप्राः सम अस्वरन ॥ ― vṛ́ṣaṇaṃ dhībhír aptúraṃ sómam ṛtásya dhā́rayā । matī́ víprāḥ sám asvaran ॥ ― To the water-crossing bull, Soma, in a stream of truth have the inspired poets cried out in unison with their insights, their thought.
यस्त्वेतान्युपक्ल्प्तानि द्रव्याणि स्तेनयेन्नरः ― yastvetānyupaklptāni dravyāṇi stenayennaraḥ ― (please add an English translation of this quotation)
to:
वृषणं धीभिर अप्तुरं सोमम ऋतस्य धारया । मती विप्राः सम अस्वरन ॥(vṛ́ṣaṇaṃ dhībhír aptúraṃ sómam ṛtásya dhā́rayā । matī́ víprāḥ sám asvaran ॥, “To the water-crossing bull, Soma, in a stream of truth have the inspired poets cried out in unison with their insights, their thought.”)
I object. A usex is not a list so it's not clear to me why we should use the same formatting. In a list, the translation and transliteration are truly parenthetical. In a usage example they are much more important. DTLHS (talk) 03:16, 21 November 2018 (UTC)[reply]
@DTLHS:, I'm sorry, what do you mean by "not a list" and why's it relative? I'm not sure also why a transliteration and translation wouldn't be parenthetical to the given sentence. --Victar (talk) 03:38, 21 November 2018 (UTC)[reply]
Go for it. No reason to misuse mdashes and this is actually a more logical way to do things. But please do not misuse HTML5's <small> tag: it is for fine print. There's no need for small text at all, as this isn't a print encyclopedia. —Justin (koavf)❤T☮C☺M☯05:15, 21 November 2018 (UTC)[reply]
Throwing another 2p in the pot, I very much prefer the italics for romanizations, as that immediately and obviously sets the romanization apart from the translation. It's much easier to visually parse.
Thanks for your input, @Eirikr. To counter your two points:
If you recall, we recently had a whole debate and subsequent vote about the italicization of transcriptions in {{l}}, and the consensus in the end was that a) italicized transcriptions are more difficult to read, particularly with special ligatures, and b) it causes a loss of data in language transcription systems that use italicization as a means of distinction, such as seen in Hittite.
Em dash as a separator can be very problematic in texts that actually use dashes. For instance, in Rigvedic transcription, dashes are used very heavily to break up sentences. Parenthesis are also good at making it clear that everything within the parentheses is related to the previous sentence. --Victar (talk) 19:09, 21 November 2018 (UTC)[reply]
FWIW, I ultimately came to disagree then with a blanket approach to changing italicization, and I disagree more now after dealing with some messy fallout from related changes. There were blanket assertions that "italicized transcriptions are more difficult to read", but those were largely subjective statements limited to specific people and specific contexts -- I have encountered no such difficulty myself in working with Japanese, and I've found instead that non-italicized transcriptions can be visually confusing. Granted, I am fully aware that this is specific to my work with Japanese. One idea floated on the vote's talk page was having language-specific settings. I suspect that might still be the better route. ‑‑ Eiríkr Útlendi │Tala við mig19:39, 21 November 2018 (UTC)[reply]
Definite oppose. I think the way it looks know is pretty much perfect. It's easy to parse, thanks to transliterations being set apart from the example sentence, and the translations being set apart from the translaterations. And because the latter are italicized. Parentheses and quotation marks don't do that, and end up squishing everything together. Not to mention that in longer examples like the ones you give, its better if they're on different lines, in which case it makes little sense to add quotation marks and parentheses. Not to mention that people have not used the template in many entries, and the format they usually use is fairly consistent with the current format of the template, so changing what {{usex}} displays would create a lot of inconsistency. Andrew Sheedy (talk) 18:18, 21 November 2018 (UTC)[reply]
@Andrew Sheedy see my remarks regarding italicization and the use of dashes above. I want to make it doubly clear, I'm only talking about inline formatting when |inline=1 is used. When not used, the formatting would be the same as it is currently, on multiple lines. --Victar (talk) 19:09, 21 November 2018 (UTC)[reply]
Okay the current formatting looks goofy when one actually uses the quotation dash U+2015 the way it is devised for. So as I just have written:
Indefinite: Haben wir noch Zwiebeln? ― Es gibt noch welche im Keller. ― Do we have any onions yet? ― There are some in the cellar.
Haben wir noch Spinat? ― Es gibt noch welchen im Gefrierfach. ― Do we have spinach yet? ― There is some in the freezer.
Haben wir Streichhölzer? ― Ich hab eins / eines hier gesehen. ― Do we have matches? ― Ich have seen one over here.
We should use an obelism, which would be in Unicode apparently ÷ U+00F7 DIVISION SIGN, or perhaps ⁜ U+205C DOTTED CROSS. I want the one the left of that image. Such is found as a mark of conclusion in medieval and early modern notarial deeds. (Usex are not comparable to {{l}} links anyway.) Fay Freak (talk) 11:48, 22 November 2018 (UTC)[reply]
I'm not opposed to this, although I would rather a regular slash or backslash be used (with about the same amount of space on either side as there is now with the em dashes). I see no reason why spaces should surround slashes in example sentences (as you did in your third example). Andrew Sheedy (talk) 19:19, 22 November 2018 (UTC)[reply]
The style I usually use is no spaces when the alternative is between two words, and spaces when the alternative is between phrases. Personally I am not very keen on using slashes to separate original text, romanisation and translation. Forward slashes tend to visually blend in with italic text, and backslashes would just look a bit odd and unexpected, IMO. Mihia (talk) 20:38, 22 November 2018 (UTC)[reply]
Wait I did not suggest ”using slashes to separate original text, romanisation and translation.” That’s only coincidentally in the midst of the third example to point to variant declension. I want something ornate that separates original text, romanisation and translation. Fay Freak (talk) 00:10, 23 November 2018 (UTC)[reply]
No, you didn't, but I did. Other possible alternatives might include ～ (U+FF5E FULLWIDTH TILDE) or ⁓ (U+2053 SWUNG DASH), although maybe that would be confusing, given the role they play in other dictionaries. Andrew Sheedy (talk) 01:27, 23 November 2018 (UTC)[reply]
Haben wir Streichhölzer? ― Ich hab eins hier gesehen. ➢ Do we have matches? ― Ich have seen one over here.
U+27A2 THREE-D TOP-LIGHTED RIGHTWARDS ARROWHEAD
Haben wir Streichhölzer? ― Ich hab eins hier gesehen. ⧐ Do we have matches? ― Ich have seen one over here.
U+29D0 VERTICAL BAR BESIDE RIGHT TRIANGLE
And to separate transcription and original text there can be a different sign because the connection is closer.
Есть у нас спи́чки? ― Я тут одну́ ви́дел. ⎬ Jestʹ u nas spíčki? ― Ja tut odnú vídel ⧐ Do we have matches? ― Ich have seen one over here.
U+23AC RIGHT CURLY BRACKET MIDDLE PIECE and U+29D0 VERTICAL BAR BESIDE RIGHT TRIANGLE
Есть у нас спи́чки? ― Я тут одну́ ви́дел. ║ Jestʹ u nas spíčki? ― Ja tut odnú vídel ┃ Do we have matches? ― Ich have seen one over here.
U+2551 BOX DRAWINGS DOUBLE VERTICAL and U+2503 BOX DRAWINGS HEAVY VERTICAL.
How about using an arrow? Like one of the following: → ⟹ ➞ ➥ (the latter could be used when transliterations/translations are displayed on a separate line, for consistency). Andrew Sheedy (talk) 03:59, 23 November 2018 (UTC)[reply]
I'm against inventing new symbols and rather think we should stick to close publishing standards. One formatting you might find is Шустрая бурая лиса прыгает через ленивую собаку, Šustraja buraja lisa prygajet čerez lenivuju sobaku, "The quick brown fox jumps over the lazy dog", or perhaps 날쌘 갈색 여우가 게으른 개를 뛰어넘는다 [nalssaen galsaek yeouga geeureun gaereul ttwieoneomneunda] (The quick brown fox jumps over the lazy dog), both of which I think would be better than the current formatting, though I prefer my original suggestion. --Victar (talk) 06:47, 23 November 2018 (UTC)[reply]
In cases where there is a romanisation, I like this to be in italics. It's what I'm used to, I think it sets the romanisation apart clearly, and I do not find it in any way difficult to read. I don't mind the brackets and quotation marks. Mihia (talk) 18:42, 22 November 2018 (UTC)[reply]
Oppose: the lack of decorations in t:uxi is consistent with t:ux. I don't like the idea of making it visually similar to t:l/m either; the decorations of the latter are suited for short text embedded in a sentence (including t:usex-suffix). (yes, t:l is used in lists: but I have personal gripes about those as well). I think that this is a potential application for personal CSS gadgets that can be toggled in Special:Preferences. —Suzukaze-c◇◇23:49, 22 November 2018 (UTC)[reply]
Lack of decorations or not, separating the three parts with quotation dashes is unfortunate if the original text contains a quotation dash (which it does when it is in “question ― answer” format). Fay Freak (talk) 00:10, 23 November 2018 (UTC)[reply]
I found myself at Template:grc-IPA, wondering why periods are identified with Microsoftised ordinals (10th CE and so on). I am not familiar with the language the script is written in, but surely someone should be able to remove the superscripts for normal style? Imaginatorium (talk) 06:24, 21 November 2018 (UTC)[reply]
The Community Wishlist Survey. Please help translate to your language.
Hey everyone,
The Community Wishlist Survey is the process when the Wikimedia communities decide what the Wikimedia Foundation Community Tech should work on over the next year.
The Community Tech team is focused on tools for experienced Wikimedia editors. The communities have now posted a long list of technical proposals. You can vote on the proposals from now until 30 November. You can read more on the wishlist survey page.
Hey! It seems you are not very concerned by this survey. None of the proposals for Wiktionary came from English Wiktionary community and only few of you supports our proposals. I can't reach any conclusion about your motive for not being into it. Maybe our idea are not interesting for you, maybe your convinced this survey is useless, maybe you prefer develop your own tools internally. I don't know. I'll be glad to hear any critic or point of you about this matter! Noé14:35, 27 November 2018 (UTC)[reply]
(Sorry if this is not the correct forum. Correction welcome)
Currently Thesaurus:shit is a redirect to Thesaurus:feces. But while "feces" is the most common meaning of shit, the word also refers to various other things, including rubbish, recreational drugs, and objects generally. Also, Thesaurus:feces includes a Ws link to Thesaurus:shit, which winds up being circular. That is, if one clicks the "shit [Ws]" link on Thesaurus:feces, they find themselves at Thesaurus:feces. It seems to me like the title Thesaurus:shit should be either reworked or deleted. Cnilep (talk) 03:38, 23 November 2018 (UTC)[reply]
Not all uses are considered vulgar. We could distinguish the various senses and link for each to the thesaurus entry for an appropriate synonym. --Lambiam09:09, 23 November 2018 (UTC)[reply]
But there aren't usually separate pages for each sense; there is one page for a lemma. See, for example, Thesaurus:spirit. I think the question is, should we delete this title or rework it into a proper page? Cnilep (talk) 23:31, 23 November 2018 (UTC)[reply]
It ({{der3}}) was edited last month removing the automatic title "Terms derived from" and replacing it with "Derived terms" which is merely a repeat of the header, diff. I could revert the edit but …. {{der3-u}} wasn't touched. DonnanZ (talk) 22:41, 20 November 2018 (UTC)[reply]
Sometimes it is necessary to distinguish between different parts of speech, for example, "Terms derived from walk (noun)" and "Terms derived from walk (verb)". If so, then for consistency I feel it would be preferable for other templates to display "Terms derived from walk" rather than just "Derived terms" or nothing. Do we need to have a vote on this? — SGconlaw (talk) 03:04, 21 November 2018 (UTC)[reply]
To achieve "Terms derived from xyz (noun)", (verb) or even (adjective), it requires adding "title=Terms derived from xyz (noun)" etc. whether the displayed wording of the template is "Derived terms" or "Terms derived from xyz". I can't see any other way of doing it. But on the whole I would prefer restoring "Terms derived from" by reverting these edits. I don't think a vote is necessary. DonnanZ (talk) 13:05, 21 November 2018 (UTC)[reply]
In that case, there would be separate sections for derived terms from the noun and verb anyway. When does a given derived terms section ever need to contain more than one collapsible list? —Rua (mew) 13:58, 21 November 2018 (UTC)[reply]
I would prefer a layout for these collapsible lists that is as follows:
In the collapsed state, a few items are still shown, up to a set maximum number of lines, in order to limit the vertical space used. Any additional items will be hidden. This way, if there aren't many items to begin with, there is no need to expand the template.
In the expanded state, all items are shown.
No visible box around the list, so that it looks the same as a plain list. This reduces visual clutter.
No title bar at the top of the box, just a single floating clickable more/less link. The link could be placed in various locations, such as above the list (like now) or below it.
It has been my position that repeating "Derived terms" looks less silly than "Terms derived from X", and I pointed out we could leave the title empty and or we could say "Term list" to avoid repetition. As for "Terms derived from walk (noun)" and "Terms derived from walk (verb)", that is not necessary since these are under separate section headings. Showing some terms in the collapsed state as proposed by Rua is also an option. --Dan Polansky (talk) 10:35, 24 November 2018 (UTC)[reply]
As for forum, this does not belong to Grease pit: it is about the user-visible appearance of things, not about technical means of achieving a particular appearance. --Dan Polansky (talk) 10:39, 24 November 2018 (UTC)[reply]
I brought the matter here as they are templates, without thinking that it would grow into a lengthy discussion. Fortunately there are ways around the problem created, which I will use. DonnanZ (talk) 11:06, 24 November 2018 (UTC)[reply]
I like Dan's suggestion to use "Term list" as the header, or maybe even just "List". That way, you don't need different titles for different types of list, and can bring down the number of templates needed ({{der3}} vs {{rel3}} etc). My ultimate preference is still for what I suggested above, though. —Rua (mew) 11:42, 24 November 2018 (UTC)[reply]
This matter is getting out of hand, diff. I hate to say this, I think these templates need to be protected by admin-only editing. And maybe the discussion should be moved to the Beer Parlour. DonnanZ (talk) 12:30, 24 November 2018 (UTC)[reply]
I am fine with Rua's "List" as well. I am fine with showing a condensed list unless uncollapsed, as proposed by Rua. As for the out of hand thing, this is handled by the status quo ante principle, which I am applying as usual. --Dan Polansky (talk) 13:58, 24 November 2018 (UTC)[reply]
Despite DonnanZ's view, I think a vote is going to be required to eventually resolve this issue. By all means please continue the discussion above the line, but I've created a voting section below. — SGconlaw (talk) 14:33, 24 November 2018 (UTC)[reply]
To summarize my reasons, as mentioned above, if some templates are going to be titled "Terms derived from XYZ (noun)", for instance, then for consistency I feel the rest of them should be similarly titled "Terms derived from XYZ". — SGconlaw (talk) 17:17, 24 November 2018 (UTC)[reply]
But there is hardly ever a need for there to be "Terms derived from XYZ (noun)"; the location of the section heading makes it clear whether they are derived from a noun or a verb. Furthermore, even if such sections were next to each other, they could be just listed as one list since it does not really matter whether a term is derived from a verb from a noun. --Dan Polansky (talk) 08:19, 25 November 2018 (UTC)[reply]
Maybe I didn't understand. As I see it, unless a contributor replaces or edits the text, what would appear to users would be "Terms derived/related/etc. from/to XYZ". Is the intent to shame the contributor into editing or deleting the show/hide bar text? Perhaps we could augment the shame by inserting the user's name in the bar as well, and display it in red. DCDuring (talk) 00:07, 28 November 2018 (UTC)[reply]
Abstain This is acceptable, but "Term list" or "List" would address the concern that the heading, e.g., "Derived terms" is then immediately repeated in the title of the collapsible section. --Dan Polansky (talk) 15:21, 24 November 2018 (UTC)[reply]
I think the point is to avoid an empty title. I think an empty title is acceptable; it is also not listed as an option. And if duplicating a section heading is pointless, it is even more pointless to rephrase the section heading and at the same time duplicate the entry name. Such a duplication may fool the eye, but will not fool the perceptive mind. --Dan Polansky (talk) 15:29, 24 November 2018 (UTC)[reply]
Support, given the three options given. The creator of the poll omitted Rua's proposal of showing a couple of items even when uncollapsed, which is also a good option that I's support. Let's explore options. --Dan Polansky (talk) 15:18, 24 November 2018 (UTC)[reply]
@SGconlaw: Can you clarify? Are you saying that when there is a heading "Derived terms" and, underneath, there is a collapsible section entitled "Term list" or "List", the user would not know what to expect there? --Dan Polansky (talk) 16:55, 24 November 2018 (UTC)[reply]
Personally, I feel that "term list" is an odd collocation, the meaning of which is not immediately evident. As for "list", it seems too terse and so a little unclear. — SGconlaw (talk) 17:13, 24 November 2018 (UTC)[reply]
@SGconlaw: Why does "List" need clarifying, given there is "Derived terms" immediately above it? What makes you say "term list" is an odd collocation, in view of google books:"term list", which finds "A bridge of words: a term list based on the study and classificatio ..." as the first item found and contains plentiful other items found? --Dan Polansky (talk) 17:39, 24 November 2018 (UTC)[reply]
@Equinox: May I ask about your preference, if any? Should the collapsible box be empty? Should it show →? Should there be no collapsible box per default? Or should it show a truncated list, as proposed by Rua? --Dan Polansky (talk) 08:29, 25 November 2018 (UTC)[reply]
comment: The box currently has the word “show” and a downward-facing triangle at the right end. What if this were shifted to the left side in lieu of a title? Would that look odd? — SGconlaw (talk) 01:57, 27 November 2018 (UTC)[reply]
Support. The demo Example #1 in User:Victar/der3 looks pretty good, and it can be made even better if adjustments are explored. For reference, the example shows 3 columns and 3 rows. Some time ago, I verified that 3 columns look okay on a fairly small mobile device. I find 3 rows to be okay; there do not need to be fewer. --Dan Polansky (talk) 00:01, 1 December 2018 (UTC)[reply]
Oppose I think it gives the impression that the previewed terms are somehow more important or common than the expanded ones. Victar's lists look nice, but... what the hell is wrong with a collapsible box? It's straightforward, simple, and useful even if we can't agree on the text. Ultimateria (talk) 21:55, 1 December 2018 (UTC)[reply]
A collapsible box hides all the items, making it inferior to a plain list, which shows you items without having to click anything. It really annoys me when I have to click a button to see any terms. —Rua (mew) 22:20, 1 December 2018 (UTC)[reply]
I'm not saying that we wouldn't need a default. It just occurred to me that it would be nice if there were a list of common valid content that automagically appeared when {{der}} was first added or on demand by, say, clicking on a "+". Show/hide bars are useful for concealing all kinds of space-consuming content (other than definitions), such as multiline cognates sections and multiple conjectural etymologies, semantic relations etc. Thus "cognates" and "conjectural etymologies" might be included among the choices as well as "terms derived from {{PAGENAME}} ([pulldown for PoS])", "terms related to {{PAGENAME}} ([pulldown for PoS])". We could add other possibilities such "hypernyms of", "hyponyms of", etc. At least there would be some significant labor-saving, arthritis-relieving benefit associated with nudging contributors away from free-form and absent content. DCDuring (talk) 17:26, 24 November 2018 (UTC)[reply]
Repeating a header in a template is — not smart. In programming there is a rule called DRY ("don't repeat yourself"). This isn't just to save our fingers but it means that if we make changes (like moving things around) we don't have to change and update a lot of separate copies. If an entry has a Derived or Related Terms subsection then we already know the source term (because it's the entry headword) and the function of the listed terms (because that's what the subheading says) and repeating it is unwise. Equinox◑08:53, 25 November 2018 (UTC)[reply]
I guess removing the headers like ====Derived terms==== is not an option, is too radical and would upset the applecart. Which is why I support option 1, the best one. DonnanZ (talk) 11:56, 25 November 2018 (UTC)[reply]
Of the options above, I guess I like 1 or 2 best, but I am most interested in the suggestion of having no header and just displaying a portion of the list with some sort of "expand" button to reveal the rest (similar to what's done for quotations). - -sche(discuss)21:51, 25 November 2018 (UTC)[reply]
And I suppose we'll just pick 5 random entries to show? Or now we have to do even more work to determine which are the most important and mark them up somehow? DTLHS (talk) 21:52, 25 November 2018 (UTC)[reply]
I do not mind Rua's proposal if it can be technically implemented, again if there isn't consensus for option 1. Rua, perhaps you would like to formulate your proposal as another option and add it above. — SGconlaw (talk) 19:09, 27 November 2018 (UTC)[reply]
It could be made into a configurable option. Displaying zero rows by default would then be equivalent to the current setup. —Rua (mew) 13:50, 28 November 2018 (UTC)[reply]
Hungarian entries use multiple tables, one for derived terms (with suffix), one for compound words, one for expressions and one for words with verbal prefixes. See folyik. This is to separate the different derivations and to provide clarity and ease for the user to find items. How would this structure be impacted by this change? Panda10 (talk) 17:42, 28 November 2018 (UTC)[reply]
Victar and Chuck Entz, I'm not sure I understand your replies to Panda, who I understood to be asking how multiple tables would be kept separate and distinctly-labelled if the tables didn't have header bars saying "Derived terms", "With prefixes", etc. I don't think Panda's issue is sorting the terms inside the table. I am suggesting that they could be kept separate by prefacing each headerless table with ;With prefixes etc, like here (except with each list of derived terms being enclosed in a collapsed table). Adding a parameter to the template which would add such a header would also work (but "limit" seems like an opaque name for such a thing). - -sche(discuss)17:13, 29 November 2018 (UTC)[reply]
@Vriullop, I don't get it. What's the point of scrolling the collapsed entries line-by-line? If you're going to suggest a scrollbox, you may as well do away with the collapse feature. --{{victar|talk}}08:11, 29 November 2018 (UTC)[reply]
Ok, I did not notice the parameter limit of links-list. Your template does it better, but note that it does not work on mobile view. The difference is that columns are not rearranged and Firefox does not show the scroolbar for just one line. A simple scroll box can be an alternative. --Vriullop (talk) 08:53, 29 November 2018 (UTC)[reply]
I'm not enamoured with the scroll box. There are times when one wishes to see all the terms at once, and this is not possible with a scroll box. Also, I'm not sure how well it would work on mobile devices. In general, let's also ensure that whatever solution is adopted meets accessibility standards. — SGconlaw (talk) 09:03, 29 November 2018 (UTC)[reply]
On mobile, it's best to just show the full list because mobile browsers often do wonky things with javascript, if it isn't disabled entirely. The collapse method I'm using is the one found in the en.wikt common JS and is used in declension tables and such. --{{victar|talk}}09:59, 29 November 2018 (UTC)[reply]
Yet another version; this time individual list elements are assigned to the hidden and expanded states so there's less duplication: User:Erutuon/der3. (A vsAlwaysShow class would avoid duplication altogether.) I don't love how list items change position between the hidden and expanded states. It would be nice if they could stay in the same position. But since the columns are apportioned by the browser renderer, I don't know of a way to locate the items that should be hidden (the items in all rows besides the rows shown in the hidden state) either in Lua or in JavaScript. — Eru·tuon10:24, 29 November 2018 (UTC)[reply]
Actually I quite like the way the first three items shown in the collapsed list become the first three items in column one when the list is expanded, because it means that we are consistently displaying the first three (or whatever number of) items in the list rather than what randomly happens to be at the top of all the columns in the list. But I'm not too fussed either way. — SGconlaw (talk) 11:00, 29 November 2018 (UTC)[reply]
For consistency with other "click to display" links like "quotations", perhaps the "show more" link should be on the right side of the screen? — SGconlaw (talk) 11:04, 29 November 2018 (UTC)[reply]
I like Erutuon's method as well, and code-wise it's cleaner than Victar's. A downside is that the number of items that's shown and hidden is hardcoded in the output, instead of configurable in some way. —Rua (mew) 15:34, 29 November 2018 (UTC)[reply]
A method I have considered is to not use vsSwitcher at all, but instead have a single div (or even reuse the ul) whose vertical size is changed when the button is clicked. CSS would ensure that the excess items disappear, and no scroll bar is shown. If CSS is disabled, then the box would revert to its default sizing, which means showing all of it. I'd also prefer not hardcoding the number of columns, people have different display sizes so the number of columns should depend on the available width. —Rua (mew) 15:40, 29 November 2018 (UTC)[reply]
It's better now, but I'm not really fan of dividing the list into two separate lists. I know it doesn't really matter much for how it looks, but I like the HTML to be clean too. —Rua (mew) 16:10, 29 November 2018 (UTC)[reply]
The problem with the method Erutuon is using is that vsSwitcher leaves a sliver of spacing for each item you hide, which can add up, and is why you see a huge gap now between the columns and button. I'm not sure what you mean about the HTML being cleaner.
@Victar: I'm not seeing any extra spacing. It might be a browser-specific thing; I'm currently using Firefox 63. But if it happens for anyone, it's a problem. — Eru·tuon23:02, 29 November 2018 (UTC)[reply]
Now that I've jogged my memory, I've had this problem with declension tables as well when I apply vsHide to table cells instead of rows. I'm wondering if it's related to this. --{{victar|talk}}00:18, 30 November 2018 (UTC)[reply]
Since it's the same JavaScript function doing the showing and hiding, probably the two issues are related. Maybe the mobile Chrome renderer doesn't completely invisiblify elements that have the CSS property display:none; (which is used by jQuery.prototype.hide and thence by the vsSwitcher-handling function), but leaves a bit of space. That is unfortunate because from what I read online it's not how the CSS property is supposed to be rendered. — Eru·tuon00:33, 30 November 2018 (UTC)[reply]
Did you want to make an example of what you have in mind for a vsSwitcher-less version? I'm having trouble understanding it. --{{victar|talk}}16:38, 29 November 2018 (UTC)[reply]
I considered the idea of cutting off the bottom part of the list with an enclosing block element, but is there a way to ensure that the block element cuts off a whole row (does not chop words in half vertically)?
I created an example Example #3, which I think was what @Vriullop was trying to accomplish and what you are referring to above. As you mention, the problem with this is the possibility of cropping the content at the wrong place. I've set it to height:calc(24px*3) based on line-height:14px;padding-bottom:10px, but I'm not sure how static these values are. --{{victar|talk}}00:18, 30 November 2018 (UTC)[reply]
In my browser, that height value is too large: the top of the letters in the fourth row is visible. The actual size of each row probably depends on multiple factors, such as font family and font size. You could try using em values, which I guess are related to at least one of the font sizes used on the page. — Eru·tuon01:11, 30 November 2018 (UTC)[reply]
The problem is the line-height is set in pixels, not em, which is unfortunate. You might be able to get the line-height in each case using JS. --{{victar|talk}}01:22, 30 November 2018 (UTC)[reply]
In my browser, the line height for the li elements is set in em. So I guess it's browser-dependent or something. That complicates the cropping technique. — Eru·tuon03:03, 30 November 2018 (UTC)[reply]
The number of items that is shown could be configured using JavaScript. If we stick with vsSwitcher, a script could switch the class of some number of elements from vsShow to vsHide or the other way around, and duplicate items if necessary. Then users can decide how many list items to show by default. But that's kind of hacky, so if we want to allow customization, it would make more sense to design a new switcher that hides or shows all but a certain number of items in the list, and doesn't use classes for individual items at all. [Edit: Prototype at User:Erutuon/scripts/listSwitcher.js. To try it, add importScript("User:Erutuon/scripts/listSwitcher.js") to your common.js and look at User:Erutuon/der3 § List switcher.] — Eru·tuon 21:41, 29 November 2018 (UTC) — Eru·tuon20:41, 29 November 2018 (UTC)[reply]
We could also probably use the module to add class="vsShow" to the first, middle, and last items in the terms table.
@Erutuon: Hmm, $("#example4 ul li").addClass("vsHide").css("display","list-item") didn't fix it. Meh, going to bed, but with this, we can set the number to display with data-vs-showcount="3". --{{victar|talk}}07:19, 30 November 2018 (UTC)[reply]
Your code isn't working for me yet. I think that using simple arithmetic to figure out which items are in each column will not always be accurate. For instance, if several items in column 1 take up two or more lines, then column 2 will start sooner and some of the items from the top of column 2 will probably be in the "vsHide" group. — Eru·tuon19:42, 30 November 2018 (UTC)[reply]
Given that some people like Ultimateria prefer a collapsible box, a compromise would be to design the collapsible list in such a way that it can be converted to a collapsible box by JavaScript. Then those who want a collapsible box could just install a gadget or script that changes the list to a box. — Eru·tuon23:17, 1 December 2018 (UTC)[reply]
I would not be in favor of that and in a vote, would downvote it. I would rather the status quo of option #1 than have two formats. --{{victar|talk}}23:46, 1 December 2018 (UTC)[reply]
Like I said, I just don't want two completely different looking versions of the same module. If people want to be stubborn, they can modify their personal CSS and JS. --{{victar|talk}}00:30, 2 December 2018 (UTC)[reply]
That sounds rather like what I'm proposing. To make it easy for people to change the appearance of the list through JavaScript or CSS. I don't see where we disagree. — Eru·tuon00:50, 2 December 2018 (UTC)[reply]
Yeah, I might have misread your suggestion. What I'm saying is, I would not support a built in option for users to select between two different versions, but if you're just suggesting some JS or CSS people can put in their common file, I have no problem with that. --{{victar|talk}}01:15, 2 December 2018 (UTC)[reply]
Okay. I don't know what you mean by built-in; I wouldn't object to such a script being added as a gadget. But that is a remote future possibility. — Eru·tuon01:50, 2 December 2018 (UTC)[reply]
Erutuon, what is your rationale for having the boxes expanded by default and collapsed as an option, and not vice versa? Look at water; who wants to scroll past an entire 3.5 screens' worth of derived terms? Ultimateria (talk) 02:17, 2 December 2018 (UTC)[reply]
Huh? That's not what I'm proposing. My proposal is to allow users to convert Option 5 (a collapsible list) back to the current format of a collapsible box using JavaScript. — Eru·tuon02:25, 2 December 2018 (UTC)[reply]
Let’s recall that the aim of this discussion is the title that should be used with such lists, and the point of Option 5 is to eliminate the need for a title altogether. If a collapsible table is reintroduced and it needs a title, then we’re back at square one and Options 1–4. — SGconlaw (talk) 04:07, 2 December 2018 (UTC)[reply]
Oops, don't know how I read it that way. I'm more or less okay with Option 5 as long as the option to collapse is at the top and not the bottom. But I take the opposite approach to Rua on collapsible boxes. I'd rather open any that I'm interested in than scroll through endless lists on a page; think of Romance verbs like alterar which triples in length when you open the 5 conjugation tables. Ultimateria (talk) 19:24, 2 December 2018 (UTC)[reply]
The box has to be expanded by default because otherwise it won't ever be expandable on mobile. This just means that the HTML, as we write it, is in the expanded state. The JavaScript will then collapse it as soon as the page is loaded. I wouldn't like it if the content stayed expanded, either. —Rua (mew) 17:34, 4 December 2018 (UTC)[reply]
The remaining question is which of the implementations of Option 5 to choose, which is more of a Grease Pit–type issue. — Eru·tuon05:13, 28 December 2018 (UTC)[reply]
I would prefer that Example 1 is placed to der3 immediately so that we have a good temporary solution in place. Then, those interested can discuss whether they have something even better, and if required, a separate poll can be created. It would be a pity if the advancement got stalled only because of indecision about what seems to be a minor point. --Dan Polansky (talk) 10:09, 28 December 2018 (UTC)[reply]
@Erutuon: I had a look, and I prefer to have the button at the center, but can accept the button at the left as well. I would be happy to see your version in {{der3}} ASAP; I'd say, whoever beats the others in our effort to make the website nice for the users has the first mover advantage, and I hope any remaining differences can be amicably resolved. --Dan Polansky (talk) 11:16, 28 December 2018 (UTC)[reply]
I now had a closer look at User:Erutuon/der3#List switcher implementation; it looks pretty cool in that it just envelops wiki lists with certain divs, and unlike the first implementation, it does not use <li class="vsHide">. I also did the import into my common.js to actually test User:Erutuon/der3#List switcher myself. I would say, go for it, add the necessary JavaScript to site-wide .js page, and expect a possible revert, but I can see no truly good justication for that revert. --Dan Polansky (talk) 11:39, 28 December 2018 (UTC)[reply]
One problem I noticed is that when I apply List switcher to a list of mere 6 items, the Show more button is still shown. I think in that case, it should not be shown. --Dan Polansky (talk) 11:46, 28 December 2018 (UTC)[reply]
Sorry, @Erutuon, but I would not support your implementation. I find the version I created (version #4) much cleaner, more flexible, and takes better advantage of client-side CSS. --{{victar|talk}}11:49, 28 December 2018 (UTC)[reply]
I think we should not get stalled on which implementation is "cleaner". If I understand correctly from User:Victar/der3, Victar #4 requires markup like "{{links-list|en|columns=3|beer and skittles|beer belly|beer-bust|beer can|beered-up|beer garden|..., which is not as flexible as Erutuon's implementation, which can be applied to any wiki list. I prefer Erutuon's implementation, but will ultimately be happy as long as the user experience is good. --Dan Polansky (talk) 12:15, 28 December 2018 (UTC)[reply]
(edit conflict) @Victar: I want to implement Example #4, but think it is a good idea to start with the "list switcher" version because the JavaScript is closer to ready and the HTML is fairly compatible with the JavaScript for Example #4. — Eru·tuon12:22, 28 December 2018 (UTC)[reply]
Okay, but there is more work involved. The goal before actually putting Example #4 into commission is to have an importable user script that has been tested and proved on a page with multiple lists (and perhaps with other vsSwitcher elements to make sure it doesn't interfere with them) and to have a drop-in replacement for the create_table function in Module:columns that generates the necessary HTML. (I agree with Dan in that I would like to simplify the wikitext.) That exists now for the "list switcher" version, but not for yours. If you'd like to hasten the implementation of your version, I'd suggest working on that. — Eru·tuon23:44, 28 December 2018 (UTC)[reply]
The JavaScript part's more or less done; see below. By drop-in replacement I mean a module that will have similar behavior when it is invoked in templates and required in modules, so that you can just edit the templates or modules and change the name of the one module to the other. Module:links-list has a different name for its template-invokable function and doesn't provide a function for modules to use, so it would be a complicated operation to switch {{der3}} and other templates over to it, and a new function would be needed to switch modules over to it. I guess I could have brought this up, but I just went and made my own replacement module in Module:columns/sandbox. — Eru·tuon10:07, 31 December 2018 (UTC)[reply]
@Erutuon: I see. But would that be too complicated for the ordinary user? Is there any way of replicating that effect without the use of JavaScript? If not, maybe that option can be made available for users who are more familiar with JavaScript, and one of the other options should be implemented as the primary solution. — SGconlaw (talk) 11:12, 28 December 2018 (UTC)[reply]
@Sgconlaw: All of our showing and hiding of quotations, synonyms, lists, and whatever else uses JavaScript. It's just temporary that you have to mess around with your user JavaScript page. Once we choose an implementation, it will be automatically loaded and will run without any action by users. — Eru·tuon11:20, 28 December 2018 (UTC)[reply]
A version of the new list switcher (Option 5 in the vote above) is now live. It involves changes in MediaWiki:Common.js and Module:columns. This changes the format of various templates: {{der3}}, {{rel3}}, and other multiple-language templates, as well as the language-specific templates {{th-der}} and {{vi-der}}.
If editors of Thai or Vietnamese would like to change their templates back to the previous format, please let me know and I will do that. I had to change {{zh-der}} back because the new version of Module:columns was using too much memory on pages like 水. To switch to the old format, simply use Module:columns/old instead of Module:columns.
I am far from impressed with the change, where a template is modified with the addition of title= it is overridden. For example sea#Derived terms, which now looks quite stupid. Please revert back to the original. DonnanZ (talk) 11:44, 30 December 2018 (UTC)[reply]
Yeah, that looks terrible. I've changed the module so that the title will be displayed if it's been supplied to the template (not to the module invocation). Meaning, {{der3}} doesn't display "Terms derived from ..." everywhere, but "Names of seas" does display. — Eru·tuon12:30, 30 December 2018 (UTC)[reply]
Yes, that's much better, but I still prefer derived terms to be completely hidden, not half-hidden, in the same manner as translations are. All it does is make an entry lengthier, which IMO is not a desirable feature. DonnanZ (talk) 13:19, 30 December 2018 (UTC)[reply]
That's what you prefer, but that's not what I prefer and not what the poll shows to be the overwhelming preference. I think the result looks great, and could look even better if the background color were dropped, but as it is, it is a huge improvement. --Dan Polansky (talk) 14:29, 30 December 2018 (UTC)[reply]
On my user page I replaced {{der2}} with {{der-top}}, which is quite ironic really, given my enthusiasm for {{der2}} etc. until now. At least the contents are fully hidden until clicked on. Converting the United States county index will be more challenging. DonnanZ (talk) 17:49, 31 December 2018 (UTC)[reply]
There appears to be a problem with column balancing as well, e.g. with {{der3}} the middle column can be longer than the other two, and with {{der2}} the right column can be longer than the left one. DonnanZ (talk) 14:07, 30 December 2018 (UTC)[reply]
Could you give examples, for reference? I don't think there's anything I can do to fix this, though, because in the new version column balancing is done by the browser (whereas in the old version it was done by the module). It would be annoying to have to make the module do it again (and it would probably require changing the JavaScript code). — Eru·tuon03:07, 31 December 2018 (UTC)[reply]
Oh, never mind. Apparently it happens whenever the number of items is not a multiple of the number of columns. Makes me mad. — Eru·tuon09:20, 31 December 2018 (UTC)[reply]
@Donnanz: Those sets of columns are being apportioned correctly. If the total number of lines in the list is not divisible by the number of columns, the rightmost column should have empty space at the bottom. That leads to only two of the three columns being expanded in both of the examples you give, and to there being a gap in the hidden state in rygg. I don't think there is a good way to prevent either of those things. — Eru·tuon21:18, 5 January 2019 (UTC)[reply]
Dan, I'm not going to go over every difference with you -- you're welcome to have a look yourself -- but I objected to Erutuon's version before implementionation and I'm objecting after as well. --{{victar|talk}}19:36, 30 December 2018 (UTC)[reply]
Well, you're going to have to be specific about what you don't like. I can't just copy and paste your code. At the moment I'm planning to use the idea of choosing which items to show in the hidden state by approximately calculating which items are in the first x number of rows. If there is something else you really want, let me know. — Eru·tuon03:07, 31 December 2018 (UTC)[reply]
Okay, so you and DonnanZ do not appreciate my work. That is frustrating. I do plan to work on your version and wish you were helping rather than complaining. It should be possible to plug your basic idea into the "list switcher" code I've written. — Eru·tuon20:03, 30 December 2018 (UTC)[reply]
I appreciate the fact that you have done a lot of work, but flaws have to be pointed out, even if I aren't happy with the end product. Back to the drawing board. DonnanZ (talk) 21:04, 30 December 2018 (UTC)[reply]
Okay, and I am glad for the bugs that you've pointed out. I'm not eager to switch back to the old version, though, because it will be hard to find bugs without lots of people looking at the new version in the actual situations where it's used. I had a bunch of testcases, but nothing with a manually supplied title because I hadn't thought of that. — Eru·tuon08:25, 31 December 2018 (UTC)[reply]
I too appreciate your hard work, you know I do, especially working the sort function into Module:links-list. What I don't is that you moved forward with an your version, temporary or otherwise, despite objections. --{{victar|talk}}07:25, 31 December 2018 (UTC)[reply]
First of all, Donannz objections don't count since they lost the poll to an overwhelming supermajority. Second, you (Victar) can place your code to {{rel-top}} and make it work in Czech motiv (without editing the Czech entry, obviously), and then we can talk about which implementation is better and why. We need to get moving and this is what Erutuon has done. --Dan Polansky (talk) 07:35, 31 December 2018 (UTC)[reply]
Okay, well, I am the person actually doing the work and asserted the right to choose how to do it. I chose the way that seemed most manageable to me. I regret that I did not feel up to doing it the way you wanted; it would have led to less conflict and people wouldn't be inflicted with the unfortunate discomfort of seeing the inferior implementation before the better one. — Eru·tuon08:25, 31 December 2018 (UTC)[reply]
@Erutuon: There is a spelling error in the der templates, presumably coming from the module: "It has two optional parametres:", which should read parameters. The spelling is the same in both Am. and Br. English. DonnanZ (talk) 18:53, 31 December 2018 (UTC)[reply]
The oddest thing, perhaps, is that only the top of each column is shown, so that you have to "show more" to find what's there in between the tops of the columns alphabetically. That is weird, and takes some getting used to. DonnanZ (talk) 15:26, 2 January 2019 (UTC)[reply]
Okay, I got Victar's nicer implementation working. (I messed with the code and eventually figured out a much simpler version.) Unfortunately, it's only working when the number of items (or of lines?) is a multiple of the number of columns, at least in my browser (Firefox). Otherwise, list items shift position between the shown and hidden states.
This is because of how my browser apportions columns (for elements with the column-count: <number>; CSS property). It doesn't try to make sure all but the rightmost column is full, but seems to try to put items in the middle. Very bizarre and I have no idea how to figure out which items will be at the top of each column. — Eru·tuon09:20, 31 December 2018 (UTC)[reply]
Okay, weird column apportionment is caused by the fact that the column count CSS property is applied to the enclosing div tag. It can be fixed by applying that property to the ul tag. Doesn't seem possible to do that in the wikitext –
this
is
a
HTML
list
– except by replacing asterisks with li tags as follows:
I haven't really been following this, but I do appreciate all the effort you've put in to get this to work right. —Rua (mew) 12:24, 31 December 2018 (UTC)[reply]
So, I looked at a few ways to make the ul tag have the columns, not the div tag. I wanted to do it with TemplateStyles, but the sanitized CSS content model doesn't allow browser-specific column-count CSS properties (-moz-column-count, etc.). I also considered doing it with JavaScript, but that would mean that people without JavaScript enabled would see a one-column list. And as mentioned, it can't be done directly in the wikitext. The only solution that I could come up with was to add CSS properties to MediaWiki:Common.css, which I've done, and then to make a simple change in Module:columns. I don't like to add more CSS, but it apparently can't be avoided. — Eru·tuon21:35, 31 December 2018 (UTC)[reply]
In my opinion a change of this nature needs a vote. Specifically the vote should be about the default. All those in the know can select their own preferred layout. But unregistered users cannot and many other users will not know how to do so.
I think this matters because the new layout is inconsistent with the layout used in translations and in non-list contexts where our familiar show-hide bars are used. Again, for those in the know they can manage things to suit themselves. For others we have created visual discord, effectively making the site harder to use. DCDuring (talk) 23:35, 31 December 2018 (UTC)[reply]
I was under the impression that we already voted on this, as indicated above. The issue was what default wording should be used as the title for morphological-relation tables like {{der2}} and {{rel3}}. Option 5 was that the wording should be omitted altogether and replaced by a technological solution that hides part of the list until a link is clicked on. That was the option which most editors agreed on. — SGconlaw (talk) 04:34, 1 January 2019 (UTC)[reply]
There was a poll with solid participation, but feel free to create a vote in WT:VOTE. Our original practice was to have Related terms and Derived terms non-collapsible, and to use no introductory phrase there, but some people started to change the practice with neither a poll nor a vote. The result was what I found to be a much poorer user experience, which lead to some reverts in templates, discussion and polling, and the result was the choice of the option that a supermajority of people preferred. We are lucky there since with our requirement of supermajority (2/3 or such), there could have been a stalemate. The ultimate status quo ante is no collapsible boxes around RT and DT lists and no introductory titles. As for the look of translation collapsibles, I think they look pretty bad, like heavy concrete slabs, but that's for another improvement. --Dan Polansky (talk) 07:44, 1 January 2019 (UTC)[reply]
Our translation collapsibles would look much better if they looked more like what is produced by {{prefixsee}}, e.g. in psycho-: 1) no boldface, 2) no gray background; could have light blue background like in {{prefixsee}}, 3) no gray outline surrounding a white outline. --Dan Polansky (talk) 08:51, 1 January 2019 (UTC)[reply]
I think everyone knows my view. What we have now is inconsistent with other collapsibles like translations (which should be left alone) and options like {{der-top}}, and as Dan mentions {{prefixsee}} and {{suffixsee}}. And now we know what it looks like, IMO it doesn't look good either. So if you think a vote would help go ahead with one. DonnanZ (talk) 14:58, 1 January 2019 (UTC)[reply]
Although the ability to edit each translations section separately would be appreciated, instead of sometimes having to wade through a long list (and I have sometimes made an entry in the wrong section). DonnanZ (talk) 15:18, 1 January 2019 (UTC)[reply]
It was not a "a supermajority of people", it was perhaps a supermajority of those who actively participate in BP discussion, not put off by a TLDR discussion. I also think that the interests of unregistered and occasional users were not mentioned, let alone explicitly addressed. This is, of course, our usual, selfish practice. I have no problem with gadgets being added for those who have particular tastes or needs. I do have a problem with the trashing of a relatively consistent user interface. DCDuring (talk) 16:21, 1 January 2019 (UTC)[reply]
It does make sense to me to have a vote. The poll above started with "what title should these various templates have?" and ended up at "let's totally change how they look". And with that change, these templates look different from the translations box and from the various top and bottom templates (which I haven't changed yet). It's a pretty dramatic change to be housed in a section entitled Titles of morphological relations templates. If you would like me to change the templates back in the meantime, that only requires a simple reversion in Module:columns. — Eru·tuon19:42, 1 January 2019 (UTC)[reply]
There seems little way to provide for “unregistered and occasional users” to participate in discussions, polls and votes, so I’m not sure it is worth trying to design a system that will accommodate that. That being said, I’ve no objection to a vote being held to clarify the issue. There is a clear difference between translatIon tables and morphological relation tables, though. The former definitely need a label indicating the sense being translated. The latter usually do not, which is why a technical solution that eliminates the need for a label solves the problem of editors disagreeing on what the label should be. — SGconlaw (talk) 01:47, 2 January 2019 (UTC)[reply]
Our voting process would only reflect the interests of unregistered and casual users only if we were explicitly address them in the discussion and vote based on them. We apparently have the notion that we are typical users whose needs are virtually the same as theirs. Of course, we could also maintain the kind of fiction beloved by lawyers and law-makers that such users have all the opportunity to vote that they need and thereby must be approving our decisions by their silence. This is laughable and self-serving. DCDuring (talk) 16:33, 2 January 2019 (UTC)[reply]
By all means raise the arguments in the vote, bearing in mind that trying to discern what unregistered and casual users find useful will be somewhat speculative. — SGconlaw (talk) 16:50, 2 January 2019 (UTC)[reply]
I think we can safely assume a few things about such users:
Almost all expect us to be a dictionary.
Because many don't come here often, they are easily put off by departures from standard web practice.
Some of who do come here more than once become accustomed to long-established conventions we've adopted.
My assumption is that they probably use mobile devices. In mobile view, the templates in question appear expanded, and show one item per line. Except the translation table, which is closed and has to be clicked to open it. Panda10 (talk) 17:51, 2 January 2019 (UTC)[reply]
Good point. That hasn't been mentioned in this discussion either, which further demonstrates that we are only talking about our own needs and preferences as active contributors. I wonder how many use the app, how many use the mobile page through a browser, and how many go to desktop view (not too many of the last I assume). DCDuring (talk) 19:07, 2 January 2019 (UTC)[reply]
In mobile mode, the old version of the templates in question is collapsible, but the new version isn't because the JavaScript for it only runs in desktop mode. (That's also true for the inflection table in Sanskrit देव(deva) and the pronunciation in most Ancient Greek entries.) That is a big problem when the the lists of words are very long. Though I thought that you could collapse a section by clicking on the section heading on a smartphone. Maybe that was only on Wikipedia. It's not true when I view pages in mobile mode on my computer. — Eru·tuon21:05, 2 January 2019 (UTC)[reply]
@Erutuon: Hi, agreed this is bad not being able to collapse these very long lists in the mobile view. I found out that only level 1 (=) headings at the language level are collapsible in minerva. What JS-code exactly collapses rel3 and der3? I would like to test it in my mobile.js.--So9q (talk) 14:45, 13 September 2019 (UTC)[reply]
Advanced Search will become a default feature on your wiki on November 28. This new interface allows you to perform specialized searches on the search page, even if you don’t know any search syntax. Advanced Search originates from the German Community’s Technical Wishes project. It's already a default feature on German, Arabic, Farsi and Hungarian Wikipedia. Besides, more than 40.000 users across all wikis have tested the beta version. Feedback is welcome on the central feedback page.
English Wikipedia has a very convenient page mover role. Would it be possible to make such a role here on en.wikt? I don't have any need for vandalism tools, but I move pages on a daily basis, and relying on admins to delete pages, especially when moving a page back, is a very tedious time-killer. @Chuck Entz, -sche, Surjection, Dixtosa --Victar (talk) 00:50, 27 November 2018 (UTC)[reply]
It's probably technically possible, but it'd probably need some kind of consensus within admins, and I'm not sure who exactly could even create a role like that. SURJECTION·talk·contr·log·10:56, 27 November 2018 (UTC)[reply]
It doesn't exist on this wiki yet, so it's not just waiting for admins to assign. If it's anything like the template editor role, it would require a Phabricator request to the Wikimedia technical powers that be to add it to our wiki, which they would only grant if we demonstrated that there was a consensus here in favor of it- among the community as a whole, not just the admins.
Once it was added, we would need to set up a procedure for nominating and approving candidates. It sounds similar to the rollbacker role, which we currently grant after one admin requests it at the Whitelist and another admin concurs.
At any rate, I'm a bit fuzzy on the exact steps to make it happen, but the above is my general impression based on what happened with the template editor role. Chuck Entz (talk) 14:48, 27 November 2018 (UTC)[reply]
Although it's not overly pressing (redirects get deleted eventually), adding such a user group/right seems useful. AFAICT it wouldn't allow vandals to move pages any quicker than the normal "move" function, so I see no reason to be concerned about misuse. Probably a straw poll here would be sufficient evidence of consensus (for linkng to in a Phab ticket), assuming a reasonable number of users participate and this doesn't turn out to be controversial for some reason. - -sche(discuss)19:31, 27 November 2018 (UTC)[reply]
@-sche:, the biggest annoyance for me is moving back an entry, which normally requires that I add a {{d}} to the redirect, wait patiently for and admin to delete it, and then move the entry back. If I could use the undo button in some of those cases, that would be really helpful. --Victar (talk) 22:31, 27 November 2018 (UTC)[reply]
Interestingly, it looks like this role is assignable by admins (not just bureaucrats), so we might want to make a quick outline for how it should be handled. I just gave the rights to Victar as a test case. - TheDaveRoss21:10, 7 January 2019 (UTC)[reply]
I suggest granting it on the same basis as "whitelisting" (which is also, as I understand it, how "rollbacker" is granted), which means one admin proposes it and another seconds/grants it, or a non-admin requests it and two admins agree. That keeps bureaucracy to a minimum, while not allowing anyone to act unilaterally. - -sche(discuss)02:29, 8 January 2019 (UTC)[reply]
Indicate whether you support or oppose having the "page mover" right described above turned on for en.Wiktionary, tentatively to be granted to users through the same procedure as "rollbacker" rights.
I have been adding alphagrams to anagram sections (for example antiscreening). This means it is possible to search for "alphagram XYZ" and get all anagrams of XYZ even if XYZ isn't a word. If this isn't wanted the display can be turned off in Module:anagrams. DTLHS (talk) 02:03, 27 November 2018 (UTC)[reply]
Seems like like a cool idea. So I can get English words with the alphagram acer by searching insource:"anagrams" insource:/en\|a=acer[|}]/ or insource:"anagrams en a acer". Searching would be more intuitive if the parameter were named "alphagram"; then you could just search for insource:"en alphagram acer". (That would find instances of {{anagrams|en|alphagram=acer| because punctuation characters are ignored when you search for a series of words in quotes.)
To me this also suggests the idea of housing anagrams on separate pages indexed by alphagram and transcluding them rather than updating a bunch of pages when a new anagram is found. — Eru·tuon22:28, 5 January 2019 (UTC)[reply]
I really don't like the idea of creating hundreds of thousands of template pages for such a purpose (or any purpose). DTLHS (talk) 22:34, 5 January 2019 (UTC)[reply]
I'm currently learning Thai, mainly online. I don't have a teacher or a reference grammar.
I've discovered that ว่า and ที่ both mean that and are used in some kinds of relative/subordinate clause equivalent. But I have not yet understood them and their differences at any depth.
From what I have been able to figure out ว่า is used for "He said that ...", "It seems that ..."; and ที่ is for "The thing that did X", "The thing which did Y".
I regard those functions is similar in English, which is why the same word can be used for both situations. Of course "which" cannot be used for the "said", "seems" situations though.
When I come across pairs of words like this in any language where the usage crosses over to any degree in English I have always linked them in the "See also" section. This is the section for connecting words that are not derived from or etymologically related to each other but have some semantic or usage overlap of any kind. And to me, not necessarily in the native language, but an overlap in their translations to English has been sufficient.
I recently linked these two via see also and those have been reverted.
I've posted an "attention" in the relevant sense of each Thai word asking for usage examples. Only one of the words appeared in any translation table at "that" so I added the other in the section that looked appropriate to me and also added an "attention" template so somebody more knowledgeable can check it.
Firstly, I'd like to first ask any contributors who know Thai if they can explain the differences between these two words, assuming my rough attempt above is not sufficient.
Secondly, I'd like to ask all contributors if they think there is or is not sufficient semantic or usage overlap to warrant these two words for "that" to refer to each other in a "See also" section. Thought on why or why not greatly appreciated.
ที่tîi is “which, that”, a relative pronoun used to refer to people, places and things, restricting the noun in front. It can also be used to mean “that which, the one that, the ones that, ...” in a way similar to สิ่งsìng, and thus function as a nominaliser. Verbs of emotion (‘sorry, happy, angry’, etc.) can also be followed by tîi.
ว่าwâa typically follows a verb and is similar to “that” in English, although it is less droppable in Thai. It can only follow certain verbs, e.g. verbs of utterance (‘say, whisper, call’, etc.), mental activity (‘think, remember, hope’, etc.) and perception (‘see, understand, know’, etc.).
Thanks! It so happens that I now live walking distance from a university library. I visited this afternoon and they had three Thai reference grammars. One referred to these two words as "complementizers" and another had a little section specifically about how they differ. This reinforced my opinion that they should be cross-linked via "See also". It turns out there is another word which is a compound of these two: ที่ว่า, another term for "that". — hippietrail (talk) 07:24, 28 November 2018 (UTC)[reply]
Noé 15:40, 1 November 2018 (UTC)
Oppose - I think we should get away from having templates do this sort of thing. Any result which is unlikely to change often should be static text, which is better for the servers and better for anyone who might wish to use the underlying data in any context other than this wiki. If we could make the template subst in the transliteration automatically I would support that. - TheDaveRoss 14:41, 6 November 2018 (UTC)
Support. DTLHS (talk) 16:09, 6 November 2018 (UTC)
Abstain. Neither good nor bad. Per utramque cavernam 23:00, 29 November 2018 (UTC)