Wiktionary:Beer parlour/2016/February

I believe the whole section WT:CFI#Idiomatic phrases is the province of WT:EL#Entry name, not of WT:CFI. I propose removing the whole section from CFI.

I propose using this (updated) text for WT:EL#Entry name, which is the same thing from CFI but without some repetitions and explanations (updates are underlined):

--Daniel Carrero (talk) 04:49, 1 February 2016 (UTC)

Edited: --Daniel Carrero (talk) 11:40, 1 February 2016 (UTC)

Hmmm.

1. This doesn't seem to differentiate between uses of {{also}} (for orthographic differences that map to the same character in the absence of diacriticals and case differences) and the Alternative forms header (for forms of the same Etymology or PoS, including those that otherwise meet criteria for inclusion in top-of-the-page "also").
2. It neglects to suggest the possibility, let alone desirability, of redirects from common forms of MWEs that use pronouns other than one/one's, someone/someone's, or something/something's to the lemma, which uses those person- and number-free pronouns. Furthermore, in English, sometimes the lemma should include a specific personal pronoun. For example, a folksy proverb like you can't fight city hall would be the lemma, not one can't fight city hall. DCDuring TALK 11:02, 1 February 2016 (UTC)

What about now? I edited the text. The text you saw and replied to is in this revision. --Daniel Carrero (talk) 11:40, 1 February 2016 (UTC)

I created Wiktionary:Votes/pl-2016-02/Entry name 3. --Daniel Carrero (talk) 15:34, 7 February 2016 (UTC)

I created/populated Category:English trisyllabic words; just one category, for the purpose of discussion. If people like it, I'd like to create the full category tree, which would be:

• Category:English monosyllabic words
• Category:English disyllabic words
• Category:English trisyllabic words
• Category:English tetrasyllabic words
• Category:English pentasyllabic words
• Category:English hexasyllabic words
• ...

Should there be any hard limit for the number of syllables? And, of course, I'd like to create the FL counterparts:

• Category:Portuguese trisyllabic words
• Category:French trisyllabic words
• Category:Spanish trisyllabic words
• etc.

I created {{hyphenation categorization}} for that purpose, which categorizes entries that use {{hyphenation}}.

I was kinda inspired by ptwikt, which has categories like pt:Categoria:Trissílabo (Inglês) and pt:Categoria:Trissílabo (Português). They are populated by a template that I created years ago. --Daniel Carrero (talk) 07:16, 1 February 2016 (UTC)

I'm not sure I see the need for these categories. Benwing2 (talk) 07:23, 1 February 2016 (UTC)

English is my second language. Hyphenation is one aspect of English I have yet to grasp decently. That category seems helpful to me, as I admit I wouldn't recognize more than half of those words as trisyllables: the fact that "eukaryote" and "acquainted" have 3 syllables seems a little bizarre to me. In Portuguese, we separate syllables basically by counting vowels and vowels combinations. (there are also a few more rules, like the thing with "rr" and "ss", but that's it) --Daniel Carrero (talk) 07:32, 1 February 2016 (UTC)

Totally useless. Please don't do it. SemperBlotto (talk) 07:38, 1 February 2016 (UTC)

BTW, eukaryote has 4 syllables, something like 'eu-kar-y-ote' in my dialect if you hyphenate by pronunciation; I think Brits would hyphenate 'eu-ka-ry-ote' if following their pronunciation. Evidently Wiktionary's English hyphenation isn't a reliable guide to how many syllables there are in a word. BTW hyphenation in English is a total mess; no one really understands it. It seems to involve a great deal of conventional rather than linguistic rules, and undoubtedly differs from dictionary to dictionary. The traditional purpose of English hyphenation is to indicate where words can be broken in printed text, and doesn't have much anything to do with pronunciation. Benwing2 (talk) 07:53, 1 February 2016 (UTC)

In fact there are many 4-syllable words in your list of English trisyllabic words, e.g. just among the a's there are abaxial, achievable, analysis, anthology, antipathy, and authority, plus 5-syllable atrabilious. Benwing2 (talk) 07:57, 1 February 2016 (UTC)

In Portuguese, we have very fixed hyphenation rules that we learn at school as children. (in my experience in Brazil) Like: característica = ca-rac-te-rís-ti-ca. Also, perhaps I should update polissílabo, that word in Portuguese seems to be always about a word with specifically 4 or more syllables, not just "more than one syllable", but it's conceivable that the latter could be citable as a separate sense.

If "hyphenation in English is a total mess" then it makes sense that we should not have the proposed category tree for readers. Still, I fixed "eukaryote" based on what you said and you pointed other mistakes in hyphenation. Do you think categories like Category:English trisyllabic words could serve the purpose of helping editors seeing lists of words that use {{hyphenation}} and check if they are being used correctly? If so, maybe they could stay but as hidden categories?

I'm curious if there is any foreign language for which "Category:(language) n-syllabic words" would be a deeply helpful thing for readers. --Daniel Carrero (talk) 08:13, 1 February 2016 (UTC)

The problem is, hyphenation is used for two different purposes: indicating syllables, and indicating where words can be broken with a hyphen in printed text. In English they aren't the same, so e.g. the hyphenation 'atra-bili-ous' may be correct for printing purposes. It's not obvious to me that you should correct this to follow syllable divisions, similarly with 'eu-kary-ote', which is probably correct as-is for printing purposes. Benwing2 (talk) 08:39, 1 February 2016 (UTC)

Ah, never mind then. I reverted my edit on eukaryote. I'll delete {{hyphenation categorization}} and Category:English trisyllabic words later if no one wants it. --Daniel Carrero (talk) 10:20, 1 February 2016 (UTC)

• Not sure what chronique scandaleuse is doing in this category....--Ce mot-ci (talk) 21:26, 1 February 2016 (UTC)
  • Hyphenation is not a good way to determine the number of syllables. Just today I added the {{hyphenation}} template to two disyllabic words that are hyphenated as if they were monosyllables: abreast and ahead, which are never broken across a line break, because one of the rules of hyphenation in English is to never leave a single letter by itself. Also, dictionaries differ as to where acceptable hyphenation points in English are: for eukaryote, Merriam-Webster's and Oxford agree with us that -kary- should not be broken up even though it's two syllables, but American Heritage does break it up as eu·kar·y·ote. —Aɴɢʀ (talk) 22:07, 1 February 2016 (UTC)
    • As another example: lever is broken as le-ver (by one US dictionary), lev-er (by another), or lever (by a UK dictionary) by different dictionaries. - -sche (discuss) 05:57, 4 February 2016 (UTC)

I don't think such categories are a good idea, and (as noted above) they certainly can't be populated by the hyphenation template. - -sche (discuss) 23:21, 1 February 2016 (UTC)

Not wishing to dogpile but I also think this is a waste of time and resources even if it were done accurately. Perhaps at some point we can reliably generate such info from the IPA transcriptions or something. By that time it is not clear that we will still be using the existing category system at all. Also, has anyone ever asked for this as a feature? Equinox ◑ 23:24, 1 February 2016 (UTC)

Well, I'm asking for the ability to group words by number of syllables. I get it that hyphenation is not the same as syllabification. I am willing just to mark words as 1 syllable or 2 syllables etc. I am trying to teach English to a friend, and think the list of 1 syllable and 2 syllable words is useful. I created the categories, and they were deleted. What can I do to just allow the categories to exist as well as entries marking the various English words, and to not fight those who don't want them or want to delete them because they think it is a futile endeavor ? Bcent1234 (talk) 20:55, 2 September 2016 (UTC)

Nobody asked for it, I was just copying ptwikt. They also have categories like pt:Categoria:Oxítona (Português), pt:Categoria:Paroxítona (Português) and pt:Categoria:Proparoxítona (Português) for oxytone, paroxytone and proparoxytone words. AFAICT, it may be tied to our culture of learning to count syllables in school, it also affects the placement of accents. But I'm not sad to see the category Category:English trisyllabic words go, I see that using {{hyphenation}} for that purpose was a bad idea. In the case of Portuguese, counting syllables is often as easy as counting letters IMO, (if you ignore some stuff like the pt:Categoria:Proparoxítona aparente (Português) thing that affects words like advérbio) so I wouldn't argue we need a special category for it, maybe only if it served the purpose of checking how many of the entries are correctly tagged with hyphenation. (hyphenation = syllables in Portuguese) --Daniel Carrero (talk) 23:45, 1 February 2016 (UTC)

The only way to do this automatically in English is to use the IPA pronunciation, assuming that it's correct (e.g. eukaryote has a strange second pronunciation listed that would suggest it has 5 syllables). BTW, I saw an error in pt:Categoria:Trissílabo (Inglês) -- eclipse is only two syllables. Benwing2 (talk) 01:18, 2 February 2016 (UTC)

I am content to just do it manually, and not automatically. If someone disagrees they are free to add another category based on their preferences. Do I need to mark what I'm doing to say in some way that its my particular dialect I am marking ? Bcent1234 (talk) 20:55, 2 September 2016 (UTC)

Maybe this can be enabled only for specific languages like Portuguese, with regular hyphenation rules. DTLHS (talk) 01:24, 2 February 2016 (UTC)

I confess I'd like that if other people agree with it. Does Spanish have regular hyphenation rules, too? --Daniel Carrero (talk) 12:33, 2 February 2016 (UTC)

Most languages have regular hyphenation rules, I think. Spanish spelling is regular enough that you can count syllables just based on the spelling, exactly like in Portuguese. Benwing2 (talk) 15:22, 2 February 2016 (UTC)

I can support this if the categories are named in regular English (one-syllable, two-syllable, or perhaps 1-syllable, 2-syllable) rather than the obscure Greek. —CodeCat 12:57, 2 February 2016 (UTC)

Support. I prefer Category:Portuguese 1-syllable words, rather than Category:Portuguese one-syllable words. --Daniel Carrero (talk) 14:33, 2 February 2016 (UTC)

Rationale: categories named with "1" are easier to sort; and also easier to parse visually. --Daniel Carrero (talk) 17:01, 2 February 2016 (UTC)

I can't really see any harm in this. A lot of our categories are in my opinion not very useful for human users (as opposed to finding stuff for bot edits) and this is no worse. Renard Migrant (talk) 14:21, 2 February 2016 (UTC)

Do we have any evidence that any of our categories are ever used by our users. I just assumed they were for our own benefit. SemperBlotto (talk) 15:28, 2 February 2016 (UTC)

FWIW, someone wrote about Wiktionary categories it in a book: link. Does that count as evidence that it Wiktionary categories helped their research? "Categories such as etymology, POS categorizations, personal names, numbers, and plural nouns are obviously important clues for POS tagging." --Daniel Carrero (talk) 15:40, 2 February 2016 (UTC)

I've looked at stuff like CAT:es:Baseball before. If you're talking about non-editors I guess you'd have to look at WT:FEED. Renard Migrant (talk) 16:16, 2 February 2016 (UTC)

I'm thinking of creating only the Portuguese categories for a start, others can be created later. I'll edit the template so only the allowed languages have syllable categories. Let me know if I should enable the categories for more languages right now. (French, Spanish, etc.?)

• Category:Portuguese 1-syllable words
• Category:Portuguese 2-syllable words
• Category:Portuguese 3-syllable words
• Category:Portuguese 4-syllable words
• Category:Portuguese 5-syllable words
• Category:Portuguese 6-syllable words

...

--Daniel Carrero (talk) 04:27, 3 February 2016 (UTC)

The problem is that in many stress-timed languages, including English, syllabicity is not always clear. Are file, peel, hire mono- or disyllabic? Are filing, peeling, hiring, peddling, genial di- or trisyllabic? Are honorable, fashionable tri- or tetrasyllabic? Etc. Should we just allow most of these to be in both categories? --WikiTiki89 20:21, 3 February 2016 (UTC)

I don't see what you mean. When is file or peel or hire ever a two syllable word? Bcent1234 (talk)

Maybe there are people who pronounce these words in such a way that they are unquestionably monosyllabic (especially for peel), but most people don't (at least for file and hire). For those people, the question isn't when it is or isn't, the question is how you see it. The way I see it, file and hire have two syllables (/ˈfaɪ.əl/ and /ˈhaɪ.əɹ/) and peel might depending on your pronunciation (either /ˈpiː.əl/ or just /piːl/). --WikiTiki89 21:06, 2 September 2016 (UTC)

@Wikitiki89: I think it would be a good idea if we could type {{hyphenation|hi?re}} and thus categorize the entry into Category:English 1- or 2-syllable words. There are some words in Portuguese that have a quirk in hyphenation and definitely would be able to fill categories like Category:Portuguese 4- or 5-syllable words, too. (compare Category:Portuguese 3-syllable words) --Daniel Carrero (talk) 21:12, 2 September 2016 (UTC)

But the problem is that the actual syllabification is not related to the standard hyphenation. You cannot hyphenate hire as hi-re. --WikiTiki89 21:23, 2 September 2016 (UTC)

That seems easy to understand, and I see your point. But when I proposed using {{hyphenation|hi?re}}, I did not say that you can hyphenate hire as hi-re. I just wanted to use "?" to populate an English syllable category. We may as well create a new syllabification template that accepts {{syllabification|hi|re}} or {{syllabification|hi?re}} as different inputs to place the entry is different categories. --Daniel Carrero (talk) 21:32, 2 September 2016 (UTC)

The only way to do this would be using the IPA templates, since there are sometimes different pronunciations for the same term that have different numbers of syllables. Even that has problems: not everyone includes syllable marks, and determining syllabification from the IPA is very tricky or impossible for many languages (it's not uncommon for syllabification to lag behind when phonemes change over time). Perhaps it could be done with an optional parameterChuck Entz (talk) 21:41, 5 September 2016 (UTC)

An exaggerated illustration of this is the The Doors' song Light My Fire, which not only rhymes fire with words like higher and liar, but at one point draws the word out for dramatic effect, starting the second syllable with a j semivowel. Chuck Entz (talk) 21:41, 5 September 2016 (UTC)

Ok, I got it that English's syllabicity is weird. My first guess is that maybe there could be a point in letting the words you mentioned in both categories. But, anyway, I deleted Category:English trisyllabic words and edited {{hyphenation categorization}} in a lazy non-Lua way to categorize entries in Portuguese as discussed above. Now categories like Category:Portuguese 1-syllable words are being populated. I should be able to Luacize that template later to allow for more languages. (Spanish, Italian, maybe, most/all Romance languages would be okay?) Also, update {{poscatboiler}}.

What should the top category be called? Category:Portuguese words by syllabicity? --Daniel Carrero (talk) 04:55, 6 February 2016 (UTC)

"...by number of syllables" would be plainer English. - -sche (discuss) 07:24, 6 February 2016 (UTC)

 Done. I created the categories for Portuguese (1-13 syllables) and Spanish (1-9 syllables). I was too lazy to Luacize {{hyphenation categorization}}, though. But it should work with any language now, provided it's listed in the template. Other languages won't generate categories, to avoid cases like English, where you can't get the syllables from the hyphenation. --Daniel Carrero (talk) 04:22, 7 February 2016 (UTC)

It's weird that Category:Spanish 6-syllable words contains: batará lineado, chova piquigualda, manzana de caramelo. Should we allow entries comprised of multiple words to have a {{hyphenation}}? If the answer is yes, then Category:Portuguese 6-syllable words should be renamed to Category:Portuguese 6-syllable terms. Example: a curiosidade matou o gato is a 12-syllable proverb. But the hyphenation should be found in each component word anyway: a, curiosidade, matou, etc. --Daniel Carrero (talk) 17:18, 7 February 2016 (UTC)

@Daniel Carrero: Though this discussion concluded eight months ago, I'd like to register my preference for the naming scheme Category:English monosyllables, Category:English disyllables, Category:English trisyllables, Category:English tetrasyllables, et seqq. "1-syllable words", "2-syllable words", "3-syllable words", "4-syllable words", et seqq. may have the benefit of autosorting (though, presumably, "10-syllable words", "11-syllable words", "12-syllable words", "13-syllable words", autosort either before "1-syllable words" or between "1-syllable words" and "2-syllable words"), but they look very unprofessional. Moreover, using the №syllables nouns cuts the Gordian knot with regard to the words–terms dichotomy. — I.S.M.E.T.A. 00:44, 13 October 2016 (UTC)

If people think that the format Category:English 7-syllable words is unprofessional, sure, I'm fine with changing it. Although I prefer keeping it, because it's easier to read and it looks professional to me, too.

I don't think the "words" part is too problematic: I wouldn't want to add phrases and proverbs like curiosity killed the cat into syllabic categories anyway, so "words" looks fine to me in all cases. Due to the use of {{hyphenation}} in some entries of Portuguese phrases of proverbs, they were added in syllabic categories, but I'm not happy about it. Unless we want separate categories like Category:English 7-syllable SENTENCES. --Daniel Carrero (talk) 01:11, 13 October 2016 (UTC)

@Daniel Carrero: These are the first ten pages brought up by searching google:use guide numerals in text. If you read the revelant parts of those, you will see time and again the regulation that the numbers zero to nine be written out in words, especially in "humanistic" (as opposed to "scientific") writing; this is a widespread professional standard. Words of over nine syllables are comparatively very rare (that go-to English super-long word, antidisestablishmentarianism, has only eleven syllables), so the way to write the numbers one to nine will be the most relevant for us. But if we write Category:English one-, two-, three-, etc. -syllable words, we lose the benefits you cited of autosorting and visual parsing, meaning we might as well return to the original nomenclature you proposed: Category:English mono-, di-, tri-, etc. -syllabic words. Note that, of all the people who participated in this discussion, only CodeCat objected to your original nomenclature (though I found her objection to "the obscure Greek" pretty hypocritical in the light of some of the terms she uses in entries for reconstructions, like "amphikinetic inflection", "full-grade nu-present", and "athematic root aorist").
I agree with you that we wouldn't want these categories to include "phrases and proverbs like curiosity killed the cat", since each of those phrases' and proverbs' constituent words (curiosity + killed + the + cat) would be in its own category. However, languages sometimes borrow other languages' phrases wholesale (like English has done with de facto and the above-mentioned chronique scandaleuse); in those cases, the constituent words are unlikely also to be terms in the recipient language, meaning they would be omitted from the categories, leaving us no choice but to categorise the full phrases. It is in those cases that "the 'words' part is…problematic". Accordingly, because of the words–terms dichotomy, I therefore continue to advocate the Category:English monosyllables, Category:English disyllables, Category:English trisyllables, Category:English tetrasyllables, et seqq. nomenclature.
Apologies for the long post. I probably care about this issue too much. — I.S.M.E.T.A. 14:13, 21 October 2016 (UTC)

No worries, I think most of my posts are long too. Personally, at some point I decided it would be better just writing them without apologizing at all, or else I might as well add "Sorry" in my four-tilde signature to make it appear automatically. Now to the point: I'm aware, too, of the regulation that the numbers zero to nine be written out in words. It seems to work out exactly the same in English and Portuguese. Basically, I always see "one", "two", "three" or "um", "dois", "três", instead of "1", "2", "3" in books.

But, please read this: https://www.nngroup.com/articles/web-writing-show-numbers-as-numerals/

A few years ago, I had the habit of reading articles from Jakob Nielsen about internet usability, and this text is one reason why I'm convinced that it's a better idea to use digits, not words when writing online, as opposed to books. Other Wikimedia wikis uses some category names like w:Category:9th century, c:Category:9 (number). Wikipedia has number articles like w:4 (number). In my examples, the titles use digits rather than spelled out numbers. I don't know if there are many examples of Wikimedia wiki articles or categories using spelled out numbers like "seven" and "seventh". --Daniel Carrero (talk) 14:38, 21 October 2016 (UTC)

@Daniel Carrero: Unfortunately, I can't respond properly because clicking that link just generates the message "Server not found" for me. Could you copy and paste the article hereinafter, between {{rel-top}} and {{rel-bottom}}, please (if it's not too long)? — I.S.M.E.T.A. 18:53, 21 October 2016 (UTC)

That's strange, the link is still working properly to me. I don't think I can copy the whole article because it would be copyright infringement, can I? Please try this link instead: https://web.archive.org/web/20160805181535/https://www.nngroup.com/articles/web-writing-show-numbers-as-numerals/ If all else fails, I can e-mail the text to you. --Daniel Carrero (talk) 19:11, 21 October 2016 (UTC)

@Daniel Carrero: Nope, that didn't work either; this time the message read "Secure Connection Failed". Yes, please email me the article, if you wouldn't mind. — I.S.M.E.T.A. 19:20, 21 October 2016 (UTC)

The link was working for me earlier, but not now. It's probably due to the massive DDOS attack on the East Coast of the US going on right now. --WikiTiki89 19:33, 21 October 2016 (UTC)

@Wikitiki89: Oh? How did you find out about that? And who's doing it? Anonymous? — I.S.M.E.T.A. 20:22, 21 October 2016 (UTC)

@I'm so meta even this acronym: I heard coworkers talking about it and then I Googled it. I don't think it's known who's doing it, but they managed to take down high-profile sites such as Twitter, Reddit, and Netflix, among many other lower-profile sites. Google it. --WikiTiki89 20:25, 21 October 2016 (UTC)

@Wikitiki89: Interesting. It seems that Dyn was/is the target. — I.S.M.E.T.A. 21:00, 21 October 2016 (UTC)

@I'm so meta even this acronym: Hi, are you able to see the site now? --Daniel Carrero (talk) 17:03, 1 November 2016 (UTC)

Previous discussions:

• Wiktionary:Beer parlour/2012/April#Moving 'alternative forms' down in ELE
• Wiktionary:Beer parlour/2015/December#Alt forms BEFORE the definition?
• User talk:Daniel Carrero#Reordering L3 headers

I would like to see alternative forms down in the entry. But where could we place it exactly?

Here's one proposed order, I'm open to different ideas:

• L3: POS section
• L4: (Inflections and/or Usage notes, the order of these two is the subject of a separate discussion)
• L4: (Quotations -- but see a critique of this header here)
• L4: Alternative forms
• L4: Synonyms

--Daniel Carrero (talk) 17:23, 1 February 2016 (UTC)

Rationale:

• Having less things above the defitions is a way to promote the definitions.
• Alternative forms and Synonyms are similar concepts.

