Wiktionary:Beer parlour/2016/February

discussion rooms: Tea roomEtym. scr.Info deskBeer parlourGrease pit ← January 2016 · February 2016 · March 2016 → · (current)

About entry names (removing from CFI, adding to EL)Edit

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.

Many phrases take several forms. It is not necessary to include every conceivable variant. When present, minor variants should simply redirect to the main entry. For the main entry, prefer the most generic form, based on the following principles:


Prefer the generic personal pronoun, one or one’s. Thus, feel one’s oats is preferable to feel his oats. Use of other personal pronouns, especially in the singular, should be avoided except where they are essential to the meaning.


Omit an initial article unless it makes a difference in the meaning. E.g., cat’s pajamas instead of the cat’s pajamas.


Use the infinitive form of the verb (but without “to”) for the principal verb of a verbal phrase. Thus for the saying It’s raining cats and dogs, or It was raining cats and dogs, or I think it’s going to rain cats and dogs any minute now, or It’s rained cats and dogs for the last week solid the entry should be (and is) under rain cats and dogs. The other variants are derived by the usual rules of grammar (including the use of it with weather terms and other impersonal verbs).


A proverb entry's title begins with a lowercase letter, whether it is a full sentence or not. The first word may still be capitalized on its own:

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):

The name of the entry is the term, phrase, symbol, morpheme or other lexical unit being defined.[1]

For languages with two cases of script, the entry name usually begins with a lowercase letter.[2] For example, use work for the English noun and verb, not "Work". Words and phrases which begin with a capital letter in running text are exceptions. Typical examples include proper nouns (Paris, Neptune), German nouns (Brot, Straße), and many abbreviations (PC, DIY). Compare: you can't judge a book by its cover and Rome wasn't built in a day. If someone tries accessing the entry with incorrect capitalization, the software will try to redirect to the correct page automatically.

Omit an initial article unless it makes a difference in the meaning. E.g., cat’s pajamas instead of the cat’s pajamas. For multi-word entries, prefer the generic personal pronoun for the main entry. (one, oneself, someone, one’s, etc.) Common forms with other pronouns are usually redirected to the main form. For example, fall over oneself would be the main entry and these are some entries that would redirect to it: fall over himself, fell over himself, falling over himself, fall over herself, fall over themselves, etc. Use the infinitive form of the verb (but without to) for the principal verb of a verbal phrase, for example: rain cats and dogs. In English, sometimes the lemma should include a specific personal pronoun. For example, the proverb you can't fight City Hall would be the lemma, not one can't fight City Hall. For prefixes, suffixes and other morphemes in most languages, place the character "-" where it links with other words: pre-, -ation, -a-, etc.

When multiple capitalizations, punctuation, diacritics, ligatures, scripts and combinations with numbers and other symbols exist, such as pan (as in "frying pan"), Pan (the Greek god), pan- (meaning "all-") and パン (pan) (Japanese for "bread"), use the template {{also}} at the top of the page to cross-link between them. When there are too many variations, place them in a separate appendix page, in this case Appendix:Variations of "pan".

Use the "Alternative forms" header for variations of the same word kept in multiple pages, including:

Some page titles can't be created because of restrictions in the software, usually because they contain certain symbols such as # or |, or are too long. The full list of those entries is at Appendix:Unsupported titles. They are named using the descriptive format "Unsupported titles/Number sign", while using JavaScript to show the correct title like a normal entry.

Matched-pairs, such as brackets and quotation marks, can be defined together as single entries. The entries are named with a space between the left and right characters. Examples: ( ), [ ], “ ”, ‘ ’, " ", „ ”, « », ⌊ ⌋, ¡ ! and ¿ ?.[4][5]


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

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

  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)

Proposal: "Category:English trisyllabic words" and similar categoriesEdit

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:

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

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.?)
--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)

Alternative forms after definitionsEdit

Previous discussions:

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)

  • 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[s] 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)

need bot permissionEdit

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 Quotations headerEdit

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:

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)

Emilian-Romagnol vs. Emilian?Edit

User:Gloria sah asked me:

I noticed that in the page "", 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)

Proposal: Removing "Flexibility" from WT:ELEdit

While the information below may represent some kind of “standard” form, it is not a set of rigid rules. 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. Be ready to discuss those changes. If you want your way accepted, you have to make the case for that. Unless there is a good reason for deviating, the standard should be presumed correct. Refusing to discuss, or engaging in edit wars may also affect your credibility in other unrelated areas.

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)

Should all adjectives have adverbial sections?Edit

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)

Switching from є to е in Old Church SlavonicEdit

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.[1] 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)

“Trivia” or some other suitably explanatory headingEdit

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.


  • 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)
[2] --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 my proposalsEdit

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)TCM 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)

Declension tables after every new etymologyEdit

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)

how to represent "Y; in [some dialect], also pronounced X"Edit

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) [3], [4], [5], [6], and [7]. 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 [kʰʊ̃ːæ̯̃n] (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. —Μετάknowledgediscuss/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)

Poll: pronunciation exampleEdit

FYI: There's a poll going on:

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)

Placement of a English-specific pronunciation ruleEdit

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: h-system and x-systemEdit

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)TCM 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 (talkcontribs) 00:07, 9 February 2016 (UTC)

Blocking policy - full revisionEdit

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)

Hapax legomenaEdit

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)

Interwiki links - actual regulationsEdit

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)

WT:About German - "Obsolete spellings"Edit

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. - 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 [kʰʊ̃ːæ̯̃n] (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.
- 17:21, 21 February 2016 (UTC)

Categorize by translationEdit

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)TCM 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 (tc) 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. —Μετάknowledgediscuss/deeds 23:30, 13 February 2016 (UTC)

Presenting the absolutely useless ancestor chainEdit

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)

Placement of "Descendants"Edit

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?


  • 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".


--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 - list of termsEdit

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.


A term need not be limited to a single word in the usual sense. Any of these are also acceptable:

--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 (C6H12O6 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 (talkcontribs) 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 .
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 (talkcontribs) 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)

CFI terms - revision 2Edit

@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.


These items are acceptable to be included as dictionary entries:

--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)

Finnish inflected nouns labelled as noun (forms) and adverbs - consistency? policy?Edit

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.org/wiki/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)

Minor edit: nonexhaustive gender list in ELEdit

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:

  • Provide the grammatical gender of the translations of nouns, if appropriate, giving the parameters m, f, n and c for “masculine”, “feminine”, “neuter” and “common” respectively to {{t}}.

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

  • Provide the grammatical gender of the translations of nouns, if appropriate, giving the parameters such as m, f, n and c for “masculine”, “feminine”, “neuter” and “common” respectively to {{t}}.

--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. —Μετάknowledgediscuss/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 [somewhere] 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)

"NORM: 10 proposals" ends in 2 daysEdit

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)

Tying ancestors to families by defaultEdit

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:
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)

Chinese traditional forms vs. simplified/variant/obsolete/archaic formsEdit

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), , 线 (xiàn) and (). 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 (), 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 (tc) 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 (tc) 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)

When exactly to use {{a}} and what to use in its place and where for register distinctions in pronunciationEdit

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)

Proposal: Using frwikt language header styleEdit

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


  • 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.


  • 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)
  SupportAryamanarora (मुझसे बात करो) 16:53, 14 February 2016 (UTC)
  SupportΜετάknowledgediscuss/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 (tc) 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)

Why is Proto-Canaanite considered a dialect of Proto-Semitic?Edit

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)