--Daniel Carrero (talk) 17:25, 1 February 2016 (UTC)

I agree, they belong close to synonyms. The way I see it, the headers that are "close" to the term in question come first, and then the relationship to the current term becomes less as you go down. —CodeCat 17:40, 1 February 2016 (UTC)

Also agreed. I recently ran into a situation where I couldn't decide whether to make ноль (nolʹ) and нуль (nulʹ) be alternative forms or synonyms of each other. It's easy to miss alternative forms when they're at the top. (And it's even easier to miss the "see also" notes at the very top.) Benwing2 (talk) 17:53, 1 February 2016 (UTC)

If they are to be moved below the definition, then a position above synonyms does seem like a good position for them. "Quotations" is unnecessary in most cases — when I see it, I can almost always move the quotations to be under one of the senses. - -sche (discuss) 23:14, 1 February 2016 (UTC)

A slight aside: even though we won't be a (relational?) database any time soon, if we are trying to enforce orderings of headings, perhaps we could make the editor pop up a warning where a proposed edit would cause sections to be out of the agreed order? Equinox ◑ 23:17, 1 February 2016 (UTC)

Would we make that warning appear before or after all entries are fixed to conform to the same heading order? If we do it before the entries are fixed, then when a user edits an entry with the wrong section order and leaves the section order unchanged, they will see the warning even though it is not his/her "fault". --Daniel Carrero (talk) 23:35, 1 February 2016 (UTC)

I'm just suggesting a general practice, not implementation details. If it can't be done it can't be done. Equinox ◑ 23:38, 1 February 2016 (UTC)

Ideally, if we can fix all entries, then make the warning appear in new edits, I'd support it.

If the warning thing can't be done (I didn't check), maybe we could use tags like the no-documentation, new-L2, etc. (wrong-section-order) --Daniel Carrero (talk) 23:53, 1 February 2016 (UTC)

• A counterargument, in re: Alternative forms and Synonyms are similar concepts:

Alternative forms are terms where (generally) everything matches except the graphemic representation.

Synonyms are terms where nothing matches except the meaning (and often just a subset of meanings).

As such, it has always seemed sensible to me that alternative forms would be towards the top: everything beneath applies to the given alternative forms. It has also always seemed sensible to me that synonyms would go beneath the definitions: synonyms generally only match a subset of meanings, with {{sense}} required to stipulate which. ‑‑ Eiríkr Útlendi │^{Tala við mig} 21:02, 2 February 2016 (UTC)

I agree, it generally makes sense to put the alternative forms at the top. Quite a few other dictionaries do it this way as well. Plus, I think that it divides information nicely between the top and bottom sections. Nibiko (talk) 22:13, 2 February 2016 (UTC)

Alternative forms can have different pronunciation, gender, inflection and even descendants. The line between alternative forms and synonyms is very thin. The only criterium seems to be similarities between the terms. So there is no assumption that "everything beneath applies to the given alternative forms", because it certainly doesn't in many cases. —CodeCat 22:26, 2 February 2016 (UTC)

ноль (nolʹ) and нуль (nulʹ) are good examples. They are both clearly derived from Latin nūllus, but possibly through different paths. The meanings are overlapping but not quite the same, and the declensions are related but different (ноль has two declensions, one of which borrows most forms from нуль). Other examples in Russian are воскресенье (voskresenʹje) (meaning "Sunday" and also "resurrection") and воскресение (voskresenije) (meaning "resurrection"), or e.g. мгновенье (mgnovenʹje) and мгновение (mgnovenije) (both meaning "moment, instant"). Benwing2 (talk) 23:37, 2 February 2016 (UTC)

• Hmm, that's quite interesting, thank you both. It seems that again Japanese might be the oddball here. Alternative forms for Japanese are mostly cases of graphemic differences that are otherwise overlaps. C.f. 山樝子 / 山査子 (sanzashi, “hawthorne, Chinese hawthorne”), or the more complicated example of 漏れる / 洩れる / 泄れる (moreru, “to leak (out from something); to be omitted, to be left off or out”). The etymologies, pronunciations, and senses overlap, with only some usage notes to clarify the different spellings. ‑‑ Eiríkr Útlendi │^{Tala við mig} 01:39, 3 February 2016 (UTC)
• In the case of Finnish myydä, the alternative form myödä can be traced to a separate Proto-Finnic form. So the doublet can be traced back to an ancestral language. Proto-Slavic *pljuťe and *pluťe are derived from different ablaut grades of the root. Serbo-Croatian still has both varieties, differing by dialect. Compare also Finnish auttaa vs avittaa. —CodeCat 01:53, 3 February 2016 (UTC)

An English example of ambiguity between alt forms and synonyms is finocchio, which listed "feminine forms" like finocchia as alt forms: in this case, there's no difference in meaning (they both mean "fennel"), but in the case of a (presumably Italian-derived) word with X-o and X-a forms where one referred to a man who did X and the other referred to a woman who did X, I doubt we'd list the forms as alternative forms, since the meaning as well as the pronunciation and (slightly) etymology would be as different as they are for finocchio vs finocchia; conceivably the plurals could be different, too. Obviously, there are other cases where it's clear that two things are alternative spellings, like realize (Oxford-British and American spelling) vs realise (alternate British spelling). - -sche (discuss) 02:35, 3 February 2016 (UTC)

Are there any examples of English etymological doublets that are treated as synonyms or alternative forms in modern usage, perhaps differing by dialect? —CodeCat 03:33, 3 February 2016 (UTC)

Some of the alternative forms of hajduk go back through different languages, e.g. hajduk is directly from Hungarian, haiduc is via Romanian, haidouk is via French. There are probably many words like that. In contrast, English borrowed Narragansett mishcùp (plural mishcùppaûog) four times with sufficiently different forms that I labelled them synonyms rather than alt forms: mishcup, scup, paugie, and scuppaug. Quasi-synonyms include regal and royal. You may also find Wyang's comment here interesting, about how "Every time Vietnam was conquered by China, the Chinese officials brought with them the Chinese pronunciation of the character at that time", leading to the same characters being borrowed repeatedly with subtly different pronunciation and sometimes meaning, e.g. 卷 (“to roll; a roll”) became cuốn, cuộn, cuợn, quận, quấn, quyển, quyền, and quyến. - -sche (discuss) 17:26, 3 February 2016 (UTC)

To me it seems so far like a problem with classifying certain things as alternative forms rather than a problem with alternative forms themselves. Just because a word is a cognate, doesn't necessarily mean that it's an alternative form. In Japanese, there are plenty of cognates, many are considered alternative forms, many are not. The line is drawn on a practical level. Furthermore, synonyms is far from being the only alternative to classifying something as an alternative form, as there are other headers such as related terms, see also, usage notes, coordinate terms, and for ubiquitous concepts in a language there is usually some template parameter. Nibiko (talk) 03:47, 3 February 2016 (UTC)

I think that synonyms, as mentioned above, may (and for a vast majority of words, in all languages, this is the standard) refer to a specific sense-meaning (or some of them) of both words (both words can be used interchangeably but only for some specific meanings in each of them). As alternative forms we must present "real" alternative forms aka where everything matches (in meanings of both words, the lemma and the synonym) except the graphemic representation. That's why we use {{sense}} in the section of synonyms but not in the section of alternatives. Dialectal variables must not confuse us and must not be taken into account. --Xoristzatziki (talk) 05:05, 3 February 2016 (UTC)

It sounds like you are proposing to get rid of all alternative forms as we have them, and rename alternative spellings to alternative forms. —CodeCat 17:49, 3 February 2016 (UTC)

• @CodeCat, are you talking about the label? I'm not aware of any ===Alternative spellings=== header. ‑‑ Eiríkr Útlendi │^{Tala við mig} 19:29, 5 February 2016 (UTC)
  • Alternative spellings are, generally, the only pair of words where everything matches except the graphemic representation. Right now, we treat them as a subset of alternative forms, in which other things may differ as well. If we only allow pairs, where the graphemic representation is the only difference, to be labelled "alternative forms", then we are essentially relabelling what is currently "alternative spellings" into "alternative forms". The implication seems then, that whatever pairs remain that were formerly alternative forms but not alternative spellings, would become labelled as synonyms. —CodeCat 20:39, 5 February 2016 (UTC)

• Support alternative forms after definitions: IMO, the definition/POS should be as early as possible because that's probably what people are looking for. Purplebackpack89 17:48, 3 February 2016 (UTC)

  I created Wiktionary:Votes/2016-02/Placement of "Alternative forms". --Daniel Carrero (talk) 15:42, 7 February 2016 (UTC)

i am user from Bangladesh. i wanted to add new BN word . so i need bot flag . Rahul amin roktim (talk) 03:37, 2 February 2016 (UTC)

You don't need the bot flag to add new words, just add them directly. Benwing2 (talk) 04:56, 2 February 2016 (UTC)

A bot gives you the ability to do an enormous amount of damage very quickly, if you don't know what you're doing. Why should we risk allowing that when you haven't edited a single entry here at English Wiktionary? Not only that, but you've been blocked at bn Wiktionary for continuing to run a bot on your main account after being told not to, which doesn't inspire confidence in your willingness to follow the rules. You need to edit here for a while without a bot so we can see that you know how to do things right- then, maybe, we'll give you permission to run a bot. Chuck Entz (talk) 08:20, 2 February 2016 (UTC)

Oppose per Chunk Entz. Bot flags are for 'creating words' anyway but for repetitive minor edits that would flood the recent changes. Renard Migrant (talk) 14:19, 2 February 2016 (UTC)

No need for a bot flag in the first place, and no reason for giving one to an unknown and untrusted user with few edits. Prior behaviour on other wikis only weighs further against. We should keep an eye on the user and block if they evade our bot policies. —CodeCat 22:28, 2 February 2016 (UTC)

In fact zero edits in the main namespace. First ever edit for that user was the one that started this thread! Renard Migrant (talk) 22:36, 2 February 2016 (UTC)

I have no idea why he/she would try to evade the bot policy yet again by private request. --kc_kennylau (talk) 13:25, 6 February 2016 (UTC)

Proposal: Removing the Quotations header from all entries.

1. If there are quotations in the Quotations header, move them to the respective senses.
2. If there is just {{seeCites}} (which links to the citations page), remove the Quotations header altogether, it's just a duplication of the citations link at the top of the entry.

For example, remove the Quotations header from abyss.

Previous discussions:

• Wiktionary:Beer parlour/2010/July#Value of the Quotations header?
• Wiktionary talk:Votes/pl-2015-12/Headings#Quotations

Can we do that? --Daniel Carrero (talk) 17:31, 2 February 2016 (UTC)

{{seeCites}} can also be moved under whatever senses it applies to (being converted to {{seemoreCites}} if there are existing citations). All of this can be done in most cases. But in a few cases it's unclear which sense a quotation applies to; housing these is the stated reason for the existence of the (oft-misused) Quotations header. What should be done with such citations if the Quotations header is removed? I suppose they could just be moved to the citations page. - -sche (discuss) 22:23, 2 February 2016 (UTC)

We add quotations and other usage examples to illustrate usage. If we don't even know what they illustrate, then they don't really belong in the entry. —CodeCat 22:29, 2 February 2016 (UTC)

Massively support. But 'moving them to the respective senses' has to be done by human editors, so it's a big job. Like CodeCat says, just move them to the citations page and put them back into the entry when a human user gets round to it. Renard Migrant (talk) 22:39, 2 February 2016 (UTC)

Goods points from both of you. Yes, it seems like a bot could just move 'em all to the Citations pages. (A bot could even skip cases where the citations page already existed, if that would make things easier; that would probably cut the number of remaining quotations sections down to something humans could manage.) For reference, as of the last database dump 4223 entries had quotations sections. - -sche (discuss) 22:55, 2 February 2016 (UTC)

I dislike the idea of relegating them to the citations page, but I do support getting rid of the quotations header. The only time I've seen one where the quote couldn't be moved to a specific definition is at PC, which has a quotation containing three different senses of the word. Andrew Sheedy (talk) 00:15, 3 February 2016 (UTC)

According to WT:EL, if it's possible to sort quotations under a sense, it's acceptable to do so. In my experience, only a tiny fraction of the 4223 entries which use quotations headers use them for the WT:EL-approved purpose of housing unclear quotations; most entries can be cleaned up on sight with no change in policy (and for years I have been cleaning them up when I rarely encounter them). - -sche (discuss) 23:01, 2 February 2016 (UTC)

I don't feel super-comfortable with this; I tend to miss the Citations page and I imagine I'm not alone here. Benwing2 (talk) 23:40, 2 February 2016 (UTC)

Might as well. Be warned that there might be a handful of pages where this header has been used to add a citation of uncertain or missing meaning. Equinox ◑ 00:32, 3 February 2016 (UTC)

On reflection, ====Quotations==== should be kept but should only ever contain {{seeCites}} and not the actual citations. I share Benwing's concern also, but I think the idea is that we log all the bot created citations page (Special:Contributions would do it automatically for example) and move them back into the entry as fast as humanly possible. Perhaps indeed all pages with a citations page should contain {{seeCites}} under the quotations header, which I think, could be done by bot. Providing the bot can read the language statement in {{citations}} and put the quotations header in the right spot. Renard Migrant (talk) 13:36, 3 February 2016 (UTC)

What's the benefit, when a blue-linked Citations tab at the top already indicates the presence of such a page? Equinox ◑ 03:55, 4 February 2016 (UTC)

I'm with Equinox there. --Daniel Carrero (talk) 04:04, 4 February 2016 (UTC)

The benefit is that those who are focusing on the entry itself rather than on the user interface might see it where they wouldn't otherwise. Also, not everyone recognizes "citations" as meaning quotations. Chuck Entz (talk) 04:08, 4 February 2016 (UTC)

Your last sentence could be used as a good argument to change the Citations: namespace into Quotations:. (Citations:abyss -> Quotations:abyss) --Daniel Carrero (talk) 04:17, 4 February 2016 (UTC)

I created Wiktionary:Votes/2016-02/Removing "Quotations". --Daniel Carrero (talk) 04:55, 10 February 2016 (UTC)

User:Gloria sah asked me:

I noticed that in the page "cà", since I wanted to write about Emilian-Romagnolo language, I had to write the abbreviation "egl" (that conversely usually refers only to Emilian language) instead of "eml"=Emilian-Romagnol language. Do you think in the future I'll have to write "egl" again, or there is something to fix upstream? Thank you in advance, --Gloria sah (talk) 16:39, 2 February 2016 (UTC)

I don't know enough about these varieties to answer the question. Anyone? Benwing2 (talk) 17:32, 2 February 2016 (UTC)

@Gloria sah: ISO 639-3 has deprecated eml and now treats Emilian egl and Romagnol rgn as two separate languages. Therefore, please always use egl for Emilian words and rgn for Romagnol words, and use the headers ==Emilian== and ==Romagnol==. If a word happens to be spelled the same in both languages, you can create two entries. —Aɴɢʀ (talk) 18:56, 2 February 2016 (UTC)

Although (Gloria), if you think Emilian and Romagnol should be treated as a single language, we could have a discussion of the appropriateness/inappropriateness and benefits/drawbacks of that. - -sche (discuss) 19:08, 2 February 2016 (UTC)

Thank you for your precious answers. I'll ask my colleagues too. --Gloria sah (talk) 20:01, 2 February 2016 (UTC)

Who are your colleagues? Renard Migrant (talk) 21:56, 2 February 2016 (UTC)

My eml.colleagues, I meant. Now, it's ok as per Angr told me here above. Thank you and good luck, --Gloria sah (talk) 07:18, 3 February 2016 (UTC)

Oh right, there's a unified Emilian-Romagnol Wikipedia rather than two separate ones. —Aɴɢʀ (talk) 10:09, 3 February 2016 (UTC)

I'm not a big fan of WT:EL#Flexibility. That section was added in this diff from 2006 by Eclecticology and has been kept completely unchanged for 10 years. (adding a comma and minor formatting don't count) See also this diff of just the section, compared between 2006 and now.

Here's what I think about that text:

1. "While the information below may represent some kind of “standard” form, it is not a set of rigid rules."
   • No, I believe they are. Granted, some information in WT:EL may be outdated or contradictory so it tends to get ignored, but the voted rules and standard formatting tend to be followed more seriously. In 2006, our grasp of what exactly should be the entry layout was in an earlier stage of development, so I'm willing to bet that making up rules as you go along was something more sensible then than it is now.
2. "You may experiment with deviations, but other editors may find those deviations unacceptable, and revert those changes. They have just as much right to do that as you have to make them."
   • Ok, that does not seem to be something we want to encourage. Deviations from the standard format tend to get reverted on sight. WT:EL is directed at newbies for some extent, so I wouldn't want them to think they are in complete control of the presentation of the entry and have ideas like "I'll color my entry completely pink, it's going to be more beautiful" or something. To be fair, seasoned users would probably think of new ways to do stuff that actually make sense, but they would normally be expected discuss these things anyway, I think.
3. "Be ready to discuss those changes. If you want your way accepted, you have to make the case for that."
   • However sensible that may be, it's not a layout rule.
4. "Unless there is a good reason for deviating, the standard should be presumed correct."
   • This sentence could be added to any policy without changing the content in any way. WT:CFI could say: "Unless there is a good reason for deviating, the standard should be presumed correct." WT:BLOCK, WT:BOT, WT:AJA, etc., all of them. So the sentence can be removed safely.
5. "Refusing to discuss, or engaging in edit wars may also affect your credibility in other unrelated areas."
   • That's advice concerning human interaction, that's not a layout rule.

Can we remove WT:EL#Flexibility? --Daniel Carrero (talk) 14:16, 3 February 2016 (UTC)