Watching page categorizationEdit

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)

Minor edit: wiki code -> wikitext in NORMEdit

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.


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

Affected text:

This is a list of aspects that govern how the wiki code wikitext behind an entry should be formatted. They are invisible to the readers, e.g., following these rules makes no difference to how a user sees the page, but they do make the pages conform more to a standard format reflecting what we think of as best for the wiki code wikitext.

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

  SupportΜετάknowledgediscuss/deeds 03:04, 18 February 2016 (UTC)
  Done --Daniel Carrero (talk) 12:07, 17 March 2016 (UTC)

Index of current votes - planned and runningEdit

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

About translations:

Removal of EL content:

Editing all entries:

Placement of headings:

WT:CFI edits:

WT:NORM edits:

WT:BLOCK edits:

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

Additional votesEdit

—⁠This unsigned comment was added by DCDuring (talkcontribs). 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)

No Solresol at all?Edit

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. 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? -- 23:55, 15 February 2016 (UTC)
Thanks, SemperBlotto and -sche! :) -- 00:00, 16 February 2016 (UTC)

SI units that have little or no actual usageEdit

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)TCM 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)TCM 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)

Etymology vote = February 27Edit

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)

Categories at the end of the language sectionEdit

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

  • Categories are placed at the end of each 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)

3 months without creating votesEdit

Planned, running, and recent votes [edit this list]
(see also: timeline, policy)
No current or planned votes.
(=0)[Wiktionary:Table of votes](=0)

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)

Section on styling templates, should it have a different name?Edit

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)

Postponing/withdrawing votesEdit


Postponing this vote: (suggested at the talk page)

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

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. - 16:25, 20 February 2016 (UTC)

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

Proposal: Derived lemmas below primary lemmasEdit

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)

Translingual musical terms?Edit

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, , mi, fa, and sol respectively. —Aɴɢʀ (talk) 15:19, 21 February 2016 (UTC)

Removing multiple Daniel Carrero votes from the vote watchlistEdit

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)

Mobile headersEdit

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 [kʰʊ̃ːæ̯̃n] (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)

User page appropriate or notEdit

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)

Rescinding all indefinite IP blocks which are in placeEdit

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: 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 [kʰʊ̃ːæ̯̃n] (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: 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 --Catsidhe (verba, facta) 21:43, 1 April 2016 (UTC)

Linking foreign-language wordsEdit

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 (tc) 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)

Changes to Thai headwords, new semi-automatic transliteration, abstract nouns with ความ, etc.Edit

@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)


@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)
Abstract noun (อาการนาม) is a type of noun taught in school. (Others are common noun, proper noun, collective noun, and classifier.) It is formed by put การ or ความ before stem. General rule is: การ for verb and ความ for adj & adv. This noun is unavoidably mapped with English vocab, for example, การเดิน=walking, การใช้=using/usage, ความสุข=happiness, ความพอใจ=satisfaction. (ความไทย may mean to Thai-ness but people usually use ความเป็นไทย instead.) Most words apply this rule. But sometimes the rule is broken because some words can use both and some words cannot be prepended; this can be determined by how people or literature use it. (This is like RFV. Googling is an option.) Another condition I have noticed recently is that adj & adv which come from proper noun (like countries) won't become abstract noun. However, every rule has exception, right? If you are afraid that checking its existance will be big task. Don't worry. This is not urgent matter. I can volunteer to check them all. Th-headword module has been used on th-wiktionary for months and it works well, therefore I copy it here and hope it useful. --Octahedron80 (talk) 02:08, 26 February 2016 (UTC)
PS. Which parts of my changes you want to revert? Please discuss to me each case. --Octahedron80 (talk) 02:08, 26 February 2016 (UTC)
About transliteration, I can't say much because I didn't co-develop the module. I just did data correction. In my opinion, Thai tranlit will never be perfect since there's a lot of exceptions. Direct logic can't take it all. By the way, there is another system by the Royal Institute that is officially used for naming and documents . Should this be included too? --Octahedron80 (talk) 02:54, 26 February 2016 (UTC)
@Octahedron80 Thank you for responding! No, I won't revert anything without an agreement but I was worried about the impact and if nobody looked after the changed entries, then there wouldn't be anyone to fix the wrong ones. Have you assessed how many adv, adj and verb entries need "-"? Are you able to check ALL of them over time?
As for transliteration. You may be right that the automatic translit may not work for all cases, all the more it's important to keep the old one in place, rather than disabling tr= parameter altogether. --Anatoli T. (обсудить/вклад) 03:26, 26 February 2016 (UTC)
@Octahedron80 this revision of แขก (kɛ̀ɛk) doesn't show any transliteration, although it has "|tr=kàek". I am fixing it now but there are many entries to be fixed. --Anatoli T. (обсудить/вклад) 04:06, 26 February 2016 (UTC)

Th-headword module improved. Headword can also show transliteration by these conditions:

  1. If tr parameter is set, show its text.
  2. If mono (monosyllable) parameter is set, transliteration will be made with its text via th-pron module. (may suggest better parameter name)
  3. If nothing above is set, transliteration will be made with its pagename via th-pron module.

--Octahedron80 (talk) 08:29, 26 February 2016 (UTC)

@Octahedron80 Thanks for the changes. #1 is important but when all entries are fixed to use {{th-pron}}, we won't need |tr=. The transliterations (the method itself) can change at any moment in the future, that's why Wyang suggested to remove tr= on new and converted entries. #2 may be flawed, as could be the case with ทราย, compare ทราย (saai) vs ทราย (saai) - the same word transliterated differently. The 2nd works correctly because the word is defined and it has a working {{th-pron}}. The best way, if we need transliteration in the headword as well, is to use method #3, monosyllabic or long words.
Okay I will drop tr. And you see ทราย and จักรยานยนต์ again. --Octahedron80 (talk) 11:37, 26 February 2016 (UTC)
Are you planning to go through all adj, adv and verbs to check if "abstract noun ..." is used correctly? I don't know enough Thai to do that myself but it's now the default for all entries using {{th-adj}}, {{th-adv}} and {{th-verb}}. Do you think there will many entries, which don't need it? --Anatoli T. (обсудить/вклад) 11:32, 26 February 2016 (UTC)
Yes, I will. From my experience at th-wiktionary. About 10-20% of total verbs, adjs & advs can't be abstract noun. That is the reason why I can check. I also have a bot to collect new words list periodically. --Octahedron80 (talk) 11:41, 26 February 2016 (UTC)
@Octahedron80 Thanks. It's better to remove the auto-translit from the headword (if there's no "|tr="), please see ฉลาด (chà-làat), which shows "chlàat", instead of "chà-làat". Unless you can make it use the phonetic Thai, the same as in the pronunciation section. Do you agree? --Anatoli T. (обсудить/вклад) 11:51, 26 February 2016 (UTC)
Not sure if I explain myself well. tr= is still needed but during the transitional period because there are a lot of entries still, which don't have {{th-pron}}. NEW or converted entries may do without "tr=". --Anatoli T. (обсудить/вклад) 11:54, 26 February 2016 (UTC)
@Octahedron80 I can see you're fixing it with "mono". Thanks. I guess it's OK (only some duplication effort, perhaps). A better name would be "phon" - for "phonetic" or "phonemic". Please note, that Chinese headwords don't have transliterations in the headword (but they cater for multiple topolects), so, if this requires too much effort, the pronunciation section would probably suffice. --Anatoli T. (обсудить/вклад) 12:07, 26 February 2016 (UTC)

I think I made it. The first parameter from th-pron is brought to tranliterate in th-headword. Now we don't have to retype phon (or mono) as well as that page uses th-pron template. (case of needing, see สระ) Also we can track down Category:Thai terms without th-pron template; in that case, phon (or mono) will be used. Let's ignore those tr's and change to th-headword template. --Octahedron80 (talk) 04:57, 27 February 2016 (UTC)

Thanks @Octahedron80 for your various edits on Module:th-pron. I make combinations like h+m/n/l/r/ng/w/y interpreted as main+coda unless there is a vowelless sign in between. There may be existing entries containing such combinations undesirably interpreted as main+coda, and we can modify the module to categorise them into a maintenance category to track them down. I support the removal of headword transcriptions. While we are here, let's also discuss (1) Template talk:th-pron: a potential tabular display of {{th-pron}}; (2) and modification of Module:links, such that any attempt to link to a Thai word (whether it be via {{l}}, {{m}} or {{compound}}) is handed over to Module:th#link. Alternatively, we need to make {{th-compound}} for use in Etymology. Wyang (talk) 05:29, 27 February 2016 (UTC)

@Wyang Do you want to use w:ISO 11940 or not? If not I will recover your complete old charTable. --Octahedron80 (talk) 05:44, 27 February 2016 (UTC)
I liked the vowel part of ISO 11940 but not so much for the consonant part. The sound values are not very apparent. So I restored the table for consonants but left the one for vowels unchanged. Any thoughts on the tabular format and linking? Wyang (talk) 06:00, 27 February 2016 (UTC)

@Wyang, Iudexvivorum, Octahedron80, Atitarev Hello! I have some questions regarding transliteration of homographs (คำพ้องรูป). What we should do when a single entry contains several etymologies/parts of speech with different pronunciations? Examples: เจ้า can be pronounced "jâao" (chief, lord, master, etc.) and "jâo" (second person pronoun, particle, etc.); เช้า can be pronounced "cháao" (morning) and "cháo" (basket); etc. Can we manually add transliterations in the headwords when each etymology/part of speech pronounces differently? Or can we enable the templates to automatically generate different transliterations in a single entry? The newly fixed templates seem to automate only one transliteration (as seen in เจ้า). --หมวดซาโต้ (talk) 08:35, 27 February 2016 (UTC)

It can detect only first one; this is also my intention. It doesn't know where th-noun was put before or after or how many they are or which one to show. In this case we have to put phonetic next to it. Take some action for less problem. --Octahedron80 (talk) 09:28, 27 February 2016 (UTC)
PS. Please split dialects as another language section. Northern Thai which uses 'nod' code is not actually sub-set of Thai. Isan (tts), Southern Thai (sou), Pattani Malay (mfa) either. --Octahedron80 (talk) 09:32, 27 February 2016 (UTC)

The tree structure of derived terms categoriesEdit

Recently I have been thinking it's not really necessary that the "derived terms" categories appear in a big tree. It makes them hard to navigate, and also requires that the user has intimate knowledge of how we distribute languages among families. Just look at how deep Category:English terms derived from Zulu is nested! Moreover, the "family" categories are often empty, it's the leaf categories where everything interesting is. So, I wonder if there is enough support for "flattening" the tree, by listing all the categories in a single list?

Another thing I would like to propose is to make a separate category for borrowings per language. Currently, {{borrowing}} just lumps them all into one category, and puts them in the generic "derived from" category. I think it would be more useful if borrowings from a language had their own category. —CodeCat 19:28, 25 February 2016 (UTC)

I would oppose removing the tree structure (which makes it easier to navigate around and compare derivations from related languages), but I wouldn't mind double-categorizing all the "leaves" also into one big category, similar to how the topical categories are hopelessly deeply nested into a myriad of pigeonholes, but then usefully also duplicated in Category:en:List of topics. - -sche (discuss) 20:09, 25 February 2016 (UTC)

66,6% = passes, right? (Short blocking policy)Edit

I already extended Wiktionary:Votes/pl-2015-11/Short blocking policy twice. It's going to end in less than 10 days. (on March 5)

Current results: 4-2-0, which means 66,6% in support.

  • Proposal: If no one else votes by the end date, closing this vote as passed.
  • Rationale: Just standard practice: 66,6% = passes. If possible, I'd like to close the vote rather than extending it again.

Needless to say, feel free to cast your votes if you didn't already do it. --Daniel Carrero (talk) 20:15, 25 February 2016 (UTC)

I'm pretty sure that standard practice is that 2/3 support is closed as no consensus. --Yair rand (talk) 21:02, 25 February 2016 (UTC)
Actually I think standard practice is to let the closing admin decide. I might not like it much but hey, the whole reason we're talking about standard practice is that there are no rules on the matter. Renard Migrant (talk) 21:56, 25 February 2016 (UTC)
@Yair rand: Any evidence? --Dan Polansky (talk) 12:06, 27 February 2016 (UTC)
Hm, it looks like this is more complicated than I thought. WT:Votes/pl-2014-07/Allowing well-attested romanizations of Sanskrit's original closing (12-6-1, passing) was disputed, and extended as a result. WT:Votes/2012-10/Enabling Tabbed Languages's original closing (13-6-0, failing) was similarly disputed and then extended. WT:Votes/pl-2007-07/Brand names of products was closed as failed at 13-6-1. And, as you mentioned below, in 2013 a vote passed with 6-3-2. --Yair rand (talk) 19:21, 28 February 2016 (UTC)
@Yair rand: Thank you for actually looking into the issue, and digging up specific votes. I'll grant you that there is very little evidence as for whether, in the actual practice as shown through actually closed votes, 2/3 is a pass. The practice is still volatile and in the process of being made rather than being firmly solidified. Let me note that, in WT:Votes/pl-2014-07/Allowing well-attested romanizations of Sanskrit, the dispute was not about the threshold but about the vote being closed as soon as the threshold was reached rather than further extended, which looked like fishing for a specific result. --Dan Polansky (talk) 20:15, 28 February 2016 (UTC)
The opposite of Yair, I was under the impression that 2/3 support was usually a pass. Some old discussion can be found here, and I got the impression that the practice of passing votes with 2/3 support had solidified / become more common in the four years since that discussion. - -sche (discuss) 22:56, 25 February 2016 (UTC)
Wiktionary:Votes/pl-2013-03/Romanization and definition line is a vote that was closed as passed with 2/3 support.
I support the practice of closing policy votes that achieved 2/3 supermajority as a pass. --Dan Polansky (talk) 12:06, 27 February 2016 (UTC)
Wiktionary:Votes/pl-2014-12/Making simplified Chinese soft-redirect to traditional Chinese was closed as passed even under 2/3 threshold; this vote was locked by an admin to prevent me from disputing the result of the vote on the vote page. --Dan Polansky (talk) 20:18, 28 February 2016 (UTC)
66.7%. Renard Migrant (talk) 12:28, 27 February 2016 (UTC)

German Verb Conjugation TablesEdit

Should German verb conjugation tables mark forms that have long fallen into disuse? Take sprechen as an example; all subjunctive I forms except the 3rd person singular (ich spreche, du sprechest, wir sprechen, ihr sprechet, sie sprechen) are simply inapplicable in modern language. Also, the 2nd person preterite forms (du sprachst, ihr spracht) and especially the 2nd person subjunctive II forms (du sprächest, ihr sprächet) are technically applicable, but are perceived as archaic and very rarely used.