No I think flexibility is a great idea as it reflects actual practice (which is the major problem with WT:CFI as I see it; it doesn't represent what we actually do). The rules should follow standard practice, not the other way around. Renard Migrant (talk) 14:43, 3 February 2016 (UTC)

I don't like most of it either. Talking about what "right(s)" editors have seems irrelevant to the page, and the implied threat about "refusing to discuss" somehow reminds me of that awful TODO Group Code of Conduct. Equinox ◑ 15:23, 3 February 2016 (UTC)

We need some freedom in at least one of two places: in having only rules that have very broad consensus OR in loose enforcement of rules. The second option is much like real life, in which many laws are not enforced with any regularity.

In our little world, IMO, we need more help in improving content (In English, that means quality more than coverage.) than we need prohibitions of non-standard formatting or template use. I would hope that we would get more of such help. Instead we get more standardization. DCDuring TALK 16:00, 3 February 2016 (UTC)

If anything in CFI we should have a flexibility clause, that consensus overrides WT:CFI as that's what happens in vivo. Renard Migrant (talk) 16:28, 3 February 2016 (UTC)

I get it that you are comparing the need of standardization vs. the need for improving content. But I don't suppose you are arguing that standardization is a bad thing? Random example: If we didn't have a standard format for translation tables, then we wouldn't have an "add translation" gadget that works properly, it would be more tedious to add translations and we would probably have a smaller number of translations than what we have now. --Daniel Carrero (talk) 16:33, 3 February 2016 (UTC)

A great deal of our standardization IS a bad thing. For templates it often is done for reasons of tidiness or to give our technical adepts some more or less challenging problems to work on, unaccompanied by any improvement in ease of use for contributors or users. Some standardization of format, headings and templates may have bad effects on languages for whom we have no current contributors to express the problem.

What has been done to make it easier to improve definitions, especially in entries for polysemic terms? To eliminate the use of rare, obsolete, and archaic English terms in definiens? To compile a defining vocabulary? DCDuring TALK 20:23, 3 February 2016 (UTC)

@DCDuring Your criticism is not very specific, do you want to discuss some template or style rule or change in particular? In any event, I don't think you can lecture anyone for not helping in a particular way, since we're a volunteer project, people edit where they choose to. Do you think the presence of WT:EL#Flexibility as it is currently written helps Wiktionary? If I created the vote to delete the section, do you think you would support, oppose, abstain? --Daniel Carrero (talk) 03:37, 4 February 2016 (UTC)

<rant>It's a matter of the apparent interests of many of our contributors. Many seem to be interested in all the fascinating tricks that software can be made to do. Although normally our better technical contributors don't break the infrastructure, many reforms disrupt habits, time-saving user snippets, and user consensus (or unearth buried hatchets). The uniformitarian impulse seems to stem from the desire for universally applicable software. All irregularities need to be eliminated to make the wiki safe for relative simple and dramatic "innovations". (I can't say solutions, because they often aren't.)</rant> I am actually afraid to ask for any technical help other than bug fixes because I am afraid of the unwanted consequences. I may take a chance next year and ask for help when the MW folks ask for ideas. DCDuring TALK 03:52, 4 February 2016 (UTC)

@DCDuring: Re "I am actually afraid to ask for any technical help other than bug fixes because I am afraid of the unwanted consequences.": Ok, I don't think there's nothing wrong with doing completely new stuff, it's just that I'd expect these things to be discussed and approved by the community first, that's all. If a new idea is bad, hopefully problems can be spotted in the discussion of the proposal, right? Let's not change the whole system without warning. (I'm being hypocritical if I did major changes in the past without discussing; still, the right thing is to discuss first.) OTOH, if it's a good idea that people want, then I'd argue it should be implemented anyway. -- Did you like the system of Template:votes where you can see how many people voted? :) It was properly discussed. I think that's a complex "innovation" that I could do right. Obviously we can talk if you disagree. -- Again, there could be some specific templates/changes/etc. that you'd like to discuss.

On that note, I'm still going to create a vote on deleting Flexibility if no one minds or has a different idea. I thought about maybe rewriting the section but there's little related to entry layout written there. If there's any piece of text people would like to keep ("Be ready to discuss those changes. If you want your way accepted, you have to make the case for that." is sensible, as I pointed out.), that could be done in some page other than WT:EL. --Daniel Carrero (talk) 06:41, 4 February 2016 (UTC)

I created Wiktionary:Votes/pl-2016-02/Removing "Flexibility". --Daniel Carrero (talk) 04:35, 9 February 2016 (UTC)

Is the purpose of this best spun as "to legitimize the de facto unvoted-on imposition of inflexibility by the design and implementation of templates"? DCDuring TALK 16:02, 13 February 2016 (UTC)

There are some languages which can reuse adjectives as adverbs without modifying them, for example German and Romanian. We could add an adverbial section to an adjective like laut, simply defining it as loudly. This would be technically correct, would make the project more complete, and I suppose that it wouldn’t harm anybody, but this could be wasteful or unprofitable for almost everybody except for absolute beginners of the language (who would probably expect a closely‐related language to have extremely similar laws and functions like theirs). For natives, adverbial uses of adjectives are seen as both given and obvious. I’d like to read your thoughts on the matter. I’m remaining neutral for now. --Romanophile ♞ (contributions) 17:56, 3 February 2016 (UTC)

For Dutch, adverbs with the same meaning as the adjective are not given separate entries, but are instead listed as "adverbial" in the inflection table of the entry. See snel, WT:ANL. —CodeCat 18:35, 3 February 2016 (UTC)

But there must be at least some adjs that can't be advs, right? Equinox ◑ 19:26, 3 February 2016 (UTC)

Spanish is similar. But different too. --Ce mot-ci (talk) 15:33, 4 February 2016 (UTC)

Previous discussion: Wiktionary:Beer parlour/2012/December#Є/є in Old Church Slavonic

In the previous discussion linked to above, it seems we were in agreement to switch to е. What happened to that? I still strongly dislike the use of є. --WikiTiki89 23:43, 3 February 2016 (UTC)

@CodeCat, Angr, Mzajac, Atitarev, Ivan Štambuk, Useigor: Is anyone interested in going through with this? --WikiTiki89 21:34, 18 February 2016 (UTC)

I have no objection to having all OCS words moved from є to е, but I'm not going to do it myself. It's way too big a task for someone who doesn't know how to run a bot. —Aɴɢʀ (talk) 22:05, 18 February 2016 (UTC)

I'm not asking you to do it. Just for your opinion on whether it should be done. --WikiTiki89 22:10, 18 February 2016 (UTC)

I’m not up-to-date on the subject, but it still seems to be the right thing to do. I haven’t noticed any Unicode changes that would change my mind.

Note that U+0454 Є є is also correctly used as a variant character in some places, in some recensions, alongside of U+0435 Е е, so I don’t know if a blanket renaming of all our entries would be correct. The “official” details appear to be outlined in a recent technical note at Unicode.org. See letters table on p 11, mention of upper and lowercase forms bottom of p 39, glyph variants table p 42, transliteration table p 80. —Michael Z. 2016-02-24 00:11 z

Thanks for the link! @CodeCat, Atitarev, Ivan Štambuk, Useigor: By the end of the month, I'm going to take your silence as consent. --WikiTiki89 16:04, 26 February 2016 (UTC)

@Wikitiki89: I will abstain, i don't know OCS grammar. However i see that ЭССЯ and Черных use є. In Russian Wikipedia i read that є is being used to distinguish forms with homophony. —Игорь Тълкачь (talk) 18:13, 26 February 2016 (UTC)

Abstaining as well, as I don't know which one is right. I did have a clearer opinion on this back in 2012 when I was interested and read on the subject but I don't remember now, LOL, but my old post seems to match your change. Go ahead if you think you know what you're doing. --Anatoli T. ^{(обсудить}/^вклад) 05:53, 27 February 2016 (UTC)

Update: I've finished moving all pages to entry names with "е". I haven't fixed all in-entry uses yet. Quotations will obviously be left as attested. --WikiTiki89 22:58, 15 September 2016 (UTC)

The section WT:EL#Anagrams and other trivia is an explanation of anagrams, followed by the paragraph below. Can we remove the part "or some other suitably explanatory heading"?

• Other sections with other trivia and observations may be added, either under the heading “Trivia” or some other suitably explanatory heading. Because of the unlimited range of possibilities, no formatting details can be provided.

Rationale:

• If there are any new trivia ideas, just "Trivia" should be fine in most cases, other names for trivia sections can be discussed later if needed. I don't recall the use of Trivia sections other than "Trivia", "Anagrams" and "Statistics". If anything, the Statistics section should either be mentioned explicitly in WT:EL or deleted. The Statistics section is used in entries like this: man#Statistics. It serves the purpose of keeping {{en-rank}}, a template that is currently in RFDO: WT:RFDO#Template:en-rank.

--Daniel Carrero (talk) 08:31, 4 February 2016 (UTC)

Four policy proposals in five days feels a bit much, doesn't it? A user who's away for a single week might miss a lot. Equinox ◑ 13:06, 4 February 2016 (UTC)

He harbours (not-so-)secret plans to rise to the position of WT overlord. All hail! --Ce mot-ci (talk) 15:32, 4 February 2016 (UTC)

--Daniel Carrero (talk) 15:56, 4 February 2016 (UTC)

@Equinox: I'll reply in the next section. I'd like to keep this section only for the proposal of editing WT:EL#Anagrams and other trivia, in case I create a vote later and link back to this discussion. --Daniel Carrero (talk) 15:56, 4 February 2016 (UTC)

About @Equinox's question in the discussion above:

I have a file on my PC listing my multiple pending Wiktionary projects. I've been trying to reduce it in size by creating the proposals you are seeing in some of the discussions above, in the course of the last days. :p For example, this link is more or less how I envisioned WT:EL largely revised by me on October 2015. But some things changed since then, so that's not the exact policy I would propose.

So, as Equinox pointed out, I created 4 policy proposals in the last 5 days. (There are also a bunch more BP discussions I created on January 31.) One may argue that I'm rushing things up, but IMHO that's the opposite, I'm taking my time. (If a certain topic is arguably very minor and/or uncontroversial, like the Trivia section thing, does it even count?) I'm trying to get all the discussions I want out of the way, there are others I didn't find the time to create. Not to mention that I'm participating in all the discussions and creating a bunch of related votes. (off the top of my mind, some unresolved issues to be discussed in short-term are: appendices for letters, deleting some index pages, I'm creating a periodic table for the entries, I'd like to see checkmarks in the vote box when I voted and X marks when I didn't vote, it does not make sense that WT:EL#The entry core is nested under WT:CFI#Additional headings, and Beer Parlour Archive Secret Project).

Re: "A user who's away for a single week might miss a lot." But policy changes can only be implemented with a vote, giving the user more time to review the changes. Also, when people complain of something wrong during the course of a vote, I usually create separate votes to address these issues, so that's more votes I either have already created or plan to create in the future. In the end, it takes some time to repeatedly revise the text of some of our voted policies. :p Last year, I created 3 NORM votes (Wiktionary:Votes/pl-2015-05/Normalization of entries, Wiktionary:Votes/pl-2015-07/Normalization of entries 2 and Wiktionary:Votes/pl-2015-11/NORM: 10 proposals), 2 headword line votes (Wiktionary:Votes/pl-2015-10/Headword line and Wiktionary:Votes/pl-2015-12/Headword line 2), etc. to address points raised in the previous votes.

Bottom line is: Please let me continue creating a lot of proposals. (if possible) :) In most cases that I have planned, they should be just codification of actual practices (either obvious ones or ones that may require discussion). There's some new stuff, but IMHO those should be helpful if other people agree (appendices for letters = remove clutter from letter entries), I'll give more details when I actually create the discussions. (Also I wouldn't mind dumping my whole Wiktionary.txt file on my Sandbox, but I can't promise it's completely intelligible.) --Daniel Carrero (talk) 15:56, 4 February 2016 (UTC)

@Daniel Carrero: I'd suggest that you create a page like User:Daniel Carrero/Suggestions and get some feedback now before you propose them for real. —Justin (koavf)❤T☮C☺M☯ 14:45, 5 February 2016 (UTC)

Ok, sounds good. --Daniel Carrero (talk) 15:26, 5 February 2016 (UTC)

Then again, the only difference between making a list of 4 proposals as separate BP discussions and making a list of 4 proposals in my userspace is the location, unless I use my userspace to make a compact/dumbed down list of multiple items. If I'm able to type full proposals and I'd like some feedback, maybe BP is the best place after all. --Daniel Carrero (talk) 15:29, 5 February 2016 (UTC)

Yeah, I don't see the point in moving these discussions to userspace. (I think the original complaint was that there are too many proposals being made in a short time, not where they were being made.) - -sche (discuss) 15:42, 5 February 2016 (UTC)

Dumbed down list:

Part 1 - new things

• appendices for letters that should replace most letter entries
• deleting most index pages
• creating a periodic table for the entries
• seeing in Module:votes whether I voted or not in a vote
• it does not make sense that WT:EL#The entry core is nested under WT:CFI#Additional headings
• Beer Parlour Archive Secret Project
• move compass points template to "Template:table:compass points/en"
• character map
• I don't like that "# {{given name|female|lang=es}}." and other templates require a manual dot but maybe there's nothing to be done
• update WT:NS
• Appendix:Superscript and subscript
• redirect ² to 2, ⁿ to n (?)
• pics of myself for Appendix:Gestures
• gloss database in a module
• Appendix:Date and time formats
• script code + categories for 1, 2, 3...
• Portuguese conjugation page
• rewrite blocking policy
• actual voting policy page
• long names for topical categories
• rename request categories
• check if a table template is being used in all pages

Part 2 - codify or standardize rules

• you can't format abbreviations as: laugh out loud
• {{pedia}} and other external links templates should use a bullet point
• place images in the language sections, not together with {{also}}
• language-specific templates are preferable to {{head}} when they exist (?)
• don't add ---- except between languages
• quotations in chronological order
• list of languages with stripped accents
• translations of: kg, etc
• delete WT:Anagrams if WT:EL#Anagrams is enough
• explain better the difference between External links and References, if any
• mention {{ttbc}} or {{trreq}} or whatever we are using now
• mention {{trans-see}} in a policy
• make Help:Translations out of Wiktionary:Translations
• edit WT:NORM's rule about "#:*" together
• no links in the gloss between parentheses (?)
• standard style for Citations: (gloss: italic or between quotation marks; also require ----)
• use Unicode "micro sign" in English instead of Greek letter, etc.

This is mostly what I never said I wanted to do. If I said it somewhere, it's still on my list, but I didn't want to repeat it here. --Daniel Carrero (talk) 03:27, 6 February 2016 (UTC)

• I for one am concerned above all with there being too many votes. I am less concerned about too many proposals, unless lack of opposition to these proposals in Beer parlour leads to their implementation. I do find the volume of the proposals tiring and the added value to the project minimal. Also, the proposals contain, to my mind, too many fairly obvious defects. But then, multiple editors will probably think otherwise; I don't know. --Dan Polansky (talk) 19:49, 14 February 2016 (UTC)

  I love the line which says "mention {{ttbc}} or {{trreq}} or whatever we are using now". This summarises so perfectly where all these improvements to templates and policies and whatnot brought us ... --Droigheann (talk) 20:19, 14 February 2016 (UTC)

  @Dan Polansky: Re.: "the added value to the project minimal". Most of my current votes are proposed edits to WT:EL. Some are questions about the placement of certain headings, which also are expected to affect EL. That's the only way to edit the policy, which I'd like to do quickly if possible. When I created the vote Wiktionary:Votes/pl-2015-12/Translations, it proposed too many changes at once and failed. I found it seems to be best proposing small changes separately.

  "the proposals contain, to my mind, too many fairly obvious defects" Feel free to discuss them. Often, a mistake is fixed or an improvement is implemented before the votes start. Then, when people find something wrong after the vote started and oppose it, most of the time, it's something that was not mentioned before and could have been fixed if people noticed it earlier. Since there are too many votes and discussions about them going on, I'm not too worried if this happens. Just oppose the current vote, I should be able to fix it in the next vote using your suggestions and complaints. I created multiple votes about specific aspects of translations now because that large translations vote failed. Most of my recent votes passed either at the first time or the second time after a revision, but I don't have the actual number of votes that passed/failed.

  @Droigheann: Are you critizing the fact that templates and syntax often change? The intention of my "mention {{ttbc}} or {{trreq}} or whatever we are using now" was to use WT:EL to mention how to request translations and request the current translations to be checked, if other people support that idea. I'm not creating the actual proposal right now, it would require further thought about the wording, etc. In fact, "mention both {{ttbc}} and {{trreq}}" would seem more sensible because we do both things, except {{trreq}} is currently a redlink. --Daniel Carrero (talk) 04:28, 15 February 2016 (UTC)

  Criticising that they often change? Rather, bewailing that they change much too often. Bewailing how my watchlist is larded with edits simply substituting some letters in a template for other letters with no difference for a reader (I don't even want to imagine what I'd see if I allowed my watchlist to list changes by bots). Bewailing that I have to do edits like this to get entries out of a request category. (I rather doubt the original contributor took the pains to make the translation but not to check it was visible, especially as there are more entries like this; I rather suspect this somehow happened as a consequence of the usex->ux move.) Bewailing that I'm no longer certain when to e.g. mark gender by simple |m}} and when by |g=m}} and have to edit by "trial, preview and error". Bewailing that we are wasting time by supporting a text by a vote in January and almost immediately vote on changing it in February. On votes in which Proposal 1, if supported, is followed by Proposal 2, allegedly making the result more specific, but actually consisting of several options half of which effectively annul Proposal 1. Bewailing that after 10 years of the project we're probably spending as much time discussing format in Beer parlour as we are by discussing contents in Tea room. I could rant on like this all night. You say you want to "help new users to understand our entries by using the policy, not just by copying the layout of other entries". I have no doubt you do. But may I suggest to you that all this flux may drive even not-so-new editors to doing exactly that? Why should I care about learning templates and studying policies when I have well-grounded suspicion that one year down the line half of what I've learned shall have been changed? Why not just edit by copypaste-and-edit or, alternatively, in plain text, using only my own horse sense and the very basic markup of ==, #, *, '', ''', ], and "leaving proper formatting to the guys in the IT and legal departments, you know mate, they're the only ones who know what's in vogue this week anyway"? --Droigheann (talk) 01:05, 16 February 2016 (UTC)

  @Droigheann: Ok, let's see if I can add something to this discussion. But I'll talk about my proposals and leave aside (for the moment) the issue of template moves. I'm usually supportive of the template moves you mentioned but I need more time to think about what people have been saying and what can I say about the subject. I'd use a separate thread for that, so for now I'm just going to talk about my proposals, which are, strictly speaking, the current topic.

  In the interest of openness, I'll repeat one thing that I'm planning to do, so other people can tell if it's a good idea or they'd rather ask me to stop. I'll probably create the "version 2" of multiple EL votes soon. The reason is simple: people keep suggesting improvements or complaining about problems with the votes, I'd like to implement them, and I'd like to do it fast. After the 1st language vote passed, I created the 2nd vote because there were some complaints (that nobody said in the discussions or the talk page, they said it while casting their votes and nobody was too specific either) and I'll probably create the 3rd language vote next; there's already some discussion on how could WT:EL#Language be further edited. The rules in the 1st and 2nd language votes are the same (actually, the 2nd vote proposed adding 1 rule); the 2nd vote proposes changing a lot in the presentation, but that's because of the people's complaints. These proposals are just normal revisions, except we need votes to edit WT:EL.

  Let's get one thing out of the way: concerning WT:EL, I'm most certainly not in the habit of changing my mind and proposing contradictory edits arbitrarily. Say, after Wiktionary:Votes/pl-2015-12/Part of speech passed, Acronym, Abbreviation and Initialism were officially disallowed per WT:EL#Part of speech, so I don't have the intention of creating a new vote to reuse them as allowable headers. So, if I'm doing things right, the multiple votes should be going in the direction of building something uniform out of consensus, (because if there's no consensus, the votes would fail) these are not arbitrary changes.

  I don't know if many things should change a year down the line; I'd probably say yes. If there are, say, 50 things need changing, let's do it fast. Revising EL is a good thing, at least in my opinion, and that includes large revisions. There are votes for almost all sections in WT:EL, currently. My answer to your last 3 questions should be simple enough: I'd just like WT:EL to reflect the dictionary in the most accurate way possible to the current date, so no matter how quickly the dictionary changes our policy should stay updated, so copying entries would be optional; nobody should be forced to copy entries because the policies failed them. You'd just go to WT:EL and you'd understand how the rules work. --Daniel Carrero (talk) 06:19, 16 February 2016 (UTC)

I doubt that anyone here has the foresight to know all the consequences, not just the hoped-for ones, of any proposal, but the resulting uncertainty cannot be avoided. I am certain that no one here has the ability to understand the consequences of multiple simultaneous proposals (including options) which can succeed or fail in various combinations. This second difficulty can be avoided by resolving issues one at a time and providing sufficient time for more folks to understand the consequences of the implemented proposal. Adding poor wording to the proposals just makes it even less clear what the consequences of single and multiple proposals might be. DCDuring TALK 13:12, 16 February 2016 (UTC)

@DCDuring: Can you name 2 votes that are conflicting in the way you described? For example, I only created multiple translation votes after the large Wiktionary:Votes/pl-2015-12/Translations failed, and the multiple translation votes are completely separate subjects (namely: automated transliterations, taxonomic names and literal translations of idioms). --Daniel Carrero (talk) 14:18, 16 February 2016 (UTC)

I don't find it worth the time. The point is that only someone who has been working on this full time for a week or two, ie, you, is in any position to determine that. That narrows all of the voting to a matter of trusting your judgment about possible consequences of combinations of outcomes. Frankly, I don't have that trust. I see haste and sloppiness and don't have the time or willingness to verify by reviewing each combination of proposals. The simpler course is to accept low-risk proposals and reconsider others in due course, say, in three, six, or twelve months. DCDuring TALK 14:43, 16 February 2016 (UTC)

That's fine by me, I guess. I'd like you to read each proposal carefully if you had the time/willingness, but I accept that we have the freedom to vote based on our own reasons. There are also multiple discussions associated with that vote, which I know take time to read and take part on.

I think some (though probably not all) of the proposed changes maybe will take more time to be effected, so I can't predict anything but maybe you might even have three, six or twelve months in some cases. Perhaps the largest proposals take a longer time to be revised and accepted, since they have a higher probability of containing mistakes to be fixed -- mind you, I often propose a new EL text and people complain about a mistake or omission but it was present in the current EL text as well, like when you noted that my large Translations proposal didn't account for translations of taxonomic names; the current EL was also guilty of that. Take WT:NORM as another example. It went through a number of voted revisions since Wiktionary:Votes/pl-2015-05/Normalization of entries was created by me in May 2015 and failed, multiple proposals were accepted or rejected and now it is a complete voted-on policy.

@Droigheann: Re "On votes in which Proposal 1, if supported, is followed by Proposal 2, allegedly making the result more specific, but actually consisting of several options half of which effectively annul Proposal 1." That was @Wikitiki89's idea at Wiktionary:Beer parlour/2016/January#Placement of "Usage notes", but I support it. I had something different in mind before supporting it, but I agree that Wikitiki89's idea is good. If the proposal 1 passes, no matter what option from the proposal 2 passes, it's a step away from the current rule that the "Usage notes" section can be placed wherever in the entry, which I don't believe is true. --Daniel Carrero (talk) 15:58, 16 February 2016 (UTC)

I don't care whose idea it was and I don't have the time to read yet another lengthy discussion; I doubt it would disclose to me any significant difference between the current "wherever" and Proposal 2 Option C's "up to personal preference". But more importantly: what I'm complaining about is that the current development gives me no confidence in your "You'd just go to WT:EL and you'd understand how the rules work" without adding "at the moment, but of course you'll have to go there pretty often". How many people have the time? You seem unable to understand, despite the fact that you yourself have basically stopped contributing in the mainspace, that in this deluge of changes and proposals for changes there are few people who have both the time to notice them properly, let alone think them through and even discuss them, and the time to work on entries. And although I don't underestimate the usefulness of having rules, I also try not to lose sight of the fact that a poorly formatted entry containing the information being looked for is more useful than a perfectly formatted entry not containing it. --Droigheann (talk) 00:16, 17 February 2016 (UTC)

@Droigheann: You are repeating some of your points, so I won't answer them in this message to avoid repeating myself too. Maybe we should agree to disagree. I realize it would be unfair to you if by "agree to disagree" I meant "we should stop discussing, I'll ignore you and create more votes". But as I said below, I can stop creating votes for a few months even if I don't particularly like the reasoning behind it, if other people think it would be better this way. One thing I didn't ask to you yet is: Would you keep WT:EL the way it is now? It is linked in the {{welcome}} and {{welcomeip}} so it has high visibility, especially to newbies. If there are ways to improve the policy, then it needs editing most urgently, in my opinion. The reaction to WT:EL that you described is much better to me than the current "Yes, WT:EL is the right place to go for our layout rules... but ignore it when it is outdated or internally inconsistent." --Daniel Carrero (talk) 00:54, 17 February 2016 (UTC)

By all means let us agree to disagree, I've been through enough debates in my life to recognise one with infinitesimal chance of one party convincing the other. I'm not telling you to stop creating votes, I'm just telling you that in my opinion what you're doing (or rather, the way you do it) is counterproductive (and therefore vexing me), but of course that's my opinion versus yours (and I believe several editors' on either side). Similarly to your question: You're afraid people would ignore WT:EL because they'll perceive it as outdated or internally inconsistent, so you want to change it completely and quickly and keep changing it often; I'm afraid people would ignore WT:EL because they'll perceive it as unstable or inconsistent with actual practice, so I'd prefer gradual changes thought out properly enough for people to remember them and use them for quite some time before they need to be changed again. --Droigheann (talk) 02:48, 17 February 2016 (UTC)

Any proposal, once it has achieved consensus, can only be reversed by a consensus to undo or correct it. That means that only an obvious disaster with a simple remedy is likely to be corrected, even though a majority dislike the result. I don't think that any but the most clearly beneficial, simple proposals deserve that advantage. The other proposals can wait a few months for a vote. Most would benefit from copy-editing, if not total rewrite, anyway. DCDuring TALK 17:17, 16 February 2016 (UTC)

There are a few ongoing discussions that I'd like to create more votes for. (maybe 10 more votes) After that, maybe I could refrain from creating any votes from March to May 2016, to give time for people to observe the outcome of the current votes? What do you think about this idea? --Daniel Carrero (talk) 17:53, 16 February 2016 (UTC)

That will be too late IMO. DCDuring TALK 13:22, 17 February 2016 (UTC)

You also said "Stop NOW" in your edit summary, but I don't want to stop right now because of the reason I said in my message directly above yours. My idea of not creating any vote for 3 full months is a compromise between my "let's create as much votes as needed to edit WT:EL" and your "stop". After I create my 10 or so votes, I'll stop creating votes for 3 months. --Daniel Carrero (talk) 16:49, 17 February 2016 (UTC)

@Dan Polansky: You have no right to be concerned with there being too many votes, since these votes are a direct result of your own opposition to direct changes to the policy pages. --WikiTiki89 19:48, 16 February 2016 (UTC)

I rather think votes are a direct result of somebody creating them. --Droigheann (talk) 00:16, 17 February 2016 (UTC)

@Wiki: That is quite obviously incorrect. Yes, my and other editors' insistence on policies being edited only via votes contributes to there being policy votes. After all, we have no taste for Animal Farm being replicated in the English Wiktionary. The barn wall should better be vote-controlled, although revision-controlled barn wall is already a huge step in the right direction. But no, that alone does not force anyone to create a high volume of less-than-ideally drafted votes for other editors to burn their attention on. Moreover, the more votes are running at the same time, the more they lose their vote-character or votehood and the less reliable evidence they become of presence or absence of consensus. The critical attitude requires that the voters give careful thought and effort to finding for each vote why it should be opposed; when there are too many votes, there is not enough time and mind for such an effort. It is therefore perfectly consistent for someone to both require policy changes to be vote-controlled and at the same time require that there are never too many policy votes running concurrently.

If this does not stop, I will propose the following limit: no editor can create more than 3 policy votes in a given month. --Dan Polansky (talk) 11:52, 20 February 2016 (UTC)

I discussed if it's necessary to have declension tables after every new etymology - if the word and all its forms remain the same - with a fellow Wiktionarian, but we couldn't recall if there's a rule about this. See pală to see what we're talking about. I personally think that it looks a bit cluttered. Do we have a policy to guide us in this matter? --Robbie SWE (talk) 11:49, 5 February 2016 (UTC)

I'm fairly sure there's no policy on this. WT:EL would be the place to look. Common sense, in my opinion, says to just include the declension once with a level 4 header (this signals that it's not under any specific etymology, as that would be level 5). Renard Migrant (talk) 13:13, 5 February 2016 (UTC)

I agree. I'll take a look and see what I can do. Should we have a policy on this though? --Robbie SWE (talk) 15:27, 5 February 2016 (UTC)

One thing that could alleviate the problem is to make the declension tables less conspicuous. Starting with not taking up the entire width of the screen. --WikiTiki89 15:30, 5 February 2016 (UTC)

@Wikitiki89: I see what you mean. I'll do the necessary changes. Thanks for the advice! --Robbie SWE (talk) 15:39, 5 February 2016 (UTC)

Just out of curiosity, aren't there some cases where two homographs have different declensions? I am looking at you Russian. I like the cleanliness of a single declension/conjugation table, but there may need to be flexibility in any policy around it when required. - TheDaveRoss 15:39, 5 February 2016 (UTC)

Plenty of such cases. That's why we tend to include inflection tables in every POS section. --WikiTiki89 15:46, 5 February 2016 (UTC)

Yeah, I think it's good to include an inflection table in every POS section to clarify when the information is the same vs when it's different. (Renard's suggestion is also acceptable, though, and might work better for some languages where inflection depends solely on a lemma's spelling, or is uniform throughout the language as in constructed languages.) - -sche (discuss) 15:53, 5 February 2016 (UTC)

@TheDaveRoss: Sure there are – not only in Russian, but in Romanian too. I usually include multiple declension tables only if the word has more than one declension (see copil in the Romanian Wiktionary). The issue here is that the same declension table appears 5 times and it just doesn't look appealing, if you ask me. I think that Renard's suggestion is worth a shot, but I would feel more comfortable knowing if the greater community approves of such a "rule". --Robbie SWE (talk) 16:52, 5 February 2016 (UTC)

I think the inflection should always be in the same place, nested under the POS header, below the definitions and usage notes. I oppose any deviation from this format. If there are multiple POS headers with the same inflection, then they should have separate inflection tables nonetheless, because I think keeping to a standard format and ordering is more important for users than our desire to fiddle around with the nesting. —CodeCat 16:56, 5 February 2016 (UTC)

@CodeCat Hmmm, I kind of jumped the gun and went ahead and erased the superfluous declension tables: Should I revert my own canges? --Robbie SWE (talk) 17:02, 5 February 2016 (UTC)

In the page you edited, there should be at least something that says what the declensions of the other nouns are. Right now, I'd be inclined to think they are missing, and add them back in if I knew what they were. A message saying "see above" may work, but you might as well put in a declension table instead. —CodeCat 17:05, 5 February 2016 (UTC)

Ok, I'll revert my edits for now, but I strongly believe that we shoud discuss this further and agree on a policy. --Robbie SWE (talk) 17:09, 5 February 2016 (UTC)

I agree. My hope is that one day, each POS section can stand on its own as a distinct entry, just like in paper dictionaries, and that nesting is no longer used for shared properties. I still support POS sections at level 3 only. —CodeCat 17:15, 5 February 2016 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ My policy for Russian is to include a declension table under every new etymology or POS header, even when all etymologies happen to share the same declension. This is because logically the declension is nested under the POS header and a part of it, and most of the time different etymologies don't share the same declension, and it seems too confusing to do it the other way. I agree with CodeCat in this respect (except for the position of usage notes, which is a fairly minor issue). Benwing2 (talk) 18:18, 5 February 2016 (UTC)

Say a word can be pronounced a certain way in most varieties of English, but in one of them, it can also be pronounced a second way. I've seen this indicated in a variety of ways, none of which seem really satisfactory to me, including (rather than try to find the old examples I just mocked them up on meringue, but you can find some examples by typing e.g. insource:"a US also" into the search bar) , , , , and . What do you think, how should this kind of thing be formatted? PS the specific "also" pronunciation of meringue may actually be spurious, but let's discuss the general case. - -sche (discuss) 15:36, 5 February 2016 (UTC)

Since only in #6 I understood what you wanted to say, I vote for that one. The first ones to me are not clear enough about whether the USA has both pronunciations or only the "also"-variant. Korn (talk) 16:01, 5 February 2016 (UTC)

@Korn: Don't use the numbers, they can change. --WikiTiki89 16:05, 5 February 2016 (UTC)

Yeah, the last one (currently number 6, but as noted that could change if someone adds a link to a section above this one) does seem clearest to me. What Wikitiki favors below also works, and probably better fits how we label other things (we usually say "US" not "in the US")... it just seems less clear. - -sche (discuss) 16:20, 5 February 2016 (UTC)

I think it's fine to use {{a|US|also}}: (US, also). --WikiTiki89 16:05, 5 February 2016 (UTC)

• I know this isn't the point of your post, but that second pronunciation is actually how I natively pronounce it. But in any case, I think Wikitiki's solution is good. —Μετάknowledge^{discuss/deeds} 16:39, 5 February 2016 (UTC)
• I think adopting the practice of "one pronunciation per line" would be good. So I would prefer putting the second pronunciation on its own line, rather than at the end of the first. —CodeCat 16:46, 5 February 2016 (UTC)
  • I would be against a "one pronunciation per line" rule. But I would definitely support a "one tag per line" rule. --WikiTiki89 16:51, 5 February 2016 (UTC)
    • What are your objections? —CodeCat 16:52, 5 February 2016 (UTC)
      • Because pronunciations sections that have five pronunciations each for UK and US English, would have to take up 10 lines instead of two. --WikiTiki89 17:00, 5 February 2016 (UTC)
        • Do those five pronunciations have notices saying when and how they are used, which are more frequent than others, etc? Also, how do you deal with pairing enPR and other language-specific transcription systems with the IPA? I think putting IPA on one line and other schemes on another line is bad. It establishes no correlation between the two. That's why I proposed the rule: to make it clear which "things" are different representations of the same pronunciation. —CodeCat 17:07, 5 February 2016 (UTC)
          • Sometimes that kind of data is unavailable, especially when the variants are essentially interchangeable and not associated with any dialect, sociolect, or anything like that. And the enPR, if it really needs to be paired, can be paired by order alone. --WikiTiki89 17:14, 5 February 2016 (UTC)

Perhaps some sort of all-encompassing tag might be better, to be clear that the first pronunciation is more or less universal. It might be silly to have some sort of {{a|everywhere}} tag, though. I suggest using {{a|in the US, also:}} (with the comma and colon), as that's probably the least ambiguous option. Andrew Sheedy (talk) 18:32, 5 February 2016 (UTC)

We have Template:pronunciation respelling of and Template:eye dialect of. Should we have a template for eggcorns? Entries that could perhaps use it include for all intensive purposes and greatfruit. - -sche (discuss) 20:43, 5 February 2016 (UTC)

I have created T:eggcorn of. - -sche (discuss) 22:48, 8 February 2016 (UTC)

Is eggcorn itself citable as an eggcorn of acorn? Keith the Koala (talk) 18:55, 9 February 2016 (UTC)

FYI: There's a poll going on:

• Wiktionary talk:Votes/pl-2016-01/Pronunciation#Poll: example word

The purpose of the poll is choosing an example word for the updated WT:EL#Pronunciation, if the vote Wiktionary:Votes/pl-2016-01/Pronunciation passes. Thanks! --Daniel Carrero (talk) 00:33, 6 February 2016 (UTC)

About this rule:

• "The r phoneme used in English in words like red, green and orange is to be represented with /ɹ/ instead of /r/, except in accents where it is actually a trill."

It was voted in 2008-01/IPA for English r. It currently is located in WT:EL#Pronunciation.

The vote Wiktionary:Votes/pl-2016-01/Pronunciation should start in a few days. It proposes to rewrite most of WT:EL#Pronunciation but it does not touch that rule. Are we OK with keeping that rule there or should we move it to WT:AEN? My opinion is: WT:AEN is not a "true" policy, it is a think thank (at least in the opinion of the user who placed the TT template in the page, see diff) and I'd like to rewrite much of it. (it would be off-topic to say exactly what parts of it and how) Since it's a hard and fast voted-on rule, let's keep it in WT:EL#Pronunciation and move it to WT:AEN later when we have a proper About English page. Does that sound good? --Daniel Carrero (talk) 01:44, 6 February 2016 (UTC)

We should move it to WT:AEN. Even if WT:AEN is not a policy page, this rule is a policy because it was voted on. Not all vote results need to be on an official "policy page". --WikiTiki89 01:48, 6 February 2016 (UTC)

If we are going to move it between policies, I'd rather do it without a formal vote. Changing the location of a voted policy text is an "unsubstantial change", IMO. That is, it does not change actual practice. --Daniel Carrero (talk) 04:17, 6 February 2016 (UTC)

 Done. See: diff 1, diff 2. --Daniel Carrero (talk) 15:16, 7 February 2016 (UTC)

Esperanto contains diacritics (e.g. ĉirkaŭ). Some entries, such as cxirkaux, serve as the x-system spelling of those words. Are they necessary? And should they be here at all? --kc_kennylau (talk) 04:39, 6 February 2016 (UTC)

@Kc kennylau: This isn't paper, so it doesn't hurt to have standardized forms like this. —Justin (koavf)❤T☮C☺M☯ 15:10, 6 February 2016 (UTC)

They don't get a free pass from WT:CFI so they still need to be attested. Renard Migrant (talk) 17:06, 8 February 2016 (UTC)

Should they have a free pass from CFI? In 2011 a vote passed to allow pinyin transcriptions of attested Chinese words even when the transcriptions themselves are unattested—are h-system and x-system spellings a similar case? It's not obvious to me one way or another. We would need a vote to allow unattested h/x-system spellings, but I agree with Koavf that adding them when attested doesn't hurt. Many, including cxirkaux, are citeable from Usenet. See also Wiktionary talk:About Esperanto#X-system and H-system for past discussion including several suggestions on how to handle these spellings.

As a side note, current practice is to allow x-system and h-system spellings as citations for Esperanto words with diacritics. Regardless of whether we include entries for x/h-system spellings, I think we should continue allowing them as citations for the entries with diacritics. —Mr. Granger (talk • contribs) 00:07, 9 February 2016 (UTC)

Now that Wiktionary:Votes/pl-2015-11/Short blocking policy failed, I propose revising WT:BLOCK completely. I tried and created a new version of the policy below. What do you think? Could this replace the current policy?

Notes: The current WT:BLOCK is part-policy, part-"non-binding explanation". The proposed rewrite is supposed to use all of that content and convert it to be 100% policy. Some commentary such as "For anonymous IP addresses, the 99% case is non-recurring stupidity." was removed. Word such as "usually" and "recommended" were added at some points.

See it here: User:Daniel Carrero/BLOCK. Feel free to edit the page.

--Daniel Carrero (talk) 06:21, 6 February 2016 (UTC)

The vote shows 4 for and 2 against; that, by my lights, is consensus. The vote should have been further extended, IMHO, to yield clear result. We may try again later, hoping that more people will come to the vote. One problem that I see is that there are now too many votes running, competing for attention. I don't like seeing so many votes running. One thing that makes a vote a stronger evidence of consensus is that there are never too many votes running. --Dan Polansky (talk) 11:12, 13 February 2016 (UTC)

@Dan Polansky: I agree that 4 for and 2 against is consensus. As far as I can tell, the vote de facto passed. In any event, soon after you asked for it to be extended, I extended it by 1 month, so it's still running as we speak.

Concerning the many votes going on, I created a separate discussion: #About my proposals. --Daniel Carrero (talk) 23:28, 13 February 2016 (UTC)

Do we have a template and/or a category for hapax legomena such as nudiustertian? Smuconlaw (talk) 19:04, 6 February 2016 (UTC)

IMO, nudiustertian should be a row in a table in an Appendix:English hapax legomena. I don't even see how a real definition based on conventional usage can be legitimate for such a term, unless it is morphologically obvious. DCDuring TALK 20:32, 6 February 2016 (UTC)

It does appear in the OED, though (labelled as a hapax). I did a search using Quiet Quentin, but all citations are just repetitions of the one already mentioned in the entry. — SMUconlaw (talk) 20:34, 6 February 2016 (UTC)

Therefore it would not meet WT:ATTEST. We formerly allowed terms in English and other well-attested languages that had but a single attestation in a "well-known work", but that was voted out. I'd start the Appendix, move the citation to Citations:nudiustertian, insert sortable table with a column for etymology and a column for the citations link, and call it a day. DCDuring TALK 21:00, 6 February 2016 (UTC)

We have Appendix:English nonces. - -sche (discuss) 21:02, 6 February 2016 (UTC)

Even better. DCDuring TALK 21:04, 6 February 2016 (UTC)

What I've done in the past, to preserve the edit history (for legal / attribution reasons), is move the entire entry to the citations namepsace, then strip out everything but the citation (leaving the previous content in the edit history), and then add the entry to Appendix:English nonces with a link back to the edit history. - -sche (discuss) 21:05, 6 February 2016 (UTC)

Regarding nudiustertian, note the discussion on the talk page. @Mr. Granger has found some occurrences of the term on Usenet. — SMUconlaw (talk) 21:24, 6 February 2016 (UTC)

That, of course, applies only to well-documented languages. Ancient Greek, for instance, has quite a few hapax legomena that could use such a category. Chuck Entz (talk) 21:36, 6 February 2016 (UTC)

...which could be modelled after Category:Latin hapax legomena. - -sche (discuss) 21:48, 6 February 2016 (UTC)

We have the section WT:EL#Interwiki links, which is a long explanation about the subject matter that IMO would be more suited in a help page like Help:Interwiki links. (currently a redlink)

I believe the most obvious actual regulations for interwiki links are, in this order:

• Interwiki links must point to the entry spelled exactly in the same way in the foreign language Wiktionaries.
• Interwiki links should be sorted in the alphabetical order by the name of the language as written in the language itself. (as in: German in German is Deutsch, so it is sorted under D)

But I seem to recall there were some exceptions concerning Hebrew, is that right? Are there any actual regulations for interwiki links that should be mentioned, besides the rules above? Are these rules 100% accurate? --Daniel Carrero (talk) 05:41, 7 February 2016 (UTC)

What if the language doesn't use the Latin script? —Aryamanarora ^{(मुझसे बात करो)} 00:10, 9 February 2016 (UTC)

There is no exception for Hebrew entries (and yes, this makes things inconvenient because our Hebrew entry name conventions differ from he.wikt's entry name conventions). As for the alphabetization rules, I think they are actually more complicated than that. User:Ruakh should know all about it. --WikiTiki89 01:19, 9 February 2016 (UTC)

See the interwikis in the entry dog, for example. Japanese in Japanese is 日本語 (nihongo), and the jawikt link is sorted like "Nihongo" in the alphabetical order. This leds me to believe the actual rule in this cases is "sort using the transliterated language name", but I didn't check all languages. --Daniel Carrero (talk) 01:29, 9 February 2016 (UTC)

Like I said it's more complicated than that. I found a discussion explaining it: User talk:Ruakh/2014#Unsorted interwikis. --WikiTiki89 01:38, 9 February 2016 (UTC)

Thanks for the link, according to Ruakh in that conversation, the order is the one used in m:MediaWiki:Interwiki config-sorting order-native-languagename. This information could go to WT:EL, IMO. ("sort interwiki links in this exact order" qualifies as a layout rule, I suppose) --Daniel Carrero (talk) 03:55, 9 February 2016 (UTC)

I created Wiktionary:Votes/pl-2016-02/Interwiki links. --Daniel Carrero (talk) 13:10, 12 February 2016 (UTC)

Presenting AddAudio.js, a script that allows editors to easily add audio pronunciation to entries. The script adds a small "Add audio pronunciation" recording button to each language section, which allows a user to record the audio and then automatically edits the page to add the audio template (adding a pronunciation section if necessary) and uploads the file to Commons.

A few remaining limitations:

• The script currently only works in Firefox. (I don't expect this to be the case for that much longer, as partial support for the relevant API already exists on Chrome. Microsoft Edge currently has it "Under consideration".)
• The script has not been tested thoroughly, and is probably somewhat buggy. Sorry about that.
• Specifying accents is not yet possible, because I don't really know how accents are supposed to work. (How does one figure out what accent code to place in the file name? What text goes in the audio box? Is there a list of each language's accents available somewhere?) If someone could help me with that, that would be very helpful.

Feedback, suggestions, bug reports, etc. are most welcome. --Yair rand (talk) 05:49, 8 February 2016 (UTC)

Nice! But I could not make it work. I have the latest Firefox (44.0). When I click the console prints "navigator.mozGetUserMedia has been replaced by navigator.mediaDevices.getUserMedia". --Giorgi Eufshi (talk) 06:33, 8 February 2016 (UTC)

@Giorgi Eufshi: Okay, I just changed the script to use navigator.mediaDevices.getUserMedia when it's available. Maybe it will work now. If it still doesn't work, can you tell me what entry you're testing it with? --Yair rand (talk) 06:56, 8 February 2016 (UTC)

It seems I had problems with my mic. It works and it is great.--Dixtosa (talk) 17:28, 8 February 2016 (UTC)

I don't want to install Firefox just for this, but it sounds like a great start. Look forward to Chrome compatibility. Equinox ◑ 06:36, 8 February 2016 (UTC)

This sounds very helpful. Regarding accent codes: the codes for national accents are the country codes (from ISO 3166 but lowercased? or the ccTLD codes minus the dot? I can't tell which, if there is even a distinction). For example, the US pronunciation of "foo" is "En-us-foo", the UK is "En-uk-foo", New Zealand is "En-nz-foo" and Australia is "En-au-foo"; Germany's German and Austria's German are "De-de-" and "De-at-"; Portugal's Portuguese and Brasil's Portuguese are "Pt-pt-" and "Pt-br-". You could limit people to the nations where that language is natively spoken, if you like, although occasionally files get added from non-native speakers, e.g. an Italian pronunciation of Christmas tree is File:En-it-Christmas tree.oga. Subnational accents don't seem to be standardized; perhaps you could just omit support for them at first. There's File:En-us-ncalif-generictopleveldomain.ogg and File:En-us-ne-berry.ogg. Perhaps we should decide on standardized subnational codes... - -sche (discuss) 21:48, 8 February 2016 (UTC)

I must be missing something, but where should I be seeing the "Add audio pronunciation" button? I don't see it anywhere. Andrew Sheedy (talk) 04:16, 9 February 2016 (UTC)

You don't seem to have the script enabled yet. You can enable it by adding importScript( 'User:Yair rand/AddAudio.js' ); to your common.js. --Yair rand (talk) 05:55, 9 February 2016 (UTC)

Gotcha, thanks. The button doesn't seem to do anything at the moment, though I don't have a mic plugged in. Does it not do anything if it can't find a mic hooked up to my computer? (To be clear, I'm not expecting to be able to record without a mic... :P) Andrew Sheedy (talk) 07:14, 9 February 2016 (UTC)

I've just changed it to give an error message if there's no mic, instead of just silently failing to do anything. --Yair rand (talk) 08:02, 11 February 2016 (UTC)

OK, thanks. Andrew Sheedy (talk) 06:36, 14 February 2016 (UTC)

• Basic accent support is now working. --Yair rand (talk) 08:02, 11 February 2016 (UTC)
• I've added the script to WT:PREFS. --Yair rand (talk) 17:35, 15 February 2016 (UTC)

Is the current statement correct about "Obsolete Spellings" at WT:About German correct? The spelling "Alfabet" for example was deprecated in 1902 or fell out of use before that time, and was not re-introduced by the reform of 1996 etc. (duden.de for example doesn't know "Alfabet" and just has "Alphabet"). But, most likely because of reform spellings like "Delfin" and "-graf", the spelling "Alfabet" does re-appear nowadays (e.g. in books.google.de/books?id=fBET_JCIIz0C&pg=PA125 from 2009 and books.google.de/books?id=U8TSDt0h7rQC&pg=PA40 from 2012). The spelling might be rarer or non-standard, but it's not obolete anymore. So the correct statement should be:

"Spellings which were deprecated by or before the Second Orthographic Conference of 1901, or which fell out of use before then, and which have not been reintroduced by a more recent reform or have not become un-obsolete otherwise, are to be labelled obsolete."

But that's pretty much the same as:

"Obsolete spellings are to be marked as obsolete."

Put in other words: The current statement has a 1996-etc.-reform POV. -84.161.1.135 08:01, 8 February 2016 (UTC)

Obsolescence is measured by commonness of usage. There seems to be consensus that spellings like Alfabet are so rare that they have to be considered idiosyncrasies. We are not a collector of ever random spelling ever written down. (Though some users have put forth a different view in an RFD I recently brought up, cough, cough, cough.) Korn (talk) 09:07, 8 February 2016 (UTC)

If Alfabet is more than marginal in contemporary German, we can call it a {{misspelling of}}. I too am opposed to collecting every random spelling ever written down, when it comes to living languages with enormous corpora, like modern German. —Aɴɢʀ (talk) 12:03, 8 February 2016 (UTC)

My intention in writing that section was to indicate when to use "superseded spelling of" and when to just say "obsolete". If something was deprecated in 1901/1902, or earlier in some states, someone might be tempted to label it "superseded", but it should just be labelled "obsolete". {{de-superseded spelling of}} handles this if someone inputs used=pre-1901 or an earlier date (though if someone inputs an unrecognised date, it displays "former"), but people could also use {{obsolete spelling of}} on such words instead. This could probably be made clearer. (This is, IMO, separate from the question of whether Alfabet is obsolete, a misspelling, etc.) - -sche (discuss) 21:05, 8 February 2016 (UTC)

Superseded spellings can still be used. Obsolete spellings aren't used. By definition, if they're being used they're not obsolete. Renard Migrant (talk) 21:11, 9 February 2016 (UTC)

"Alfabet" is not a misspelling as it's used intentionally with f instead of ph representing the f sound (similar to other spellings, like reformed spellings such as "-graf" instead of "-graph"), not obsolete as it's used (and not as a misspeling), not archaic as it isn't used for an antique style, not hypercorrect as that means it's incorrect. In case of modern usages one might call it "hyperreformed".

Stating that the spelling "Alfabet" was superseded by "Alphabet" should be misleading or even incorrect too as it sounds like "Alfabet" was the older form or once was more common. But "Alphabet" (from Latin "alphabetum") was and is the more common form while "Alfabet" was and is rarer and rather is a younger form (even though the normalised MHG form is alfabēte).

Correct statements are: "Alfabet" was and is a rarer form, "Alfabet" was deprecated in 1902, "Alfabet" is not mentioned at duden.de and does not comply with the 1996 reform as the "Wörterverzeichnis" (word list) of the "amtliche Regelwerk" (official set of rules) only has the form "Alphabet".

Regarding the usage of the templates "obsolete spelling of" and "de-superseded spelling of": Why should a spelling like "Conjugation" just be labeled "obsolete spelling of Konjugation" and not "superseded by Konjugation etc."? "Conjugation" is the older form, then "Conjugation", "Konjugation", sometimes "Konjugazion" and forms like "Conjugazion" were in use, and in 1902 the spellings "Conjugation" and "Konjugazion" (etc.) were deprecated, superseded by the spelling "Konjugation" and became obsolete. The template "de-superseded spelling of" has the parameter "|used=pre-1901" ({{de-superseded spelling of|used=pre-1901}}) which gives "Obsolete spelling of word which was deprecated in 1902 following ...". That is, the template is made for spellings that were deprecated in 1902 and became obsolete, and in this case gives a better text (more information). Well, obviously when "de-superseded spelling of" is used without a parameter it gives a worse text. So one maybe should point out that there are parameters.

-84.161.43.70 17:21, 21 February 2016 (UTC)

I don't know if this was brought up before, but would it be a good idea to categorize the English pages by the translations that are there? For example, if the entry dictionary has French and Norse translation, then dictionary would be in Category:Words with French translation and Category:Words with Norse translation. Any thoughts? --kc_kennylau (talk) 12:58, 9 February 2016 (UTC)

I don't know. The idea has merit, but that's a lot of categories. I wonder what the limits are on the number of categories in an entry. If we implement this, water will have hundreds of categories- definitely more than have ever been included in an entry before. Chuck Entz (talk) 14:57, 9 February 2016 (UTC)

@Chuck Entz: I just took this idea from the French wiktionary. Also, fr:eau (French for water) does in fact have hundres of categories. --kc_kennylau (talk) 17:17, 9 February 2016 (UTC)

@Kc kennylau: It only has 28. —Justin (koavf)❤T☮C☺M☯ 23:02, 10 February 2016 (UTC)

@Koavf: The categories are hidden. --kc_kennylau (talk) 02:32, 11 February 2016 (UTC)

I am inclined to oppose this, because it would totally swamp the list of categories at the bottom of the entry, making it hard to find any other category I might be looking for, but I suppose there may not be many people who navigate to categories from entries rather than from categories to entries. (As DCDuring would say, do we have any data?) What would be the benefits? - -sche (discuss) 20:13, 9 February 2016 (UTC)

I was going to oppose it precisely because the French Wiktionary uses that system and it's pointless and godawful. Renard Migrant (talk) 21:09, 9 February 2016 (UTC)

@Renard Migrant: Thank you for your response. --kc_kennylau (talk) 02:32, 11 February 2016 (UTC)

@-sche: Thanks for your feedback. This problem can be solved by making the categories hidden. --kc_kennylau (talk) 02:32, 11 February 2016 (UTC)

But then they'd still swamp the page for someone like me who has hidden categories enabled precisely so that I can find or notice various maintenance categories. - -sche (discuss) 05:07, 11 February 2016 (UTC)

Exactly.--Giorgi Eufshi (talk) 05:58, 11 February 2016 (UTC)

Just a thought – maybe these categories could be added to talk pages, thus leaving the main pages without too many categories. — SMUconlaw (talk) 07:32, 11 February 2016 (UTC)

@Smuconlaw: Nice suggestion; however we would have to add a template to every talk page. --kc_kennylau (talk) 08:16, 11 February 2016 (UTC)

Yes, that would have to be done. It would solve the problem of too many categories on main pages, though. :) — SMUconlaw (talk) 08:25, 11 February 2016 (UTC)

What could one get out of these categories? —suzukaze (t・c) 05:17, 11 February 2016 (UTC)

You could track additions to a category. Of course not all translations will be tracked but still has merits. --Giorgi Eufshi (talk) 05:58, 11 February 2016 (UTC)

• Oppose; there are better ways of achieving the only positive results I could imagine from such a plan. —Μετάknowledge^{discuss/deeds} 23:30, 13 February 2016 (UTC)

Module:User:kc_kennylau/ancestor chain is basically an analysis of Module:languages/alldata, forming a chain with all the ancestors. A known problem is that languages with two ancestors are displayed twice. This module serves no other purpose than testing my programming skills. --kc_kennylau (talk) 17:15, 9 February 2016 (UTC)

If anything, it makes the visualisation of which language codes are missing ancestor data easy. — Ungoliant ^(falai) 17:19, 9 February 2016 (UTC)

@Ungoliant MMDCCLXIV: Well, thanks. --kc_kennylau (talk) 18:22, 9 February 2016 (UTC)

Why is Yiddish listed as a descendant of Hebrew? —CodeCat 17:42, 9 February 2016 (UTC)

@CodeCat: Presumably because it's called Judaeo-German? --kc_kennylau (talk) 18:22, 9 February 2016 (UTC)

But it doesn't actually descend from Hebrew, it's Germanic at its core. —CodeCat 18:24, 9 February 2016 (UTC)

Because Yiddish inherited quite a bit of its phonology, vocabulary, and grammar from Hebrew. But if you want to dispute that, let's not do that in the Beer parlour. --WikiTiki89 18:27, 9 February 2016 (UTC)

Seconding CodeCat: that is not what "inherited" means in linguistics. If you end up having a discussion elsewhere, I'll be happy to expand on my reasoning. --Tropylium (talk)

I agree also. Yiddish is inherited from German, but has borrowed a lot from Hebrew. Benwing2 (talk) 19:38, 9 February 2016 (UTC)

I agree too. Yiddish didn't inherit anything from Hebrew, but it borrowed a lot from it. I've removed Hebrew as ancestor of Yiddish from the module. —Aɴɢʀ (talk) 20:25, 9 February 2016 (UTC)

Anyone interested in discussing Yiddish, I have sort-of started a discussion at Tropylium's talk page. But I think we should keep this tangent from expanding here. --WikiTiki89 21:13, 9 February 2016 (UTC)

Listing several languages that need ancestors would be easy. A small sample:

1. Samoyedic (ancestor: syd-pro)
   • Kamassian xas
   • Mator mtm
   • Nganasan nio
   • Selkup sel
   • Tundra Nenets yrk
2. Iranian (ancestor: ira-pro)
   • Bactrian xbc
   • Chorasmian xco
   • Khotanese kho
   • Median xme
   • Ormuri oru
   • Sogdian sgd
   • Wakhi wbl
   • Yaghnobi yai

(This does not even exhaust Iranian languages that still need ancestors, but I believe some Western ones will possibly need to have their descendants set to Old Persian, and at minimum in the case of Tajik (tg), to Middle Persian (pal); some other groups might need low-scale protolanguages eventually.) --Tropylium (talk) 19:06, 9 February 2016 (UTC)

@Tropylium: I'm not sure I know what you mean. Do you mean that I should write a module to show languages that need an ancestor? --kc_kennylau (talk) 19:44, 9 February 2016 (UTC)

I think he's saying that this module already does show language that need an ancestor. --WikiTiki89 19:46, 9 February 2016 (UTC)

I'm currently sorting through the Iranian languages and I was wondering whether we should give Tati a code like ira-tat. Also, I would love if this ancestor tree became permanent. —JohnC5 20:34, 9 February 2016 (UTC)

Iranian languages really need to be organized more. Here is a detailed tree: File:Iranian Family Tree v2.0.png. --WikiTiki89 20:48, 9 February 2016 (UTC)

Also, Luri (ira-lur)? —JohnC5 20:51, 9 February 2016 (UTC)

@Wikitiki89, Tropylium: I'd really like a full proposal for how the languages should be sorted before I create any new language codes. For now, I'll just stick anything that is ambiguous under ira-pro for later sorting. —JohnC5 20:55, 9 February 2016 (UTC)

Theoretically, there should be a proto-language (or better yet, an attested ancestor language) at each branch point in the tree. --WikiTiki89 21:02, 9 February 2016 (UTC)

Real or etymology only languages? —JohnC5 21:17, 9 February 2016 (UTC)

If we can use etymology-only languages as ancestors, that would probably be the ideal solution. --WikiTiki89 21:19, 9 February 2016 (UTC)

I think we can. Wanna try? —JohnC5 21:20, 9 February 2016 (UTC)

I do want to try, but as I'm finding out, the Northeastern/Southeastern/Northwestern/Southwestern groupings are actually areal and not genetic. Therefore, no proto-language can be theorized for these groups. We need a more linguistically-accurate tree to work from. --WikiTiki89 21:55, 9 February 2016 (UTC)

My original point is that it's already evident from experience that numerous languages do not yet have ancestors added.

As for linguistic subgrouping, it is often a very contentious task, in particular in dialect continuum situations. I don't think any well-accepted tree of Iranian exists that would substantially group the Iranian languages together. (It's even been proposed that "Iranian" itself would be just an areal group of Indo-Iranian varieties.) --Tropylium (talk) 10:35, 11 February 2016 (UTC)

@JohnC5: We can try etymology-only languages with Proto-Canaanite. Its ancestor for now would be Proto-Semitic (sem-pro), and its descendants would be: Ammonite (sem-amm), Edomite (xdm), Hebrew (he), Moabite (obm), Phoenician (phn). --WikiTiki89 19:22, 11 February 2016 (UTC)

@Wikitiki89, Kc kennylau, CodeCat, Vahagn Petrosyan What do we think? Do we just start creating every intermediate language (Proto-Canaanite, Proto-South-Slavic, Proto-Osco-Umbrian) as full fledged reconstructed languages, as etymology-only languages (but allow them to act as ancestors), or add a new "reconstructed-stage" category of languages which may only act as categorizing ancestors? —JohnC5 19:30, 11 February 2016 (UTC)

I think they should be etymology-only languages, because after all, any such stage can also be used in etymologies. --WikiTiki89 19:34, 11 February 2016 (UTC)

It doesn't look like it currently works to me, but we I think we could alter that. —JohnC5 19:35, 11 February 2016 (UTC)

Yeah, I've been thinking of proposing merging the etymology-only language data into the regular language data modules, but giving them a parameter such as "etymonly = true". That way we would need much less special handling. @CodeCat: What do you think of that? --WikiTiki89 19:40, 11 February 2016 (UTC)

Not a fan. That would allow every template to accept etymology languages too, even when we don't want to. An opt-in for each template is better than having to explicitly code an opt-out for many templates. Also I'm opposed to Proto-South-Slavic unless there is a consensus that it existed. And I don't like the idea of creating lots of proto-languages for branch points. It wouldn't be practical. We got rid of Proto-Finno-Ugric for just that reason. —CodeCat 20:03, 11 February 2016 (UTC)

I think we should allow existing etymology-only languages to act as ancestors (e.g. Byzantine Greek for Cappadocian Greek and Pontic Greek) but we should not create new ones when there is no consensus that it existed. --Vahag (talk) 20:13, 11 February 2016 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Proto-South-Slavic was a bad example, but I do agree that having etymology only languages act as ancestors would be nice for categorization. Saying all the Romance languages are effectively the same seems a little silly to me. —JohnC5 20:30, 11 February 2016 (UTC)

We categorise languages by family, not by ancestor. —CodeCat 20:37, 11 February 2016 (UTC)

@CodeCat: Our decision to get rid of Proto-Finno-Ugric is essentially equivalent to a decision not to recognize it as a branch point. Every real genetic branch point theoretically has a proto-language. Regarding merging etymology language data with regular language data: Templates do not have direct access to the language data anyway. All access is mediated through Module:languages, which would be the only module that needs to know how to handle the etymology-only languages. --WikiTiki89 20:39, 11 February 2016 (UTC)

In other news, I created Proto-Na-Dene (xnd-pro) which I feel is fairly uncontroversial. —JohnC5 21:24, 11 February 2016 (UTC)

Creating proto-languages for generally accepted bottom-level families (so, this clause including neither the likes of Proto-Nilo-Saharan nor the likes of Proto-East Sudanic) should be uncontroversial, but beyond that it gets tricky. Consider Proto-Northwest Germanic, which is generally accepted but looks something like 90% identical to Proto-Germanic. Even if we didn't duplicate the PGmc appendices altogether, having to turn every "from Proto-Germanic" to "from Proto-Northwest Germanic, from Proto-Germanic" would be just pointless repetition in etymologies. Someone who knows about the difference will also already know that Gothic comes straight from PG, all other Germanic languages thru PNWG.

The only potential benefit I can immediately see to adding even an etymology-only PNWG would be pretty similar to what we're doing with Proto-Finno-Ugric: alerting readers that the word lacks both a Gothic and wider IE cognates, and hence cannot be necessarily assumed to have existed yet in Proto-Germanic proper. Even then, this could be better indicated in prose (cf. Proto-Uralic/-Finno-Ugric *käte). --Tropylium (talk) 18:25, 12 February 2016 (UTC)

I wasn't advocating changing instances of "from Proto-Germanic X" to "from Proto-Northwest Germanic X, from Proto-Germanic X". That's generally not what etymology languages are for anyway, they are never required to be used. They only exist for the occasional circumstances in which it might be beneficial to distinguish them from their "parent". In this case, I see it as just serving the purpose of organizing the tree (and only maybe the occasional use in an etymology section). Alternatively, maybe we could just integrate families into the tree so that they can be used for organization instead of extra proto-languages. --WikiTiki89 20:37, 12 February 2016 (UTC)

I've done all the Iranian languages I could find and the above-listed Samoyedic languages. —JohnC5 22:08, 9 February 2016 (UTC)

I've also done Italic. We really should make a policy about the creation of intermediate language stages for categorization, but not for actual lemmata, reconstructed or otherwise. —JohnC5 23:57, 9 February 2016 (UTC)

I think I found a bug. For some reason, "zh" is not showing up as the descendant of "ltc" as a descendant of "och", instead "ltc" appears twice, the second time in its own mini branch with just "zh". Also, it seems the Turkic languages need work. —CodeCat 00:09, 10 February 2016 (UTC)

I was thinking of looking at the Turkic languages, but was wondering whether to wait for a more permanent ancestry solution than just pointing them all at Proto-Turkic. Also, I would hope that if we could make this into a fully fledged template, it would contain the actual language names. —JohnC5 01:26, 10 February 2016 (UTC)

I've done what I can for Turkish. —JohnC5 03:55, 10 February 2016 (UTC)

@CodeCat, JohnC5, Wikitiki89: I think I found a bug. Mingo iro-min is listed as the descendant of iro-pro, which (iro-pro) is not in the database... --kc_kennylau (talk) 02:48, 11 February 2016 (UTC)

I've added Proto-Iroquoian since we'd need it eventually anyway. There still seems to be an error in the module that causes reduplication. —JohnC5 03:30, 11 February 2016 (UTC)

@JohnC5: For example? --kc_kennylau (talk) 07:40, 11 February 2016 (UTC)

Well, I guess I meant that Middle High German and Old Chinese just stop and then start again later as their own branches. Is that behavior intentional? —JohnC5 08:01, 11 February 2016 (UTC)

@JohnC5: Sorry, fixed. --kc_kennylau (talk) 08:26, 11 February 2016 (UTC)

@Kc kennylau I love the new layout. Is it possible to disconnect the top-level languages so it doesn't seem like they are related? Also, and I'm not sure this is possible given the cursive nature of the calls, but could you sort alphabetically by level? —JohnC5 17:03, 11 February 2016 (UTC)

@JohnC5: Done. --kc_kennylau (talk) 17:20, 11 February 2016 (UTC)

@Kc kennylau You're the best. Editing this is my favorite Wiktionary activity I've done in quite some time. —JohnC5 17:23, 11 February 2016 (UTC)

1. Why is Proto-Canaanite all on its own?

2. Can you add collapsible toggles to the branches?

3. Can we add this to {{langcatboiler}} (collapsed by default)? DTLHS (talk) 02:22, 12 February 2016 (UTC)

1. We were hoping they would alter the code to allow etym-only languages (such as Proto-Canaanite) to act as ancestors. No movement yet on that front.
2. I would love that also.
3. Technically, this feature already exists in the category system, but I would also enjoy having this mapping. —JohnC5 02:32, 12 February 2016 (UTC)

@Kc kennylau Could you make it so the etym-only languages either don't link or link without the trailing "language"? —JohnC5 05:48, 12 February 2016 (UTC)

Also, can we change etym-only languages so that aliases don't show up multiple times? —JohnC5 05:51, 12 February 2016 (UTC)

@JohnC5: Thank you very much for your continuous feedback. However, would appreciate if you could provide some examples next time. Took me some time to figure out what you're talking about. --kc_kennylau (talk) 10:43, 12 February 2016 (UTC)

@DTLHS: Could you make an example on WT:SB so that I may know how to make collapsible branches? --kc_kennylau (talk) 11:04, 12 February 2016 (UTC)

@Kc kennylau, thanks so much for all you've done so far. I apologize for continuously failing to provide examples. It seems like your edit to fix the aliasing problem for etym-only languages has broken the end-of-branch drawing behavior. The example here is Vulgar Latin (V.L.) has a branch continuation symbol as opposed to branch ending symbol. —JohnC5 16:22, 12 February 2016 (UTC)

@JohnC5: Thanks, fixed. --kc_kennylau (talk) 16:35, 12 February 2016 (UTC)

What does it mean to add this to {{langcatboiler}}? --kc_kennylau (talk) 15:48, 12 February 2016 (UTC)

Some questions:

1. Should "Descendants" be the last section within the language entry? Should "Descendants" be always L3?
2. Alternatively, should "Descendants" be the last subsection within the POS section? Should "Descendants" be always L4? (entries with multiple etymologies/pronunciations notwithstanding)
3. Maybe there are other alternatives?

Note:

• Arguably, "Descendants" is the information that is most "distant" from the definitions, since it is not about the current entry in the current language, so it could be well placed in the end of the entry, after all sections, including "Translations".

Note:

• I started this discussion based on @DCDuring's comments at Wiktionary:Votes/pl-2015-12/Headings#Oppose.
• Currently, there is some inconsistency in WT:EL about the placement of that heading.

  WT:EL#Additional headings places "Descendants" between "Translations" and "References".

  WT:EL#Order of headings places "Descendants" between "Related terms" and "Translations".

--Daniel Carrero (talk) 22:07, 9 February 2016 (UTC)

• If an entry had only a single etymology, it seems obvious to me that it would appear at L3 at the end of the L2 section, above some trivial content (eg, Statistics, Anagrams) and possibly above References and even External links. This situation with multiple etymologies would seem to be about the same with it appearing at L3 at the bottom of the applicable etymology section. There could be issues in cases where semantically related terms of different PoS are presented with distinct etymologies for the PoSes. But I would think we could refer the reader to one Descendants section, rather than duplicate it or somehow alter the entry layout to accommodate this uncommon, minor lack of structural clarity. DCDuring TALK 22:44, 9 February 2016 (UTC)

  The vast majority of entries that have a descendants section put it at level 4. I see no reason to change that. —CodeCat 23:58, 9 February 2016 (UTC)

I think it makes sense for Descendants to be L4 like (and probably near) Derived terms. Descendants are usually POS-specific, e.g. Tok Pisin rais is from the English noun rice and not the verb rice; I expect there are cases where a language like German or French borrowed both a noun and a verb from English in different forms (applying a verb suffix to the verb). - -sche (discuss) 00:42, 10 February 2016 (UTC)

I created Wiktionary:Votes/2016-02/Placement of "Descendants". --Daniel Carrero (talk) 14:27, 14 February 2016 (UTC)

@DCDuring, -sche, CodeCat: Can we get actual entry examples with each different placement of the "Descendants" section to link to in the vote? --Daniel Carrero (talk) 14:29, 14 February 2016 (UTC)

Proposal: Expanding WT:CFI#Terms with more terms. Added items are underlined. Did I forget any? (Bonus: I'm formatting all examples using {{m}}).

Note: This expansion was taken from Wiktionary:Criteria for inclusion/Editable, which was proposed to be deleted.

--Daniel Carrero (talk) 03:50, 11 February 2016 (UTC)

Chemical formulae are pretty controversial. As far as I know, we haven't really decided how to deal with them. H₂O and CO₂ are clear keeps, some are more controversial (see Talk:LiBr) and some not even I would support keeping (C₆H₁₂O₆ is probably citable). Smurrayinchester (talk) 10:52, 11 February 2016 (UTC)

I have two concerns: first, a sign in a sign language is a word in the usual sense—why does it get a separate bullet point?

Second, my understanding is that the phrase "ideographic writing" is inaccurate as a description of Chinese (see Unicode's FAQ on the subject and Wikipedia's article), so maybe that should be rephrased. We could combine that bullet point with the "Letters, numerals, and symbols" bullet point lower down. —Mr. Granger (talk • contribs) 13:30, 11 February 2016 (UTC)

Don't we exclude language codes like fro? DCDuring TALK 17:11, 11 February 2016 (UTC)

If there are any other suggestions, I'll make a new version of the text using them, later.

@Mr. Granger, about your first concern, I suppose you're right. I have a proposal: Maybe we should remove the whole introduction "A term need not be limited to a single word in the usual sense." and add a first bullet point concerning what items are acceptable:

• Words in the usual sense, including signs in a sign language.

About your second concern, thanks for the link. I had already read that specific FAQ in the past but I failed to remember that "ideographic writing" is not 100% accurate concerning Chinese characters. But what would be accurate about them? Both "字" and "ʃ" are used as examples of "ideographic" and "phonographic" writings, so it seems to serve as a catch-all way to say "we include most symbols here". (can we say that 1 is ideographic writing and A is phonetic writing?) Would it be a good idea using this:

• Chinese characters such as 字 (zì).

The problem I see with the idea of mentioning "Chinese characters" directly would be the slippery slope: why not saying "Chinese, Korean, Armenian, Arabic characters"?

@DCDuring, I suppose language codes are OK for the minority that are attestable? I was able to attest 2 script codes in the past and created entries for them, after this discussion: Citations:Latn and Citations:Cyrl. --Daniel Carrero (talk) 19:38, 11 February 2016 (UTC)

@Smurrayinchester, we could say "some chemical formulae". --Daniel Carrero (talk) 19:42, 11 February 2016 (UTC)

Same applies to "compounds and multiple-word terms": not all are acceptable. Equinox ◑ 20:56, 11 February 2016 (UTC)

Regarding "ideographic": we could refer to 字 as a Han character or maybe just a character, if we want to include it. But if we want an example to demonstrate the range of symbols that we include, I think Chinese characters are not a good choice—they're not so different from English letters, just in a different type of writing system. Wiktionary does have entries for things that I think would be accurately described as ideographic, such as ಠ_ಠ, ♂, ;), and <3. Maybe one of those could be an example. —Mr. Granger (talk • contribs) 21:30, 11 February 2016 (UTC)

• It's a start. Needs to go farther, but it's a start. Purplebackpack89 01:41, 12 February 2016 (UTC)

@Smurrayinchester, Mr. Granger, DCDuring, Equinox, Purplebackpack89:

I tried and revised the text based on all the ideas you gave. If I forgot to add something mentioned above, or if you think of something new, let me know. (I removed "fro" because it currently does not exist as a Translingual word.)

Also, I expanded the line about prefixes/suffixes.

--Daniel Carrero (talk) 12:40, 12 February 2016 (UTC)

I created Wiktionary:Votes/pl-2016-02/CFI: List of terms. --Daniel Carrero (talk) 01:00, 17 February 2016 (UTC)

Many of these are labelled both as noun forms with the title Noun and as Adverbs. You can see them by intersecting Category:Finnish_adverbs and Category:Finnish_noun_forms or by searching for ssa or lla (for example) with your browser on the adverbs page. A specific example is here: https://en.wiktionary.orghttps://dictious.com/en/humalassa

Both might be considered correct. Certainly the template used "noun form" is correct, however on the page it says "Noun", not noun form. This kind of fair enough though since in the body of the definitions they all say they're inflected forms. Adverb makes sense since they are equivalent at an adpositional phrase in English and this is how Kotus classifies them also. The general trend seems to be that the "Noun" heading contains, eg Inessive plural form of Foobar and the Adverb heading definition contains an actual definition and possibly a usage example.

My main problem with this set up is it seems inconsistent and it implies they have a different etymology or are a different part of speech. Most of the entries I have seen, it's quite hard to argue that the "Adverb" usage is different from the "Noun Form" usage (I will admit it is possible though - inflection can behave more like derivation). My preference would be that once one is decided on and the entries within the page are merge (I'm currently leaning towards Noun form - simply because there are more). A more radically approach would be to remove the pages altogether (or replace with redirects?) and merge the usage example and extra definitions into the lexeme. My main reasoning that this would be better is people are more likely to look at the lexeme's page and if the usage examples were merged in there would be more information where people are actually looking, rather than having it fragmented across different inflections.

Or am I barking up the wrong tree? Is there already some sort of a policy for this stuff that I'm ignorant of?

--Megajuice (talk) 20:19, 11 February 2016 (UTC)

The noun sense is different from the adverb sense, so they cannot be combined. The noun form humalassa also means "in the hop plant", for example. Entries for inflected forms are accepted in all languages. --Makaokalani (talk) 12:16, 19 February 2016 (UTC)

As proposed here by @Droigheann and later here by @I'm so meta even this acronym I would like to edit one item of WT:EL#Translations, to note that the list of genders given is nonexhaustive. I'm also pretty sure we have POSes with genders in translation tables, other than nouns.

(let' do this change without a formal vote if possible, this is an unsubstantial change)

Current text:

Possible text (I'm open to other suggestions):

--Daniel Carrero (talk) 12:16, 12 February 2016 (UTC)

Support — I.S.M.E.T.A. 15:25, 12 February 2016 (UTC)

Support Equinox ◑ 15:29, 12 February 2016 (UTC)

Abstain This change only means accepting gender for other POS than nouns, it says nothing about the aspect of verbs or, more importantly, plurals. I remain convinced that if the translation is a plurale tantum, this should be marked in the translation table, especially if the English word isn't, such as "a watch" vs hodinky f pl. --Droigheann (talk) 17:14, 12 February 2016 (UTC)

Oppose. The addition of "such as" is good, but not the removal of nouns. Adjectives shouldn't have genders, since they have no inherent gender. —CodeCat 17:18, 12 February 2016 (UTC)

The gender with an adjective informs the reader that the translation only applies to a specific (lemma) gender and, unlike in English, other forms for the other genders are to be found at the FL entry.

Incidentally, what other genders than m, f, n & c are there? Wikipedia suggests animate/inanimate but I've never seen that distinction made in a translation table. --Droigheann (talk) 17:38, 12 February 2016 (UTC)

But the same can be applied to things like cases too. Do we need to indicate that a specific form only applies for subjects (nominative case)? I hope not. We shouldn't have to educate our users on the grammar of languages in every translation table. If they know how adjectives work in a language (which they should, if they are going to use the word with any accuracy) then they know that translation tables only give the lemma form, and they know that it may need to change in gender, case or whatever to match usage. —CodeCat 17:41, 12 February 2016 (UTC)

I have to concede that's a good point (and probably applies not only to adjectives, but to pronouns and numerals as well). I know some nouns which don't have an inherent gender, like dítě (“child”), which is neuter, but whose plural děti (“children”) is feminine, but I wouldn't put that into the translation table either. --Droigheann (talk) 06:18, 13 February 2016 (UTC)

But there may be situations in which marking an adjectival gender is useful, such as if the word for "pregnant" can only be feminine in a particular language. It is also theoretically possible that a language could distinguish inherent genders for things other than nouns (but I don't know of any examples of this). --WikiTiki89 19:51, 16 February 2016 (UTC)

Oppose - I concur exactly with CodeCat as above. SemperBlotto (talk) 17:22, 12 February 2016 (UTC)

Oppose per CodeCat: adjectives in translation tables should not have genders since masculine is the lemma form. To make an analogy, verbs should not be tagged with inf to indicate that the lemma form is the infinitive. --Dan Polansky (talk) 11:16, 13 February 2016 (UTC)

I agree completely, but in some languages, verbs are not in their infinitive forms, such as Latin (1st person singular present), and Sanskrit (3rd person singular present). —Aryamanarora ^{(मुझसे बात करो)} 16:48, 13 February 2016 (UTC)

Oppose per all. —Aryamanarora ^{(मुझसे बात करो)} 16:48, 13 February 2016 (UTC)

Support --WikiTiki89 19:51, 16 February 2016 (UTC)

OK, I get it that the "noun" part is opposed by many people. Can I at least add the "such as" without a vote or would that require a vote? --Daniel Carrero (talk) 23:26, 13 February 2016 (UTC)

I say go for it. Andrew Sheedy (talk) 06:35, 14 February 2016 (UTC)

Yeah, nobody has expressed opposition to that. —Μετάknowledge^{discuss/deeds} 19:31, 14 February 2016 (UTC)

Yep, so we'll be allowed to add more genders to nouns in addition to m, f, n & c. And still no one told me what these other genders are. Some change, as far as I'm concerned. --Droigheann (talk) 20:16, 14 February 2016 (UTC)

@Droigheann: Actually, I meant other parameters like animate/inanimate and plurals and I took the idea from you. (as credited in the first message) --Daniel Carrero (talk) 23:41, 15 February 2016 (UTC)

Thanks, but I don't think anybody would interpret "grammatical gender with parameters such as m, f, n & c" as "this includes plurals where appropriate". It's like saying "a verb form should be marked for tense with parameters such as past, present and future" and expecting others to interpret it as "this includes grammatical person". --Droigheann (talk) 01:08, 16 February 2016 (UTC)

Please see Wiktionary:Votes/pl-2015-11/NORM: 10 proposals for the last time, and consider using these final moments to cast your votes if you didn't do it yet. The vote ends in 2 days. Thanks.

The vote contains lots of ideas together, so the page is larger than usual. The vote lasted for 3 months. (it started on November 15) --Daniel Carrero (talk) 14:47, 12 February 2016 (UTC)

Right now there's a major undertaking to add ancestor information to lots of languages, which is good. But I've noticed that in many cases, the ancestor duplicates the language family. The ancestor of family X is proto-X, so specifying both may be a bit redundant. Therefore, I'd like to propose the following change to how ancestors are worked out in Module:languages:

• If the ancestors = value is present, use that, like is done now.
• If it's not present, then look at the family of the language, and see if a language exists with -pro added to the family code. If so, then use that.
• If that doesn't work either, then progressively go up the family tree, doing the above check until a language is found.

So, for Old English, it would first look at the ancestors = value. Let's say it isn't present. So then it looks at the family code specified for Old English, which is gmw (West Germanic). It then checks if a language with code gmw-pro exists. It does not. So it then looks at the parent family of gmw, which is gem (Germanic). A language gem-pro does exist, so that is returned as the ancestor of Old English.

By using this method, we can get away with not specifying the ancestor of many languages, if that ancestor is simply the proto-language of the family. For Middle English and modern English we'd still need to specify it. But it would lessen the workload tremendously. It would probably be necessary to add a way to override the proto-language of a family. For the Romance languages, we'd want to use Latin as the ancestor, rather than the default roa-pro which does not exist. So in the family data for Romance, we might specify protolang = "la" to override the default. —CodeCat 17:01, 12 February 2016 (UTC)

I've implemented proto-languages for families, since I didn't think that part would be controversial. The proto-language of a family is now displayed in the info table on the family's category page, see Category:Germanic languages or Category:Romance languages for example. Note that it is not necessary for every family to have a proto-language. For example, Category:West Germanic languages doesn't have one. —CodeCat 19:26, 12 February 2016 (UTC)

Support. - -sche (discuss) 20:46, 12 February 2016 (UTC)

Support. —JohnC5 22:01, 12 February 2016 (UTC)

I've implemented this now. I came across a small oversight, in working out the ancestor of a proto-language itself. Proto-Germanic is in the Germanic family, which has Proto-Germanic as the ancestor, so it would loop back around infinitely. I solved that by adding an extra rule that, if the current language is the proto-language of its family, then start searching at its parent family instead (that is, skip step 2 in the list above). In any case, the rules seem to work well. Old East Slavic has been made the proto-language of the East Slavic language family, and Russian no longer has an ancestor specified (I removed it), and it uses the proto-language of the family by default, which works out right. See Category:Russian language. —CodeCat 20:55, 13 February 2016 (UTC)

Thank you! When adding proto-languages I noticed as you did that we tended to classify proto-languages as belonging to the families they produced; is this appropriate or should e.g. Proto-Germanic be classified as belonging to the Indo-European family instead? (I could see benefits to putting it in both categories, actually, but I have no strong opinion...) - -sche (discuss) 21:34, 13 February 2016 (UTC)

I think Proto-Germanic belongs to the Germanic family by definition, since it has as a minimum all characteristics that define a Germanic language. I would expect to see it listed in Category:Germanic languages. —CodeCat 21:38, 13 February 2016 (UTC)

Now that this has been done, it should be remembered, of course, that ancestors are tied to families. So when an ancestor isn't appearing, it may be the family data that's at fault. I came across a few languages that had no family defined but did have an ancestor defined. These would need to be fixed. It may also be worthwhile to consider whether an attested language is the proto-language of some family. These families currently have non-default proto-languages:

• Category:Arabic languages
• Category:Aramaic languages
• Category:East Slavic languages
• Category:Egyptian languages
• Category:Frisian languages
• Category:Kipchak languages
• Category:Romance languages

We may want to have a look at Category:Goidelic languages and Category:Sinitic languages. The oldest Goidelic language in the category is Primitive Irish, but all the modern Goidelic languages are considered to descend from Middle Irish. In a similar way, Middle Chinese is the ancestor of all the modern Sinitic languages, but the oldest is Old Chinese. —CodeCat 22:04, 13 February 2016 (UTC)

I could notice a few pages like access modifier with the label object-oriented. But this doesn't categorize yet, so I'm just suggesting to modify Module:labels/data in this sense. Because as you can see at least into fr:Catégorie:Lexique en anglais de la programmation orientée objet, there are a horde of them. JackPotte (talk) 15:21, 13 February 2016 (UTC)

Today I could have modified Module:labels/data and filled the category if only I hadn't got:

You do not have permission to edit this page, for the following reason:
This page has been protected from editing because it is transcluded in the following page, which is protected with the "cascading" option turned on:
Wiktionary:Main Page

JackPotte (talk) 22:50, 1 April 2016 (UTC)

And it's the same obstacle to fill Category:en:E-mail. JackPotte (talk) 21:41, 19 April 2016 (UTC)

Apologies for the delay, and thanks for your persistence. I've now added the Java and object-oriented labels. - -sche (discuss) 01:01, 20 April 2016 (UTC)

Should we have some guidelines for what constitutes as traditional forms and what doesn't? For some entries, it's easy to decide, e.g. 蘋／苹 (píng). But for others, it's sort of debatable, e.g. 癡／痴 (chī), 臺／台 (tái), 汙／污 (wū), 線／綫／线／缐 (xiàn) and 雞／鷄／鸡 (jī). Oftentimes, for the latter category of characters, Taiwanese and Hong Kong (and even Mainland) standards differ. Also, in what situations should we be putting forms into {{zh-forms}}, and in what situations should we be putting them under ===Alternative forms===? Calling on Chinese editors, including @Suzukaze-c, Wyang, Tooironic, Kc kennylau, Atitarev, WikiWinters, Hongthay — justin(r)leung _{{ (t...) | c=› }} 00:50, 14 February 2016 (UTC)

One way is to use what I did for 雞／鷄／鸡 (jī), which you listed. 雞#Chinese uses {{zh-see|雞|v}}, which is just another way of saying {{alt form of|雞|lang=zh}} but matches the format of simplified only forms and saves listing all PoS's. --Anatoli T. ^{(обсудить}/^вклад) 00:56, 14 February 2016 (UTC)

台#Chinese is also a complicated case because it can be a simplified variant or a traditional variant of multiple characters or a character with no variant but it's the right way, IMO. --Anatoli T. ^{(обсудить}/^вклад) 00:59, 14 February 2016 (UTC)

Thanks for your input, @Atitarev. My bigger concern is, which one do we choose as the traditional? For example, 臺 is the standard form in Taiwan and the traditional form in the PRC standard, but 台 is the standard form in Hong Kong (and very common in Taiwan). Do we use historical usage as our basis? National standards? Other cases include 裡 vs. 裏, 群 vs. 羣, 癡 vs. 痴 — justin(r)leung _{{ (t...) | c=› }} 03:28, 14 February 2016 (UTC)

Perhaps usage notes should be placed ("Usage notes: 鷄 is commonly used in Hong Kong", "Usage notes: 缐 is only used as a last name").

IMO, characters should be placed in {{zh-forms}} if it is commonly/regularly used (like, no-one will bat an eye if you use it; for example 台 vs. 臺). —suzukaze (t・c) 22:30, 14 February 2016 (UTC)

Thanks for your input, @Suzukaze-c. Do you think we should have a bit of consistency with choosing some form as the "main" entry and others as the "redirected" entries? Take the situation with 癡／痴 (chī). Some words have 癡 being the main entry like 癡情, while others have 痴 being the main entry like 痴呆. — justin(r)leung _{{ (t...) | c=› }} 03:28, 14 February 2016 (UTC)

Seeing those two entries bothers me. I think that consistency is good. —suzukaze (t・c) 23:55, 14 February 2016 (UTC)

The choice is not always straightforward and sometimes it's preferable to use {{alt form of|TERM|lang=zh}}, especially if the alt form has its own simplified forms. Whatever is chosen, it's better to centralise the contents, rather than duplicating it. If a wrong main form is chosen, it can be changed in the future. --Anatoli T. ^{(обсудить}/^вклад) 02:10, 15 February 2016 (UTC)

• Given how complex this situation is, we could just maintain the status quo - rely on the judgement of experienced editors? We may find the cure worse than the disease. Unless someone can find an elegant way to automate it... ---> Tooironic (talk) 22:54, 15 February 2016 (UTC)

So I've been using {{a}} for register distinctions ("colloquial", "casual, fast speech") and for things that sound sort of like accents ("dated or regional"). The docs for {{a}} say to use it mostly for place names, although the labels in Module:a/data also refer to things like the pen-pin merger and rhotic vs. non-rhotic accents. So:

1. Presumably {{i}} should be used instead for things like "colloquial", "dated" and maybe also "regional"?
2. Do these notes go before or after the pronunciation? I've been putting them before, but what about long notes like "esp. when followed by other words"?
3. What about "St. Petersburg or dated"? I would split it into {{a|St. Petersburg}}, {{i|dated}} but that will look weird, with two sets of parens.

Benwing2 (talk) 04:32, 14 February 2016 (UTC)

• Good point actually. I think something like {{a|Russia|rare}} is totally find, although without any region name it should be {{i|rare}} not {{a|rare}}. Renard Migrant (talk) 16:32, 14 February 2016 (UTC)

Previous discussion: User talk:Daniel Carrero#Reordering L3 headers. (pinging participants: @Metaknowledge, -sche, CodeCat)

Proposal:

• Use the frwikt style of L2 language sections. (gray background in the middle of two horizontal borders which are added by CSS, not ----) Example: fr:sea.

Rationale:

• Arguably, it looks nicer than the current style. In addition, it would be easier to find the beginning of each language section and visually parse where is each different language section.

--Daniel Carrero (talk) 14:48, 14 February 2016 (UTC)

Support! —CodeCat 16:28, 14 February 2016 (UTC)

I've always preferred out style, it's simpler and importantly, doesn't involve using templates inside section titles, which will generate a lot of extra typing. Renard Migrant (talk) 16:35, 14 February 2016 (UTC)

It may be possible to do it all with CSS. Not sure though. —CodeCat 16:48, 14 February 2016 (UTC)

Support —Aryamanarora ^{(मुझसे बात करो)} 16:53, 14 February 2016 (UTC)

Support —Μετάknowledge^{discuss/deeds} 19:30, 14 February 2016 (UTC)

Grudging Support if, and only if it can be done automagically after an editor adds the language heading in the usual way. I don't want to have to remember even more templates. SemperBlotto (talk) 07:05, 15 February 2016 (UTC)

If this can be done with CSS or a gadget (like the one which adds flags to language headers — which suggests that adding fr.Wikt's header style via gadget should be possible), and especially if it can thus be optional, then I abstain. I oppose anything that changes the headers from e.g. ==French== to =={{some template|French}}==. - -sche (discuss) 07:16, 15 February 2016 (UTC)

I support it to be a opt-in gadget initially. A highly customizable gadget. --Giorgi Eufshi (talk) 07:26, 15 February 2016 (UTC)

@Giorgi Eufshi Since you have User:Dixtosa/common.css, I know you are aware of it, but you can use CSS code in Special:MyPage/common.css. It's as highly customizable as it gets. --Daniel Carrero (talk) 15:55, 18 February 2016 (UTC)

Should we create a vote for that? Yes, we can use CSS to do that without using templates. But CSS would take care of both the top and bottom borders, so we would probably have to get rid of ---- from all entries. --Daniel Carrero (talk) 15:01, 15 February 2016 (UTC)

I created Wiktionary:Votes/2016-02/Using frwikt language header style. --Daniel Carrero (talk) 10:05, 18 February 2016 (UTC)

I think that it should be a gadget. It looks like it came from 2004. —suzukaze (t・c) 10:11, 18 February 2016 (UTC)

I don't think it should be a gadget. One can use Special:MyPage/common.css to change the L2 style if they want. --Daniel Carrero (talk) 15:51, 18 February 2016 (UTC)

We currently consider Proto-Canaanite a dialect of Proto-Semitic, yet I've also seen people say that certain languages descend from it. If it's a true language with its own descendants, why is it not considered a full language? —CodeCat 16:46, 14 February 2016 (UTC)

Why can't dialects have descendants? And why does etymology-only imply that it's a dialect? --WikiTiki89 19:53, 16 February 2016 (UTC)

That's pretty much the definition of etymology-only languages that we've used. They're not full languages, they're subsumed under their parent. —CodeCat 20:19, 16 February 2016 (UTC)

Then answer the first question. --WikiTiki89 20:29, 16 February 2016 (UTC)

This is just a transitivity of identity issue, right? If Proto-Canaanite is still the same language as Proto-Semitic, then the common ancestor of Canaanite is indeed (a dialect of) Proto-Semitic.

On the other hand, is there any pre-existing work out there about Proto-Canaanite in the first place? I've usually seen it defined just in terms of one or two sound changes, and that's definitely not enough to warrant a separate proto-language. --Tropylium (talk) 23:31, 27 February 2016 (UTC)

That's exactly the point. I don't want there to be a separate proto-language, but just another node on the tree for organization. The whole point of creating it was to be the ancestor of its descendants. --WikiTiki89 16:01, 29 February 2016 (UTC)

previous discussion: Wiktionary:Grease pit/2015/August#New feature

Perhaps I'm the only one who hadn't noticed until now, but FYI there is once again a checkbox on the watchlist which enables monitoring of "page categorization" (i.e. you see when someone adds a page to or removes a page from a category you watch). Presumably the devs fixed the issue that caused it to be disabled last year so soon after it was initially deployed. - -sche (discuss) 22:56, 14 February 2016 (UTC)

Thanks a lot. I had missed it.

Did anyone document it? If someone did how would one find the documentation? Was it discussed somewhere that I missed or have forgotten about? It took me a while to confirm that the feature operated as I would want it to. DCDuring TALK 14:08, 15 February 2016 (UTC)

It took me a while, but I tracked down the previous discussion; see the link I've added to the top of this section. - -sche (discuss) 18:00, 15 February 2016 (UTC)

Thanks. It is sad that I was an active participant in the discussion only 6 months ago, had covered much of the same ground that I felt I had to cover again yesterday, but had only the faintest recognition that there might have been a BP discussion. I have ever more sympathy for those witnesses in legal proceedings who say they can't remember. DCDuring TALK 18:59, 15 February 2016 (UTC)

According to @This, that and the other, "wikitext" is correct, not "wiki code". See Wiktionary:Votes/pl-2015-11/NORM: 10 proposals#Proposal 1 (specifically in the proposal 1). I don't know if that's accurate.

WT:NORM uses "wiki code" twice in the introduction.

Proposal:

• Edit WT:NORM without a vote to change "wiki code" into "wikitext".

Affected text:

--Daniel Carrero (talk) 04:44, 15 February 2016 (UTC)

Support —Μετάknowledge^{discuss/deeds} 03:04, 18 February 2016 (UTC)

 Done --Daniel Carrero (talk) 12:07, 17 March 2016 (UTC)

WT:EL edits (except votes found in the lists below):

• EL introduction
• Language 2
• Entry name 3
  • Entry name: sign languages (also affects WT:ASGN)
• Etymology
• Pronunciation
  • Multiple pronunciation sections
  • Notes about pronunciations
• Definitions
• References
• Trivia
• Interwiki links

About translations:

• Literal translations in translation tables
• Translations of taxonomic names
• Automated transliterations

Removal of EL content:

• Removing "Flexibility"
• Remove "The essentials"

Editing all entries:

• Removing "Quotations"

Placement of headings:

• Placement of "Alternative forms"
• Placement of "Usage notes"
• Placement of "Descendants"

WT:CFI edits:

• Attestation vs. the slippery slope 2

WT:NORM edits:

• Spaces in links (I created it now based on Wiktionary talk:Normalization of entries#Spaces in links)

WT:BLOCK edits:

• Short blocking policy

--Daniel Carrero (talk) 05:09, 15 February 2016 (UTC)

• Wiktionary:Votes/2016-02/Using frwikt language header style Vote added above by Daaniel 10:05, 18 February 2016 (UTC)
• Wiktionary:Votes/pl-2015-12/Etymology to start on February 27. Vote added above by Daniel Carrero at 11:21, 18 February 2016 (UTC)
• Wiktionary:Votes/pl-2015-12/Remove "The essentials" = February 29. Vote added above by Daniel Carrero) 15:22, 18 February 2016 (UTC)

— This unsigned comment was added by DCDuring (talk • contribs). DCDuring TALK 20:49, 18 February 2016 (UTC)

@DCDuring added these "Additional votes" above using my signature. (diff) Please don't do that. I removed my signature from these additions. --Daniel Carrero (talk) 20:40, 18 February 2016 (UTC)

I was trying to show the rush with which the items were added after the main table of votes was created. I must have succeeded. DCDuring TALK 20:49, 18 February 2016 (UTC)

You mistyped my signature a few times, was it part of the effect you were aiming for? "Daaniel" without the surname, "Daniel Carrero)" with a stray paren.

I'm going to repeat myself: I want to create votes related to some ongoing discussions that I was already planning to create votes for before you complained. I'm a rush because of the promise I made to you of not creating any votes for 3 months as I said. The Etymology and the Essential votes were created on December 2015. I was delaying the start of both, then I started them, because I wouldn't want to start them during my 3-month promise or let them lingering unstarted until June.

When I talked to you, I said I would like to create about 10 new votes before February ends. Now there are about 3 or 4 votes I'd like to create. (You missed a few votes in your list, and 10 was probably a generous estimate anyway.) --Daniel Carrero (talk) 21:12, 18 February 2016 (UTC)

Not very good faith... This feels like a kid being told he can't eat any snacks after 6 p.m., so he gorges to satiety at 5:59. The problem that was raised wasn't so much "you should not create votes at all" as "you are creating too many votes too rapidly". So you're still doing it, promise or no. Equinox ◑ 21:35, 18 February 2016 (UTC)

I'm just keeping my original plan: create a bunch of discussions, then create the votes that follow. It would be really frustrating if I had to stop midway and leave those discussion without the proper next step of creating the votes. Or maybe I should let others create the votes if they want, I don't know. During these 3 months, I'll probably won't even create new discussions for substantial edits to WT:EL because they would require votes. Equinox, I don't particularly like your analogy because DCDuring does not individually outrank me in deciding what to do. There are other people who take part in the votes and ask me to create some new proposals, but to be fair I don't know if they individually support or oppose having 29 votes as we have now. (Is 29 really that much? It must be because we are a small community, and have to do things the slow way. Suppose we had dozens of thousands of active contributors, and new votes every day.) It is a recurring complaint that WT:EL is outdated and difficult to edit because it needs to be voted, so I decided to do it. When I made the 3-month promise, I was not strictly taking orders from DCDuring, I just thought of doing it as a compromise, especially given his argument about needing time to appreciate the full consequences of the last edits to the policy. There you have it, 3 months. --Daniel Carrero (talk) 00:40, 19 February 2016 (UTC)

I think that Equinox was just suggesting that your haste to beat a deadline, one that happened to be of your own making, looked a bit silly.

You seem to be "keeping your original plan" as if that plan were something sacred. Does that plan have deadlines? Does it have realistic goals? Why should we (or you) be slaves to that plan? Why not just withdraw for now some or all of the proposed votes? For votes that have begun, why not withdraw just some of the ones with the least support so far? DCDuring TALK 01:09, 19 February 2016 (UTC)

(after edit conflict) I don't think the analogy had anything to do with somebody outranking somebody else, that's just a straw man. And yes, 29 votes (we do have a new vote every day now) are a lot, if you care about the project, want to think them out properly (and also consider what others have to say), while at the same time continuing to contribute in the mainspace. I can believe that WT:EL's being outdated is a recurring complaint, but I don't believe the complainers want us all to put everything else here to one side until you manage its complete overhaul. Sure, we could simply ignore them, as @Pengo suggests elsewhere, but if you care about something you don't just say "oh, let them do what they want to with it, I don't have the time" and later complain you don't like the outcome. --Droigheann (talk) 01:29, 19 February 2016 (UTC)

@DCDuring: The realistic goal is just updating WT:EL (main goal) and perhaps other policies a bit. Discussing+voting would just be the proper procedure if it weren't for the quantity of votes, but without many votes it would take so long to edit the policy. Sure, I can withdraw some votes, I guess.

@Droigheann: Sorry, I didn't understand the part about "oh, let them do what they want to with it, I don't have the time". --Daniel Carrero (talk) 01:56, 19 February 2016 (UTC)

This diff. --Droigheann (talk) 02:06, 19 February 2016 (UTC)

I've just seen there are not Solresol entries in en.wiktionary. Not even the word Solresol is there. Is it because it's a constructed language or any other reasons? Is there at least some kind of list somewhere? Thanks. 87.222.104.154 09:54, 15 February 2016 (UTC)

See WT:CFI#Constructed_languages. --Yair rand (talk) 11:12, 15 February 2016 (UTC)

Thanks, Yair rand. I find it strange that Solresol is not even mentioned. No discussion about the language at all? --87.222.104.154 23:55, 15 February 2016 (UTC)

Thanks, SemperBlotto and -sche! :) --87.222.104.154 00:00, 16 February 2016 (UTC)

I think that this has been discussed previously, but I can't remember when, or what arguments were given - sorry.

Our criteria for inclusion is such that only words in actual use in the real world may be included. This is a good thing.

However, we allow inflected/conjugated forms of nouns, adjectives and verbs to be included if the lemma itself is includable - we even allow bots to generate these forms mindlessly. So, derived terms are allowed if the base term is good, and the method of inflection/conjugation used is the right one - even if such derived forms are never used in the real world.

I think we should expand this to include SI units (formed from a valid prefix and a valid base unit), even though their actual usage in the real world may be vanishingly small. The SI brochure says of these units:- "They are listed in many textbooks and in many references, but any such list can only be a selection of the possible quantities and equations, which is without limit." The SI are implying that any combination of a valid prefix and a valid base unit is itself valid (they don't seem to actually spell that out).

I think it would be a good idea to include (in those terms that have little or no actual usage) a warning to that effect. Any thoughts? SemperBlotto (talk) 12:02, 15 February 2016 (UTC)

I don't like it. Allowing unattested lemmas is different from allowing unattested inflections (which I also disagreed with until fairly recently, when I shrugged and gave in to consensus and began to create them). Although SI is a long-standing scientific organisation I don't think they or any other should have carte blanche to override our usual rules on what is a word. Equinox ◑ 14:24, 15 February 2016 (UTC)

@SemperBlotto: What do you have in mind? Something like yottajoule or picometer? —Justin (koavf)❤T☮C☺M☯ 14:56, 15 February 2016 (UTC)

Well, yes, but we have both of those. I was really thinking of foreign-language translations. The language of science is overwhelmingly English, so it is much more difficult to find citations of foreign equivalents of SI units that, in English, are easily citeable. SemperBlotto (talk) 15:20, 15 February 2016 (UTC)

See yottakatal. Renard Migrant (talk) 16:45, 15 February 2016 (UTC)

@Koavf Picometer is actually used, though. Sizes of atoms and bonds are described in it. —CodeCat 16:51, 15 February 2016 (UTC)

@CodeCat: I think I see what you mean--the Estonian or Navajo equivalent of "picometer" which can be constructed from pico- and meter in those languages. I'd be fine with including these. —Justin (koavf)❤T☮C☺M☯ 04:00, 16 February 2016 (UTC)

Support --Daniel Carrero (talk) 05:00, 16 February 2016 (UTC)

I should have mentioned that mégafarad (French) and megafarad (Italian) are currently in RfV, and is what prompted this question. (I didn't push my luck and add Megafarad (German)) SemperBlotto (talk) 08:07, 16 February 2016 (UTC)

I believe the correct German spelling is Megafahrrad. —Aɴɢʀ (talk) 08:28, 16 February 2016 (UTC)

Wouldn't that be a very large bicycle? SemperBlotto (talk) 14:49, 16 February 2016 (UTC)

shh- you'll spoil the joke!. Chuck Entz (talk) 14:57, 16 February 2016 (UTC)

ಠ_ಠ —Aryamanarora ^{(मुझसे बात करो)} 01:36, 18 February 2016 (UTC)

I understand that 19 April, 2016 is Fahrrad Day, the 73rd anniversary of a bicycle ride famous in some circles. DCDuring TALK 15:08, 18 February 2016 (UTC)

• Let's go by current CFI and therefore exclude SI units that are not attested in use. Similarly, let's not include unattested -ness forms only because they make perfect sense in principle. For a vote related to SI units, see Wiktionary:Votes/2009-12/Proposed inclusion of words and abbreviations with meanings established by recognized international bodies and formally adopted by multiple national governments. --Dan Polansky (talk) 12:01, 20 February 2016 (UTC)

I've scheduled Wiktionary:Votes/pl-2015-12/Etymology to start on February 27.

I had created that vote a few months before, but I was delaying the start, basically because it had a reference to Wiktionary:Votes/pl-2015-12/Headings so I wanted to see if the headings vote would pass first. (it failed, so I edited the etymology vote to account for that) --Daniel Carrero (talk) 11:21, 18 February 2016 (UTC)

Also Wiktionary:Votes/pl-2015-12/Remove "The essentials" = February 29. --Daniel Carrero (talk) 15:22, 18 February 2016 (UTC)

I suggest adding this rule to WT:NORM without a new vote:

• Categories are placed at the end of each language section.

Rationale:

• That rule is not only current practice, it was formally voted already in Wiktionary:Votes/2007-05/Categories at end of language section,

--Daniel Carrero (talk) 14:41, 18 February 2016 (UTC)

Support. --Yair rand (talk) 14:54, 18 February 2016 (UTC)

 Done. - -sche (discuss) 19:48, 18 February 2016 (UTC)

Planned, running, and recent votes

(see also: timeline, policy)

Ends	Title	Status/Votes
Oct 11	User:Catonif for admin	passed
Oct 24	User:Ioaxxere for admin	passed
Nov 11	User:Svartava for admin	11 2 4
Nov 27	Excluding trivial present participal adjectives	0 4 0
(=4)		(=78)

As I said in #About my proposals, I decided I'm going to create a few more votes as a result of multiple ongoing discussions, then I won't create any votes from February 29 (or sooner) until May 31. (3 months)

My reason is: in the discussion linked above, @DCDuring and @Droigheann asked me something along the lines of "don't flood Wiktionary with votes". (I'm paraphrasing, they should be able to explain better.)

As a result, the list of votes (visible here in the right-hand side) should be noticeably emptied after the current votes end, particularly around the end of March. Most of the votes I created are about editing WT:EL. There are other things I'd like to propose changing in the policy, and I'd like to create revised versions of the current votes after they end, but I can wait. --Daniel Carrero (talk) 15:24, 18 February 2016 (UTC)

Thanks. DCDuring TALK 17:11, 18 February 2016 (UTC)

You're welcome. --Daniel Carrero (talk) 17:52, 18 February 2016 (UTC)

I withdraw my thanks. There are still too many votes. Any vote not yet begun could be postponed and IMO should be postponed.. DCDuring TALK 19:35, 18 February 2016 (UTC)

He said "I'm going to create a few more votes... then I won't create any votes from February 29...", so he did no more than he said he would. —Aɴɢʀ (talk) 19:50, 18 February 2016 (UTC)

Yes. I hadn't had time to fully parse all of the items he'd added, so I mistakenly thanked him for what I thought he'd done rather than what he's actually done. I think it's as wrong as something done in good faith could be. DCDuring TALK 20:02, 18 February 2016 (UTC)

We could create a vote about you not creating any more votes. --Ce mot-ci (talk) 21:40, 18 February 2016 (UTC)

I think this flood of votes that require cleanup activity is particularly unseemly coming from Dan in light of the payment for such work as discussed at Wiktionary:Beer_parlour/2015/November#term_cleanup_in_user_pages_and_discussion_pages. DCDuring TALK 21:54, 18 February 2016 (UTC)

Dan is not on trial here. There is no conflict of interest. Cleaning up EL requires votes. If you don't want to vote, don't vote. Stop whining that someone is trying to get something done within the system we have. Pengo (talk) 23:59, 18 February 2016 (UTC)

I see no reason why the unprecedented voting process that he is driving shouldn't be examined from all angles and several why it should.

It's the pace that most worries me. There are many votes that simultaneously change a single document, with the force of policy. Would it really kill us to have three or five votes at a time, followed by some large-scale implementation before leaping to the next set of changes? If a bot is going to do this, isn't it simpler and safer to implement the changes one at a time?

The rapid process effectively limits the number of active participants. Who wants to follow more than two or three of these discussions for a month or two? The process is biased toward the participation of a small number of people, perhaps with specialized interests.

The number of votes that have required fundamental changes in wording also worries me in that it is suggestive that the proposals are half-baked. At least one wording change was made in the middle of the vote with the consent of four folks and no opportunity for wider participation. (Whether or not such participation would have been forthcoming is immaterial.)

What's the rush to rearrange the deck chairs? Is there some kind of undisclosed deadline or other pressure? DCDuring TALK 00:23, 19 February 2016 (UTC)

To answer your last question: "Is there some kind of undisclosed deadline or other pressure?" I got cocky with the votes and said on my user page 13 days ago: "I decided I'm going to push WT:EL to be completely voted by the current year (2016) if it's in my power." In retrospect, maybe I shouldn't go so far as to make a mission out of it, but I admit I kind of did. I also said to a friend that I was trying to make 30 votes on consecutive days. (my friend is not a Wiktionary editor but he knows I edit Wiktionary; heck, most people I know know it) I'll take it back if that's a problem, but the fact is I just don't see it as a problem. To be safe, I'll take it back if people decide as a community that we don't want that kind of thing to happen, even if I don't personally want to stop. That's how a democracy ideally works, I think. The votes about WT:EL were proposed as an improvement to the policy. If some votes pass, it means 66,6%+ people supported the proposal, I can't edit the policy by myself.

DCDuring mentioned paid editing. Let's get this out of the way: I was not paid or hired or received any favor or service or anything to create votes. I did get some "thank you"s and that's it. --Daniel Carrero (talk) 01:13, 19 February 2016 (UTC)

Thanks for clearing that last point up. Would you forswear any future paid editing for any proposal that you put forward? DCDuring TALK 01:30, 19 February 2016 (UTC)

Are you talking specifically about these votes? I got paid to do the term cleanup (50% done) and Merging entries (didn't start yet because it would need discussion+consensus as discussed in my talk page, sorry). --Daniel Carrero (talk) 01:40, 19 February 2016 (UTC)

I'll do as you told but I'll place specific dates on it. I forswear any past, present and future paid editing for my votes that I created or am going to create from 1 January 2016 to 31 May 2016. Reason: I just didn't get paid for them, if that worries you. If someone offers me a million dollars tomorrow and says "Good job for creating Wiktionary:Votes/pl-2016-01/Translations of taxonomic names, I'm giving this money to you because you created it." I'm going to refuse it, even if I have to curse you for having to do that on that extremely unlikely event.

But could I get paid to create votes in the future? I don't know. Would that be harmful to Wiktionary in some way? Maybe it could be harmful, but I didn't think it through. --Daniel Carrero (talk) 01:53, 19 February 2016 (UTC)

@Pengo, I appreciate you defending me, thank you very much. I do think it's generally a good idea to edit WT:EL fast to keep it up to date, and discussion+votes is really the only system we have. Once in October 2015 I tried to edit WT:EL without a vote, but soon a discussion was created asking for my edits to be reverted, to which I quickly obliged. After I created too many votes now, because of the complaints, I did promise to stop creating votes from February 29 to May 31. Maybe in the meantime we could have some discussion/poll concerning exactly what are the limits for creating votes. Heck, I'll probably find something else to do (creating appendices/templates or editing entries as I had planned and listed in #About my proposals, or doing whatever outside Wiktionary) so I could easily make it 4 or 5 months without creating votes. --Daniel Carrero (talk) 02:21, 19 February 2016 (UTC)

Cash for votes sounds like Cash for questions. Not good. Equinox ◑ 02:44, 19 February 2016 (UTC)

On an unrelated note, could people please stop calling Daniel Carrero "Dan"? It's very confusing. For me and probably most regular Wiktionarians, Dan is someone else entirely. —Aɴɢʀ (talk) 07:03, 19 February 2016 (UTC)

User:DCDuring asked for a permanent, prominent location for a comparison between styling templates. I created it here: WT:STYLE#Styling templates. I am going to link this from the docs of all of the templates in question, but first I want to make sure people don't think there is a better name for the section or a better place for it to go. Benwing2 (talk) 00:09, 19 February 2016 (UTC)

I was looking for only the first three columns in the first table, but what you've done is much better, providing context and more content, making it potentially useful to a larger audience. Neither the name for the section, nor the ordering of sections in WT:STYLE seem wholly satisfactory, but I have neither suggestions nor specific reasons for my dissatisfaction today. I took the liberty of adding some things to column four of the first table, which I hope are intelligible.

What path would newer or returning users follow to find WT:STYLE? DCDuring TALK 00:50, 19 February 2016 (UTC)

It would be linked from all the templates that are mentioned in it, mentioned prominently near the top if you think that's a goo idea, so that people will know to look there for comparisons. Benwing2 (talk) 00:59, 19 February 2016 (UTC)

Proposals:

Postponing this vote: (suggested at the talk page)

• Wiktionary:Votes/pl-2016-02/CFI: List of terms

Withdrawing this vote: (it's probably going to fail because the example entry has not been decided)

• Wiktionary:Votes/pl-2016-01/Pronunciation

Do you support doing that with these two votes? What other votes would you rather postpone or have them withdrawn? --Daniel Carrero (talk) 02:40, 19 February 2016 (UTC)

Please fix this template. German nouns can have more than two diminutives, so there has to be a "|dim3=" etc. For example, see Kind which has the diminutives Kindlein, Kindelein, Kindchen or Sack which has Säckchen, Säcklein, Säckle, Sackerl. -91.16.59.251 16:25, 20 February 2016 (UTC)

You meant T:de-noun and I fixed it. --kc_kennylau (talk) 16:55, 20 February 2016 (UTC)

If a term has multiple etymologies, it sometimes occurs that one is derived from the other. This is especially common in English, where verbs can be derived from nouns and vice versa without any suffixation (and neither lemma has an ending). It has bothered me that there are some entries where a relatively obscure or derived noun sense is listed first, while the much more common verb sense is down below. Examples include fix, fly, help, wane, fall. All of these are primarily verbs, and are only nouns secondarily. I'd therefore like to propose a set of rules:

• Derived terms are to be listed below primary ones.
• Etymologies should be listed in order of usage frequency, except that derived etymologies should be listed right beneath the primary etymology.

—CodeCat 22:33, 20 February 2016 (UTC)

I think in these cases, there should only be one etymology section. --WikiTiki89 15:57, 26 February 2016 (UTC)

Are musical terms (allegro, D.C. al fine, fermata) qualified to be translingual? I have a book of etudes with each song name and playing instructions translated into 5 languages, but the actual words used in the passage are unchanged. —Aryamanarora ^{(मुझसे बात करो)} 01:05, 21 February 2016 (UTC)

WT:AMUL specifically mentions Italianate musical terms as something that should not be considered translingual. — Ungoliant ^(falai) 01:36, 21 February 2016 (UTC)

However, some are more "naturalised" than others. If it's only in sheet music, I find it hard to consider it English; whereas e.g. allegro occurs in running text with an English -s plural. Equinox ◑ 02:02, 21 February 2016 (UTC)

Yes, but that precisely makes it not "translingual", since it is being subject to the rules of English morphology. Imaginatorium (talk) 06:03, 21 February 2016 (UTC)

What about the dynamics abbreviations, like pp, p, mp, mf, f, and ff? They usually aren't used in running text and do feel very translingual to me. —Aɴɢʀ (talk) 06:15, 21 February 2016 (UTC)

All depends, I suppose, on what makes things "feel" translingual to you. How would it help to categorise pp as translingual? I would have thought that this was for words/symbols etc for which it really was not possible to assign a language. True, if Rachmaninoff wrote ffffff (which he did), one could claim that "fortissississississimo" is not really Italian, but there's the slippery slope. Imaginatorium (talk) 08:40, 21 February 2016 (UTC)

I think categorizing pp as translingual is as helpful as categorizing kg as translingual: it means the same thing in all languages where it's used. It makes more sense than creating two dozen language entries for pp that are all defined as "pianissimo; very softly" or something. —Aɴɢʀ (talk) 10:12, 21 February 2016 (UTC)

But why do you need to do that? Quo vadis is Latin, and no doubt used throughout the European languages, but there is no need to write "Quo vadis: Czech, from Latin" "Quo vadis: Italian, from Latin" etcetcetc. Of course there should be some expression like "std. mus. notation"; any more entries is just fluff. Is the object to make Wiktionary bigger or more useful? Imaginatorium (talk) 16:29, 21 February 2016 (UTC)

What about A, B, C, D, E, F and G? These “feel” translingual. — Ungoliant ^(falai) 14:39, 21 February 2016 (UTC)

Those feel less translingual to me because B, for example, is called H in German, and in French, these seven notes are called la, si, do, ré, mi, fa, and sol respectively. —Aɴɢʀ (talk) 15:19, 21 February 2016 (UTC)

I propose to remove the following votes from the vote watchlist, and make sure they are added back no sooner than on May 1.

Ends Vote Starts

• Mar 22 Placement of "Descendants" starts: Feb 22
• Mar 23 Spaces in links starts: Feb 23
• Mar 24 Space after context labels starts: Feb 24
• Mar 25 CFI: List of terms starts: Feb 25
• Mar 26 Using frwikt language header style starts: Feb 26
• Mar 27 Etymology starts: Feb 27
• Mar 28 Boxes and images starts: Feb 28
• Mar 29 Remove "The essentials" starts: Feb 29

Rationale: There are now too many votes on the vote watchlist: 28 votes. Votes require due attention of their participants, or else there is too big a risk that they become that which gives rise to the evil meme "votes are evil". Raw voting without due thought to vote consequences and without enough time and attention for discussion of pros and cons is a bad thing.

Does anyone agree? --Dan Polansky (talk) 11:07, 21 February 2016 (UTC)

• I do, of course. I had been hoping that Dan would see the error of his ways and that this would not be necessary. That we should be dancing to his tune with regard to his puerile commitment to having one vote every day for a month is particularly annoying. It wouldn't be so bad if the proposals were not so amateurishly crafted. DCDuring TALK 12:59, 21 February 2016 (UTC)
• So do I, needless to say. --Droigheann (talk) 13:54, 21 February 2016 (UTC)

I think we should at least delay them or hold them back somehow. Equinox ◑ 22:21, 21 February 2016 (UTC)

•  Done. I didn't edit the date in each vote page separately but I did remove them all from the vote box. --Daniel Carrero (talk) 04:22, 22 February 2016 (UTC)

Looking over Daniel C.'s votes, I thought about something and would like to get some feedback on it; for example, whether it has been discussed before: Can't we have movable headers? I'm thinking about something like: 'Alternative forms' and 'Pronunciation' stay unnested on top of the page as long as they apply to every entry on it but get moved down and assigned in some fashion when an entry is made which does not fall under them. Korn (talk) 15:46, 21 February 2016 (UTC)

That's more or less what we do now. Would any of the votes be contrary to that or apparently favor an alternative? DCDuring TALK 18:00, 21 February 2016 (UTC)

We do? I thought that when the pronunciation differed for a noun and a verb they went both into an L3 Pronunciation, rather than into separate L4 Pronunciations under their respective L3 POS's, as in e.g. excuse or survey, although sometimes this seems to be dealt with by having two (identical) Etymologies as in record. --Droigheann (talk) 00:49, 22 February 2016 (UTC)

I'm sorry, I was more focused on Alternative forms. But the principle we follow for Alternative forms and for Derived and Related terms in complex entries could be applied to Pronunciation as well, though Pronunciation has more complications than Derived and Related terms and has, I think, more numerous instances of problem cases than Alternative forms. I am extremely skeptical that the best layout for every situation in every language will result from the imposition of any rule, especially not the rigid ones that are being voted on. We can't really even answer the question of "best for whom, looking for what, with what prior knowledge?" DCDuring TALK 03:40, 22 February 2016 (UTC)

I'm not against rules in general (e.g. in this case I think that a general advice in WT:EL on how to format these POS-variable pronunciations would be more valuable than finding the perfect carrot example word), but I don't believe in 'one size fits all', which is why I'm so concerned about the current votes on the position of usage notes and on 'removing flexibility'. --Droigheann (talk) 00:11, 23 February 2016 (UTC)

Is User:Iceblock/Oxford Dictionary of Astronomy appropriate as a user page? Iceblock (talk) 17:35, 21 February 2016 (UTC)

This is a job for our legal department, I think. @BD2412. DCDuring TALK 18:09, 21 February 2016 (UTC)

w:Wikipedia talk:Copyright problems/Archive 18#Copy headwords from a dictionary

DCDuring - Is the link related to your supposition? Iceblock (talk) 19:39, 21 February 2016 (UTC)

Yes. But we are a dictionary, not an encyclopedia, so we are "closer" to the material in question. In any event BD has Wiktionary's peculiarities at heart, more than NihonJoe. I wouldn't be surprised if the answer was the same. DCDuring TALK 20:12, 21 February 2016 (UTC)

I am more skeptical of the proprietary of copying a list of 4,000 headwords, since the listing of words included reflects the judgment of the writers of the dictionary. As a general principle, to avoid any kind of question, we prefer to generate lists of headwords needing entries from public domain works, or generating combined lists from multiple sources without identifying which source provided which words. bd2412 T 02:36, 23 February 2016 (UTC)

I assume that almost any use of the list that was on one's own computer and that did not display the list would be less subject to challenge. For example, use the list to find which terms from the list were already used as headwinds, defining terms, in appendices, user spaces, or WP article names or redirects. This could be do a by runs against dump files. The results of the runs, it seems to ma, would involve sufficient value added to no longer be a simple derivative work. Is this reasonable? DCDuring TALK 04:11, 23 February 2016 (UTC)

DCDuring, that is correct. Although publication of the infringing material is not a necessary element of copyright infringement, it is a necessary element of proof of copyright infringement. As long as the person who has privately made such a list doesn't sit and do nothing but serially make all the entries in the order of the original dictionary, there is no basis to prove infringement. bd2412 T 13:00, 23 February 2016 (UTC)

To me it seems like a fair use copyrighted data to use multiple copyrighted lists to produce a master list, especially if no one list provides the bulk of the content and one can show that most of the items have multiple sources. DCDuring TALK 13:58, 23 February 2016 (UTC)

Yes, that is doable, and is the basis of Brian0918's Hotlist. However, we can put off that issue by generating and completing comparable public domain lists first. By so doing, we can substantially reduce the number of missing words to be found on lists generated from copyrighted works. bd2412 T 18:00, 23 February 2016 (UTC)

OK. That's good guidance.

It's also true that as we increase the quality of individual entries, we can find more terms to add, in small numbers, linked to what we have. DCDuring TALK 18:25, 23 February 2016 (UTC)

It's a list of terms from astronomy. It includes no copyrighted definitions. I have already added some of the terms that we were missing (using a variety of sources). SemperBlotto (talk) 09:15, 22 February 2016 (UTC)

Sort of stating the obvious, but I'm with BD2412 on this one as there's a certain amount of creativity involved in compiling a list of words deemed acceptable for a dictionary, even if you're not including the definitions. There's this lawsuit in the UK over Spotify using the order of tracks from Ministry of Sound albums. The settled out of court by the way. Renard Migrant (talk) 11:42, 23 February 2016 (UTC)

• One way to avoid on-wiki use of such a list is to generate a list of headwords of WP astronomy articles and, further, a list of the vocabulary used therein. From that one would subtract general-use words, to yield a master list of possibly distinctive astronomical terms. For the general-use words a concordance would help identify any distinctive astronomical use of the general-use words. A list such as the one in question would be reduced to that of checking completeness of the list of distinctive astronomical terms.

Other ways would involve harvesting glossaries and dictionaries in the .gov domain.

Another possibility would be to check a list of terms derived from any source that were missing from Wiktionary for their apparent attestability. Unattestable terms can include some planted to detect possible infringement. DCDuring TALK 13:58, 23 February 2016 (UTC)

Not everything in the .gov domain is necessarily public domain. —Aɴɢʀ (talk) 11:06, 24 February 2016 (UTC)

Long ago we enforced OP blocks (mostly TOR) locally through a coordinated meta project. Both of those things have gone by the wayside, and OP blocks are now managed globally by stewards. I would like to suggest that we rescind the local blocks which are in place so that IPs which have been reallocated are no longer blocked. There are many thousands of such IPs, some of which are range blocks. - TheDaveRoss 22:20, 24 February 2016 (UTC)

Is there risk? Presumably the older the block, the more likely it is to be unproductive. Also, the broader the block. Why not get rid of older, broader blocks first and see what, if anything, happens?

To me indefinite blocks seem likely to be possibly useful, but a policy of successively multiplying by ~10 the block period would also seem to be useful and less likely to exclude innocent users. Do we have tools to track recurrence of bad behavior by IP? DCDuring TALK 23:56, 24 February 2016 (UTC)

The risk is, of course, that vandalism from IPs may increase. I don't think it would increase much, the only increases would come from IPs which are blocked here but not globally (which excludes most OPs). We would, of course, just reblock problem IPs with a long-but-not-indefinite block. - TheDaveRoss 13:50, 25 February 2016 (UTC)

User:193.63.87.227 is not globally blocked on Meta (as far as I can tell) but the history shows that this IP cannot be left unblocked. -- Liliana • 00:08, 25 February 2016 (UTC)

There are so many such blocks that I assume the unblocks would have to be performed by a script or bot running from an admin account. If it would be possible to compare a list of local indefinite blocks and global blocks, I would suggest unblocking people who are blocked globally and then seeing what remains. There may be a few IPs like Liliana mentions which need to remain blocked. (Following this consensus I previously lifted indef blocks of IPs other than suspected proxies.) - -sche (discuss) 01:02, 25 February 2016 (UTC)

I can look into pulling the lists of IP blocks from both, I am not sure how possible it is. I am not suggesting that we don't maintain local IP blocks for local problems, I am saying that we have a lot of IPs blocked which may or may not be problematic, and nobody is maintaining those blocks (as in checking to see if they are still relevant). - TheDaveRoss 13:50, 25 February 2016 (UTC)

If it's not feasible to only unblock people who are globally blocked, I don't mind you (or someone else) lifting all the indef IP blocks; we can always reblock the (few?) local problems. Incidentally, I've noticed a few 'practically indefinite' IP blocks like blocks for 99 years; if someone could make a list of (or even just proceed straight to shortening) any blocks that expiry more than four years in the future, that would also seem like a good idea to me. - -sche (discuss) 20:34, 25 February 2016 (UTC)

We could do worse than rescind them all and block on a case-by-case basis where needed. But not indefinitely. Renard Migrant (talk) 21:58, 25 February 2016 (UTC)

I went ahead and pulled (clarify, didn't remove the blocks, just downloaded them) all blocks and all global blocks. There are 13,700 indefinite blocks locally (range, single IP and user) and almost 6000 global blocks (all IP, some range). I can try and compare lists (it will be a pain) if people are really interested in that, but I suggest we just unblock and go from there. - TheDaveRoss 22:38, 25 February 2016 (UTC)

OK. It's interesting that so many local blocks are not global, but only a handful of indef IP blocks are more recent than 2008 (and most are from 2006), so IPs may have been reassigned, etc. I am OK with just lifting all indefinite IP blocks. - -sche (discuss) 03:08, 26 February 2016 (UTC)

Late comment here: As someone using the project from a network shared with 500 or so access points which do not always get assigned the same IP, I'd like to make a call for leniency. Some years back I had to contact an admin because my internet had magically flipped over to another IP which was blocked on Wiki. It took three days to get it fixed while the original perpetrator probably wasn't even living in the same city anymore, pointless hassle. I'm sure there is some period of time after which the average Wiktionary-troll will have forgotten about his hobby. Korn (talk) 21:03, 28 February 2016 (UTC)

Not late at all, thanks for weighing in. I think you are right that there is a practical limit to the length of time a given troll might have a single IP or even be on a particular IP range, and anyone who is included to do so can easily evade blocks anyway. - TheDaveRoss 13:30, 29 February 2016 (UTC)

I think a one-day block is usually enough. A one-week block for persistent ones. Anything longer is useless. An amateur troll will stop caring quickly. A "professional" troll will know how to get his IP changed anyway. --WikiTiki89 16:06, 29 February 2016 (UTC)

As there hasn't been much controversy over the idea, I am going to go ahead and unblock a bunch of these and see what happens. I'll spread it out over a couple weeks to avoid flooding and give people who may not have seen this discussion a chance to react if they like. - TheDaveRoss 18:20, 25 March 2016 (UTC)

Still no controversy, I am going to switch to flood flag mode soon and just knock out the remaining few thousand of these. - TheDaveRoss 14:19, 30 March 2016 (UTC)

All done! There is one weird block remaining, here, no target. Some kind of DB bug I guess. - TheDaveRoss 13:56, 31 March 2016 (UTC)

@-sche, Liliana-60 re the one IP (User:193.63.87.227) can we change that block to something which is long but not indefinite? I think a policy of no indef blocks for IPs should be in place. - TheDaveRoss 16:05, 31 March 2016 (UTC)

@TheDaveRoss OK, I've reblocked the user for two years; their last problematic edits (see their deleted contribs) were in 2012; I guess we can see if they're still a problem in 2018. I think blocks that are longer than 4 years (and especially really long blocks like 99 year blocks I've seen once or twice) are actually more dangerous than indef blocks, because they're practically indef but harder to find. (If it wouldn't be too difficult, it'd be great if you or someone else could check for any IP blocks where the expiration date isn't until sometime after 2020. I'd be tempted to shorten such blocks.) Btw, on the subject of "one weird block": take a gander at this impossible IP address! - -sche (discuss) 17:40, 1 April 2016 (UTC)

Thanks for modifying that. I agree that very long blocks are problematic, there are only three extant IP blocks which are longer than the revised block you placed, all expiring in 2019. I was able to unblock that impossible IP one through the API yesterday, it took a bit of finagling to get it though. - TheDaveRoss 18:24, 1 April 2016 (UTC)

Oh, good, thank you checking (for long blocks). Btw, I notice that 663.19.150.52 has no contributions (not even deleted contributions); I wonder why it was blocked in the first place. I remember being unable to unblock it the last time IP blocks were discussed. - -sche (discuss) 21:32, 1 April 2016 (UTC)

Because it's an impossible IP address. (Each part is a byte, and must be between 0 and 255.) I would guess that it was a typo for 63.19.150.52. --Catsidhe ^{(verba, facta)} 21:43, 1 April 2016 (UTC)

If terms exist in two or more foreign languages, but there is no English equivalent, is there any way to link them together?

I was thinking of the French bar-tabac and the Italian bar-tabaccheria. SemperBlotto (talk) 11:39, 25 February 2016 (UTC)

Etymology sections showing them as cognates? DCDuring TALK 11:55, 25 February 2016 (UTC)

Unless they aren't cognates. The example that always occurs to me is a verb meaning "to be silent". Most European languages have a simple verb for this (French se taire, German schweigen, etc.), but English doesn't, meaning there's no place (other than silent itself, which is suboptimal) where we can equate those terms. It's kind of annoying, but on the other hand, I suppose it isn't really English Wiktionary's job to facilitate translation between French and German. —Aɴɢʀ (talk) 12:43, 25 February 2016 (UTC)

Maybe under ===See also===. I think a handful of older Chinese + Japanese entries do this. —suzukaze (t・c) 12:52, 25 February 2016 (UTC)

If they aren't demonstrably cognates, strictly speaking, why not just put them in each other's etymology with a simple "See". I assume that what is somewhat interesting is that two languages seem to have followed very similar patterns to form the term, even if neither is a descendant of the other and we have no evidence at this time that they have a common origin. DCDuring TALK 14:42, 25 February 2016 (UTC)

I think it's a misuse of the etymology section to put that kind of thing there. There are all kind of interesting patterns of what one might call "convergent evolution" between languages only some of them, such as "see you later" as a goodbye are represented in English, but English is atypical in many ways, so not all of them are. I think the best we can do using current formats is "See also". Chuck Entz (talk) 15:02, 25 February 2016 (UTC)

But we don't put words from languages not the same of the headword's anywhere other than in Etymology and Translation sections. We are asserting some kind of connection, just not necessarily one we can specify better at this time. Perhaps it is imitation, a form of interlingual influence that does not have much parallel in organism inheritance processes. I think treating "See also" as an all-purpose garbage can is as bad as stretching the use of "Etymology". DCDuring TALK 16:53, 25 February 2016 (UTC)

{{translation only}} --kc_kennylau (talk) 15:14, 25 February 2016 (UTC)

{{translation only}}, but we should vote about some policy about it, otherwise it might get deleted. Matthias Buchmeier (talk) 12:22, 26 February 2016 (UTC)

In general, I agree with what Chuck says: use "See also". Pace DCDuring, "See also" is our "catch-all" for anything that doesn't fit elsewhere, and to me "see some etymologically unrelated but comparable phrase" makes more sense as a "See also" than as "Etymology". In specific interesting cases like "be silent", create a translation target, as Kenny suggests. - -sche (discuss) 20:16, 25 February 2016 (UTC)

Translation target ... that's what sometimes occurs to me to do, but I then realise I'd see it the next day nominated for deletion by the anti-SOP brigade, so I solace myself with the argument given above by Angr and I let it be. --Droigheann (talk) 20:50, 25 February 2016 (UTC)

Ideally we would create a single translation section somewhere and transclude it into all of the applicable entries. The whole concept of translation target makes sense, what doesn't make sense is creating a main namespace entry which purports to be an English term but which is really a concept for which there is no singular term in English. Maybe a Translation namespace, with page titles being glosses or something... Another usecase for relational databasing. - TheDaveRoss 12:34, 26 February 2016 (UTC)

@Wyang, Iudexvivorum, Octahedron80, หมวดซาโต้, Alifshinobi

There are a lot of rapid changes currently happening to Thai entries. Wyang has developed a semi-automatic module to transliterate phonemic Thai using Paiboon publisher's method. It seems to work in most cases and has been accepted by Thai editors and more changes introduced. Good job!

Now, the original Thai transliterations get out of date and become dispreferred. That's fine but entries still use them. It's OK to remove the old transliteration when the new transliteration is added in the Pronunciation section - only in one place, to keep it in sync with any future changes.

However, the majority of entries have not been converted to use {{th-pron}}. Can we really change the headword, so that most entries don't have ANY transliteration? I don't think users will be happy with that. Maybe some transliteration is better than nothing.

{{th-noun}}, {{th-verb}}, etc. now ignore manual transliterations and don't display automatic - the reason is that manual is non-standard and automatic one may be wrong for non-phonetic short words. (only monosyllabic words are transliterated automatically but irregular words are transliterated incorrectly).

BTW, {{th-l}} will correctly transliterate words that are defined and use {{th-pron}} (or if phonetic respelling is added with |p=).

Also, Octahedron80 changed the Thai headword to add "abstract noun ความ) to EACH verb, adjective and adverb. Many such PoS would benefit form it but many has become wrong, such as ไทย, etc. which now shows ไทย (abstract noun ความไทย). That's wrong for this and many other entries. The fix is easy, just add "|-" but someone would have to check hundreds of other verbs, adjectives and adverbs!

We need to decide on the rules and what should be allowed. E.g. adding ความ to all verbs, adjectives and adverbs was probably a bad or rash idea if no-one knowledgeable checks ALL these entries. Rather than removing transliterations from the headword, maybe auto-translit should be turned off? --Anatoli T. ^{(обсудить}/^вклад) 13:50, 25 February 2016 (UTC)

{{look}}

@Wyang, Iudexvivorum, Octahedron80, หมวดซาโต้, Alifshinobi I still need to hear native users' and Wyang's (as the main developer of the module) opinion on the two matters. Please don't ignore this important topic. Your attention is required as there are hundreds, if not thousands entries affected by changes. My knowledge of the language is not enough and it's also very time-consuming. I have suggestions but I want to hear your opinions first. If you don't respond, I am afraid I have to revert some changes by Octahedron80 and do something about missing transliterations. --Anatoli T. ^{(обсудить}/^вклад) 22:08, 25 February 2016 (UTC)