I think marking these forms somehow to inform of their obsolescence is something worth considering since it would surely come helpful to Wiktionary users. Unfortunately, it wouldn't be without its complications: some or all of these normally out-of-use forms find use with the auxiliary (sein, haben, werden) and modal verbs (wollen, können, etc.), and a few other verbs like aussehen (eg. du sahst heute voll schön aus) or wissen (eg. das wüsstest du wohl gerne).

Would this be plausible? TrioLinguist (talk) 20:27, 25 February 2016 (UTC)

I think the subjunctive forms should be marked somehow as they are clearly out of use but the preterite forms are very rare but still in use. Matthias Buchmeier (talk) 12:19, 26 February 2016 (UTC)
The preterite forms aren't even that rare up here in the northern half of Germany, I think. I hear them in speech frequently enough, even for content verbs (not just auxiliaries and modals). I certainly have no impression that the 2nd person singular preterite is rarer than the other persons. —Aɴɢʀ (talk) 15:40, 26 February 2016 (UTC)
I would wonder what is used for the 2nd person singular in the past. —CodeCat 17:55, 26 February 2016 (UTC)
The periphrastic perfect: du bist gegangen instead of du gingst; du hast angerufen instead of du riefst an. —Aɴɢʀ (talk) 18:14, 26 February 2016 (UTC)


An adverb section has been added to evenings - e.g. "I usually go to out walking evenings".

Isn't this just a plural of evening with some sort of preposition missing. Similar constructions include "I go to French class (on) Mondays" and the like. SemperBlotto (talk) 15:14, 26 February 2016 (UTC)

Cambridge and Collins include it as an adverb. It could be parsed as a plural with an implied preposition; on the other hand, -s does exist as an adverb-forming suffix, and it functions like an adverb, as does Mondays, which is labelled an adverb. Is Monday, with no -s, an adverb? It's labelled one, like other days of the week are. - -sche (discuss) 17:03, 26 February 2016 (UTC)
Historically it is a genitive of the noun. In 19th century writings one can also find adverbial use of of an evening and of evenings. It occurs with time words, like evening, days of the week, months, and seasons. Another example that can be so used is of recent years.
As this genitive doesn't really fit into current grammar, we could choose to present it usexes of the noun or as an adverb. The adverb presentation doesn't capture the fact that the nouns can be modified by adjectives and determiners: "Those hot summer evenings we would ....". Do we conceive of such expressions as prepositional phrases with the preposition elided? DCDuring TALK 18:39, 26 February 2016 (UTC)

Resuming term cleanupEdit

I'm gonna resume my project of adding the langcode to {{term}} as explained in User:Daniel Carrero/term cleanup.

I've done 10,020 pages. There are 11,125 pages to go. --Daniel Carrero (talk) 02:40, 27 February 2016 (UTC)

For full disclosure, as I said before, this is a paid project in which I'm receiving $1 every 100 entries from @Angr. (minus Patreon and PayPal taxes) --Daniel Carrero (talk) 02:46, 27 February 2016 (UTC)
And for even fuller disclosure, I don't get anything at all from his doing this other than the satisfaction of seeing the number of items in Category:term cleanup go down. —Aɴɢʀ (talk) 08:13, 27 February 2016 (UTC)
I came across this from the WMF Terms of Use document. (I wasn't looking for it.) Though I doubt that it was intended to cover this kind of thing, it nevertheless applies:

"Paid contributions without disclosureEdit

These Terms of Use prohibit engaging in deceptive activities, including misrepresentation of affiliation, impersonation, and fraud. As part of these obligations, you must disclose your employer, client, and affiliation with respect to any contribution for which you receive, or expect to receive, compensation. You must make that disclosure in at least one of the following ways:

  • a statement on your user page,
  • a statement on the talk page accompanying any paid contributions, or
  • a statement in the edit summary accompanying any paid contributions.

Applicable law, or community and Foundation policies and guidelines, such as those addressing conflicts of interest, may further limit paid contributions or require more detailed disclosure.

A Wikimedia Project community may adopt an alternative paid contribution disclosure policy. If a Project adopts an alternative disclosure policy, you may comply with that policy instead of the requirements in this section when contributing to that Project. An alternative paid contribution policy will only supersede these requirements if it is approved by the relevant Project community and listed in the alternative disclosure policy page.

For more information, please read our FAQ on disclosure of paid contributions.

We reserve the right to exercise our enforcement discretion with respect to the above terms."

Simple compliance is probably easier than trying to draft our own policy. We aren't going to get anywhere trying to get the WMF Board to change this. We could ignore it because it doesn't really apply to our situation. But someone who was actually doing the bad things this is trying to prevent could conceivably try to use our noncompliance as an excuse for nondisclosure. DCDuring TALK 12:08, 27 February 2016 (UTC)
I read the whole thing. meta:Terms of use/FAQ on paid contributions without disclosure#Can a local project adopt an alternative disclosure policy for paid editing? says: "Disclosure of paid contributions to any of the Wikimedia projects is a requirement under the disclosure provision of the Terms of Use. Nonetheless, individual projects may create an alternative disclosure policy when their projects or communities have particular needs to either strengthen or reduce the requirements."
So, no, disclosure is still mandatory. Why would we ignore that policy?
I think the "bad things" the policy is trying to prevent is someone being paid to push a point of view in Wikipedia articles. --Daniel Carrero (talk) 17:12, 27 February 2016 (UTC)
I know, but you're still caught in the net. DCDuring TALK 17:44, 27 February 2016 (UTC)
Are you saying that I (or anyone) should be able to work on a paid project like User:Daniel Carrero/term cleanup without disclosing that it is a paid project? I'd rather know if these things are happening and I have no problem telling other people when I do it. --Daniel Carrero (talk) 17:49, 27 February 2016 (UTC)
"Simple compliance" with the specific means that they suggest would be best. To me the statement on your user page looks like the easiest way to comply, though it is less informative than what you've already done on this page. Obviously you wouldn't want to waste time and space on the talk page for mere format corrections. DCDuring TALK 18:02, 27 February 2016 (UTC)
I think the spirit of the law is that the community deserves to know if the edits are likely to be influenced by they payment. In the case of the tasks Daniel is undertaking they are technical cleanup tasks, and have little chance to result in conflict of interest. He is also asking for payment from the local community, which further reduces the problem. I don't think he needs to be more upfront about his activity than he has already been. Edit summary notes, in particular, I find to be over-the-top. - TheDaveRoss 19:39, 27 February 2016 (UTC)
I know what bad behavior it was intended to control. I don't see how ignoring it works. We can comply with the policy as stated, we can vote on a replacement policy, or we can not comply and rely on the discretion of WMF in enforcement. I personally doubt that they care about Wiktionary at all. DCDuring TALK 21:50, 27 February 2016 (UTC)
Do you have any replacement policy in mind? --Daniel Carrero (talk) 22:08, 27 February 2016 (UTC)
No. We can comply by doing any one of the things they prescribe. The notification at the Beer Parlor is still probably the best single kind of notification, but doesn't meet their express requirements. It just doesn't seem worth a vote, compared to, say, improving one English function-word entry or adding three taxonomic names. DCDuring TALK 23:23, 27 February 2016 (UTC)
In any event, I'm complying with the rules on Meta: 1) I have a statement on my user page ever since I started this project in October, 2) also when I edit an entry for the project, I link to the project page in the edit summary. Example: diff. (Just a link, without any explanation in the edit summary itself. I hope that's acceptable in your opinion, @TheDaveRoss?) --Daniel Carrero (talk) 06:39, 28 February 2016 (UTC)
I am fine with the status quo. - TheDaveRoss 13:31, 29 February 2016 (UTC)
You only have to do one of the three things WMF requires to be in compliance. I appreciated the BP mention, which they don't require, but seems more effective in notifying wiktionarians. DCDuring TALK 15:39, 29 February 2016 (UTC)

Re-borrowings and Etymology-only languagesEdit

I see that the modules have been changed so that it's no longer possible to have a derivational category where the language is deriving from an etymology-only variety of itself. This is as it should be, IMO, since we don't allow categorization of the etymology-only languages as destination languages, and so some of the finer context can't be represented in the categories. I would go further, and have {{etyl}} stop adding these categories.

That raises the question of what to do with cases where a term is borrowed into a language from a foreign-language term that's ultimately derived from the same language it's being borrowed back into. Where there's no etymology-only code involved, this would be categorized into a "Twice-borrowed terms" category. Perhaps the {{etyl}} template should just convert the etymology-only code to its main code and treat it the same way.

I can see a couple of problems with this, though they're not really specific to etymology-only languages:

  1. Without constant vigilance, most of the "Twice-borrowed terms" members are bogus, because people tend to use the {{etyl}} template for internal derivation processes such as nouns coming from verbs in the same language. This would add a whole new class of potential bad uses, especially inheritance from older stages of the same language. On the other hand, with the current state, those would just turn up as the bogus categories mentioned above- so they would have to be fixed, ether way.
  2. "Twice-borrowed terms" doesn't quite fit for cases such as Latin where the parent language coexists with daughter languages and can borrow from them: there's no borrowing in the history of an inherited Spanish term, so a Latin term borrowed from it isn't really "Twice-borrowed". This can't be dealt with automatically, since daughter languages can also borrow from a parent language as well as inheriting from it. On the other hand, this is rare- I'm sure there are examples, but I can't think of any. Also, it can be somewhat mitigated by an explanation in the wording of the "Twice-borrowed" categories.

As I see it, these are the obvious options for dealing with source and destination codes being the same (i.e. ML. and la):

  1. Do nothing with the modules, and just clean up the bogus categories when they come up, as well as adding the "Twice-borrowed categories by hand.
  2. Disallow categorization, and hope someone adds the "Twice-borrowed" category by hand in the rare cases it's appropriate:
    1. Just throw a module error.
    2. Add no category at all, as if the source code were really "-"
      1. Add only a cleanup category
  3. Treat the category-only source language code as its main code (i.e. treat ML. as la), and keep an eye on the "Twice-borrowed terms" categories.

What does everyone else think? Chuck Entz (talk) 22:26, 27 February 2016 (UTC)

Somewhat related: ιστόγραμμα, νέον, ουτοπία, and other cases where (in this case) Greek has borrowed a word from English that English either borrowed from Ancient Greek or formed from Ancient Greek roots. - -sche (discuss) 03:09, 28 February 2016 (UTC)
I definitely realise this is a problem, but I don't really have any good solutions for it right now. I just wanted to say that in case you felt ignored. —CodeCat 17:15, 29 February 2016 (UTC)

About learning ArabicEdit

Someone I know -- I don't wish to identify him/her :) -- said, in all seriousness, the following statement about languages, but it does not feel quite right to me. (the person is a Brazilian Portuguese speaker)

"I wanted to learn Arabic, but it's very difficult because it's so different from Portuguese. So I started by studying English and French. All languages came from Arabic, so first I should learn different languages to get ready before starting to learn Arabic."

I don't think I am qualified enough to tell to what extent it makes sense or if it's complete nonsense. I know that English, French and Arabic are part of different language families, and they seem to have a sizable number of words borrowed from Arabic (I checked the categories and read a bit of w:Arabic), but that's different from saying that they (let alone all languages) came from Arabic. Apparently that person did not actually go very far in learning any of the foreign languages mentioned yet, so I assume that statement is just what that person believes would work as a good plan to learn Arabic.

Apparently we are bound to return to this topic of conversation sooner or later, so would you help me in pointing out and clearing any misconceptions in that statement? What would you say if someone said that to you? --Daniel Carrero (talk) 09:04, 28 February 2016 (UTC)

Sounds silly to me. The writing system is completely different, for one thing, and e.g. English doesn't share much Arabic vocabulary. I have native English and found Arabic hard and unfamiliar. Equinox 09:06, 28 February 2016 (UTC)
Certainly the claim "all languages come from Arabic" is utter nonsense. I've often heard the same claim made about Sanskrit, but that's utter nonsense too. However, it probably is true that it's easier to learn a difficult language if you've already learned some easier languages first. Not because the easier languages directly make the harder language easier, but rather because you're already familiar with what learning a foreign language entails, and what sort of things you have to learn when you're learning a language. —Aɴɢʀ (talk) 09:49, 28 February 2016 (UTC)
Good point, I agree with you about "it probably is true that it's easier to learn a difficult language if you've already learned some easier languages first" for the reasons you mentioned. --Daniel Carrero (talk) 16:12, 28 February 2016 (UTC)
I wonder how they got this idea. The “every language comes from Sanskrit” thing is because during the early days of historical linguistics Sanskrit was used as more or less a synonym of Proto-Indo-European, but I’ve never seen this claim made for Arabic. — Ungoliant (falai) 16:18, 28 February 2016 (UTC)
I was curious specifically about the statement "All languages come from Arabic" so I didn't say much else about our conversation to avoid going off-topic, but that person also gives credit to Arabic speakers for other things: "Arabic speakers invented math, all we have in civilization today can be traced back to Arabic speakers."
It's true that some important development in math and civilization (culture, etc.) happened in Arabic-speaking countries, but "all of it can be traced back to them" does seem like an overstatement to me. --Daniel Carrero (talk) 16:43, 28 February 2016 (UTC)
For a long time, the Arabic contribution to Western civilization was underplayed and ignored. They played an important part in keeping knowledge from the classical civilization alive while Europe went through the dark ages, and they provided a route for connecting India's system of learning to the West. It's good that people are bringing attention to this, and to the Muslim world's own achievements, but it seems like it's being taken to the point that they're starting to be painted as the originators of what they merely perpetuated and improved upon. Chuck Entz (talk) 17:10, 28 February 2016 (UTC)
I think he is confusing languages with alphabets/scripts. Of course, all languages did not descend from Arabic, but almost all alphabets and abjads did come from Phoenician, which itself came from Proto-Sinaitic, which came from Egyptian hieroglyphs. The Arabic abjad also came from Phoenician. Arabic and Phoenician are both Semitic languages, so that is probably where he started to get confused. The scripts to the west of Phoenician became true alphabets (Greek, Latin, Cyrillic, Glagolitic). The scripts in the Middle East became abjads (Hebrew, Arabic). The scripts to the east of Phoenician became abugidas (Brahmi, Gupta, Devanagari, Gujarati, Oriya, Sinhalese, Gurmukhi, Bengali, Kannada, Telugu, Burmese, Khmer, Thai, Tibetan, Javanese, Hanunó'o, Tagalog script, numerous others). An example is the letter e, as it developed in different scripts: 𐤄 ,ה, ε, e, ھ, ए, এ, ਏ, એ, ଏ, எ, ఎ, ಎ, എ, එ, เ, ເ, ဧ, េ. —Stephen (Talk) 11:49, 28 February 2016 (UTC)
Isn't the idea of the Brahmic scripts descending from Aramaic kinda controversial? From what I've read, it seems researchers are divided on this issue. —Aryamanarora (मुझसे बात करो) 16:01, 28 February 2016 (UTC)
I have never heard that there was any controversy about this, or that researchers were divided. There is some controversy over certain individual alphabets and scripts such as Georgian (with regard to how much influence the Greek alphabet had on the Georgian alphabet), and some controversy surrounding Korean Hungul and 'Phags pa, and questions about Armenian, but in general I have not heard of any controversy. —Stephen (Talk) 16:58, 28 February 2016 (UTC)
Found this in a book:
"Written from right to left, Kharoshthi seems to have been derived from the north Semitic Aramaic script. The origins of Brahmi, a script written from left to right, are not as clear. Some scholars have suggested an indigenous origin, others [] " [8]
Aryamanarora (मुझसे बात करो) 17:35, 28 February 2016 (UTC)
That's very helpful, thanks. Yes, it's possible that person is confusing languages with alphabets/scripts. --Daniel Carrero (talk) 16:12, 28 February 2016 (UTC)

Linguistics is not a easy subject, so you see folk etymologies like "NEWS comes from North East West South" accepted as truth everywhere. Is he/she a Muslim? --kc_kennylau (talk) 12:06, 28 February 2016 (UTC)

He/she is most certainly not a Muslim. --Daniel Carrero (talk) 14:12, 28 February 2016 (UTC)

Wikimania 2016: call for posters, discussions and trainingsEdit

Hi people,
the calls for posters, discussions and trainings for Wikimania 2016 are officially opened, you can find all the relevant links on the conference wiki:


The calls will be closed on March 20.

Posters will be reviewed just to make sure that there aren't things which are too much out of scope. Since we have a whole village we will surely find places to attach them, even if we they will be a lot!

Discussions will be managed by a guiding committee who will work on the wiki to meld all the proposals and suggestions.

Trainings will be reviewed by the programme committee. Please note that we request that each training has at least 3-5 interested attendees in order to be put in the programme.

By the beginning of April we will have a first list of all the accepted proposals.

If you have questions we suggest you to ask them on the discussion pages on wiki, so that everyone will be able to see them (and their answers, of course).

We are looking forward to read your ideas! --Yiyi (talk) 13:28, 28 February 2016 (UTC)

I created this page to have a central list of all templates that have a parameter that must match the current language. This is useful for people wanting to run a bot to check and fix these. The list is probably not complete; please add any that are missing! —CodeCat 15:07, 28 February 2016 (UTC)

Why not put them in a category instead? DTLHS (talk) 20:07, 28 February 2016 (UTC)

Prakrit languagesEdit

After seeing the success in Pali being (mostly) converted to the Latin script, I'd like to propose something similar for the Prakrit languages. Yes, these are also extinct Indo-Aryan languages that can be written a multitude of scripts (like Brahmi, which very few browsers support). Most current work on the Prakrits are done in the Latin script, and since we currently have little coverage of these languages, manual conversion won't take too long. —Aryamanarora (मुझसे बात करो) 15:58, 28 February 2016 (UTC)

I know that a lot of modern non-religious publications of Pali are in Latin script; is that true of the Prakrits as well? —Μετάknowledgediscuss/deeds 20:22, 28 February 2016 (UTC)
No - these are basically dead languages. New publications are recordings of inscription, new grammars, and the like. A lot of the current research shows either original inscriptions (i.e. photographs or drawings) or transliterations in the Latin script. Also, there are dozens of varieties - the main ones are Maharastri, Sauraseni, and Ardhamagadhi. —Aryamanarora (मुझसे बात करो) 02:54, 29 February 2016 (UTC)
We gave Pali the Latin script because material is still written in it and it never had one script that was common enough to be recognized globally. The Prakrits were all well attested and written in Brahmi, so I would vote against the Latin script. Also, work being done on the language means that it is a mention, not an attestation. This is why, though so much work is done on Egyptian Arabic in the Latin script, we do not provide Egyptian Arabic lemmas in the Latin script. DerekWinters (talk) 05:51, 29 February 2016 (UTC)
@DerekWinters The Prakrits are actually written in several scripts, such as Devanāgarī, Sinhala, Oriya, Gupta (not in unicode) and more. —Aryamanarora (मुझसे बात करो) 20:10, 29 February 2016 (UTC)
On a similar note, should we begin converting all Tocharian lemmas to Kharosthi, the same way that we have Gothic lemmas and romanizations? We use Ogham, Gothic, Chakma, etc. already for languages, and I doubt that they have very wide browser support. DerekWinters (talk) 05:56, 29 February 2016 (UTC)
Tocharian has a long history of being in the Latin scripts, so it's best to keep it as it is. Also, there are easily four or five varieties of the Brahmi script - which one would we write it in? The Prakrits are also written in Devanāgarī, Sinhala, Bengali, and so on. The two fonts that I know support Brahmi are Noto Sans Brahmi (I use this) and Segoe UI Historical. —Aryamanarora (मुझसे बात करो) 13:01, 29 February 2016 (UTC)
Also, Tocharian isn't written in Kharosthi, it's actually the Brahmi script. See Tocharian alphabet. —Aryamanarora (मुझसे बात करो) 16:28, 29 February 2016 (UTC)
Gothic also has a tradition of being reproduced in Latin script. —CodeCat 17:14, 29 February 2016 (UTC)
Also, the Tocharian alphabet isn't in Unicode yet, so we don't really have any choice but to write it in romanization. —Aɴɢʀ (talk) 18:55, 29 February 2016 (UTC)
Sorry, I meant Brahmi for Tocharian. What I'm saying is that it is perfectly fine to have romanization entries, but that they should lead to a the main entry being in that script of attestation. And as CodeCat said, many languages have "traditions of being reproduced in Latin script", but they weren't produced in that script by speakers ever. DerekWinters (talk) 19:02, 29 February 2016 (UTC)
That is the status quo already. The only time we have only Latin-alphabet entries is when the native script isn't in Unicode, as is the case with Tocharian, and the only time when Latin-alphabet entries are the main entries and the other scripts are secondary is when there isn't any single predominant native script, as is the case with Pali. —Aɴɢʀ (talk) 19:49, 29 February 2016 (UTC)
Umm, Brahmi is in Unicode. Brahmi (Unicode block). It's just Brahmi was unicode-ized very recently, so ~99% of research is still done in the Latin script. —Aryamanarora (मुझसे बात करो) 20:08, 29 February 2016 (UTC)
I'm not sure that Unicode block is suitable for Tocharian, though. Certainly not with the glyphs shown in the corresponding PDF file. Perhaps it would be possible for someone to make a font accommodating the Tocharian glyphs, but I think it's more likely that Tocharian will one day have a Unicode block of its very own. —Aɴɢʀ (talk) 20:20, 29 February 2016 (UTC)
Actually, I take that back: that Unicode block is definitely unsuitable for Tocharian, because it doesn't have any space for the Tocharian letter and vowel sign conventionally transliterated ä. I'm also not quite sure how the consonant transcribed kᵤ works in the native script, so I don't know whether the Brahmi block can accommodate it. —Aɴɢʀ (talk) 20:25, 29 February 2016 (UTC)
You're right, it is missing them. Besides kᵤ, I have also seen in Tocharian A - would that just be "Brahmi letter DHA"? —Aryamanarora (मुझसे बात करो) 20:29, 29 February 2016 (UTC)
I assume so; I've never seen it. Is it used only in Sanskrit loanwords that have ध? —Aɴɢʀ (talk) 20:44, 29 February 2016 (UTC)
I've only seen in a name, Siddʰārth, so likely it is a loanword. —Aryamanarora (मुझसे बात करो) 13:27, 1 March 2016 (UTC)
Having read this, it seems that ä has no symbol, but is just a change in pronunciation based on the previous syllable. —Aryamanarora (मुझसे बात करो) 13:39, 1 March 2016 (UTC)
But back to the original question, I think we should have all Prakrit lemmas in Brahmi, or the script of attestation, with corresponding romanizations. Similar to how Gothic lemmas are done. Except, without a million Gothic romanizations with deadlinks. DerekWinters (talk) 22:35, 29 February 2016 (UTC)

Is it really in the third declension? Are the declined forms attested? --kc_kennylau (talk) 14:43, 29 February 2016 (UTC)

Translation-only entries are not English lemmasEdit

I noticed that [[in three days]], a translation-only entry, appears in Category:English lemmas. If there is to be any point to having translation-only entries, they should be excluded from that category. I don't know whether there are other, similar categories from which they should also be excluded. DCDuring TALK 17:28, 29 February 2016 (UTC)

What about Category:English adverbs? Should it be in there? —CodeCat 17:38, 29 February 2016 (UTC)
I think that the word-class categories have some value, but they could be dispensed with because we know the language for these is English and the L3 heading conveys the word class. I hope that all of these use {{translation only}} so we can do efficient searches for them. DCDuring TALK 21:56, 29 February 2016 (UTC)

Template ParametersEdit

I would like to propose that we allow bots to fill in the names of parameters for all templates which assign unnamed parameters to named parameters. I would also like to suggest that templates which accept more than one parameter be required to name those parameters. I understand that some folks prefer the shortcut which is afforded by using unnamed parameters, which is why I suggest that we allow that practice to continue, but have the bots cleanup after the fact. The major benefits of this scheme are that future changes to templates are less likely to break existing usage, and that editors who are less familiar with the templates in question will be able to more easily understand which parameters mean what.
Further, I would like to suggest that we normalize a few very common parameters, and document their appropriate usage. Then we should ensure that existing usage matches those standards. Off the top of my head I suggest that year, date and lang be standardized, I am sure that there are more major parameter names which should be included as well. By normalizing these I mean that we should establish rules about acceptable formats, and require that the parameters always be called the same thing if they are being used for the same purpose. Thanks. - TheDaveRoss 20:41, 29 February 2016 (UTC)

Oppose as a general rule, but I would be willing to support the concept on a case-by-case basis, but mostly for templates that take a large number of parameters, like {{quote-book}}, for which this is usually already the case. To your second paragraph, I would say I agree that when these parameters are named, they should be named consistently. --WikiTiki89 21:07, 29 February 2016 (UTC)
Can you elaborate on why you oppose? I am not trying to be argumentative, just looking for clarity on what the drawbacks of the proposal are. - TheDaveRoss 21:30, 29 February 2016 (UTC)
Because I do not think that this is beneficial for all templates. --WikiTiki89 21:31, 29 February 2016 (UTC)
I guess there may be cases where it is better to leave the parameters unclear, but I can't think of any. - TheDaveRoss 12:17, 1 March 2016 (UTC)
I agree that mandatory naming of all template parameters beyond the first would be overdoing it (as long as the parameters are documented in some way). It could be useful for a number of widely used templates, but for less-used ones, especially with more idiosyncratic parameters, this just sounds like busywork. --Tropylium (talk) 21:59, 29 February 2016 (UTC)
What bots may do doesn't bother me as much as adding keystrokes at the time of initial use of the template. A system of paired templates, one member allowing numbered parameters, the other requiring names would be OK if the shorter name was for the one allowing numbered parameters and the longer one was transparently constructed from the shorter one. That way the bot-conversion targets could easily be identified. Presumably, it would be easier for all to add parameters to the named-parameter templates than to add them to numbered-parameter templates.
As a general rule, anything that makes it more time-consuming or tedious to manually add content should be strictly avoided, IMO. It's not as if our entries are at all close to reaching a gem-like perfection of content not requiring new definitions, etymologies, citations, requests, etc. DCDuring TALK 22:13, 29 February 2016 (UTC)
I agree, editing should be easy, but having obfuscated templates makes edits beyond the first edit more difficult instead of less difficult. The concept of paired templates may be worth pursuing, but that may also just add to the confusion. - TheDaveRoss 11:50, 1 March 2016 (UTC)
I agree that template parameters should make sense and be well documented, but that can be done without the hassle of named parameters. --WikiTiki89 15:12, 1 March 2016 (UTC)
  • I definitely oppose doing this to all templates. I use a number of templates where the first two or three parameters are made up of the parts of the word, e.g. {{dsb-decl-noun-19|wukni|k}} at wuknik, or {{ga-mut-cons|b|róg}} at bróg, or {{affix|my|ဝမ်း|ဆွဲ}} at ဝမ်းဆွဲ. Having to name those parameters, even if only done botwise after the fact, would cost a great deal of intuitiveness and ease of reading the edit box and would have no discernible benefits at all, as far as I can tell. —Aɴɢʀ (talk) 11:25, 1 March 2016 (UTC)
    • From my perspective, as a non-user of those templates, having parameter names added would be of great benefit. I assume that in those templates some part is the root of the word, and the other part indicates some declension pattern, but if I spotted an error in the declension I would have to go read the template markup or documentation to understand what needed fixing. They are only intuitive if you already know what you are looking at. - TheDaveRoss 11:50, 1 March 2016 (UTC)
      • The "k" in the first one and the "b" in the second one don't stand for anything; they're literally the last letter of the word and the first letter of the word, respectively. In the Burmese example, it's just the two parts of a compound word; I could just as easily have used {{affix|en|dog|house}} for doghouse as an example. —Aɴɢʀ (talk) 12:05, 1 March 2016 (UTC)
        • Which would be {{affix|lang=en|root=dog|suffix=house}}? Is that less intuitive? I understand why that might be more work to type, but I am not suggesting that, I am suggesting that such a use would get updated in the background so that it would display as such in the markup. - TheDaveRoss 12:15, 1 March 2016 (UTC)
          • "house" isn't a suffix, though, it's just the second root. It's not just a matter of being more work to type, it's a matter of being able to read the source code easily. I don't want to be confronted with {{dsb-decl-noun-19|firstpartoftheword=wukni|lastletter=k}} or {{ga-mut-cons|firstletter=b|restoftheword=róg}} when I open the edit box, even if I don't have to type it myself, nor do I want my watchlist to be cluttered by bots making totally unnecessary changes. Someone who doesn't use these templates anyway isn't helped by having explicit parameter names, and someone who wants to use these templates for the first time can look at the template documentation page to see how to write them. —Aɴɢʀ (talk) 12:56, 1 March 2016 (UTC)
            Why should we have to type 17 more characters (more than 75% more) for this "clarification"? DCDuring TALK 13:16, 1 March 2016 (UTC)
            • Why would you have to type more characters? I type {{t|es|palabra|m}} and behind the scenes it is converted to {{t|lang=es|tr=palabra|gender=m}}. Later, you note that the gender is wrong, and you can easily identify that the gender=m should be gender=f, type one character and save. - TheDaveRoss 13:30, 1 March 2016 (UTC)
              So I see " Spanish: palabra m ", I realise that "m" means "masculine", which is a mistake, but trying to edit it I don't see where in {{t|es|palabra|m}} the information is hidden? Come on ... --Droigheann (talk) 15:58, 1 March 2016 (UTC)
              • This is a more obvious example than others, there are much less obvious examples available. See: any of the myriad quotation and declension templates. There are also less obvious codes than m and f, but I am not sure this proposal will make them any more obvious. - TheDaveRoss 17:20, 1 March 2016 (UTC)
Effort in typing is not just a creation issue. If a bot replaces short markup with longer markup, anyone who subsequently edits the entry has to navigate through the long markup. I personally hate seeing fields of {{l|en|blah}} instead of simple old square brackets. Equinox 13:23, 1 March 2016 (UTC)
Certainly there would be more markup, but the markup would be less obfuscated than the current markup. Simpler markup has its merits, but the trend has been steadily away from simplicity, without corresponding usability considerations. If templates are going to continue to get more and more use, with more and more inbuilt functionality then we should also attempt to make the usage transparent. - TheDaveRoss 13:30, 1 March 2016 (UTC)
That seems to beg the question somewhat. One could flip it around and say "if more inbuilt functionality in templates is going to add complexity for everyday users, we should rethink it". Equinox 13:56, 1 March 2016 (UTC)
I am in agreement, we should put a lot more consideration into the templates and modules we create. There should be more concern about how user-friendly they are, and how resource intensive. We should consider how they might affect exiting usage, and how they might affect future plans such as migration to a relational structure of some kind. Right now there are lots of parallel efforts which are often uncoordinated, and little if no concern for anything other than expediency and ease of use for select power users. Not a great system. - TheDaveRoss 17:20, 1 March 2016 (UTC)
Oppose. So, instead of typing {{it-adj|tipic|o|a|i|he}} (for an Italian adjective, as an example) I would have to type something like {{it-adj|tipic|m=o|f=a|mp=i|fp=he}}. I do too much typing already, thanks. SemperBlotto (talk) 13:53, 1 March 2016 (UTC)
Nothing in this proposal suggests that original edits change in any way. If you type {{it-adj|tipic|o|a|i|he}} now you would type the same in the future. - TheDaveRoss 15:54, 1 March 2016 (UTC)
Oppose per all above. It doesn't help the reader, while inconveniencing (as others mentioned, it's not only about typing, it's about reading the markup as well) editors who contribute most contents. I don't care if it helps bots or people constantly meddling with templates, this isn't Google Translate. So far at least. I'm not against normalising common parameters though: if "tr" really means "translation" somewhere (as your "palabra" example above indicates) and "transliteration" elsewhere (as it does in Template:ux), that's wrong, it should always mean either the one or the other. --Droigheann (talk) 15:58, 1 March 2016 (UTC)
I am utterly at a loss as to how named parameters in usage make the markup less comprehensible. Longer? Absolutely. Harder to understand? That is like saying that it is easier to understand text with all of the vowels removed because there are fewer characters. Also, you should care about bots and people who meddle with templates, because the majority of the practical use of Wiktionary has little to do with the way we present data, and everything to do with the data we have and the parsability of that data. - TheDaveRoss 17:28, 1 March 2016 (UTC)
I do care, that's why I'd like templates only meddled with carefully. The farther you go into an entry's history, the more red lines saying "Template:infl" and "Lua error in Module" &c you see. Why should I believe that this once things will improve, rather than deteriorate further? All the previous changes were meant to be improvements, weren't they? As for "easier to understand", do you prefer to say "the first day of the month of March of the year 2016" to "the first of March 2016"? --Droigheann (talk) 19:54, 1 March 2016 (UTC)
I prefer March 1st, 2016 to 3/1/2016. Further, this would prevent a lot of those red lines in the future. - TheDaveRoss 20:13, 1 March 2016 (UTC)
For timestamps, I prefer the international standard of "2016 March 1". But I don't see how anything proposed here would "prevent a lot of those red lines in the future". Also, see this xkcd. --WikiTiki89 20:29, 1 March 2016 (UTC)
I also like standards, getting anyone here to agree on which standard is a task I am not enthusiastic about undertaking. Re preventing errors, named parameters do not care about order, so unless someone removed a named parameter entirely a modification to the template which changes the order of parameters will not break historical usage. - TheDaveRoss 20:35, 1 March 2016 (UTC)
A "modification to the template which changes the order of [named] parameters" is impossible anyway. The backwards compatibility problem is mostly caused by deleting templates entirely or changing the way their arguments work, which applies equally to named parameters. You can rename a parameter, remove it, change its purpose, etc. --WikiTiki89 21:03, 1 March 2016 (UTC)
Ordinary humans first. Machines last. Programmers in between. DCDuring TALK 17:31, 1 March 2016 (UTC)
The current ethos is editors first, who cares about anything else. - TheDaveRoss 17:49, 1 March 2016 (UTC)
I know. DCDuring TALK 18:23, 1 March 2016 (UTC)
Oppose per Angr. The drawbacks to cluttering up the wikitext outweigh the supposed benefits, IMO. - -sche (discuss) 19:14, 1 March 2016 (UTC)
Abstain, but I do see TheDaveRoss's point. Unnamed parameters can be very confusing and should only be used in the few cases where it makes sense (I like the {{affix}} usage where it also reads naturally), when there are very few input params. However, the aforementioned {{it-adj|tipic|o|a|i|he}} is confusing (unless you've already spent a lot of time around here and memorized call order). Named params facilitate self-documentation. Jberkel (talk) 00:05, 2 March 2016 (UTC)
Inflection templates, even with a lot of parameters, seem to me to be entered only based on inspection of the documentation and by a small group of people. (Something similar applies to {{taxon}}.) Those people probably can master the parameters reasonably quickly and probably appreciate reduced wear and tear on the joints of their fingers. (I know I do with respect to {{taxon}}.) IOW, there is many a template whose user base should probably make its own decision about what kind of template is preferred. Imposing a diktat seems simply ridiculous. If someone would like to drive me out of Wiktionary, continuing this kind of thing could work. DCDuring TALK 00:25, 2 March 2016 (UTC)
Ok, we do have a weirdly skewed user base ranging from casual contributor to power user. It will be tricky to make sure all interests can be served equally, maybe it's just not possible. I'm not even sure what the common goals of the community here are. But user friendliness / hostility as a problem seems to come up every now and again, and need to be addressed somehow. For my part I'd love to see some Wiktionary specific tools which could help with things like inline parameter documentation or autocomplete. The VisualEditor extension kind of goes in this direction but hides too many details and probably would not work here. But that's a different discussion. Jberkel (talk) 02:46, 2 March 2016 (UTC)
I'm certainly not opposed to improving the intuitiveness of certain templates ({{de-conj-weak}} and {{de-conj-strong}} come to mind as having far too many positional parameters with unintuitive arguments), I'm just opposed to this proposal being applied to all templates. —Aɴɢʀ (talk) 12:43, 2 March 2016 (UTC)
Twelve unnamed parameters in {{de-conj-strong}}, that's insane. Adding named parameters would be an option, but even better would be to have the template / module figure out some of it on its own, if possible, and remove the params from the call. Jberkel (talk) 13:35, 2 March 2016 (UTC)