Wiktionary:Beer parlour

Wiktionary > Discussion rooms > Beer parlour

Lautrec a corner in a dance hall 1892.jpg

Welcome, all, to the Beer Parlour! This is the place where many a historic decision has been made and where important discussions are being held daily. If you have a question about fundamental Wiktionary aspects—that is, about policies, proposals and other community-wide features—please place it at the bottom of the list (click on Start a new discussion), and it will be considered. Please keep in mind the rules of discussion: remain civil, don't make personal attacks, don't change other people's posts, and sign your comments with four tildes (~~~~), which produces your name with timestamp. Also keep in mind the purpose of this page. There are various other discussion rooms which may serve the idea behind your questions better. Please take a look to see which is most appropriate.

Sometimes discussion identifies an issue as an idea for policy development or rewriting. Such discussions may be taken out of the Beer parlour to a relevant page, or a brand new page may be created. Usually, the active policy pages will be listed in one of the sections below. See also the policy development page and the votes page.

Questions and answers will not remain on this page indefinitely, as it would very soon become too long to be editable. After a period of time with no further activity (usually a couple of weeks), information will be moved to the archives. We make a point to preserve all discussions that were started here in the archives. However, talk that is clearly not intended for this page may be moved and will not end up in the archives. Enjoy the Beer parlour!

Beer parlour archives edit

February 2017

Czech verbs ending in -ti or -t?Edit

@Dan Polansky All my etymological Slavic sources (Derksen, ESSJa, Vasmer) consistently write Czech infinitives ending in -ti, but in Wiktionary they are entered ending in -t instead. What's going on here? Should we at least create soft redirects for the forms in -ti? Benwing2 (talk) 04:58, 1 February 2017 (UTC)

The -ti endings must be archaic. Most modern Czech verbs end in -t, AFAIK - brát, psát, číst, nést, být, dělat. --Anatoli T. (обсудить/вклад) 05:36, 1 February 2017 (UTC)
Quoting one web source: A Czech infinitive usually ends in -t (infinitives in older literary texts may end in -ti). --Anatoli T. (обсудить/вклад) 05:38, 1 February 2017 (UTC)
Dan has answered this for me before. Older dictionaries lemmatize with -ti, newer dictionaries lemmatize with -t. As far as I know, both forms have always existed in parallel (and are not etymologically the same form and sometimes the difference is non-trivial, e.g. péct vs. péci). I think both forms should be given in conjugation tables, with the -ti form being treated like any other non-lemma form. We should probably also give them separate names. --WikiTiki89 15:22, 1 February 2017 (UTC)
@Benwing2: -ti is archaic. -ti forms are used neither in modern speech nor in modern writing, as you can verify in Google Books for yourself. Nonetheless, even some 20th century dictionaries like {{R:PSJC}} and {{R:SSJC}} lemmatize on -ti. Interestingly enough, SSJC uses -ti as lemma but -t in its definitions, e.g. for "plavati"[1]. In my Wiktionary editing practice, I am ignoring the -ti forms altogether. --Dan Polansky (talk) 13:21, 4 February 2017 (UTC)

Russian-Rusyn offline dictionary (PDF)Edit

@Wikitiki89, Benwing2, CodeCat I've got a copy of Russian-Rusyn dictionary by Igor Kercha (Игорь Керча)- 65,000 terms as two scanned PDF files, over 30 MB altogether. It seems good but I'd check translations with other sources occasionally. It's cumbersome to use (the files are not searchable) but I can share it. Please suggest how to send it to you if interested. --Anatoli T. (обсудить/вклад) 11:39, 1 February 2017 (UTC)

empty declension sections (?)Edit

Hi, some terms show an interrogation mark in sections of their declensions, e.g. https://en.wiktionary.org/wiki/أغلب#declension. I'd like to know what it exactly means and how it could be filled. Thnks in advance. --Backinstadiums (talk) 19:33, 1 February 2017 (UTC)

Most elatives aren't declined any more. The ?'s indicate that the forms probably aren't attested. Benwing2 (talk) 03:46, 2 February 2017 (UTC)
@Benwing2 Not even in the whole arabic wikipedia? There're some probabilistic approaches which offer really good results using such corpora, but as no possible copyright issues may arise regarding the existence of lexicographic terms, so any good dictionary, as for example the oxford arabic, or lexicon could offer so. Furthermore, OCR'd resources might be used as well. --Backinstadiums (talk) 19:08, 4 February 2017 (UTC)
@Backinstadiums I looked through several dictionaries to find elative forms. Benwing2 (talk) 19:23, 4 February 2017 (UTC)

Suggestions without reply in entry discussion sectionsEdit

Hi everybody, I've been adding some remarks and suggestions on different 'discussion' tabs of some entries. I'd very much appreciate it if someone could check them out and discuss on them. Thank you so much in advance. --Backinstadiums (talk) 08:38, 3 February 2017 (UTC)

Seventh LexiSession: feverEdit

Monthly suggested trend topic is fever. You are invited to participate in the common goal to discover what can be gathered around the word fever! It may be description of subtype of fever, creation of a Wikisaurus, add of sounds or pictures.

This is a collaborative experiment without any guide nor direction. You're free to participate as you like and to suggest next months topic. If you do something, please report it here, to let people know you are involve in a way or another. I hope there will be some people interested by this one   Noé (talk) 10:50, 3 February 2017 (UTC)

Standardizing homophone qualifiersEdit

I've noticed we don't really have a standard for designating in which accents a word is a homophone. What I see most commonly is after the IPA, assumed to be for all accents (unless indented under one) unless there is a qualifier template with "in some accents". There must be a way to do these consistently though, such as directly in the homophones template ("ex1|ex2|q1=some|q2=caught-cot" or similar?). As it stands, if there are 3 homophones and the last 2 are "in some accents", there is no clear solution. It's also tricky with automated translations, such as in ca-IPA where Central Catalan has many, many homophones compared to Valencian, and I think it is worthwhile to specify where two words are homophones, and it is clearest under the line in question instead of after them all. Ultimateria (talk) 22:18, 4 February 2017 (UTC)


This contributor has been warned about, and blocked for, questionable entries several times. First they were creating entries of protologisms, and finally unblocked when they agreed not to do that any more. Since July, they've been mass-creating entries from lists, all with exactly the same content even when it doesn't make sense. In September, it was country-name prefixes, all with exactly the same etymology except for the source country-name and the entry name- an etymology that was correct for only a handful of the entries. Today they created entries for about 154 given names (there may be a few in there without the English section), each with an English and a Serbo-Croatian section, without any evidence that most of these Serbo-Croatian names have ever used in English. Many of them, such as "Ognjemir", would be unpronounceable to the vast majority of English speakers. They also created 48 Latin proper-noun entries based on Serbo-Croatian names. After seeing how much work it took to clean up their September run, I simply mass-deleted the the whole batch from today (and also reverted an edit where they changed the declension of a Latin noun ending in -a from first to second declension).

At the same time I blocked them for two weeks. Given that they continued to create bogus entries using both their own account and IPs long after being warned and blocked (they blanked their talk page, so most of the warnings aren't visible), and that they were blocked and warned again in September for mass-creating entries, but came back and did it again, I would like to extend that block much longer, to make it indefinite- but I would prefer to have the consensus of the community before doing so.

They've been wasting a lot of other people's time and effort with their actions over the past couple of years. The specific types of bad edits have changed, but the pattern of reckless disregard for accuracy has been quite consistent. Even if they stop their current practices, I see no reason to expect that they won't come up with something equally irresponsible later on.

What does everyone else think? Chuck Entz (talk) 03:51, 5 February 2017 (UTC)

When someone consistently adds bad stuff I think it becomes reasonable to demand a discussion and block them if they refuse to engage/reply. So far it looks as though all he has ever done with his talk page is to blank it. Equinox 08:58, 5 February 2017 (UTC)
Don't think I'm vandalizing again. I blanked my talk page because I have right to do so. I clean every WhatsApp message when I read it, I did the same with my talk page. I didn't realize that my mass creation could be a problem, because there are thousands of entries much worse than mine (and I think mine are good).
Today they created entries for about 154 given names (there may be a few in there without the English section), each with an English and a Serbo-Croatian section, without any evidence that most of these Serbo-Croatian names have ever used in English. Many of them, such as "Ognjemir", would be unpronounceable to the vast majority of English speakers.
This is the proof that the name is used in English. English is a universal language, thus every Serbo-Croatian name without diacritics is also English name and it belongs to English language. That's why I love English. You cant just delete all my entries without asking what I'm doing. If you told me, I would make everything right. And without people like me, on Wiktionary would be no more than a hundred entries. And there are much more unpronounceable words than "Ognjemir" like Hradec Králové, hryvnia, hsianghualite, ZWNBSP, Þrymskviða, Łukasiewiczian, ǂKxʼauǁʼein, Świętochłowice, Ṛgvedic... is that pronouncable to vast majority of English speakers???
The problem is with Latin entries. Please recreate those entries because they have nothing to do with Serbo-Croatian names in English, they are completely fine and correct:
I think he is now Bjelun (talkcontribs). SemperBlotto (talk) 15:20, 7 February 2017 (UTC)
You don't think correct. --Bjelun (talk) 15:22, 7 February 2017 (UTC)

Reconstructed Latin terms are not linkedEdit

Hi, the etymology of meddle states "from Late Latin misculare", yet misculare is in red, without specifying it's a reconstructed term despite there being an entry for it. I think I have seen reconstructed terms indicate so with an asterisk. Thanks in advance. --Backinstadiums (talk) 19:35, 5 February 2017 (UTC)

Mhm, so you add the asterisk when you see something like this. I've fixed it now. — Kleio (t · c) 19:44, 5 February 2017 (UTC)
@Backinstadiums: Okay, I'm going to give you some basic information on linking. You can fix this stuff yourself. The way to link to the Reconstruction namespace is to place an asterisk before the term in the linking template (or etymology template in this case): thus, {{m|la|*misculo}} or {{der|en|VL.|*misculō}}. The asterisk and language code tell Module:links to add the text Reconstruction:Latin/ to the wikilink. Also, you can link to entries using [[meddle]] or [[Reconstruction:Latin/misculare|*misculare]] (or with the linking template {{m}}) rather than copying out the whole URL. — Eru·tuon 06:05, 6 February 2017 (UTC)
Also, etymologies in English-language dictionaries tend to use the infinitive, but we use the first-person present indicative for our lemmas, so it's a good idea to change to that form when you see it in our etymologies. Otherwise users click on the link, only to get a "form of" entry referring them to the lemma. Chuck Entz (talk) 13:14, 6 February 2017 (UTC)

Glyph origin voteEdit

I created Wiktionary:Votes/2017-02/Glyph origin.

It was based on the discussion Wiktionary:Beer parlour/2017/January#About "Glyph origin". --Daniel Carrero (talk) 18:47, 6 February 2017 (UTC)

@Daniel Carrero Thank you so much. I do support it. --Backinstadiums (talk) 14:11, 7 February 2017 (UTC)

"only present in non-English entries"Edit

WT:EL#Headings after the definitions contains this line:

  • Inflection, or Conjugation for verbs, or Declension for nouns and adjectives, or Mutation, only present in non-English entries

I'd like to remove the part "only present in non-English entries", and I guess we don't a need a vote for that.

Rationale for the edit: the entry be#English has a conjugation section, and I believe that's OK. --Daniel Carrero (talk) 14:24, 7 February 2017 (UTC)

Mutation is entirely separate from Inflection, both co-occur in entries. So it should be changed so that Mutation doesn't appear to be a variation on Inflection. —CodeCat 14:27, 7 February 2017 (UTC)
Maybe we can just list them like this:
  • Inflection
  • Declension
  • Conjugation
  • Mutation
This would be consistent with Synonyms, Antonyms, Hyponyms, etc. that are all in separate lines. --Daniel Carrero (talk) 14:49, 7 February 2017 (UTC)
But Inflection, Declension and Conjugation are mutually exclusive, whereas Synonyms and Antonyms are not. —CodeCat 16:17, 7 February 2017 (UTC)
OK. Then it probably should be:
  • Inflection, Declension or Conjugation
  • Mutation
--Daniel Carrero (talk) 16:19, 7 February 2017 (UTC)
  Done --Daniel Carrero (talk) 21:50, 16 February 2017 (UTC)

Vulgar Latin hypothetical verb forms and Ibero-RomanceEdit

I was wondering if there should be a distinction noted for the descendants of Vulgar Latin verbs in Ibero-Romance (not including Catalan). Specifically, these languages merge the Latin second and third conjugation types (though the infinitives derive from the second type, with the long e in -ēre). For example, coser, saber, vender, torcer, etc. I understand there's no need to make a distinction for a main Latin entry (of an existing word), but if we're making the Vulgar Latin entries more detailed for those who wish to study or learn about it more, including differentiating various types of conjugation for the types of Romance, should there be a distinction made for these languages (for example in *cōsō or *torcō)? Or should it just be assumed that Portuguese, Spanish, Asturian, Galician, etc. always have the stress on the final syllable of infinitives, even if the Vulgar Latin form they're listed under has stress on a different vowel (which would apply for the rest of Romance). Does anyone know if this was a later phenomenon in that region or if they presumably used a separate form of Vulgar Latin in this regard? Since the first records of these languages comes much later, it's hard to come to a conclusion on this. In other words, would Spanish coser have come from a *cosēre, as a variant or later evolution of *cōsere, or simply just changed the stress for all its verbal infinitives later, analogically? Word dewd544 (talk) 22:39, 7 February 2017 (UTC)

Petitioning to change Turkic Khalaj to KhalajEdit

Anyone who's heard of Khalaj knows Khalaj is a Turkic language, Iranic Khalaj appears to be a ghost language and it would be a good idea to stop perpetuating confusion about this. Crom daba (talk) 02:23, 8 February 2017 (UTC)

@Crom daba: I support the change. My materials always call this language simply "Khalaj". --Vahag (talk) 08:57, 12 February 2017 (UTC)

finding an unknown wordEdit

I would like to be able to find all possible words with particular first and last letters by typing in at least the first letter of a word, and a certain number asterisks (or ?), representing subsequent letters and then the last known letter. Is this something I can do in Wiktionary? Or perhaps someone knows another site that can help me do this. Clduncan (talk) 16:57, 8 February 2017 (UTC)

This would be extremely helpful, but I'm pretty sure you can't do it on Wiktionary. Andrew Sheedy (talk) 17:24, 8 February 2017 (UTC)
Try the simple way using '*' for a wildcard. You may want to restrict yourself to English lemmas using 'incategory:"English_lemmas"'. It works for me. DCDuring TALK 18:39, 8 February 2017 (UTC)
Well, look at that. I could have sworn I'd tried it before without success. Andrew Sheedy (talk) 18:45, 8 February 2017 (UTC)
I hadn't realized it until I went to the Mediawiki documentation (CirrusSearch) today. I thought it would take some regex search, which I didn't know how to limit to entry titles. DCDuring TALK 19:54, 8 February 2017 (UTC)


Since the Saxons didn't name themselves after the seax, where does the word *sahsô come from? ÞunoresWrǣþþe (talk) 19:42, 8 February 2017 (UTC)

Display order of Template:cite-bookEdit

Right now, it displays the author(s), then the year, then the entry, then the title of the book. This doesn't really make sense to me. A more sensible order would be to have the entry first, then the title, then author(s), then year. Can this be changed? —CodeCat 19:02, 9 February 2017 (UTC)

IMO, the year needs to come first. This helps with ordering the citations in chronological order. --Daniel Carrero (talk) 19:05, 9 February 2017 (UTC)
Yes, and Wiktionary:Quotations#How to format quotations calls for putting the year first. —Aɴɢʀ (talk) 10:37, 10 February 2017 (UTC)
These are citations though, not quotations. —CodeCat 13:32, 10 February 2017 (UTC)
Aren't citations just quotations found in the "Citations:" namespace? Is there any reason to format them differently at all? (except you add a "#" when the quotation is directly below a sense in an entry) --Daniel Carrero (talk) 14:07, 10 February 2017 (UTC)
See the documentation of {{cite-book}}. —CodeCat 14:39, 10 February 2017 (UTC)
Can this be implemented please? {{R:WNT}} contains a link to a web page with the entry, but this link is hidden in the middle of the text rather than being placed first. —CodeCat 15:33, 8 March 2017 (UTC)
I understand how sorting by date is important for quotations, as you want to know when a word first came into use, but for references, I think the author is much more important than the date. I think that's also the reasoning behind it being the standard in published works. I'm opposed to switching them around. --Victar (talk) 05:23, 27 March 2017 (UTC)


Huh? Why is this not in IPA? —CodeCat 14:01, 10 February 2017 (UTC)

-త- Wyang (talk) 10:50, 13 February 2017 (UTC)
So can it be moved please? —CodeCat 17:09, 13 February 2017 (UTC)
Sorry I don't know Telugu. This only looks like a concerned face to me. You may wish to tag the creator Dr. Rajasekhar for his opinion. Wyang (talk) 09:41, 14 February 2017 (UTC)

Actualités: Monthly news of French Wiktionary in EnglishEdit

Hi all, Here comes the 22th issue of Actualités, the periodical news about Wiktionary, translated in English specially for you! Well, it's January edition with a small delay (only 11 days!).

This is a huge issue. Massive. You're gonna love it. It's wiktionarilly tremendous. There is three amazing articles: a focus on thesauri in French Wiktionary, a description of a published dictionary of insults (more than 9.300 insults in French!) and an article about the names for the snow in Inuit. Plus: a Wiktionarian coded a small game based on Wiktionary database and it was improved collaboratively. As usual, we also mention some briefs and provide metrics.

This time, it was quite hard to translate, so I am sorry but it is barely better than a draft and you may have to guess the meaning for some part, or to help to finalized the translation if you can. It is still made without any funding for anyone, craft by Wiktionarian hands. I hope it will be inspiring for those who will read it and I'll be delight to answer to any questions or to listen to comments on our work! Cheers, Noé (talk) 20:16, 11 February 2017 (UTC)

I wish I had time to help with the translations this time, but I haven't even found time to read it yet! Andrew Sheedy (talk) 03:54, 12 February 2017 (UTC)

Hunnic LemmasEdit

There were previously no Hunnic Lemmas on the site. I've added 18 of them, with 2 of those being reconstructions. ÞunoresWrǣþþe (talk) 12:47, 12 February 2017 (UTC)

They should all be reconstructions IMO since we don't have any primary sources. Not to mention that Pritsak's etymologies are speculative and that alternative theories exist. Crom daba (talk) 14:12, 12 February 2017 (UTC)
The Greek forms count as attested ones. ÞunoresWrǣþþe (talk) 15:58, 12 February 2017 (UTC)
We usually count those as belonging to the language they're attested in, compare Alanic *Asparuk. Crom daba (talk) 16:34, 12 February 2017 (UTC)
This is different. ÞunoresWrǣþþe (talk) 16:40, 12 February 2017 (UTC)
Yeah, to my eye, these should all be reconstructed, as there is not direct attestation of the words in the Hunnic language. We have sometimes been inconsistent (Gaulish names in Latin are sometimes put in Gaulish), but in the absence of a proper written Hunnic corpus, all lemmata should be reconstructed, especially those words that are not directly attested (bárs, munǯuq, qará, etc.). —JohnC5 18:01, 12 February 2017 (UTC)
@ÞunoresWrǣþþe: You moved all of those words to Reconstruction, but they need to be in Reconstruction:Hunnic/. Currently, they are not legal entries. —JohnC5 19:10, 13 February 2017 (UTC)
Would like to note that quite a few scholars (e.g. D.H. Green) still consider Attila to likely be a Gothic name (or a Gothicized version of a Hunnic name), his Hunnic name may very well have been different. — Kleio (t · c) 17:31, 12 February 2017 (UTC)
Those historians are a minority. ÞunoresWrǣþþe (talk) 18:52, 12 February 2017 (UTC)
What makes you say so? — Kleio (t · c) 19:31, 12 February 2017 (UTC)
Because it's a fact. ÞunoresWrǣþþe (talk) 21:08, 12 February 2017 (UTC)
Then back it up. Korn [kʰũːɘ̃n] (talk) 21:32, 12 February 2017 (UTC)
No thanks. I'm done wasting my time in pointless arguments. ÞunoresWrǣþþe (talk) 14:51, 13 February 2017 (UTC)
Love how you live in some pathetic little bubble where basic facts have to be sourced. There's no "source" to the fact a minority of historians believe it's Gothic and a majority believe it's Turkic-Altaic. Want a list of every publication that's ever leaned in favour of one or the other? Good luck. It's impossible. And since you with your superior opinion are clearly correct... Please, source the opposite claim: that there are enough historians that believe Attila is a Gothic name to even warrant the inclusion of that fringe theory in a dictionary? By all means, try, but I expect you only "contributed" to this discussion to be contrarian. Oh, don't forget to source every word in your response, otherwise we can't be sure you're speaking English or that your words mean what they do. ÞunoresWrǣþþe (talk) 15:04, 13 February 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Sorry to break it to you but some of the sources you have provided do not meet Wiktionary's standards (e.g. Reconstruction:Hunnic/strava, Reconstruction:Hunnic/medos). In addition to this, you haven't followed appropriate naming regulations either (e.g. Reconstruction:Ōybárs, Reconstruction:ōy, Reconstruction:čérkün, Reconstruction:tōn). I believe that the concerns raised by other users are well-founded – the subject at hand is not well documented and therefore prone to scrutiny, and rightfully so. I also advise you not to refer to words in languages you don't master as you did here. And last but not least, will you do us the courtesy of abstaining from personal attacks, they won't do you any favours around here. --Robbie SWE (talk) 20:43, 13 February 2017 (UTC)

@ÞunoresWrǣþþe: Also, where do the guidelines for orthography in Wiktionary:About Hunnic come from? Why are some of the vowels starred (, *oː, *aː) and others are not, especially when they are all reconstructed? Also, why is there a mix of IPA representations (*oː) and orthographic ones ()? —JohnC5 22:18, 13 February 2017 (UTC)
In that case, Robbie, never edit a Hunnic page again. You don't master the language. You clearly have some racial bias here, I can see from your user page you're Romanian. You're the last person I'd trust on this, given your source contradicts you, and was posted in a foreign language with no translation to confuse or mislead people. ÞunoresWrǣþþe (talk) 23:18, 13 February 2017 (UTC)
Cucura > Koúkouron > Cucură or Cucura > Cucură. I must say it's very "hard" to decide. Reminds me of my fringe theory where the word boat doesn't come from Old English bāt, but instead bāt > qóng > boat, came to English through Mandarin. ÞunoresWrǣþþe (talk) 00:12, 14 February 2017 (UTC)
Wow, do we have another Uther on our hands? —CodeCat 23:51, 13 February 2017 (UTC)
@CodeCat: Interesting question, let's look at the evidence. This user created the page Wiktionary:About Hunnic by copying WT:ACEL-BRY and still doesn't understand how the {{shortcut}} template works. The user has edited primarily Celtic and Anglo-Saxon pages. The user does not understand how namespaces work. The user has taken on a language for which (s)he clearly lacks a comprehensive or consistent understanding of the literature. The user has a name associated with the British Isles' mythology (Old English for Thunder's Wrath). And the user is quite rude, resorting to incomprehensible personal assaults when challenged for evidence. All in all, I'd give this one a strong 8/10 on the “Uther-o-meter”™. —JohnC5 00:14, 14 February 2017 (UTC)
I am not that person, though you may of course believe what you want. I will say, however, that you are a 10/10 on the failed abortion-o-meter. A grade-A cunt, not those made in China cunts but a bon and bred American cunt. ÞunoresWrǣþþe (talk) 00:30, 14 February 2017 (UTC)
And pssst, Thor's Wrath, you bescittende cunte, and fukkende horninsunu. Chupama y chingate, cago en la leche de th madre. ÞunoresWrǣþþe (talk) 00:32, 14 February 2017 (UTC)
Oh sorry, that is my bad as it is completely ambiguous. I'm gonna' upgrade you to a 9/10 on the Uther-o-meter. Does this mean we block now? @Chuck Entz? —JohnC5 01:23, 14 February 2017 (UTC)
After that, I support a block. —CodeCat 01:33, 14 February 2017 (UTC)
I don't know what the official policy for declaring someone a sockpuppet. Do I need a CheckUser (@TheDaveRoss)? Or can we just block Uther? Regardless, I'll block the account for a few days for offensive behavior. Anyone wanna' nuke some Hunnic entries? —JohnC5 01:50, 14 February 2017 (UTC)
I think what has happened so far is bad enough, without them being confirmed as a sockpuppet. So block away I say. —CodeCat 01:51, 14 February 2017 (UTC)
I always have trouble judging these things. I gave them a week block. If someone wants to upgrade that, feel free. —JohnC5 01:54, 14 February 2017 (UTC)
  • @JohnC5, CodeCat: I have upgraded the block; regardless of whether or not he is Uther, this is grossly inappropriate. I do think that a CU investigation would be handy all the same. The real question, which I am linguistically ignorant of, is whether we should nuke all these Hunnic lemmas, reconstructed and otherwise. —Μετάknowledgediscuss/deeds 03:21, 14 February 2017 (UTC)
    • @Metaknowledge: Thanks for the upgrade. As to the Hunnic lemmata, I possess not the knowledge to evaluate whether the entries are salvageable nor know-how to fix them if they be so. Regardless, they cannot stay as they are. —JohnC5 03:30, 14 February 2017 (UTC)
      • I've moved Reconstruction:Hunnic/adám to an acceptable name and tidied it up in accordance with the one cited source. I have neither the time nor the inclination to do the same for all the remaining Hunnic entries, but this one at least has a scholarly background. —Aɴɢʀ (talk) 09:05, 14 February 2017 (UTC)

Wow, nothing like a good ol' cup of bigotry in the morning. Not trying to defend myself here since I don't believe that anyone buys what you're selling, I just want to point out that I did not do any substantial changes to Hunnic reconstructions because I'm admittedly not well versed in reconstructed languages. However, unlike you, I speak Romanian and I know Romanian history and orthographic norms, so I'm not going to abstain from correcting obvious and elementary errors. I'm somewhat taken aback by your claim that I'm racially biased – it says much more about you than it does about me. Not that it matters since you don't know me, you apparently have no respect for anyone else around here and you do remind me an awful lot of Uther who was impossible to discuss with, but for the record I'm a Swede. Mind you, it doesn't make me more or less objective but it exposes once again your flawed logic and antagonistic behaviour. I would've blocked you indefinitely if it were up to me, but thankfully it's not. I have respect for my peers, hence I trust their judgements regarding the duration of you block and your future participation in this project. --Robbie SWE (talk) 10:34, 14 February 2017 (UTC)

We should probably delete all his Hunnic reconstructions, if only because they do not list descendants. --Vahag (talk) 07:20, 17 February 2017 (UTC)

@Vahagn Petrosyan: Would you do the honors? —JohnC5 07:27, 17 February 2017 (UTC)
  Done. All that was salvageable has been moved to Reconstruction:Proto-Mongolic/köküür --Vahag (talk) 09:52, 17 February 2017 (UTC)

De-Recognition of Wikimedia Hong KongEdit

This is an update from the Wikimedia Affiliations Committee. Translations are available.

Recognition as a Wikimedia movement affiliate — a chapter, thematic organization, or user group — is a privilege that allows an independent group to officially use the Wikimedia trademarks to further the Wikimedia mission.

The principal Wikimedia movement affiliate in the Hong Kong region is Wikimedia Hong Kong, a Wikimedia chapter recognized in 2008. As a result of Wikimedia Hong Kong’s long-standing non-compliance with reporting requirements, the Wikimedia Foundation and the Affiliations Committee have determined that Wikimedia Hong Kong’s status as a Wikimedia chapter will not be renewed after February 1, 2017.

If you have questions about what this means for the community members in your region or language areas, we have put together a basic FAQ. We also invite you to visit the main Wikimedia movement affiliates page for more information on currently active movement affiliates and more information on the Wikimedia movement affiliates system.

Posted by MediaWiki message delivery on behalf of the Affiliations Committee, 16:25, 13 February 2017 (UTC) • Please help translate to your languageGet help

I think this is a big mistake. ÞunoresWrǣþþe (talk) 18:06, 13 February 2017 (UTC)
@ÞunoresWrǣþþe: Have you tried contacting anyone at WM-HK? —Justin (koavf)TCM 19:57, 13 February 2017 (UTC)

Proposal: Implementing Wikidata accessEdit

I suggest implementing Wikidata access on Wiktionary. I believe this requires a vote and then if it passes we'll have to fill a request on Phabricator.

Apparently we can't access Wikidata using wikitext like {{#property:P569}} or Module:wikidata right now.

I'd like to use Wikidata to contain all character information (including character names and image links) that is currently on subpages of Module:Unicode data, for use by other Wiktionaries as discussed here: Wiktionary:Grease pit/2017/February#Porting and debugging of module.

There are probably other things we can do with Wikidata.

I wonder if we need all the 19 extensions from the groups "Wikibase" and "DataValues" that Wikipedia is currently using. Some of these extensions seem optional like a geographical parser and a JavaScript API, but seem nice anyway.

See these pages for the lists of extensions:

--Daniel Carrero (talk) 18:59, 13 February 2017 (UTC)

  •   Support I absolutely believe that we need to integrate with Wikidata and the rest of the WMF projects. How that will look exactly and the extent to which Wiktionary will become more like an OmegaWiki project that is primarily a database are important discussions to have but there's no doubt that there are substantial advantages to opening up to Wikidata. —Justin (koavf)TCM 20:00, 13 February 2017 (UTC)
  •   Support Strongly support. If we want to raise the quality of all language Wiktionaries we need ways to cooperate, instead of duplicate loads of data on every site. –dMoberg 21:42, 13 February 2017 (UTC)
  •   Support Absolutely. - TheDaveRoss 21:58, 13 February 2017 (UTC)
  •   Support (naturally) and also comment: If we are going to use Wikidata to contain any information in all languages (for example: the periodic table in all languages or something), then I'd also suggest eventually changing all our exceptional language/family/dialect codes to be ISO-compliant. (which can be discussed and/or done later, it does not have to be right now) Reason: it appears that any information we put there will be accessible by other people rather than only by Wiktionary, so it might make sense to use a universal standard. For example, maybe it would be nice to change our "gem-pro" to "gem-x-pro", because I believe that the former basically means "Germanic-Provençal" instead of "Proto-Germanic". (here's a previous discussion about this: Wiktionary:Beer parlour/2013/February#Changing "exceptional" language codes to comply with the HTML specification) --Daniel Carrero (talk) 06:06, 15 February 2017 (UTC)
    Basically, this is a proposal that would involve more typing for zero benefit. It would be one thing if the ISO assigned a meaningful code for Proto-Germanic (they won't), but if we are to make our own codes, they should be consistent with the ISO codes and not too much trouble — and both of those things are currently true. —Μετάknowledgediscuss/deeds 07:11, 15 February 2017 (UTC)
    @Metaknowledge: Re "they should be consistent with the ISO codes": I think I know what you mean, because our codes don't conflict with actual ISO codes. Still, we are not using strictly ISO-compliant codes. Probably the use of made-up language codes is an issue to be discussed at Wikidata too. We might want to ask them: "Are you cool with keeping some information using langcodes that Wiktionary made up like gem-pro meaning Proto-Germanic and roa-opt meaning Old Portuguese?" I guess they have a right to want ISO-compliant codes but I didn't check that yet.
    If in the future we decide to change all our codes to be ISO-compliant for whatever reason, for "gem-pro", instead of "gem-x-pro" we might use "qge-pro" and keep within the established 7-character limit. (we may even shorten it somehow) Admittedly, it would take work to change all the codes. --Daniel Carrero (talk) 15:23, 15 February 2017 (UTC)

There is an ongoing project in Wikidata to include Wiktionary data and I invite you to participate with your proposal. In my opinion, it is mainly developed by people looking at benefices for Wikidata and not so much people looking for how it can be useful for Wiktionary. I tried to make them clarify some aspects of the development, but it is still quite hard for me to understand how it can not create a fork. Anyway, I am very happy to see your discussion about Wikidata   Noé (talk) 09:11, 15 February 2017 (UTC)

  •   Support - also volunteering to help with the integration. @Noé to clarify, this proposal is a bit different and complementary to the one you linked. We need a 2-way exchange of data, this proposal deals with the integration of already existing data (such as language codes) back into Wiktionary. – Jberkel (talk) 09:28, 15 February 2017 (UTC)
    I am still not sure to understand which data do you want to use from Wikidata. Module where mentioned, but it means to host them in Wikidata and I don't know if it is a good repository for that kind of file. I will mention this discussion in French Wiktionary to invoke more comment on your proposal, and see if we may not do a common ticket on Phabricator   Noé (talk) 09:48, 15 February 2017 (UTC)
    The obvious first modules to migrate are the ones which are faux databases already, those supporting language codes/names/families and those supporting categorization spring to mind. This is data which cannot currently be well supported (those modules are just a flat-file database which is extremely limiting). Beyond that, the sky is really the limit concerning what could be migrated, the limiting factor will probably be UI development more than anything. - TheDaveRoss 12:26, 15 February 2017 (UTC)
    I suppose you are talking about e.g. Module:languages/data2? The only thing I'm worried about is performances: those lists are basically loaded once per page, which allows a page full of translations to be rendered quite quickly. I'm not sure it will be as fast if we have to query the database for every language (unless we get all the languages at once with a single query). — Dakdada 14:11, 15 February 2017 (UTC)
    Also, those faux databases are the subject of much contention. Working out Serbian vs Serbo-Croatian and all the other headaches between different Wiktionaries would make the databases a lot more complex, unless you expect the individual Wiktionaries to choose to lose their autonomy. —Μετάknowledgediscuss/deeds 17:48, 15 February 2017 (UTC)
    About moving language codes/names/families to Wikidata... Would we use Wikidata to expand "pt" into "Portuguese", "ojp" into "Old Japanese", etc.? We might have a problem if someone wants to change language names in a way that we don't approve, like if someone decides that "ang" should be "Anglo-Saxon" instead of "Old English". Someone might decide that "en" looks better as "Modern English" rather than "English" for some purpose outside of Wiktionary, which could then affect Wiktionary.
    That said, Wikidata could have a complete list of languages, including the fact that "sr" means "Serbian", but we could have an internal module blocking the use of "Serbian" in some places like translation tables. --Daniel Carrero (talk) 09:46, 16 February 2017 (UTC)
    The reason this could be a problem is simple: the language information used on Wiktionaries are not data but metadata, and this metadata needs to be controlled by the respective Wiktionaries (as in controlled vocabulary). In other words, Wikidata is not the right tool for that, and it should be reserved for actual content. — Dakdada 09:55, 16 February 2017 (UTC)
    The majority of data could probably come directly from Wikidata. For the remaining edge cases (the mentioned custom language codes, Proto-Germanic, contentious denominations like Serbian etc) we should try to see if there's a way to get this data into Wikidata, if that's not possible we could have “overrides” on the Wiktionary side(s) which would take precedence. – Jberkel (talk) 10:46, 16 February 2017 (UTC)

Another comment: apparently Wikidata already contains information (author, publication date, etc.) about some books. The page wikidata:Q43361 is about Harry Potter and the Philosopher's Stone. Maybe we can use it for quotation purposes. We could type something like {{auto quote|Q43361}} and have all the information filled automatically when possible. (the template does not have to be called "auto quote", it was just an example). --Daniel Carrero (talk) 13:13, 16 February 2017 (UTC)

A new Labs Tool to visually explore etymological relationships extracted from the English WiktionaryEdit

Hi all! I have developed a tool to visualize etymologies. Please check it out at tools.wmflabs.org/etytree. My work is funded by an IEG grant. Please leave your feedback here. It will help improve it.

As a first release, it's is impressive how well automatic extraction of data works (with some bugs of course...). This is because Etymology Sections are written using well defined standars. I would like to get some feedback about some difficulties I have encountered while extracting data and some ideas I have about new templates. I wrote some notes here. Please add your comment there if you have any. Some additional notes follow:

  1. I could not use trees as in the nicer demo because there are loops between words that cannot be fit in trees (in trees branches don't merge). Loops are conflicting etymologies. Many are due to simple inconsistencies that users can easily fix, others are real conflicting etymologies and should be represented using multiple trees. I will work on this in a future release.
  2. Etymology Sections rarely link to words and their sense/pos, generally only link to the lemma. This is a problem for homographs, cause they generally have different etymological trees which get mixed up in this current implementation. See for example the discussion on the Etymology Scriptorium. It would be nice to have more precise links in etymology sections that link to the correct word.
  3. I am not plotting all derived words as of now to clean up a bit the visualization.

Looking forward to your comments! Epantaleo (talk) 18:22, 15 February 2017 (UTC)

The use of alsoEdit

It seems PapiDimmi and I disagree on how to use also. Please advise on this reversion: [2]. Relevant policy should be here: Wiktionary:Entry_layout#Before_the_first_language_section. Equinox 19:31, 15 February 2017 (UTC)

I wouldn't say "identical letters" but rather "similar letters" as for example oe, œ, ö and ø, are different letters but can have an {{also|}} like övrig an øvrig. However, after reading WT:EL#Before the first language section I wouldn't think that chauffeur and choffer belong on Chauffer. chaufer, chaffer, caûffer and maybe many more entries are also "similar" to Chauffer. And then there's the matter of interpreting "similar". Similar in spelling, in pronunciation? As wiktionary covers many languages, fish and Fisch would be similar too, both by spelling and pronunciation. And wouldn't fis, visch, ish, gish, tish and wish be similar to fish too? With all those "similar" entries the also would become too long and the "similar" would be too vague, too open for interpretation. -Slœtel (talk) 10:32, 16 February 2017 (UTC)
I think you were right in removing those links. {{also}} is for typographical similarity. For language-dependent similarity, there is the See also section of entries. — Ungoliant (falai) 11:44, 16 February 2017 (UTC)
That template is supposed to show words that are identical except for capitalization; also for words that are identical except for diacritics. Originally there were two reasons why {{also}} was needed. First, if you typed, for example, mike, and then later typed Mike, you would go to mike and would not be able to access Mike. I think this problem has since been fixed. Second, since most people with an English keyboard have trouble typing diacritics, we also put forms with diacritics (cafe, café). {{also}} is definitely not for variant spellings, synonyms, translations, or the like. However, in the case of other alphabets and scripts, it might be useful to include words spelled with a letter that many English-speakers confuse with another letter (B, ß). —Stephen (Talk) 12:14, 16 February 2017 (UTC)
I agree with Equinox, Ungoliant, and Stephen that {{also}} is for word that differ only in capitalization (mike/Mike), diacritics (sake/saké), punctuation (wont/won't), spacing (everyday/every day), and the like. I'm undecided on visually similar characters from different scripts, though (e.g. to/το; hug/հաց). —Aɴɢʀ (talk) 12:39, 16 February 2017 (UTC)
Agreed with all the above. Another instance in which {{also}} might be useful is for confusion between the long s and lowercase f (e.g. filly could have a link to silly, if the latter is attested as ſilly). Andrew Sheedy (talk) 12:44, 16 February 2017 (UTC)
In these cases it might be useful to actually use the long s in the template, so readers can recognize it. Andrew Sheedy (talk) 12:46, 16 February 2017 (UTC)
I have long thought that the basic use of {{also}} above the first L2 was most useful to help someone get to an entry with different diacritics or capitalization in a different language. That is the reason for its placement above the first L2. IOW, having terms that are merely alternative forms in the same language would be not just redundant but wrong IMO. Whether this would be something worth the effort of correction is a separate matter. DCDuring TALK 13:56, 16 February 2017 (UTC)

Review of initial updates on Wikimedia movement strategy processEdit

Note: Apologies for cross-posting and sending in English. Message is available for translation on Meta-Wiki.

The Wikimedia movement is beginning a movement-wide strategy discussion, a process which will run throughout 2017. For 15 years, Wikimedians have worked together to build the largest free knowledge resource in human history. During this time, we've grown from a small group of editors to a diverse network of editors, developers, affiliates, readers, donors, and partners. Today, we are more than a group of websites. We are a movement rooted in values and a powerful vision: all knowledge for all people. As a movement, we have an opportunity to decide where we go from here.

This movement strategy discussion will focus on the future of our movement: where we want to go together, and what we want to achieve. We hope to design an inclusive process that makes space for everyone: editors, community leaders, affiliates, developers, readers, donors, technology platforms, institutional partners, and people we have yet to reach. There will be multiple ways to participate including on-wiki, in private spaces, and in-person meetings. You are warmly invited to join and make your voice heard.

The immediate goal is to have a strategic direction by Wikimania 2017 to help frame a discussion on how we work together toward that strategic direction.

Regular updates are being sent to the Wikimedia-l mailing list, and posted on Meta-Wiki. Beginning with this message, monthly reviews of these updates will be sent to this page as well. Sign up to receive future announcements and monthly highlights of strategy updates on your user talk page.

Here is a review of the updates that have been sent so far:

More information about the movement strategy is available on the Meta-Wiki 2017 Wikimedia movement strategy portal.

Posted by MediaWiki message delivery on behalf of the Wikimedia Foundation, 20:30, 15 February 2017 (UTC) • Please help translate to your languageGet help

Titles of pronunciation modulesEdit

I recently created the Czech pronunciation module Module:cs-pronunciation. @CodeCat said on the talk page that it should be moved to Module:cs-IPA, and I asked why, because -IPA is currently not the most commonly used form for the module names in Category:Pronunciation modules. (23 modules use -pron, 11 use -IPA, 6 use -pronunciation, and 4 use -pronunc.) @Atitarev said that it was decided in a discussion that -IPA should be used, but did not link to the discussion. I couldn't find the discussion by searching. Does anyone know where that discussion was? — Eru·tuon 20:21, 17 February 2017 (UTC)

FWIW, I would prefer them all under -IPA as well. —JohnC5 20:30, 17 February 2017 (UTC)
Aside from what name all modules should have, if the template's name is {{cs-IPA}}, it only makes sense to use the same name for the module. —CodeCat 20:32, 17 February 2017 (UTC)
I don't remember where the discussion was but I also don't see why the module can't be renamed. --Anatoli T. (обсудить/вклад) 22:48, 17 February 2017 (UTC)
Not all pronunciation modules are pure IPA modules. Wyang (talk) 02:32, 18 February 2017 (UTC)
I think they should be standardized under '-pron' because that's the most common case currently, it's easier to type, and for Wyang's reason. Benwing2 (talk) 02:34, 18 February 2017 (UTC)
@Wyang: Which pronunciation modules are not pure IPA? I have not encountered that yet. — Eru·tuon 20:09, 18 February 2017 (UTC)
@Erutuon: Module:my-pron, for example, also generates a phonetic respelling and romanizations in addition to IPA. —Aɴɢʀ (talk) 20:26, 18 February 2017 (UTC)

I guess I personally prefer -pronunciation, because it does not require editors to know what IPA stands for, and because pron is an ambiguous abbreviation that can mean either pronoun or pronunciation. — Eru·tuon 20:09, 18 February 2017 (UTC)

I recall a discussion in which it was decided that templates that automatically produce pronunciation info should be named "xx-IPA"; I don't think there was ever a discussion about what the corresponding modules should be called. Since ordinary editors very rarely have to type the names of modules (as they frequently do the names of templates), succinctness is less important for module names than for template names. I agree that "xx-pron" should be avoided as templates named "xx-pron" are usually headword-line templates for pronouns, and it would be confusing for "pron" to stand for something else in modules. Other than that, I don't really mind what the module is called as long as the template is called "xx-IPA" as expected, since the module name only has to be written once, namely in the template that invokes the module. —Aɴɢʀ (talk) 20:24, 18 February 2017 (UTC)

Tsonga DictionaryEdit

Via OTRS (OTRS ticket # 2016092010022731) someone has released a digitized Tsonga-English/English-Tsonga dictionary under CC-BY-SA. I currently have the Tsonga-English portion as a 438 page Word document, and I would like to figure out what the best thing to do with the information is. I am happy to do some work in terms of reformatting and uploading the content, however I do not speak Tsonga nor am I familiar with Bantu or any South-African languages. I gather that the language is a bit politically complicated as well. We have very little coverage of this language as it stands.

Are there any contributors who would feel comfortable helping to review the dictionary and help with getting the data ported into Wiktionary? One possible starting point is that I can reformat and upload all of the content to a collection of subpages, which could then be moved into the main namespace by contributors who feel comfortable verifying. I could also provide the Word document to interested people who could advise on the content and whether it is trustworthy enough to just upload in its entirety. - TheDaveRoss 21:00, 17 February 2017 (UTC)

How many words is it? What kind of information is present- definitions, pronunciations, inflections? DTLHS (talk) 21:01, 17 February 2017 (UTC)
I am not sure how many defined words or definitions there are exactly, there are 220,564 words in the document so I would guess that the number of defined terms is on the order of 20,000. (edit: there are 27,451 line breaks, so nearly that many terms.)
Here is a sample of the information provided:
  • abuxeni, (salutation) see avuxeni.
  • abvana 5, see bvana, maabvana.
  • accelerando 9, accelerando (music).
  • adajiyo 9, adagio (music).
  • adirese 9, (Eng.) address of a letter, postal address.
  • -adiresela, address a letter.
  • afirikati 9, (Eng.) affricate.
  • Afrika 1, the continent of Africa; -- -Dzonga, South Africa; -- wa Dzonga, Southern Africa.
  • agenda 9, (Eng.) agenda.
  • Agoste, (Eng.) August.
  • ahanti, ahati, interj. to express uncertainty, dubiousness, indecision, perhaps, weak refusal: May be! I don't know I am sure.
  • ahe, ahee, interj. as an answer to a greeting, also to express thanks, approval, assent; interj. to children and boys among themselves.
  • ahee, ahehe, interj. used as a warning against danger: mind, look out, beware; here you are, there it is.
  • -ahlama, be wide open; open one's mouth, gape.
  • -ahlamela, stay with open mouth. (Idiom) -- munhu, to pick a quarrel with a person.
  • -ahlamisa, cause mouth to open, make gape; hold open, as a sack. (Idiom) -- nomu, to gasp, to speak; -- tinhlaya, to feel drowsy.
  • -ahlamula, yawn, open the mouth.
  • -ahluka, detach, separate itself from.
  • -ahlukana, become divided, separated, as husband and wife by divorce.
  • -ahlukanya, detach, separate.
  • -ahlula, judge, adjudicate, try a case.
  • ajenda 9, (Eng.) agenda.
  • -aka, 1 build, construct, edify, elevate, erect, as a hut; -- tinghalava, shipbuild-ing. 2 dwell, inhabit. 3 be ingrained, e.g. mukhuva wu ta aka, the habit is ingrained. (Idiom) -- vuxaka, to foster friendship; -- mhaka, to prepare a court case; -- tiko, to develop a country; -- muti, to stay peacefully together, as husband and wife.
  • -akana, help each other to attain a high status; mould each other's character.
  • -akademiki, (Eng., adj.) academic.
The portion of the document that I have does not indicate what all of the annotation means, so there may be more information there (such as the 1s and 9s) than I can interpret. - TheDaveRoss 21:10, 17 February 2017 (UTC)
I'd guess the numbers are noun classes. Equinox 21:13, 17 February 2017 (UTC)
I'd recommend looking at Zulu and Swahili entries. Zulu and Swahili are the best developed Bantu languages on Wiktionary. In Zulu, verbs and adjectives are placed at the form without the hyphen but the headword is displayed with the hyphen, as are links. See bona for an example. As for the noun classes, comparing it to the list at w:Tsonga language, it appears that your list does not actually give forms that include the noun prefixes. Perhaps there are different allomorphs of the prefixes, so that for example class 9 nouns have no prefix if the noun begins with a-, but I don't know. I may look into it more. Feel free to ask me for any help as I'm already experienced in handling Zulu. —CodeCat 21:23, 17 February 2017 (UTC)
I've created a basic entry at aka, using {{ts-verb}} which I just created. You can use this as a basic template at least for the verb entries. We probably want a reference template for this dictionary, but I don't know what it's called, who made it or where it's located. —CodeCat 21:31, 17 February 2017 (UTC)
  • @TheDaveRoss: It will have to be done partially by hand, and that will require a lot of effort. Right now, the key is to make this publicly available by posting it on Wikisource. —Μετάknowledgediscuss/deeds 21:32, 17 February 2017 (UTC)
    I'll try and get it up on Wikisource once I have the remainder (especially since there may be more meta information available in the other part. - TheDaveRoss 21:50, 17 February 2017 (UTC)
    • @TheDaveRoss: For what it's worth, AWB would probably help in creating them as well. Ping me if you'd like me to assist. —Justin (koavf)TCM 03:06, 18 February 2017 (UTC)


Is rollback available to user who are non-administrators? Pkbwcgs (talk) 19:03, 18 February 2017 (UTC)

@Pkbwcgs: It is possible to create a rollbackers group but that doesn't exist here. If you want, w:WP:TWINKLE has a rollback feature. —Justin (koavf)TCM 19:13, 18 February 2017 (UTC)
@Koavf: I would like to use Twinkle but it is not available on Wiktionary. I tried to create the gadget on my own but it didn't work. See User:Pkbwcgs/Twinkle.js and User:Pkbwcgs/Twinkle warn.js. Pkbwcgs (talk) 19:17, 18 February 2017 (UTC)
@Pkbwcgs: Looks like we both learned something today (me twice!). At Special:ListGroupRights, you can see that we do in fact have a rollbacker group. —Justin (koavf)TCM 03:03, 19 February 2017 (UTC)
Not having ever had the ability to use all the sysop buttons, I've often wondered: what the difference is between using rollback and simply undoing an edit? Andrew Sheedy (talk) 03:13, 19 February 2017 (UTC)
Rollback is instantaneous. No opportunity to give an edit summary, just undo the edit as fast as possible. —suzukaze (tc) 03:14, 19 February 2017 (UTC)
Ah, OK, thanks. Andrew Sheedy (talk) 03:17, 19 February 2017 (UTC)
Rollback also marks the reverted edit as patrolled, so those of us who go through Recent changes with patrolled edits filtered out won't see them anymore. That's the main reason to be careful about who gets rollback: we lose the ability to correct mistaken reverts or to look for larger problems/patterns that the rollbacker might have missed in fixing the obvious immediate problem. Chuck Entz (talk) 04:43, 19 February 2017 (UTC)

Placement of synonymsEdit

In diff, synonyms were moved away from their Synonyms section, to definitions. I don't like this and it does not match our long-standing practice. Can someone please point me to a relevant discussion? User:CodeCat may like to comment. --Dan Polansky (talk) 19:31, 18 February 2017 (UTC)

I think putting synonyms and antonyms under their respective senses is a good idea, especially for words with lots of meanings, like head. Keeping them in separate Synonyms and Antonyms sections makes them harder to find, makes it harder to find which sense they belong to, and makes it easier for them to be assigned to senses that are not actually listed. Separate sections are fine for words that have only one or two meanings, but for words like head with a very large number of senses and subsenses and subsubsenses, I think the new arrangement is an improvement. —Aɴɢʀ (talk) 19:57, 18 February 2017 (UTC)
I have noticed these edits too. I think they are structurally an improvement, but they do suck up vertical space in a way that is awkward for somebody who just wants to read the list of definitions. I suppose I would like a way to hide *nyms until explicitly choosing to view them. Equinox 20:00, 18 February 2017 (UTC)
Especially in long entries, it is important to be able to skim definitions, which these changes make harder to do. Incidentally, the head entry is now a horrible mess of inept subsensing; there is e.g. "Mental or emotional aptitude or skill" as a subsense of "The part of the body of an animal or human which contains the brain, mouth and main sense organs". --Dan Polansky (talk) 20:02, 18 February 2017 (UTC)
I'm not fond of subsensing either, but that's an entirely separate issue that has nothing whatever to do with the placement of synonyms. —Aɴɢʀ (talk) 20:27, 18 February 2017 (UTC)
What happened to the idea that was proposed last time we discussed this, to put them in a collapsible form, identical in structure to quotations? I oppose placing them under definitions, unless they display in that format, in which case I fully support having them under definitions. Maybe we should put it to a vote so it gets more attention? Most people seemed to be in favour of putting them directly under definition lines, IIRC. Andrew Sheedy (talk) 03:16, 19 February 2017 (UTC)
FWIW Simple English Wiktionary has collapsible functionality: simple:language. —suzukaze (tc) 03:59, 19 February 2017 (UTC)
Interesting. That's exactly what I'd like to see here. Andrew Sheedy (talk) 04:01, 19 February 2017 (UTC)
I'm very fond of the format of the Simple English Wiktionary as well. Wyang (talk) 05:12, 19 February 2017 (UTC)

onelook.com problemsEdit

While onelook.com is a useful site, obvious errors never seem to be fixed, and the people operating it seem entirely unresponsive to any reports submitted through their "Contact us" page. There has for a long time been a glaring problem with Wiktionary links whereby most words incorrectly link to a capitalised form that usually does not exist. Does anyone have any inside track for contacting them about this? Or perhaps someone else will have more luck with their "Contact us" than I ever have. Mihia (talk) 21:49, 20 February 2017 (UTC)

I think the problem should be apparent from the lack of advertising. I haven't been able to get them to correct glaring problems like deadlinks to dictionaries (no just entries in dictionaries). We could produce our own equivalent I suppose. We might even be able to include some sources that they don't/can't. DCDuring TALK 00:45, 21 February 2017 (UTC)
I don't understand what you're saying about capitalised links. A lot of useless spam-scum sites either steal material from Wiktionary, or link to us, in an attempt to get credibility, hits, or whatever those sick fucks want. I think they are just best ignored. Equinox 00:46, 21 February 2017 (UTC)
I think calling onelook spam scum is unwarranted. DTLHS (talk) 01:56, 21 February 2017 (UTC)
Quite disgraceful. Mihia (talk) 03:06, 21 February 2017 (UTC)
I reached out to OneLook initially back in 2006 to suggest they include Wiktionary, and Connel and I worked on generating the list of English terms which they originally used to link back to Wiktionary. Those lists are long since defunct, and I am not sure what they are now using. I still have the email address of the creator of the site, and the guy who was maintaining it, I can try and reach out to them. A lot happens in 10 years, so they may not even be involved any longer. Re motives, at least at that point they were all about making data more open, so I wouldn't put them in the same class of folks as those who mirror content to try and generate ad revenue. - TheDaveRoss 13:49, 21 February 2017 (UTC)
I would expect that it would be better maintained if they did generate more ad revenue. I use the site often to see and show what the lemmings are doing, often adding it as an External link to our entry. DCDuring TALK 15:49, 21 February 2017 (UTC)
While OneLook indeed curiously links to Rubber from its rubber[3], it is generally a great service that I use when I want to compare the content of multiple dictionaries, which I do quite often. OneLook's Alexa rank[4] (~ 24,000) is worse than Wiktionary's[5] (626), so they don't really appear to steal readers from Wiktionary. I am glad the service exists. --Dan Polansky (talk) 11:28, 25 February 2017 (UTC)

Category:Antonomasias by languageEdit

I see we have Category:Genericized trademarks by language, which are basically a special case of antonomasia. Could we have the more general category, to treat cases like mentor and stentor, which come from Μέντωρ (Méntōr) and Στέντωρ (Sténtōr) respectively? --Barytonesis (talk) 08:39, 21 February 2017 (UTC)

That seems like a very unknown jargony term. I'd rather stick with something that people do understand. —CodeCat 14:23, 22 February 2017 (UTC)

New gameEdit

Hey. Anyone fancy another game of Wiktionary Scrabble? The last one was pretty epic, with a pretty table from Kenny. Granted, there was shambolic organisation, spelling, rulekeeping and general gamesmastership from WF. But it's been a while since we played a game, and Equinox is getting bored. I started a page at Wiktionary:Random Competition 2017. --Quadcont (talk) 18:45, 21 February 2017 (UTC)

I've been hoping for a game! Now I just need to figure out which language I can start learning that exploits these rules most effectively... —Μετάknowledgediscuss/deeds 00:54, 22 February 2017 (UTC)
I don't think there's been a game since I started editing here! Hopefully my weekend isn't too busy for me to play. (Oh good, this isn't scheduled to start till the end of the month) Andrew Sheedy (talk) 03:35, 22 February 2017 (UTC)
We start the game on Feb 24th, with the seven letters EWERSOA. --Quadcont (talk) 18:26, 22 February 2017 (UTC)
Does the first word have to go through the center square? DTLHS (talk) 18:31, 22 February 2017 (UTC)
Yes, it does. --Quadcont (talk) 18:43, 22 February 2017 (UTC)
  • I hope Scrabble doesn't sue us. --Quadcont (talk) 18:44, 22 February 2017 (UTC)
    I hope they do, because then they might merge Wiktionary with the Scrabble dictionary and it wouldn't be missing so many common words. - TheDaveRoss 19:07, 22 February 2017 (UTC)
  • We need more competitors! People who like this kind of thing: @Andrew Sheedy, DTLHS, Pingku, Wikitiki89, msh210, SemperBlotto, please join in! —Μετάknowledgediscuss/deeds 19:34, 25 February 2017 (UTC)
    • Already in (and thinking about next Christmas). SemperBlotto (talk) 20:00, 25 February 2017 (UTC)
      • ("sasowere" seems to be a Japanesy-type word (transliteration) but I can't quite get my head around it.) SemperBlotto (talk) 20:02, 25 February 2017 (UTC)
        You won't get anywhere with that, as /we/ is a disallowed syllable in modern Japanese. —Μετάknowledgediscuss/deeds 23:58, 25 February 2017 (UTC)
    I'll join in! I was away, so I couldn't join in till today. Andrew Sheedy (talk) 17:22, 26 February 2017 (UTC)

Another UtherPendrogn clone?Edit

Llacheu (talkcontribsglobal account infodeleted contribsnukeedit filter logpage movesblockblock logactive blocks). Can someone check? —CodeCat 19:25, 26 February 2017 (UTC)

THE ONLY VANDAL IS YOU! STOP! Llacheu (talk) 19:36, 26 February 2017 (UTC)

Thank you for the confirmation... :) As long as you act like Uther, you can't fool anyone. You only lasted as long as you did with the last sock because you managed to behave- up until you finally blew it. I pretty much knew it was you from the beginning, but decided to let you have a go at turning over a new leaf- which you almost did. I, for one, appreciate your trying. Chuck Entz (talk) 22:57, 26 February 2017 (UTC)
Late to the party, but confirmed. - TheDaveRoss 15:49, 27 February 2017 (UTC)

Syntax of Template:label/exampleEdit

@Erutuon You left a change message saying "odd syntax, but makes the code much shorter". I don't think making for shorter Lua code is necessarily a good reason for using an odd syntax. I'm not opposed to using en: to specify a language code instead of a separate parameter, because it may be easier to read, but having the examples separated by a semicolon instead of as separate params seems a bit dubious. In reality I don't think it would actually make the Lua code longer to iterate over separate arguments instead of splitting on semicolon. Benwing2 (talk) 19:57, 26 February 2017 (UTC)

@Benwing2: I used the odd syntax because I am not sure how else to make the template work when there are multiple examples in a row. How would the module determine where one example ends and another begins? It's not shorter Lua code; rather, shorter template code. — Eru·tuon 20:03, 26 February 2017 (UTC)
@Erutuon Can you explain further? It seems to me you could do various things:
{{label/example|en:foobar, _, bazbip;
        en:foobar, _, bazbip, slang;
        en:foobar, or, bazbip;
        en:foobar, and, bazbip;
        en:foobar, and, bazbip, or, Australia;
        en:Australia, or, foobar}}

{{label/example|en:foobar, _, bazbip|
        en:foobar, _, bazbip, slang|
        en:foobar, or, bazbip|
        en:foobar, and, bazbip|
        en:foobar, and, bazbip, or, Australia|
        en:Australia, or, foobar}}



Using a blank argument to separate sets of template arguments is fairly standard. In this case you'd probably have to strip whitespace off of the arguments, since this isn't done by default for unnamed args. Benwing2 (talk) 20:14, 26 February 2017 (UTC)

Well, okay, I guess there are a number of ways to do it. Actually, I came up with the method of indicating the parameters with punctuation at some point, and simply never changed my ways. I would change my method if there is a more generalizable method, one that can be made into a general template examples module. — Eru·tuon 20:40, 26 February 2017 (UTC)
Question: Why not keep the old template-based syntax? Adding an entire new function and worrying about its syntax seems like overkill for a static demonstration of the template. —suzukaze (tc) 00:36, 27 February 2017 (UTC)
Because I was adding a few more examples and I don't like typing out {{temp|label}} and then {{label}} with the same parameters, and adding the arrow between. It seems simpler and more reliable to have a module do it (though I admit the function takes quite a while to write). — Eru·tuon 01:10, 27 February 2017 (UTC)

User:Cl adding incorrect Dutch pronunciationsEdit

This user has been butting heads with me and User:Lingo Bingo Dingo over their edits to Dutch pronunciations. They've introduced nonphonemic features to phonemic transcriptions, as in diff, diff, diff, diff, diff. When pointed out, they removed the phonemic transcription altogether, and replaced it with a phonetic one without specifying which varieties of Dutch it applies to: diff, diff, diff, diff (these pronunciations are not universal). They also removed one of the two possible pronunciations in diff. When reverted, they start an edit war. Can this please be sorted? —CodeCat 19:13, 27 February 2017 (UTC)

I refer to reliable sources when making changes, yours are none. Cl (talk) 19:15, 27 February 2017 (UTC)
A dictionary is not a valid source, I've already pointed this out to you. —CodeCat 19:16, 27 February 2017 (UTC)
A dictionary can't but be a reliable source. Whatever you say isn't (unless supported by a reliable source). Cl (talk) 19:23, 27 February 2017 (UTC)
What is "reliable"? And no, a dictionary is not a valid source for Wiktionary. Have you read WT:WFW yet? —CodeCat 19:24, 27 February 2017 (UTC)
WHere exactly is stipulated dictionaries aren't a valid source for Wiktionary? This text, e.g., implies they are: [[6]]. It'd be highly illogical if they shouldn't be accepted as reliable sources. Cl (talk) 19:30, 27 February 2017 (UTC)
Those are references, not sources. There's a big difference. Also, it's common sense: a dictionary can't use another dictionary as a source. And again, what is a "reliable" source, and what makes your dictionary one? —CodeCat 19:33, 27 February 2017 (UTC)
Wiktionary isn't a dictionary by itself, but a secondary source. And of course existing dictionaries should be checked as a reliable source, should some question arise. How come can't a dictionary be a reliable source {of a phonetic transcription in this case) if Wiktionary itself demonstrates they are? Cl (talk) 19:45, 27 February 2017 (UTC)
Wiktionary is a dictionary and says so in its logo. Professionally published dictionaries are not the work of gods and we do not trust them unquestioningly. Equinox 19:51, 27 February 2017 (UTC)
You should have the official Wikipedia reliable source policy changed, if you adhere to a different point of view. I don't think you're going to succeed, though, because that'd result in chaos. Cl (talk) 19:54, 27 February 2017 (UTC)
Wiktionary does not follow Wikipedia policies, so their definition of "reliable source" is completely irrelevant to us and always has been. —CodeCat 19:56, 27 February 2017 (UTC)
One still needs some kind of verification, and yours has been null so far. Cl (talk) 19:58, 27 February 2017 (UTC)
Well then, what's the procedure for verifying IPA? —CodeCat 20:03, 27 February 2017 (UTC)
Pronunciation dictionaries and works on the Dutch phonology, in my opinion. Should you have a better idea, I'm ready to listen. Cl (talk) 20:07, 27 February 2017 (UTC)
It was a question asked to everyone else too. I genuinely don't know, so some other experienced editors should clarify hopefully. —CodeCat 20:10, 27 February 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── When it comes to pronunciation info, clearly our usual criteria of use in a permanently archived source by multiple independent authors spanning the course of more than a year cannot apply. When I add pronunciation info for English, German, and Burmese, I always rely on information from other dictionaries; when I add it for Irish, I rely on published phonetic descriptions of specific dialects combined with my own knowledge of the phonology of the language. For Welsh and Lower Sorbian, I rely on the spelling-to-pronunciation rules described in dictionaries as well as as phonological descriptions of the language. And for English and German, still I often come into conflict with other users who have different opinions on how best to transcribe these languages, even if we don't actually disagree on how a given word is pronounced. In general, phonemic transcriptions are more important here than narrow phonetic ones, but there's no reason not to include both. Is there any objection to {{IPA|lang=nl|/kroːˈaː.(t)si.jə/|[kroːˈwaː.(t)si.jə]}}? —Aɴɢʀ (talk) 20:40, 27 February 2017 (UTC)

@Cl: With a language that has so much variation, it requires some judgement to apply the information in references to the language in general. A phonological study is a single data point which may not represent larger patterns, unless it's specifically designed to do so. Conventions for representing a particular phoneme may be different in different sources. You have to know your "tools", and use the correct one for a particular task. Simply copying transcriptions wholesale- even from excellent references- without considering such factors would be like using a scalpel to clear brush and a chainsaw to perform brain surgery- they may be the best of their kind available, but your results won't be very good. Chuck Entz (talk) 03:55, 28 February 2017 (UTC)
Pardon, but when I'm presented with two possible transcriptions and the argument for one is we should use mine because I consider it correct and here's some works that back me up and the other is we should use mine because I say so, I don't care what we define as reliable source, one side clearly has more merit than the other. I'm sure CodeCat's transcriptions can be sourced too – but then now would be the time for CodeCat to do so, preferably with a source on top which shows why the other system should not be applied by us. @Chuck Entz I consider it a bit rude to imply that Cl has a lack of judgement and blindly copies things he doesn't understand because...really, there's no reason to. We have to refer to some source when making judgements about languages and phonological works are the obvious choice. Korn [kʰũːɘ̃n] (talk) 12:37, 28 February 2017 (UTC)
"when I'm presented with two possible transcriptions and the argument for" "the other is we should use mine because I say so"
Can you cite where that argument is made? The contention is in fact mostly about replacing phonemic transcriptions with phonetic transcriptions, e.g. diff, diff. Lingo Bingo Dingo (talk) 14:04, 28 February 2017 (UTC)
That, and adding nonphonemic detail to phonemic transcriptions, as I noted in the first set of diffs I provided. There are no /c/, /w/, /ɥ/ phonemes in Dutch. [c] is one possible realisation of the combination /tj/, but this is entirely allophonic and applies across word boundaries as well. The glides [w], [ɥ], [j] are automatically inserted between high vowels and a following vowel to break up a hiatus. —CodeCat 14:21, 28 February 2017 (UTC)
  • That argument is made by the action of reverting cited pronunciations to uncited ones and then demanding the change to cited pronunciations stop, effectively demanding to take good faith over professional publications. That's simply not good process and we shouldn't let such lapses creep in. At least my understanding of the proper Wiki process is: "Good faith until challenged, then sources." Consensus doesn't cut it, with consensus you can introduce and maintain any nonsensical junk if you have a big enough clique behind you. (Which, to be clear, nobody is trying to do here.) What if one day a bunch of POV‐pushing speakers of a remote language come and nobody can check on them and the only sane person gets shot down because his sources count nothing against their claims of phonetic irrelevancy? I simply don't want this to be a precedent for a loophole for wrong data. Korn [kʰũːɘ̃n] (talk) 18:02, 28 February 2017 (UTC)
I'm definitely okay with it if Cl adds phonetic transcriptions (or even indicates variants in phonemic transcriptions using parentheses or multiple transcriptions), while preferably also indicating what lect is being described. As for a reference for a voiced pronunciation of <v> in veertig, see the footnote here. Lingo Bingo Dingo (talk) 14:04, 28 February 2017 (UTC)
In case that link goes dead:
Another example is the present-day tendency in standard Dutch to voice initial fricatives /f/ and /s/ in the numerals veertig 'fourty', vijftig 'fifty', zestig 'sixty' and zeventig 'seventy'.
From Auer, P. & Hinskens, F., "The convergence and divergence of dialects in Europe. New and not so new developments in an old area", 1996, page 9, also see page 10. Lingo Bingo Dingo (talk) 14:16, 28 February 2017 (UTC)
I feel that both phonemic and phonetic presentation not only can but should be included, both are valuable information (even if the second should theoretically be derivable from the first). Crom daba (talk) 23:18, 28 February 2017 (UTC)

Changing the text of Template:bor from "borrowing" to "borrowed"Edit

This change has come up before, and I'd like to start implementing it. However, the template is sometimes used as part of a larger sentence, such as "a {{bor}}..." and if we change the phrasing here, it will break the sentence. Is there a way we could fix these cases easily? —CodeCat 14:31, 28 February 2017 (UTC)

As we discussed in WT:RFM#Template:borrowing and User talk:Daniel Carrero/2016#bor with nocap, I'd prefer doing this: I agree with your RFM comment when you said "We could get rid of the text from the template altogether (emphasis mine), and add it manually to the entries instead. Then it would work like {{der}} and {{inh}}, which don't include text either." I consider it an annoying inconsistency that {{bor}} currently returns "borrowing from" while {{inh}} and {{der}} do not return "inherited from" and "derived from", respectively. In fact, I've seen many entries, with code like "{{bor|it|en}} and {{der|it|fr}}", which apparently means "borrowed from English and French" but the second template was {{der}} (or {{etyl}}), likely to avoid showing up "borrowing from" twice or the need to use "notext=1".
The table below is what I'd expect to do. Also, I don't think that all instances of "borrowing" or "borrowed" need to link to the glossary. That's why I removed the glossary link from the "proposed" row.
Syntax Result
Current {{bor|en|it|pizza}}. Borrowing from Italian pizza.
Proposed Borrowed from {{bor|en|it|pizza}}. Borrowed from Italian pizza.
--Daniel Carrero (talk) 14:48, 28 February 2017 (UTC)
That works too. Perhaps a poll is in order. Also, I think if we decide to change it, we could rename the old template to {{bor-old}} or similar, and gradually replace the old one with the new. —CodeCat 14:53, 28 February 2017 (UTC)

Option 1: Leave as isEdit

  1.   Support and change the other templates to be more descriptive. DTLHS (talk) 23:49, 1 March 2017 (UTC)
    Are you suggesting that {{bor}} is more descriptive than other, similar templates? If so, in what way? Andrew Sheedy (talk) 00:24, 9 March 2017 (UTC)

Option 2: Change to "borrowed"Edit

Option 3: Remove text altogetherEdit

  1.   Support per my reasons above. --Daniel Carrero (talk) 15:00, 28 February 2017 (UTC)
  2.   Support. Let's remove this inconsistency. --Barytonesis (talk) 15:00, 1 March 2017 (UTC)
    By the way, it would be nice if the same were done for {{doublet}} as well. --Barytonesis (talk) 15:03, 1 March 2017 (UTC)
  3.   Support. The inconsistency has always bugged me, and there are times I've wanted to put it in the middle of a sentence, which doesn't work because "borrowing" is currently capitalized by the template. Andrew Sheedy (talk) 23:30, 1 March 2017 (UTC)
    Just as an aside, many such templates (including {{bor}}) have a nocap parameter to force the first letter to lower-case. ‑‑ Eiríkr Útlendi │Tala við mig 00:23, 2 March 2017 (UTC)
    Good to know, thanks. Andrew Sheedy (talk) 00:21, 9 March 2017 (UTC)
  4.   Support, but this is not particularly simple. @Daniel Carrero, how do you expect to be able to find and fix all the places where editors have structured a sentence in the etymology section based on the text it currently outputs? We may end up with a lot of ungrammatical etymologies if they are not checked. —Μετάknowledgediscuss/deeds 07:36, 9 March 2017 (UTC)
    Alright. Well, we already have a lot of ungrammatical etymologies. If the whole etymology consists of the template {{bor}}, then it currently is "Borrowing from <language> <word>." when it could have been either "A borrowing from <language> <word>." or "Borrowed from <language> <word>."
    I created these template tracking categories: Category:bor without notext, Category:bor with notext, Category:bor with nocap.
    I suggest fixing all entries and adding "notext" in all uses of {{bor}} where the entries are fixed... Some may be done automatically, including the hundreds or thousands of etymologies that consist simply of that template and nothing else.
    The category "bor with nocap" is an interesting case, since it might contain "A {{bor|...}}", meaning "A borrowing".
    Many etymologies in, say, Ido and Esperanto contain multiple uses of bor with "notext". It goes without saying that all uses of bor with "notext" are already good and don't need to be changed.
    When all entries are fixed and have "notext", then we could remove the "Borrowing" text from the template by default and then remove the "notext" from all entries. I realize it's a two-step process. If someone comes up with a one-step plan, I'm interested and open to hear it. Gotta give credit where it's due: this two-step plan was proposed by CodeCat in User talk:Daniel Carrero/2016#bor with nocap. --Daniel Carrero (talk) 11:24, 9 March 2017 (UTC)
    To provide the same text, perhaps invocations of {{bor}} without |notext=1 should be replaced with {{glossary|loanword|Borrowing}} from {{bor|...}} or {{glossary|loanword|borrowing}} from {{bor|...}}. — Eru·tuon 20:40, 9 March 2017 (UTC)
  5.   Support: 9/10 times I'm adding adding |notext= anyway. --Victar (talk) 04:23, 27 March 2017 (UTC)

Letter definitions and phonemesEdit

I noticed that {{Latn-def}} does not include any parameters to specify what phoneme a letter typically represents. Is this by design? If so, why? Also, should we have entries for digraphs and trigraphs and the phonemes they represent? —CodeCat 19:31, 28 February 2017 (UTC)

March 2017

Language code prefixes on reference templates, yes or no?Edit

Right now, some reference templates have a language code included in the name, like {{R:zu:ZED}}, while others don't, e.g. {{R:De Vaan 2008}}. This is rather inconsistent so I think we should settle on one way or another. Should we remove the language code from reference templates that have it, or add it to reference templates that lack it? —CodeCat 19:12, 1 March 2017 (UTC)

So, the obvious problem is that not all references are for one language only, and so you'll often have multiple aliases (e.g. {{R:ine:Kloekhorst2008}}, {{R:hit:Kloekhorst}}). I'm fine with this, but I'd like also to standardize the naming so that {{R:ine:Kloekhorst2008}} becomes {{R:ine:Kloekhorst 2008}}. From a housekeeping standpoint, having the prefixes is very useful, but then again, it will cause me undue anguish going from {{R:L&S}} to {{R:la:L&S}}. —JohnC5 19:41, 1 March 2017 (UTC)
Yeah, I think both options have downsides. If you remove the code, you may end up with more frequent name clashes. If you include it, you have a problem with references that cover many languages. I don't think having aliases for the latter is the way to go though. —CodeCat 20:12, 1 March 2017 (UTC)
I certainly agree that the current situation is very frustrating to keep track of and maintain. —JohnC5 20:29, 1 March 2017 (UTC)
Anyone up for taking count of how many name collisions we would surrently have, if not for language prefixes? I suspect there would not be very many at all that involve templates with the R:Lastname Year notation. More idiosyncratic abbreviations are probably a different case. --Tropylium (talk) 20:48, 1 March 2017 (UTC)
I think the best option is to not have the prefix unless we need it to disambiguate, but this is such a minor problem I'd rather not expend too much in the way of time and resources on it. Chuck Entz (talk) 03:01, 2 March 2017 (UTC)
Keep the prefix. It helps to find a template from the search bar quickly. When you forget the template name, you can enter Template:R:xxx: (+sometimes the first letter) and pick from the suggestions. I do it all the time. --Vahag (talk) 05:07, 2 March 2017 (UTC)
A very good point. The names of reference templates can be quite hard to remember, and I've made use of this trick myself. —CodeCat 14:06, 2 March 2017 (UTC)
On top of this, some templates include years, some don't; some include the author's name, while some include an abbreviation of the title; etc. For example, the five reference templates I use most commonly in Proto-Slavic entries are
Three different formats here. (On top of which, the author's names in the template don't match the resulting names in the generated text: Vasmer vs. Fasmer, Chernykh vs. Černyx. For ESSJa it's even worse: the generated text says Trubačev, which links to a Wikipedia article with the spelling Trubachyov, and meanwhile I've been using Trubachev in the main text.) Benwing2 (talk) 17:09, 11 March 2017 (UTC)
FWIW, I think "Fasmer" and "Trubačev" are wrong. These come from directly transliterating the corresponding Russian text, but that's not how names work. We normally write Rachmaninoff and Tchaikovsky, not the less idiosyncratic Rakhmaninov, Chaykovskiy or the transliterated Raxmaninov, Čajkovskij. Benwing2 (talk) 17:09, 11 March 2017 (UTC)
In bibliography it is customary to use strict transliterations of the names and titles so they can be searched in a database and found. Note the results for Trubačev vs Trubachyov and Trubachev. --Vahag (talk) 17:56, 11 March 2017 (UTC)
How should names work? There are slightly more products on Amazon using Rachmaninov than use Rachmaninoff--21K to 20K--and all but one of the products on the first page of Rachmaninov use Rachmaninov as part of English titles. I'd say, contrary to your claims, that culturally, we don't have a consensus on the spelling of Rachmaninoff's name. And that's an easy case; Rachmaninoff was a citizen of the US, and given that his New York tombstone has Sergei Rachmaninoff written on it, that's almost certainly what his English language official documentation has written on it. It's possible that we're the first or at least one of the first to transcribe into English the name of the author of a dictionary of some obscure Siberian language. We don't have any option but to pick some transliteration, being precise or diacritic filled or diacritic-free or natural.--Prosfilaes (talk) 23:27, 12 March 2017 (UTC)

@Benwing2, please undo your edits like this. I demonstrated above that bibliographic references use scientific transliteration. Or look at the references listed at the end of {{R:Derksen 2008}}. He has Trubačev, O.N., e.g. on page 580. --Vahag (talk) 07:43, 20 March 2017 (UTC)

OK, if you insist, I will undo all of them this evening (no time right now). But note that WorldCat and Derksen both consistently say "Max Vasmer" not "Maks Fasmer". Do you still think we need "Fasmer" despite this? Benwing2 (talk) 15:04, 20 March 2017 (UTC)
@Vahagn Petrosyan Benwing2 (talk) 01:36, 21 March 2017 (UTC)
@Benwing2: We can normalize "Maks Fasmer" to "Max Vasmer", I agree. --Vahag (talk) 07:59, 21 March 2017 (UTC)

If we use Wikidata for references, we won't need separate reference templates anymore, will we? If I'm not mistaken, we could delete all the reference templates and use something like {{ref|Q43361}}, where "Q43361" is the code for the reference intended. --Daniel Carrero (talk) 15:08, 20 March 2017 (UTC)

I don't know if that's a good idea. I would prefer keeping the reference templates as they are but using Wikidata on the back end. DTLHS (talk) 15:10, 20 March 2017 (UTC)
Something about which I've been unclear: with WikiData, will parameter passing be possible when transcluding? So would I be able to do {{ref|Q43361|page=12|head=foobar}}? I'm not crazy about this idea regardless, but just curious. —JohnC5 15:16, 20 March 2017 (UTC)
I assume we'll be able to do anything on this page. DTLHS (talk) 15:30, 20 March 2017 (UTC)
From what I see in Wikidata templates and modules that already exist in Wikipedia, apparently yes, we can certainly do that. We should be able to get title, author, year, etc. from Wikidata and use template parameters for more information if we want. JohnC5, you mentioned a parameter "page=12", which seems much needed: we may want to mention which page the information is on for each entry, on a case-by-case basis. --Daniel Carrero (talk) 23:00, 20 March 2017 (UTC)
I was just thinking this the other day when I was adding params to a few. I personally really like the prefixes for the sorting benefit previously mentioned. Sure, there are some sources that contain multiple languages, but for the most part they're all usually under a single umbrella language. I'd also like to see dates become a required suffix, like R:bsl:Derksen:1996, R:bsl:Derksen:2008, R:bsl:Derksen:2015. --Victar (talk) 04:51, 27 March 2017 (UTC)

"External sources" - follow-up voteEdit

Wiktionary:Votes/2016-12/"References" and "External sources" passed, except the point 4 (which would be always requiring the use of tags <ref></ref> and <references/>).

Also, I created Wiktionary:Votes/2017-03/"External sources", "External links", "Further information" or "Further reading" as a follow-up to this vote to double-check if we want to use "External sources" as the section name. As I said, if the follow-up vote fails, I believe "External sources" wins by default, because it already won in the first vote. --Daniel Carrero (talk) 11:07, 2 March 2017 (UTC)

Eighth LexiSession: French words in other languagesEdit

Monthly suggested collective task is to look for French words in other languages. You are invited to help us to describe the spreading of French in your own language or others you know, and to improve the way Wiktionaries describe semantic changes and uses.

This is a collaborative experiment without any guide nor direction. You're free to participate as you like and to suggest next month topic. If you do something to answer to this nice call, please report it here, to let people know you are involve in a way or another. I hope there will be some people interested this month   Noé 16:02, 2 March 2017 (UTC)

See Category:Terms derived from French for some examples in various languages. —Stephen (Talk) 16:22, 2 March 2017 (UTC)

What should past participle form templates link to?Edit

There are several templates like {{feminine plural past participle of}}. I have noticed that in Spanish entries they are directed to the infinitive of the word, like in abastadas. However, most French entries, e. g. abadés, link to the past participle form (although there seem to be exceptions like acceptées, which links to the infinitive form too). What is the preferred variant? Could/should it be unified? I think a bot might manage such unification. --Jan Kameníček (talk) 20:54, 2 March 2017 (UTC)

The general practice is that if an inflection has its own inflection, then each form-of entry links to the most immediate term it is a form of. That means that if a participle has feminine and plural forms, those link to the participle lemma form, while the participle lemma then itself links to the main verb lemma. See e.g. gedaan/gedane, captus/captae. —CodeCat 21:12, 2 March 2017 (UTC)
Thanks for explanation. I was asking, because the real practice was confusing to me. I suggest to unify it by bot if it is technically possible. --Jan Kameníček (talk) 23:41, 2 March 2017 (UTC)

Transwiki requests from en.wikipediaEdit

Apologies if this is not the right place to bring this, but I was wondering if anyone has looked at the requests for transwiki from en.wikipedia lately? There are articles that have been tagged in the transfer category for over 2 years. There's supposedly a bot but clearly it's defunct. Could someone take a look and maybe see if any are suitable, or perhaps de-tag any that are not suitable, with a note? I would do them myself, but I don't have Import privileges here, and I'm not super familiar with your standards of what's worth keeping. Premeditated Chaos (talk) 04:18, 3 March 2017 (UTC)

Honestly, we don't particularly want transwikis from Wikipedia. There would be no point to importing them, because the formatting requirements and criteria for inclusion are so radically different. I can go through and add ones that we lack, but then how would I mark the Wikipedia entry to show that it can be deleted? —Μετάknowledgediscuss/deeds 04:25, 3 March 2017 (UTC)
@Metaknowledge: Just remove w:en:Template:Move to Wiktionary. —Justin (koavf)TCM 04:55, 3 March 2017 (UTC)
@Koavf: But I thought they wanted to get rid of the entries on Wikipedia, so should I mark them for deletion? Some are pretty thoroughly non-notable and crappy. —Μετάknowledgediscuss/deeds 05:02, 3 March 2017 (UTC)
@Metaknowledge: w:Laz language and w:Marshallese language aren't going to be deleted--they are fully-formed articles. Theones that should be deleted can have a deletion notice put at the top of them. If you need help figuring out how to do that, I can assist you. If nothing else, you can just put {{delete|Transwikied to Wiktionary}} at the top. —Justin (koavf)TCM 05:05, 3 March 2017 (UTC)
@Koavf, yeah, I don't really know the ways of Wikipedia. I'll do that, then. —Μετάknowledgediscuss/deeds 05:10, 3 March 2017 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Savage honesty, @Metaknowledge:, I like it. If you want, I'll keep an eye on your contribs at enwiki and tag the rejected ones for deletion myself, just put an edit summary like "transwiki declined by wiktionary - (unsuitable/already present/whatever else)". I can point to this discussion to confirm you guys don't want them transwiki'd, if need be. Although if you are going to incorporate any of them over here without a transwiki, I wonder about licensing compliance...? Will you copy the en.wikipedia history to the talk page? (PS thanks for the swift responses everyone). Premeditated Chaos (talk) 06:37, 3 March 2017 (UTC)

I just dealt with a handful of them. There are a bunch that I'm not qualified to handle, like the Sanskrit, but I could always put them on the appropriate request pages if you guys want to get rid of the Wikipedia pages (not sure to what degree that's a priority). —Μετάknowledgediscuss/deeds 06:47, 3 March 2017 (UTC)
It's not really. I just have a weird obsession with clearing out old backlogs. Premeditated Chaos (talk) 09:46, 3 March 2017 (UTC)
It's not too weird. I have some categories that I intend to try to keep empty, but which capture a few items from time to time, giving me recurring satisfaction when I empty them. I find they give me more satisfaction than making a 5% dent on a ten-thousand item list of missing entries. You can also make some ad hoc lists of entries with correctable deficiencies by appropriate use of Cirrus search, especially including "insource". DCDuring TALK 12:56, 3 March 2017 (UTC)
Ahh, you get me :) Although I do have a certain 18,000-entry category on en.wiki that I have my sights on. A girl can dream. [[User:Premeditated Chaos|Premeditated Chaos]:] (talk) 21:35, 3 March 2017 (UTC)
I think Wikipedia:List_of_wasei-eigo should be transwikied and placed in Category:Etymological appendices. It's been nominated for deletion. Siuenti (talk) 17:56, 10 March 2017 (UTC)

Alternative romanizations for JapaneseEdit

Our current practice is to have ō rather than ou. However, romanizations with ou do occur in the wild, and people may want to look them up. Case in point is the Twitter channel @kitunegazou which has a name not only transcribing 画像 as gazou rather than gazō or gazo, but also transcribes tsu as tu instead. I think an allowance should be made for such variations so that people can look them up and find out what they mean, per our mission statement. —CodeCat 17:37, 3 March 2017 (UTC)

So far I only edit Latin-script languages, but I think alternate romanizations should be treated like alternate spellings. If they're attestable, I don't think there's any good reason not to include them. Andrew Sheedy (talk) 07:51, 4 March 2017 (UTC)
  • This is an easily bottable job, and IMO a good idea, but it needs consensus from Japanese editors. @Haplology, Eirikr, Wyang, Atitarev, TAKASUGI Shinji, Suzukaze-cΜετάknowledgediscuss/deeds 19:31, 4 March 2017 (UTC)
    (it's called wāpuro rōmaji BTW.) I for one am interested in seeing such entries here; they would be convenient. However, how would they co-exist with Hepburn entries? —suzukaze (tc) 20:59, 4 March 2017 (UTC)
    I oppose having entries for yet another transliteration, also non-standard. Redirects like ou/ō, hu/fu, tu/tsu are fine by me. Transliterations are not words in a language. --Anatoli T. (обсудить/вклад) 00:58, 5 March 2017 (UTC)
    I want to discuss your "non-standard" statement. I assume it arises from my "wāpuro rōmaji" claim. However,
    1. The Nihon-shiki and Kunrei-shiki standards also use つ = tu, ふ = hu, etc.
    2. The ou/ō that you mention, on the other hand, can be considered non-standard since the Nihon-shiki and Kunrei-shiki standards use おう = ô (while Hepburn uses ō).
    suzukaze (tc) 02:49, 5 March 2017 (UTC)
  • My several-cents-worth:
  1. JA romanizations are only ever soft redirects to lemma forms.
  2. Wāpuro rōmaji is not a standard that's taught in any educational materials that I'm aware of. It derives from the Latin-based spellings used by IMEs to convert into Japanese. For instance, しゃ (sha) could be entered into an IME as sha, sya, or sixya. I don't think there's a good case to be made for this as a romanization scheme to include here for headwords.
  3. Both of the romanization schemes put out by the Japanese government, Kunrei-shiki and the older Nihon-shiki, are based on a strict view of Japanese phonotactics. This is reasonable enough in a Japanese-as-Japanese context. However, this makes both of these schemes less suitable to non-Japanese speakers. The English Wiktionary is ostensibly targeted at English readers, who would be confused by ta being read as /ta/, but ti being read as /t͡ʃi/ and tyo being read as /t͡ʃo/.
  4. Both Kunrei-shiki and Nihon-shiki are also defective in that they cannot express the full range of Japanese phonemes. The phoneme つ is romanized in these schemes as tu, and pronounced as /t͡su/. The phoneme ち is romanized as ti, and pronounced as /t͡ʃi/. There is no way in either of these schemes to romanize the differentiation between /t͡su/ and /tu/, or /t͡ʃi/ and /ti/ -- even though the latter in these do now exist in the Japanese language, albeit only in loanwords.
This is basically a recapping of past discussions, which arrived at our current practice of using a modified version of the Hepburn romanization scheme for our romanized-JA entries.
Inasmuch as romanized JA entries are only ever redirects, I do not care greatly whether or not we have any entries created under such alternative schemes. However, I do feel strongly that we should keep our current modified-Hepburn romanizations for the romanized spellings shown in kanji and kana entries. I would be open to having the templates include a link to a page explaining romanization, if people feel strongly about that. ‑‑ Eiríkr Útlendi │Tala við mig 16:59, 6 March 2017 (UTC)

(possible layout?suzukaze (tc) 23:26, 6 March 2017 (UTC))

IMO reverse-transcription/transliteration gadgets and romanisation search support is the key, instead of more romanization entries. Wyang (talk) 10:29, 9 March 2017 (UTC)

Improving pronunciation assistanceEdit

A question at "Wiktionary:Feedback" prompted me to check what support we provide to assist users to figure out what our IPA transcriptions mean. Unfortunately, I found that the {{IPA}} template links the word "IPA" to "Wiktionary:International Phonetic Alphabet" and "(key)" to "w:English phonology", neither of which is easy for someone unfamiliar with IPA to understand.

I suggest that "IPA" should simply link to International Phonetic Alphabet, and "(key)" should link to a much simpler key with examples such as "w:Help:IPA for English". The latter can link to "Wiktionary:International Phonetic Alphabet" for readers who want more detailed information, but that really shouldn't be the first page that readers encounter. Could someone familiar with IPA work on this? — SMUconlaw (talk) 18:44, 4 March 2017 (UTC)

(key) links to Appendix:English pronunciation; it only takes you to Wikipedia's article on a language's phonology if the pronunciation appendix doesn't exist. —Aɴɢʀ (talk) 22:47, 4 March 2017 (UTC)
In that case something is wrong, because each time I click on "(key)" it sends me to "w:English phonology". Does anyone else experience this problem? — SMUconlaw (talk) 06:13, 5 March 2017 (UTC)
@Erutuon has been editing the backend of that recently and probably made some sort of a mistake along the way. —Μετάknowledgediscuss/deeds 06:15, 5 March 2017 (UTC)
@Μετάknowledge: Thanks for the ping. I think I hadn't added this page to my watchlist. I'll take a look at the module and figure out what's going wrong. The "key" link should point to Appendix:English pronunciation. — Eru·tuon 06:31, 5 March 2017 (UTC)
Ah yes, it was an error I introduced into Module:IPA/data. Fixed. — Eru·tuon 06:35, 5 March 2017 (UTC)
Thank you! — SMUconlaw (talk) 06:43, 5 March 2017 (UTC)

Quotations in non-lemma entriesEdit

Can non-lemma entries have quotations (see e. g. the English entry en passants) or should these be added only to lemma entries? Recently I have met an opinion that they should be added only to lemmas. I personally see some advantages if they are permitted to non-lemmas too.

  1. The quotations can show that the non-lemma form is verified. This happened with the above mentioned en passants. In Czech language there are sometimes more forms possible, for example the locative of Černovír can be both Černovíru and Černovíře. Because the latter one seems more typical for eastern part of the Czech Republic (Moravia), some people from Bohemia might feel it is incorrect, and so the quotation can be useful.
  2. The quotations serve also as an example how the particular form can be implemented in a sentence.

Some lemmas can have loads of inflection forms (Czech nouns up to 14, verbs more than 30) and so I do not think it would be a solution to list the quotations of all non-lemma forms in the lemma entry. --Jan Kameníček (talk) 08:28, 5 March 2017 (UTC)

@Jan.Kamenicek: I definitely agree and I'm surprised that anyone disagreed--can you tell me what that person's reasoning was or maybe use {{Ping}} to encourage him to participate? I see a lot of value in providing citations of a form of a word (e.g. where there are two plurals and the usage shifts--from fish as a plural to fishes for instance) or verb conjugations or really many examples. Even shifts in capitalization and spelling would be useful for many inflected forms that wouldn't necessarily change the lemma/base form. —Justin (koavf)TCM 10:05, 5 March 2017 (UTC)
I asked because @CodeCat: removed a quotation from the above mentioned entry Černovíře and added it to the main lemma entry Černovír, where I believe it is less useful. --Jan Kameníček (talk) 10:23, 5 March 2017 (UTC)
I think in general, quotations should be at the main entry, but there can be exceptions, such as when a given nonlemma form is rare, dialectal or obsolete. For example, the quote at sense 1 of childer really does belong there, not at child. —Aɴɢʀ (talk) 10:33, 5 March 2017 (UTC)
I think it is better when rules are regular from when they have too many exceptions.
Above I also pointed out that some Czech verbs can have more than 30 non-lemma forms. --Jan Kameníček (talk) 10:48, 5 March 2017 (UTC)
As far as I know, there is no established consensus that quotations should only rarely be in non-lemma entries. --Dan Polansky (talk) 11:27, 5 March 2017 (UTC)
I can't comment about Czech, but it seems to me the main argument for having quotations of inflected forms at the main lemma is to ensure that it is evident at one location the time period over which a particular lemma appears in the language. Note the quotations at vardapet, which reflect the many alternative forms of the word. (Also, when I first started contributing here, an editor – I don't recall who – advised me that quotations for plural forms should be placed at the main lemma.) Having said that, I wouldn't object to quotations being repeated both at the non-lemma and lemma forms. What we should avoid is quotations separated according to inflected form. — SMUconlaw (talk) 15:28, 5 March 2017 (UTC)
I agree. As I understand it, the main entry of the lemma can be accompanied with quotations no matter which form of the word is used, while e. g. inflected forms can be accompanied with quotations containing the particular form. --Jan Kameníček (talk) 16:59, 5 March 2017 (UTC)
Agreed. The lemma can be thought of as representing the whole paradigm of a word, making it appropriate to include non-lemma quotations in the main entry, but it is still useful to have quotations and other information on inflection pages. Andrew Sheedy (talk) 21:47, 5 March 2017 (UTC)

I think I've added quotations for non-lemma forms before. I certainly have for dialectal forms that do not have definition lines: see ἕως (héōs). I did a search for entries with "inflection of" and {{Q|grc}}, and came up with a few inflected-form-of entries that had quotations: φίλε (phíle), Ἕλλησι (Héllēsi), τείχους (teíkhous), ἔειπε (éeipe). (The last I created, actually.) I don't see a reason to forbid it, even when the forms are standard (as is the case for φίλε (phíle), Ἕλλησι (Héllēsi), and τείχους (teíkhous)). — Eru·tuon 22:53, 5 March 2017 (UTC)

But why would you decide to put them on the non-lemma? If it's just for attestation purposes, the citation page seems more appropriate. Quotations serve as usage examples, but nobody is going to need usage examples for particular inflections of one word. —CodeCat 23:35, 5 March 2017 (UTC)
I have to think more about this, but I suppose the purpose would be so that one can find the citations corresponding to a particular nonlemma form (and so that one can indicate that a form actually exists, if someone doubts it). But if there were a way to link a nonlemma page to the quotation that attests it, then it would be fine to move the quotation to the citation page. — Eru·tuon 00:41, 6 March 2017 (UTC)
To expand, if we place the citations for ἔειπε (éeipe) in the page Citations:εἶπον, then there should probably be a way to link from ἔειπε (éeipe) to the particular citations in Citations:εἶπον that show that form. — Eru·tuon 00:46, 6 March 2017 (UTC)
I'm talking about the citation page of the non-lemma form in particular. If we place citations there, I don't think quotations would have much use. —CodeCat 00:57, 6 March 2017 (UTC)
I am afraid I cannot see the advantage of founding separate citation page for each non-lemma form, but I see some disadvantages. It seems more practical to me to follow current practice of adding the quotations directly to the non-lemma entry. It is practical for the author of the entry but also for the readers. If I (as a reader) visited a lemma entry and decided to have a quick look at an inflection entry, after which I would like to go quickly back, I would not want to go further to another page with quotations. Most readers are also used to the fact that if an entry has just a couple of quotations, they usually find them listed directly under the explanation of the meaning. There is no reason to do it in a different way if there is just one or two quotations. --Jan Kameníček (talk) 01:32, 6 March 2017 (UTC)
But what is the point of putting a quotation usage example in a place where people are never going to look for usage examples? Quotations aren't for attestation, that's what citation pages are for. Quotations are citations that are entered into the entry to serve as usage examples. Attestation should be strictly kept out of entries. —CodeCat 19:38, 6 March 2017 (UTC)
No, you are mistaken, see Wiktionary:Quotations. Everything you wrote is mentioned there only as a possibility which may (not "should") be done in that way. It can be practical if the number of quotations is high, but very impractical for a few of them. If I, as a reader, wanted to check just quickly whether the word really exists, I would definitely appreciate if I had a couple of quotations directly at the entry, and only if I were more curious, I would go to see more of them to a separate page.
As for examples: If I, as a reader, decide to visit a non-lemma page, I appreciate, if there is the example of its usage provided too. It is much better than having examples of all possible non-lemma forms confusingly together on the lemma page. A few of them can be fine, but not too many. As I have written above, many Czech verbs can have more than 30 forms. --Jan Kameníček (talk) 22:06, 6 March 2017 (UTC)
I'm not mistaken. These are my views on what is proper for Wiktionary. Citation pages should be used for attestation, quotations should be considered a special kind of usage example, and should always be also present on the citation page. An editor should be able to freely delete a quotation and replace it with a better quotation or simple usage example, secure in knowing that it's still preserved on the citation page. If it's not currently like this, I am stating now that I believe it should be like this.
And why would you need usage examples of a verb form? Surely that's unnecessary if you know how that form is used in other verbs? I don't need a usage example for painted because I know how the past tense works in English. Also, if you're going to present usage examples for individual inflections, where do you write usage examples for the lemma form, without it getting lost among the nonspecific usage examples? For example, on the page for captus, how would we separate examples and quotations for captus as a word with all its inflections, from those specifically for captus the nominative singular form? —CodeCat 23:19, 6 March 2017 (UTC)
OK, I did not want to offend you and I have no problem to accept it as your opinion. It seemed to me that you had not known that part of the policy because you had not put it as an opinion but as a fact. So now it is clear to me. Despite this I do not think it is a good idea to revert a work of somebody who does what the policy allows because you do not agree that the policy allows it.
As for examples and "painted": not everybody knows every language as well as you know English, somebody may find it useful.
You are right with the captus example, but applying your attitude could make it even worse. Possible solution: if the other inflections were mentioned separately, similarly as it is done in Londinium, than each of the inflections could have its own examples – it is just a quick idea inspired by the Latin entry, a complication would be that the word captus has more meanings, while Londinium just one.
Nevertheless, "examples" are not the main point of my argument and I would not insist on it just because of them. The main point is the attestation part and that having small numbers of quotations directly in the entry is more practical than founding separate citation pages for them. In my opinion, this should be done especially with higher numbers of quotations. --Jan Kameníček (talk) 00:46, 7 March 2017 (UTC)
I reverted it because the common practice is to have very minimal non-lemma entries. There's no policy for or against putting quotations and usage examples on non-lemmas, so it's up to editor judgement, and I saw my edit as an improvement. —CodeCat 00:50, 7 March 2017 (UTC)
I generally believe that lemma forms should go on the base lemma. For one thing, I will happily cite a Esperanto noun with cites ending in a combination of -o, -oj, -on, and -ojn, since the conjugation is entirely clear. Likewise for an English word with an entirely normal plural; there is no reason cites for jat and jats shouldn't be combined. We can keep that general rule and have reasonable exceptions.--Prosfilaes (talk) 23:45, 12 March 2017 (UTC)

Wikisaurus questionsEdit

  1. Shouldn't pages be categorized by language? E.g. German thesaurus entries only.
  2. Should the English pages link to their translations? E.g. wikisaurus:drunkard to wikisaurus:juoppo.
  3. Is there a template like {{suffixsee}} but for linking to Wikisaurus in an entry? If not, there should be for formatting consistency.

I think in general it's not very user-friendly, and I hope we can fix that. Also, if WF or whoever is interested, wikisaurus:borracho/wikisaurus:borrachera would be a fun one. Ultimateria (talk) 22:37, 5 March 2017 (UTC)

@Ultimateria: You are definitely correct that this namespace is underdeveloped. An obvious example: Wikisaurus:happy exists but Wikisaurus:glad does not. If someone is looking up synonyms for "glad" then it would be nice to have a reciprocal link to "happy". (These could be maintained by a bot.) You may think, "Well, we should only have one entry for the most basic or common version of a word" but we have both Wikisaurus:anger and Wikisaurus:rage. I agree that separating them by language is also obviously necessary because the related terms for "pie" in English are going to be desserts and in Spanish they will be feet. —Justin (koavf)TCM 02:54, 6 March 2017 (UTC)

Mirandese and Old PortugueseEdit

I've noticed there are a few Mirandese entries listed as descendants of Old Portuguese, and these make sense since they differ from others in the Astur-Leonese family that Mirandese genetically belongs to (Mirandese was influenced by Portuguese over its history, naturally). But these should be listed as borrowings, shouldn't they? Since Mirandese, in its inherited core, is actually descendant of Old Leonese, more akin to Leonese and Asturian than Portuguese or Galician. Word dewd544 (talk) 04:42, 6 March 2017 (UTC)

In a similar vein, I saw some Asturian words listed as descendants of Old Spanish on the Latin word's page, as opposed to Old Leonese (like llenu on plenus)... Does anyone know if these are exceptions, in which Asturian took its word from Old Spanish, or if it's more of an orthographic matter, with Asturian mirroring Castillian type spelling? There are variants of these Asturian words, in standard for with an initial -ll-, that instead start with -ts-, indicating heavier palatalization. Word dewd544 (talk) 19:01, 6 March 2017 (UTC)
Yeah, they should be listed as borrowings. Despite the borrowings and areal features that connect Mirandese to Portuguese, it remains undoubtedly an Astur-Leonese language. — Ungoliant (falai) 19:10, 6 March 2017 (UTC)

Enabling Wikidata arbitrary accessEdit


After reading this discussion, your arguments and needs, we (=Wikidata development team) are considering allowing arbitrary access to Wikidata data on English Wiktionary :)

This step was anyway planned in the Wikidata for Wiktionary project, but we will try to shorten the process so you can soon display Wikidata data in Wiktionary, test it against your uses and processes, and we can observe together how it works.

Before enabling arbitrary access, we still have several steps to achieve (deploy Cognate & Interwikisorting, deploy sitelinks for Wiktionary meta pages). I will give you more information as soon as possible. In the meantime, you can follow this task on Phabricator.

Useful reminder: Wikidata only stores concepts and not words, yet. We're working on implementing new data types dedicated to lexemes, lemmas and forms. Before this happens, we should not try to describe words in Wikidata. If you're interested in this topic, check the project page or ask me :)

If you have any other ideas, use cases, remarks about using Wikidata data in Wiktionary, please let me know! Thanks for your interest, Lea Lacroix (WMDE) (talk) 10:32, 6 March 2017 (UTC)

@Lea Lacroix (WMDE): Thanks. This promises to be a very helpful addition. —Justin (koavf)TCM 10:37, 6 March 2017 (UTC)
Thank you. Here's an additional suggestion to be implemented eventually: Wikidata could be used to store Wiktionary interwikis like it does for Wikipedia, linking dog, pt:dog, es:dog, ja:dog, etc. Maybe that can't be done right now because we are implementing Wikidata access only on the English Wiktionary at the moment, and also because of the rule "Wikidata only stores concepts and not words, yet". Still, I think that's a good idea for the future. --Daniel Carrero (talk) 11:18, 6 March 2017 (UTC)
Indeed, this is the first part of our project. The interwiki linking will not be done using Wikidata but Cognate extension, that we will deploy soon on all Wiktionaries. Lea Lacroix (WMDE) (talk) 11:50, 6 March 2017 (UTC)
OK, thank you. --Daniel Carrero (talk) 03:37, 7 March 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── What is "arbitrary access"? — SMUconlaw (talk) 07:44, 7 March 2017 (UTC)

This will allow you to display data from Wikidata directly in any page of Wiktionary. With a short code like {{#label|from=Q81561}} or {{#statements:P964|from=Q81561}} the item label or any value from Wikidata will be displayed. Lea Lacroix (WMDE) (talk) 13:13, 7 March 2017 (UTC)
@Lea Lacroix (WMDE): At some point in the future — after new data types dedicated to lexemes, lemmas and forms are implemented, naturally — we'll probably use Wikidata to contain some information in all languages, for example the word "dog" in all languages (cachorro, perro, 犬, etc.)
I suppose we'll use language codes for that? es = perro, pt = cachorro, etc. But there are quite a few languages that don't have a language code, including for example the Old Swedish language. Apparently there's no ISO code for that specific language. The English Wiktionary uses "gmq-osw", while I believe the Swedish Wiktionary uses "gmq-fsv" (see the wikitext of sv:siælver). Do you know yet if Wikidata should be able to store Old Swedish using "gmq-osw" or "gmq-fsv", or maybe another code? Maybe Wikidata will store information using language names instead?
As was discussed here in 2013, most if not all of our exceptional language codes are not ISO-compliant. Neither "gmq-osw" or "gmq-fsv" are: "gmq" means North Germanic (which is correct), but "osw" and "fsv" are currently unassigned, and could be assigned to two other languages by ISO in the future.
I'd probably support this idea (which others may oppose or support too): using new, ISO-compliant, codes for all the languages that don't have an ISO code, especially by taking advantage of the range "qaa–qtz", the codes 'reserved for local use'.
For Old Swedish, maybe we could store data in Wikidata using the code "gmq-qos" if possible, or just "qos". I realize it would take work to change codes, but it's going to take work anyway to move content to Wikidata from scratch, so we might as well do it using a single set of language codes that anyone can use (that is, all the Wiktionaries, and also other projects outside of Wiktionary). --Daniel Carrero (talk) 06:03, 11 March 2017 (UTC)
For the record, I observe this with fear that actual lexicographical data will be stored at Wikidata and removed from Wiktionary, which to me would be an unfortunate development. --Dan Polansky (talk) 08:59, 11 March 2017 (UTC)
My opinion about some possible uses of Wikidata:
  • I'm not happy that Wikidata is CC0 (public domain) as opposed to the CC-BY-SA and GFDL licenses that Wiktionary uses.
  • That said, I would probably support moving the glosses of many foreign language (i.e., not English) lemmas to Wikidata, because say, all translations of the basic fruit sense of apple may have the same gloss, and the gloss might be stored on Wikidata. If you edit the gloss for "apple", it's going to be reflected in all languages. The same gloss may be added in etymologies, too. I would like if all etymologies that use "-cide" had the same gloss when applicable.
  • I would probably oppose moving all English lemmas to Wikidata, because a sense is English is usually longer (so it's more content to protect using CC-BY-SA instead of CC0) and it's likely to be in only one page anyway. If the idea above is implemented, English senses could have the same senseid as the glosses in Wikidata, but the actual definitions in the English section would still be in Wiktionary.
  • I would probably support getting the data for all place name definitions from Wikidata... For example, Wikidata could have names of cities, capitals, etc. and Wiktionary would use it to automatically build the senses and categories.
  • Also, I would be OK with moving the contents of tables like {{table:chess pieces/fo}} to Wikidata.
--Daniel Carrero (talk) 09:23, 11 March 2017 (UTC)
@Daniel Carrero Thanks for your input.
To answer about language codes: for the next step, enabling arbitrary access for Wiktionary, you'll be able to display any item from Wikidata, so if a language, dialect, etc. exists as an item, you can display its content. If it doesn't exist, you can create it on Wikidata without needing an ISO code.
For the future, when lexemes and lemmas will be stored in Wikidata, you will also be able to use any specific language. We will need a code to represent it in the RDF model, but this code doesn't have to be the ISO code. Using a new code system is possible, this is a topic we should discuss in the future with the Wikidata community. Lea Lacroix (WMDE) (talk) 11:27, 13 March 2017 (UTC)
If non-ISO codes are added to Wikidata, would there be a way to indicate whether a code is ISO or not, or where it originates from; for instance, to indicate that the code originated from Wiktionary? (I don't know anything about how Wikidata works.) — Eru·tuon 20:02, 13 March 2017 (UTC)
I think I can try to guess this answer. See wikidata:Q1860, which is the page about English. It already contains some data about the language, such as writing system, and different ISO codes. Probably our templates/modules could just automatically look if each language has an empty value for both ISO 639-1 and ISO 639-3, or alternatively we may discuss about adding the code "mis" ("uncoded language") to all the languages that are, in fact, uncoded. I'm particularly not a fan of adding where the code comes from, but I guess a new property ("language code origin" or something) would be able to do the job. --Daniel Carrero (talk) 20:20, 13 March 2017 (UTC)
  • For the record, the fact that Lea Lacroix says things like "[f]or the future, when lexemes and lemmas will be stored in Wikidata [...]" makes me very concerned. There is no consensus at English Wiktionary, or in the Wiktionaries in general, about how much lexicographical data should ever be on Wikidata. I often feel that people at Wikidata are driving this without concern for what is actually in our best interests, and that these kinds of conversations need to start at the most active Wiktionaries, not on stepwise plans drafted at Wikidata. —Μετάknowledgediscuss/deeds 22:02, 13 March 2017 (UTC)
  • @Metaknowledge: But anyone can use our data and Wikidata is a perfectly appropriate platform form lexicographical data. Integration with Wiktionary is one of the last hurdles of Phase 1--there have been several years to discuss this and a kind of live experiment with structured data at Omega, so I don't know what else to say. Is there a particular problem you have? —Justin (koavf)TCM 04:20, 14 March 2017 (UTC)
  • It's not "perfectly appropriate", and anyone who mucks around in the technical side at en.wikt realises that. If you want a starter, take a look at some of the issues Daniel Carrero brought up in this discussion (which include some potential solutions, because he's more technically proficient than I am). —Μετάknowledgediscuss/deeds 05:20, 14 March 2017 (UTC)
  • I echo Μετάknowledge's concerns -- Wikidata is not the appropriate place for any concept-based data store. Even the supposedly simple example given above of dog is extremely more complicated than discussion has so far touched upon -- What of the unattractive female sense? What of the coward sense? What of the morally reprehensible person sense? What of the any of various mechanical devices for holding, gripping, or fastening something, particularly with a tooth-like projection sense? What of any of the verb senses? We can clearly say that "Wiktionary [LANG A] has a page for term XXX, and so does Wiktionary [LANG B]". But we cannot say that "term XXX in [LANG A] is equivalent to term XXX in [LANG B] for all senses".
Even glosses can be much more complicated than single words. Frankly, in almost all cases, I feel that our single-word glosses are deficient -- different languages use terms differently. Take (sakura), for instance -- the entry could just say "cherry", but that would do our readers a disservice, in that the Japanese term carries many more different meanings and usages than just cherry. Etc., etc.
Languages are messy. Cross-linguistic comparisons and definitions are necessarily messy, squared. Wikidata assumes one-to-one relations, and is thus entirely ill-suited to the cross-linguistic use-case of any multilingual lexicography, be it Wiktionary or some other dictionary project. ‑‑ Eiríkr Útlendi │Tala við mig 17:32, 21 March 2017 (UTC)
I wouldn't mind using Wikidata for short glosses that can be repeated in many languages. For example, maybe the main sense of the word oxygen can have the same gloss in many languages, and maybe the same can be said for each element in the periodic table, each chess piece, and each day of the week. I think it's important that you asked about a lot of different senses of dog, and we do need to discuss about them. But in my opinion, we can simply not use Wikidata for these senses. The specific project I had in mind is this (sorry for repeating): "Use Wikidata to store short glosses used repeatedly in many languages. For other words, senses and glosses, don't use Wikidata." Feel free to discuss about that. Once again, I'd be OK with using Wikidata to contain information about place names in all languages, including automatic senses and categorization. --Daniel Carrero (talk) 17:47, 21 March 2017 (UTC)
@Eirikr: Your argument makes no sense: if that were true, then Wiktionary would be impossible itself... These pages are literally stored in a database anyway. There is no reason why a definitional database can't exist in principle any more than a multi-lingual dictionary can. —Justin (koavf)TCM 19:54, 21 March 2017 (UTC)
To be fair, this statement that Eirikr said above is true: "we cannot say that 'term XXX in [LANG A] is equivalent to term XXX in [LANG B] for all senses'". Still, nobody said otherwise in this discussion. I'm curious as to how the Wikidata sense database is going to work. In theory, it's possible for a dictionary database to work like this: the word dog has senses 41183, 98482, 61381, 98398, 43577, 87676, etc. It should be possible to build a database for all senses and words, and yes, move everything from Wiktionary to Wikidata. I'd oppose doing all that work, but it sounds doable in principle. I support only doing the specific sense moves I said above, and oppose the rest. --Daniel Carrero (talk) 20:05, 21 March 2017 (UTC)
There is a difference between using a database, and using specifically Wikidata. Wikidata was designed mostly with Wikipedia in mind, where it makes a lot of sense. Regarding interwikis, our interwiki links are relatively simple, we don't need something as complicated as Wikidata. We would only need a simple database that knows which pages exist in which language's Wiktionary. Then a bot wouldn't need to update the actual pages. Regarding senses, I would say something more extreme than Eirikr: We cannot say that any given sense of any given term in any given language is exactly equivalent to any given sense of any given term in any other given language. For example, we cannot even say that (what is currently) sense 1 of English dog is equivalent to (what is currently) sense 2 of Portuguese cachorro. --WikiTiki89 22:07, 21 March 2017 (UTC)
Currently, Portuguese cão is defined as "dog" and Spanish perro is defined as "dog" too. These definitions are the same. I wonder if it's OK to add the same gloss in these words, like this: "dog (a domestic canine mammal, Canis lupus familiaris)". This just means that the same gloss would be used for the English word in separate language sections that refer to the English word. Maybe the words cão, perro and dog are not the same at some level, but if the same gloss can be used for the English word when it appears in different language sections, then that's enough, at least for me. I think maybe Wikidata could store that gloss. Feel free to disagree if you want. Maybe that idea won't even work for the English word dog when it is referenced in all other language sections, but the other words I mentioned above (chemical elements, chess pieces, days of the week) may present the opportunity to use the same English gloss across multiple language sections. If nothing else, I still think that Wikidata could be used to generate definitions and categories for place names, which already follow a repeated pattern as it is. Contrary to your "extreme" statement, I believe Nova Iorque and Nueva York are probably "the same word", at least to the point that they probably could be defined using the same sense texts. --Daniel Carrero (talk) 23:21, 21 March 2017 (UTC)
That's also a problem. I've always been an advocate of abandoning the distinction between "definitions" in English and "translations" in other languages. They should all be thorough and independent definitions. The given sense of the English word "dog" is not going to have the same boundaries and connotations as the given senses of Portuguese "cão" and Spanish "perro". For example, if I modify the English definition of "dog", my modifications might not apply to other languages that link to that sense. This might work better for chemical elements and such because chemistry has become an internationally field and much of the terminology has been standardized, but there is only a limited set of words that that applies to and it's still not a strong guarantee that they are exactly the same. --WikiTiki89 15:46, 22 March 2017 (UTC)
  • @Koavf: Wiktionary is indeed stored in a database, but decidedly not in any data-normalized fashion: all our data is stored under the graphical representation of the lemma form, which lends itself well to the page-to-page interwiki linkage numerous posters have talked about -- but this is not what other Wikidata proponents appear to be advocating. Using Wikidata for the entirety of Wiktionary would require refactoring all our data so that each individual sense datum is stored as its own data object. This would be a monumental task, and also not terribly useful. Even just using Wikidata for gloss information is fraught with complication -- if I intend to gloss the Japanese term ぶす (busu) as dog, which sense of dog do I mean? (Since ぶす does not yet exist, I'll explain that this means unattractive female.) Using Wikidata as a multilingual back end where gloss XXX in language A must correlate to some other gloss in Language B requires that we know this at the editing stage. Leaving glosses as text data entered by individual editors might be inelegant in terms of data reuse, but it also provides the flexibility and transparency that we need.
My underlying sense here is that we have more than enough work ahead of us in simply creating, expanding, and maintaining entries. I do not see sufficient value to justify the enormous effort involved in designing a data structure that could apply to multilingual lexicography, and the work needed to suss out the inevitable pitfalls and then design around them -- let alone the work required after that to use such a data structure effectively. ‑‑ Eiríkr Útlendi │Tala við mig 00:16, 22 March 2017 (UTC)
@Eirikr: There would be no more effort than has already been applied to Wiktionary so far. We have definitions, quotations, translations, etc. and they are already in templates. You just have a bot store them in a database so that "dog", sense 1 points to "perro" and "dog", sense 2 points to "ぶす". Just like we have at the moment. Have you ever encountered OmegaWiki? What do you make of it? —Justin (koavf)TCM 02:30, 22 March 2017 (UTC)
But that is dangerous, see my comments above. --WikiTiki89 15:46, 22 March 2017 (UTC)
@Wikitiki89: "For example, if I modify the English definition of "dog", my modifications might not apply to other languages that link to that sense." But that's more of a reason to have structured data--then we can see when a particular field was changed and how. Either way, this isn't a problem for Wikidata per se, it's a problem of Wiktionary in general (a pretty fundamental one). I guess you could argue that Wikidata integration would just entrench the problem further but providing translations of terms is one of the most basic functions of Wiktionary as a multi-lingual dictionary. I'm not sure how your alternative would work. —Justin (koavf)TCM 17:10, 22 March 2017 (UTC)
You can see when it was changed now too. The problem is now you have to go and unlink all the senses in other languages to which the change does not apply. An alternative that I think would work is if we allowed many-to-many relationships between senses and abandoned the idea of a centralized gloss. Every foreign language term would still need to be independently defined, but now we would have automatically generated translation tables, that can exist even without an English term. I don't know if Wikidata has this capability. --WikiTiki89 17:44, 22 March 2017 (UTC)

Enabling access to Wiktionary:AutoWikiBrowserEdit

Please may I have access to the AutoWikiBrowser as I have 900+ edits and I am also an autopatroller on Wiktionary. Thank you. Pkbwcgs (talk) 19:31, 6 March 2017 (UTC)

What do people think? Normally I am inclined to grant these requests but Pkbwcgs has been trying to get admin privileges since a month after joining Wiktionary so I'm a bit leery. Benwing2 (talk) 03:27, 22 March 2017 (UTC)
He has no need for any of these tools, and they should not be granted. —Μετάknowledgediscuss/deeds 03:30, 22 March 2017 (UTC)

change typeface and font of a certain scriptEdit

Hi, I'd like to know how to permanently set the typeface (mainly size and font) of the Arabic script, as well as of the Chinese characters. Thanks in advance. —This unsigned comment was added by Backinstadiums (talkcontribs).

You can change it by adding code at Special:MyPage/common.css. Example code:
.Arab {
	font-size: 180%;
	font-family: "Arabic Typesetting";

.Hani {
	font-size: 200%;
	font-family: "SimSun", "Microsoft Yahei";
Hani is the script code for the Chinese script and Arab is for Arabic script. You can change the font-size and font-family to however you see fit. —suzukaze (tc) 10:02, 9 March 2017 (UTC)

Overview #2 of updates on Wikimedia movement strategy processEdit

Note: Apologies for cross-posting and sending in English. This message is available for translation on Meta-Wiki.

As we mentioned last month, the Wikimedia movement is beginning a movement-wide strategy discussion, a process which will run throughout 2017. This movement strategy discussion will focus on the future of our movement: where we want to go together, and what we want to achieve.

Regular updates are being sent to the Wikimedia-l mailing list, and posted on Meta-Wiki. Each month, we are sending overviews of these updates to this page as well. Sign up to receive future announcements and monthly highlights of strategy updates on your user talk page.

Here is a overview of the updates that have been sent since our message last month:

More information about the movement strategy is available on the Meta-Wiki 2017 Wikimedia movement strategy portal.

Posted by MediaWiki message delivery on behalf of the Wikimedia Foundation, 19:43, 9 March 2017 (UTC) • Please help translate to your languageGet help

Verbatim copying of open-ended copyright noticesEdit

   There are "over 175" instances of "Merriam-Webster, 1996–" having been copied from respective M-W Web pages -- where it presumably should be construed as meaning "we at M-W intend to keep our copyright enforceable as long as feasible, even tho our lawyers say it's too much trouble to update this notice every January to verify that our intention has not lapsed" -- to this site, where it becomes IMO ambiguous between implying

  • (the reasonable pablum) "Wikt finds it plausible that M-W has so far succeeded in protecting its copyright on any changes it has made to their cited Web page since '96"


  • (the more relevant but inherently false) "Wikt checks the corresponding M-W page annually to verify that the page either has undergone no change from its '96 content, or else (1) it now bears a newer copyright date and (2) we have verified that as of that new date it continues to support our invocation of that page (tho we don't bother to reflect that new date here)."

   I'm about to begin the process of replacing those 176 citations with calls to a template of my devising, and i'll periodically post, as further comments below in this section, how my progress is going.
--Jerzyt 02:13, 10 March 2017 (UTC)

@Jerzy: I honestly am having trouble understanding what you are requesting/complaining about. Those are all transclusions of {{R:Merriam-Webster Online}}. What is your concern? —JohnC5 05:34, 10 March 2017 (UTC)
   @JohnC5 Thanks for taking an interest. I understand clearly the different construction "Merriam-Webster, 1996". Similarly, "Merriam-Webster, 1996, 1997, 1999" would mean to me "We have copyright not only for the content of the 1996 edition, but also for the revisions that issued in '97 and '99." In my understanding, "Merriam-Webster, 1996–" could plausibly mean that in some years -- say '97 and '99 -- they updated pages of, or added pages to, their site, and those changes (and perhaps the site as a whole) are protected by copyright in the respective years (and extend the date by which at least those new portions are protected, respectively, by 1 and 3 years beyond the original copyright's expiration).
So "1996–", when it appears on the work itself presumably may mean "We anticipate updating this in the future, but we haven't yet had occasion to do so." But unless i misunderstand the meaning of the terminal hyphen (when it appears on the copyright owner's site), it is at best confusing and almost surely misleading when it is copied (as we did) onto another work whose copyright ownership is different: we are not relying on later editions/versions of their site (which we can neither anticipate as to time or content -- nor can we afford to maintain reliable surveillance on their future editions), so it is unworkable for us to try to keep our citation up-to-date reflecting their subsequent changes. We are merely asserting, accurately, that we relied upon what is (apparently; say so if you construe "1996–" differently) their unmodified '96 edition, which scholarly practice requires we be able to cite even if they later, in a new edition, omit/replace the matter we cited. (That's so, whether they are correcting an error, or reflecting later developments that they feel make the old version of inadequate interest to their target readership/market.)
   It is thus that i await some further or contrary insight of yours as to what "1997-" means on their site, or how it can be anything but a stumbling block when copied onto Wikt, in one citation, or in scores of them.
--Jerzyt 06:51, 10 March 2017 (UTC)
Ah see what you are talking about, but I'm pretty sure that no one on here cares at all about this matter—no offense intended. As long as we aren't copying the content of MW verbatim but instead are analyzing and synthesizing the content, the minutia of the cited year doesn't really matter. Most importantly, this citation is used on a tiny number of pages comparatively. You are thinking a great deal about a reference template that almost nobody uses anyway. —JohnC5 07:04, 10 March 2017 (UTC)
As the editor who updated the {{R:Merriam-Webster Online}} template, my point of view is that information like "1996–" in imprint statements such as those appearing in library catalogues, etc., refers to the date of publication of the source and makes no assertion about copyright. It simply records that the Merriam-Webster Online website was launched in 1996, and so content on the website was published between 1996 and the present day. If it was intended to be the date when the copyright was registered, the practice is to add "©" before the date. Editors are free to use |accessdate= to indicate the date when the website was consulted, and |source= if they wish to indicate the exact source relied on by the website. Perhaps you can explain how the template of your devising is going to be different. — SMUconlaw (talk) 12:55, 10 March 2017 (UTC)

Search results for multiple wordsEdit

The top two search results for "hardly ever" should be hardly and ever, assuming it doesn't have an entry Siuenti (talk) 17:44, 10 March 2017 (UTC)

I think this is something that should be brought up at https://phabricator.wikimedia.org/ for the https://phabricator.wikimedia.org/project/profile/209/ and https://phabricator.wikimedia.org/project/profile/1849/ teams, not here. —suzukaze (tc) 05:46, 11 March 2017 (UTC)
I'd support such a change in search behavior. Ever seems to be a stop word in our search, evidenced by it not appearing at all in the search results, even when the words are reversed. DCDuring TALK 19:09, 11 March 2017 (UTC)

Taking bibliographic information from Wikidata for use in quotation templatesEdit

Since we're a dictionary and not a bibliographic database, I think it would be good to start thinking about how to store quotation information on Wikidata rather than here. Benefits would include more consistency between entries, less tedious research, and more comprehensive references. The downside would be the wikicode would turn into something like {{#label|from=Q81561}}, which might be hard to edit- maybe there's a way to make it more descriptive. Above there was a statement that we would soon have "arbitrary access" so I believe we'll be able to do this on our own. DTLHS (talk) 18:42, 10 March 2017 (UTC)

@DTLHS: This is definitely something that Wikidata can and should do. It's used for references in statements and would be essentially the same. —Justin (koavf)TCM 05:43, 11 March 2017 (UTC)
I don't like this. I don't like creating substantial dependence of Wiktionary on Wikidata. If such a dependence arises, disputes will have to be resolved on a foreign project, Wikidata, and this will give increased power to those editors who will master the intricacies of understanding the relations between the two projects and where to edit what. --Dan Polansky (talk) 09:03, 11 March 2017 (UTC)
Still, is there any problem with the specific project of using Wikidata to hold quotation information, like title, year, author, etc. of a certain book? These are just objective facts about the book. What disputes could we have about this? --Daniel Carrero (talk) 10:00, 11 March 2017 (UTC)
I support using Wikidata to store quotation information, too. (I guess I was the first one to propose this? ;) I proposed it last month!)
Wikidata already stores information about some books: for example, wikidata:Q43361 is about Harry Potter and the Philosopher's Stone. Apparently Wikipedia already uses book information in Wikidata for its own purposes. A new template called {{auto quote|Q43361}} might serve to quote that specific book. We could also use a parameter "page": {{auto quote|Q43361|page=78}}.
As said above, I like that it would probably fill the publisher, year (maybe month, day if we want), etc. automatically.
One possible issue is that the same book may have different editions with different ISBNs... Also, the same quotation might be found in different pages in different editions.
About "might be hard to edit- maybe there's a way to make it more descriptive"... Maybe we could add an "edit" link to the Wikidata page automatically at the end of every quotation... Like this: "(year) (title) (author) (etc) [edit]" --Daniel Carrero (talk) 10:00, 11 March 2017 (UTC)

mineral waterEdit

Why is "Terms with manual transliterations different from the automated ones/hi" coming up in the categories? ---> Tooironic (talk) 01:28, 12 March 2017 (UTC)

IMO it's pretty self-explanatory. —suzukaze (tc) 01:30, 12 March 2017 (UTC)
I'm seeing similar weirdness at public transport. How is this useful? ---> Tooironic (talk) 01:31, 12 March 2017 (UTC)
It's indicating that the Hindi translation of "public transport" has a manual transcription that is different from the one generated by Module:hi-translit. As the category Terms with manual transliterations different from the automated ones/hi has not yet been created, the category shows up on the bottom of the page. Once {{auto cat}} has been added to the category page, the category will be hidden. — Eru·tuon 01:36, 12 March 2017 (UTC)
There. Now the category is hidden. You too can hide these categories by adding {{auto cat}} to their pages. — Eru·tuon 01:39, 12 March 2017 (UTC)
Thanks! ---> Tooironic (talk) 02:11, 12 March 2017 (UTC)

Request category vote -- future 2nd voteEdit

At some point after some of the current votes end, I'd like to create a 2nd version of the vote Wiktionary:Votes/2016-07/Request categories, which ended with "no consensus" (8-6-3) in October 2016. The vote was about renaming the request categories like this: from "Category:English entries needing quotation" to "Category:Requests for quotations in English".

I'd like to use the category names that @Wikitiki89 proposed in the vote above. The full list is also copied in this October 2016 discussion, where I also added names for the umbrella categories: Wiktionary:Beer parlour/2016/October#"Request categories" vote -- no consensus.

Apart from the 8 supporters, if some people opposed or abstained the vote above only because of the specific category names, I'd like to think there's a chance for the 2nd vote to pass, because of the new category names. I still think that the names currently used in our categories are problematic, including all the names with the word "needing" and all the ungrammatical names. I'd like to introduce this as a consistent category system, too.

Now, I'll ping everyone who participated in the previous vote or its talk page: @Erutuon, Bcent1234, I'm so meta even this acronym, -sche, Enoshd, Dan Polansky, This, that and the other, Equinox, Xbony2. --Daniel Carrero (talk) 12:06, 12 March 2017 (UTC)

I created the 2nd vote. Here it is: Wiktionary:Votes/2017-03/Request categories 2. --Daniel Carrero (talk) 10:15, 16 March 2017 (UTC)

User: adding unattested Spanish wordsEdit

I admit, my Spanish is not what it used to be, but I started to suspect that some of the contributions from anon Special:Contributions/ were fishy. Calling out to all the Spanish speakers around here to keep an eye on this anon and please feel free to revert any changes I might have done in error. --Robbie SWE (talk) 19:27, 13 March 2017 (UTC)

Make structured data for Wiktionary more useful and usable by learning more about common tasks Wiktionary editors performEdit

Hello, my name is Jan Dittrich and I create the concepts for the user interface for structured data for Wiktionary. To do this better, I would like to learn more about common tasks Wiktionary editors perform: How do you add a new word in Wiktionary? How do you watch and improve data?

Knowing more about this, I can consider these tasks better in future design decisions.

In my experience, learning about this is often best done via demonstrating these tasks – simply by doing them and letting someone else watch. This can be easily done remotely via google hangouts or https://meet.jit.si/

If you would like to help me and the team to improve structured data for Wiktionary, and would let me (virtually) look over your shoulder for about 30min-60min time, please write to jan.dittrich wikimedia.de.

--Jan Dittrich (WMDE) (talk) 08:27, 15 March 2017 (UTC)

This is a good idea, and really thoughtful of you. Thanks, Jan. —Μετάknowledgediscuss/deeds 16:39, 15 March 2017 (UTC)

etytree, a graphical and multilingual etymology dictionary based on Wiktionary: feedback and endorsementEdit

Hi all!

I have now completed the first phase of the project and I’m asking for a renewal and for your feedback! Pls add your comment at the end of page Renewal.

A link to the demo is demo, while a link to the first release is tools.wmflabs.org/etytree.

Looking forward to your comments on the grant page! Epantaleo (talk) 14:23, 16 March 2017 (UTC)

Symbols categorised as lemmasEdit

Right now, Module:headword treats letters and other symbols as lemmas, and probably rightly so. However, the category Category:English symbols is not actually a subcategory of Category:English lemmas, but is in its own category tree. Should this be changed? —CodeCat 15:10, 16 March 2017 (UTC)

Eh, I guess, for consistency. - -sche (discuss) 22:10, 18 March 2017 (UTC)

The Ndebele languagesEdit

@Metaknowledge The situation with the languages called "Ndebele" is a bit of a mess. From what I can gather from this list, there are actually three separate Ndebele languages: Ndebele (Northern - South Africa), Ndebele (Northern - Zimbabwe) and Ndebele (Southern). The issue is that there seem to be two different languages called Northern Ndebele, one a Zunda language (with the class 7/8 prefixes isi-/izi- like Zulu) and one a Tekela language (with si-/ti- like Swazi). Wikipedia only has Northern and Southern Ndebele articles, with no mention of a third. I'm having a lot of trouble figuring out which is which, whether there really are three or just two, and which of them is in the Tekela group. —CodeCat 16:57, 17 March 2017 (UTC)

As far as I can tell, this is how it stands:
Ndebele (Northern - Zimbabwe) has ISO code [nd] and is called "Northern Ndebele" here. It is a Zunda language.
Ndebele (Southern) has ISO code [nr] and is called "Southern Ndebele" here. It is a Tekela language.
Ndebele (Northern - South Africa) aka Sumayela Ndebele lacks an ISO code and thus has no coverage here. It is a Tekela language.
The question then is whether we should change this setup. Though the names we use are not necessarily ideal, it appears that grouping Ndebele (Northern - South Africa) into [nr] is fine, as the lects are extremely similar, but this may be more a result of lack of study than anything else. TBL notes that "Sumayela Ndebele is not recognized as an official language, or for education." Ideally, we would want to find a study to be sure that the dialect continuum can be safely cut this way. —Μετάknowledgediscuss/deeds 04:54, 18 March 2017 (UTC)
I wonder if there's something wrong with the information on that site then. The Zimbabwean variant is labelled "Northern Ndebele (Sindebele / isiNdebele)", but at the same time it says it's an offshoot of Zulu (which Wikipedia also says), and it's odd for a Zulu descendant to have no augment. At the same time, Southern Ndebele is given as "isiNdebele" on its page, and Wikipedia also gives this as the name of the language, which has an augment and might be a bit weird for a Tekela language. Wikipedia's page on Southern Ndebele gives examples which have z rather than the t of the Tekela languages, e.g. uLwezi for "November" contrasting with Swazi Lweti. —CodeCat 13:16, 18 March 2017 (UTC)

We invite you to join the movement strategy conversation (now through April 15)Edit

05:09, 18 March 2017 (UTC)

A local page for this is at Wiktionary:Wikimedia Strategy 2017, if you'd prefer to participate here instead of at metawiki. Looking forward to your input. Quiddity (WMF) (talk) 21:29, 21 March 2017 (UTC)

Vote: Reference templates and OCLCEdit

FYI, I created Wiktionary:Votes/2017-03/Reference templates and OCLC.

Let us postpone the vote as much as discussion requires. --Dan Polansky (talk) 07:47, 18 March 2017 (UTC)

The scope of this vote is not sufficiently broad. @I'm so meta even this acronym, Smuconlaw, I, and others for a while now have been fighting Dan to add legitimate citation information to templates only to have it removed because Dan feels that that it is "ugly" or "cluttered". An example of such an argument may be found at {{R:Gaffiot}} among others. Now, I'll admit to being overly aggrieved, but this vote should actually be whether citations should be full academic citations like Smuconlaw and I like or simpler stubs as Dan prefers. There are a variety examples on both sides, but I'd honestly say that our citations should be maximalistic. I don't particularly intend to go around adding OCLC and ISBN codes to everything, but I do not want people to be allowed to remove citational information because of appeals to style or tradition. —JohnC5 08:04, 18 March 2017 (UTC)
I have intentionally limitted the vote subject to OCLC only. The vote does not resolve the full disagreement between me and the ornamentalists. It only deals with one item. I have even intentionally omitted the subject of ISBN.
As for "full academic citatation", please show us an online academic article that uses ISBNs or OCLCs in its references section. --Dan Polansky (talk) 08:12, 18 March 2017 (UTC)
I would prefer not to be termed an ornamentalist but a maximalist, thanks. Again, I personally don't care about ISBN or OCLC, but all those other useful things you have removed like the location, the translation of the title, the full names of the author, editors, translators, volumes, editions, and most of all, a standardized formatting across all templates. —JohnC5 08:21, 18 March 2017 (UTC)
I prefer "ornamentalists" in keeping with the core of my argument. As for "full academic citatation", please show us an online academic article that uses ISBNs or OCLCs in its references section. I mean, really. If you keep making claims about standard citation format, please shows us an example of references in real academic publishing showing ISBNs or OCLCs. Maybe there are some, I don't know. --Dan Polansky (talk) 08:27, 18 March 2017 (UTC)
Once again, I'm not arguing on behalf of OCLCs or ISBNs because they are not part of academic citation. You can ban them for all I care. —JohnC5 08:31, 18 March 2017 (UTC)
I created the vote about OCLC. For a discussion on other details, I checked Britannica online article on tiger[7]. There, the section External links is very plain, even too much so, perhaps. And there, section "Additional Reading" contains very minimalistic manner of referencing, to wit, "K. Ullas Karanth, The Way of the Tiger: Natural History and Conservation of the Endangered Big Cat (2001)," There I see the sort of identification that makes sense to me: author, title, year, and there we go. Not sure whether it is "academic" enough, but looks good to me. I don't oppose going a little further beyond the Britannica example, but not in the ornamentalist manner in which an identification of a reference often spans multiple lines. --Dan Polansky (talk) 08:39, 18 March 2017 (UTC)
Anywyy, can you please show us one real academic article online whose manner of reference identification approaches the way you want to do it? --Dan Polansky (talk) 08:41, 18 March 2017 (UTC)
One of the lovely things about wrapping these types of things in a template is that you can both get what you want. Include some markup in the template that allows you to show or hide the components that you want with CSS and everyone wins. - TheDaveRoss 12:42, 18 March 2017 (UTC)
That does not really solve the problem since then you have to figure out the default. And it is the default that the overwhelming majority of users is ever going to see. I argue that numerical identifiers are inessential for a great majority of users, and that the minority of users should be accomodated by having these identifiers in an appendix that is one click away from the template. --Dan Polansky (talk) 13:02, 18 March 2017 (UTC)

Applying a consistent format to citation, reference and quotation templatesEdit

On a related issue, I'd like to see if there is consensus for aligning the formatting of reference templates (those starting with {{R: ...}}) with citation and quotation templates (those starting with {{cite ...}} and {{quote ...}}). Of course these families of templates have some differences as they serve different purposes, but I am of the view that the Dictionary would look more uniform if we tried to eliminate unnecessary differences. I would propose that reference templates be formatted as follows:

“[entry]” in [editor's name], editor, [Title], [Place of publication]: [Publisher], [year], retrieved [date of retrieval], page [page number], column [column number].
For example: “example” in Webster's Revised Unabridged Dictionary, Springfield, Mass.: G. & C. Merriam, 1913.

SMUconlaw (talk) 15:51, 18 March 2017 (UTC)

I oppose aligning external link template formatting with quotations templates used for attestation. In particular, I oppose starting the formatting of such a template with the year in boldface.
I oppose "retrieved [date of retrieval]"; it is useless unless the template was used to source the information.
I oppose the quotation marks around the entry name as long as that location has a hyperlink, which it usually has.
Beware that the majority of templates starting in R: are in fact used for external links, not references. --Dan Polansky (talk) 15:59, 18 March 2017 (UTC)
If the [] brackets above indicate that information is optional, it has to be said that page number and column number have to be optional. --Dan Polansky (talk) 16:00, 18 March 2017 (UTC)
No, my mistake: [] brackets are used to indicate that something is a field, a filler to be replaced with a specific value. Oh well. --Dan Polansky (talk) 16:07, 18 March 2017 (UTC)
I am not proposing that for references the year be placed in bold at the start. That makes more sense for quotations as it enables a reader to see at a glance the time period over which an entry is used. I agree that for references it makes more sense for the entry to be put at the start. Yes, the brackets in the example above indicate fields to be replaced by a particular value. I added an example with the values filled in for clarity. Yes, the page and column numbers are optional; it can be useful to add them when the external website linked to provides a PDF of the source. — SMUconlaw (talk) 16:17, 18 March 2017 (UTC)
I think I misunderstood what you mean by "aligning". You seem to say, let's remove some difference between attesting quotation templates and external link templates, but not all the differences. --Dan Polansky (talk) 16:28, 18 March 2017 (UTC)

For references, I propose to follow the formatting laid out in this style guide, section 16. --Vahag (talk) 07:53, 20 March 2017 (UTC)

Templates cmn-3 and zu-0Edit

At the moment, my Babel box has cmn-3 with an English sentence (along the lines of "This user has an advanced knowledge of Mandarin Chinese"), whereas all other templates give sentences in the languages they refer to. How come it shows up as "该用户能以熟练的普通话/国语进行交流。" on User:Atitarev's page? How do I get it to show that way on my page too? Another more subtle error is that zu-0 (I think that is the name, I assumed Zulu has code zu) renders as "Lomsebenzisi akanalo noluncane ulwazi lwesiNgisi (okanye kunzima kakhulu ukusiqondisisa)". Um, what? lwesiNgisi? So a long Zulu phrase telling people that "This user doesn't know English (or understands it with great difficulty)"? Surely ought to be "lwesiZulu", "Zulu", right? Somebody correct these please.

MGorrone (talk) 14:24, 18 March 2017 (UTC)

I'm struggling to interpret the Zulu sentence in other ways as well. I'm not sure if it's just my lack of knowledge or that it's actually badly written. —CodeCat 14:49, 18 March 2017 (UTC)
Effectively my translation is a guess. I subsequently tried working it out word-for-word with isizulu.net, and "noluncane" and "okanye" seem to be non-existent, whereas the rest seems like an awfully wordy and formal sentence. Let me try to give the idea: "This-user does-not-have-it [noluncane] he-knows-it of-English ([okanye] it-is-heavy indeed to-make-it-explain)". "Noluncane" might be some strange prefix + "oluncane" = "a little", so the first part would be "This user does not have a little knowledge of Zulu" (negative? Why?). Could be "na-", with/have, but that makes things redundant. As for "okanye", no idea. Maybe "Lomsebenzisi akalwazi isiZulu (noma uluqonda kanzima kakhulu)" could be better? MGorrone (talk) 16:12, 18 March 2017 (UTC)
The strange prefix is na- in all likelyhood, so it might mean "does not have even a little", modifying a class 11 noun, presumably ulwazi. But normally modifiers follow the head in Zulu, so I'd expect ulwazi oluncane (a small knowledge). So this may be a point where my knowledge is lacking. Perhaps this is some kind of fronting for emphasis. Okanye is also a mystery, though it must be somehow linked to kanye and -nye. -qondisisa is not a double causative but rather from -qonda (understand) with the intensive suffix -isisa. —CodeCat 16:32, 18 March 2017 (UTC)
If it mentions English and doesn't mention Zulu, something's wrong. We need to get a fluent speaker to provide a correction, and they can verify or fix the grammar at the same time. Chuck Entz (talk) 20:06, 18 March 2017 (UTC)
Looking further, I see that User:MGorrone uses the MW Babel extension (#Babel:it|), but User:Atitarev uses our {{Babel}} template. The former gets its texts from an exterior source, while ours gets them from our own User templates if they exist. Aside from the texts, there may be differences regarding language codes, as well. Chuck Entz (talk) 20:32, 18 March 2017 (UTC)
The correction the user gave is correct, as far as the language name is concerned. It should be "lwesiZulu", which is the class 11 possessive of isiZulu (listed in the inflection table). —CodeCat 20:39, 18 March 2017 (UTC)
I tried {{Babel|it-5|en-4|fr-3|es-3|de-1|cmn-3|ja-1|la-3|grc-2|nap-2|lmo-1|eml-3|ro-0|id-0|zu-0|ru-0|cs-0|sk-0|sh-0|nl-0|da-0|sv-0|ar-0|Grek-4|Cyrl-2|IPA-4|Arab-1|Hebr-1|template-1|Hira-2|Kana-2|Jpan-1}} and, as you can see on the side, it-5, nap-2, lmo-1, zu-0, sk-0, sv-0 are not recognized. cmn-3, however, now has text in Chinese. Why are those languages not recognized? MGorrone (talk) 13:51, 19 March 2017 (UTC)
Without looking into it, I would guess that means we have no templates for those specific combinations at Wiktionary for {{Babel}} to use. If you have the text for the template to display, it should be a simple matter to create them.
There are tradeoffs between our approach and WM's: their system has more coverage and is more consistent between wikis, but if there's an error or a language code is incompatible with our treatment of language codes here at Wiktionary, you have to deal with a non-WM website that also provides the service to other entities that don't necessarily have the same interests that we do. Chuck Entz (talk) 15:17, 19 March 2017 (UTC)

We should use the #Babel extension and delete individual templates. —Justin (koavf)TCM 15:30, 19 March 2017 (UTC)

The Babel extension doesn't support all of Wiktionary's language codes. —CodeCat 15:47, 19 March 2017 (UTC)
@CodeCat: Then either delete non-ISO codes or use templates only for those (but not, e.g. Zulu). —Justin (koavf)TCM 15:54, 19 March 2017 (UTC)
Feel free to propose that, then. —CodeCat 13:19, 21 March 2017 (UTC)

Should homophones lists include non-lemma forms?Edit

I saw that in the page manger#French, inflected forms of manger are listed as homophones of the lemma. This is not the case eg for trouver, or many other words. Does somebody find this information useful, or do you know people who might find it useful? Shall we include this information as much as possible for French verbs? — Automatik (talk) 23:59, 18 March 2017 (UTC)

Yes, it's useful. It's also easy to automate. —Μετάknowledgediscuss/deeds 00:00, 19 March 2017 (UTC)
This is unrelated, but it is inconsistent how mangeai is listed as a homophone of manger, but the former is transcribed as having open e and and the latter as having close e. IPA transcriptions of French should probably show the neutralization of the open–close contrast in open syllables: that is, both mangeai and manger should be transcribed as /mɑ̃ʒe/. It seems traditionalist to show a contrast that does not exist. But perhaps there are dialects in which this neutralization does not occur. — Eru·tuon 00:08, 19 March 2017 (UTC)
AFAIK the neutralization of open and close e does not occur in absolutely word-final position in French. Otherwise mangerai would merge with mangerais, mangeai would merge with mangeais. Also AFAIK mangeai has close e, not open e, and the pronunciation is simply wrong here. But I may be mistaken. Benwing2 (talk) 20:26, 25 March 2017 (UTC)
I could be mistaken too. I thought I didn't hear /ɛ/ word-finally, but maybe I was mishearing because my English /ɛ/ is opener. — Eru·tuon 20:35, 25 March 2017 (UTC)

Vote: CFI and place names cleanupEdit

FYI, I created Wiktionary:Votes/pl-2017-03/CFI and place names cleanup.

Let us postpone the vote as much as discussion requires. --Dan Polansky (talk) 13:24, 19 March 2017 (UTC)

Threats and ethnic slurs from a userEdit

User:Awesomemeeos threatened to send me, calling me "katsap" to Mordor and used unclear threats, implying I'm not safe. When advised, he just said it wasn't me he meant (katsap) and he is going to take a break. What's the policy? I'm seeking a block. Typing this on the phone, will post links if required. --Anatoli T. (обсудить/вклад) 21:24, 19 March 2017 (UTC)

@Atitarev You may also want to explain this reaction of yours to Awesomemeeos improving edits: [8] --Jan Kameníček (talk) 21:42, 19 March 2017 (UTC)
Awesomemeeos was already blocked for an hour last week to "cool off". He may need a longer cooling-off period this time, e.g. a day. He's said before he has "mental issues" and his "mind was messed up". Perhaps he needs some time off to sort his thoughts. @Jan.Kamenicek: Atitarev's objections are not to Awesomemeeos's edits (which are unobjectionable) but to his edit summaries, which seem to contain veiled threats. —Aɴɢʀ (talk) 21:45, 19 March 2017 (UTC)
I see, I have not noticed, thanks. --Jan Kameníček (talk) 21:50, 19 March 2017 (UTC)
When I blocked them for an hour last week, they sent me a rather bizarre email (not threats to me, but disturbing). My impression is that they have no clue about how to deal with human beings who disagree with them, and resort to over-the-top extreme statements without thinking about what they're really saying. Of course, I'm on another continent and you're within driving distance, so you don't have the luxury of dispassionate analysis of their actions. The best I can suggest is contacting the Wikimedia Foundation for advice, though I'm not sure of the correct procedure. Chuck Entz (talk) 22:50, 19 March 2017 (UTC)
  • To be fair when Awesomemeeos said "and atitarev thinks that he's safe. WELL he's not!" (in these two—now hidden—edit summaries: diff and diff), from the context of what he was doing before and after this (see also this—now hidden—edit summary: diff "and Chuck's next!"), I think he meant that Atitarev is not safe from pages relating to him being edited. It doesn't seem that he meant any threat to Atitarev's physical safety. I still think these are inappropriate edit summaries, which is why I have hidden them. In an edit in one of his sandboxes (diff), Awesomemeeos wrote the Ukrainian IPA transcription of "ви Мо́рдор каца́па" (which our current version of {{uk-IPA}} transcribes as [ʋe ˈmɔrdɔr kɐˈt͡sɑpɐ]), by which he may have meant "to Mordor with the katsap", which is a bit more troubling, but I would still assume that he was fooling around and perhaps expressing his frustration with Atatirev, which is inappropriate again, but this still shouldn't be taken as a serious threat. I don't oppose the block. --WikiTiki89 00:43, 20 March 2017 (UTC)
  • Awesomemeeos's edits are not unobjectionable. He boldly edits in languages he does not speak and makes too many mistakes. I would block him indefinitely for disruptive edits. --Vahag (talk) 07:35, 20 March 2017 (UTC)
  • Despite ethnic slurs, I do not get the impression that he is genuinely malicious, and I feel that it would be a waste of human potential to ban committed language enthusiasts no matter how randumb their ways are. On the other hand, I'm not the one who has to clean after him, and blocking him for a few days will certainly do no harm. Crom daba (talk) 21:41, 20 March 2017 (UTC)
    • The problem is that they don't have an real grasp of things like interacting with human beings or the ethics of working on reference material. They may try very hard to do things right, but any time they encounter a new situation they fall back on their old, bad approaches and go astray- in often bizarre fashion. For instance, telling someone who's given you a short block "to cool off" that you "have mental issues" isn't exactly a winning strategy (I won't tell you what they said via email, but it was worse). It wouldn't surprise me if they thought the ethnic slur was just harmless banter. They remind me a lot of Uther Pendrogn in some ways, but without the defiance or aggressive/abusive behavior (maybe RazorFlame is closer, but you probably aren't familiar with them).
    • At any rate, the question is whether their positive contributions outweigh the time and effort necessary to keep them from damaging the project- especially since their penchant for editing in difficult languages makes for disproportionate impact on the specialist editors we need most for other things. Chuck Entz (talk) 04:23, 21 March 2017 (UTC)
      • Wikipedias sometimes apply topic bans towards editors who are good contributors generally but make harm when editting some specific topics. I do not know Awesomemeeos much so I cannot say if this is the same case, I am just presenting the possibility of banning a user from editting e. g. anything besides the languages s/he can safely speak. --Jan Kameníček (talk) 15:28, 21 March 2017 (UTC)
        • As far as I can tell, Awesomemeeos's only "safe" contributions are when he templatizes untemplatized text without adding any content to it (even in these cases, the "danger" is that he will also add an improper gloss or something like that). I haven't seen him actually add any substantial material to entries, although I haven't been stalking all his edits or anything. If I'm wrong about this, I apologize, but that is my impression. --WikiTiki89 15:35, 21 March 2017 (UTC)
          • Awesomemeeos seems back to have unhealthy, in my opinion, interest in my name - first name and surname. He did also edit earlier (before the block) katsap, Russki, Entz, Petrosyan, people who he is angry with. There are no threats in the edit summaries this time but this reaction bothers me. @Jan.Kamenicek As was mentioned above, my reaction was to the user's edit summary, which is a concern - "不,Atitarjóv!我比你好!" - "No, Atitarjóv! I'm better than you!" when editing my first name's entry. --Anatoli T. (обсудить/вклад) 00:44, 23 March 2017 (UTC)

"Alternative reconstructions" or "Reconstruction" header?Edit

Some reconstruction-namespace entries have an "Alternative reconstructions" section. I've been putting alternative reconstructions under "Alternative forms" but it occurs to me this might be wrong. Is "Alternative reconstructions" a legitimate section header? Also, I've seen some sections titled "Reconstruction" near the top, which contain descriptive text about alternative reconstructions. Is this legitimate? If both are legitimate, which is preferred?


Benwing2 (talk) 03:19, 22 March 2017 (UTC)

I think that "Alternative reconstructions" has more of a referential feel- that is, here are some other ways that scholars have reconstructed this thing. And there's no definitive list of "legitimate" headers. DTLHS (talk) 03:28, 22 March 2017 (UTC)

Belarusian TaraškievicaEdit

To whoever might be interested in what's happening with Belarusian.

You might know that there are two Belarusian Wikipedias - one with the language code "be" and one with "be-x-old". The latter promotes the traditional Belarusian orthography or Taraškievica. In fact, it's not just spellings, eg сёння (sjónnja) vs "сёньня" (pronounced the same way) but Taraškievica uses older words, which significantly differ from the current standard or official orthography, slightly different styles and even grammar. In my latest observation, some liberal or opposition sites switch to Taraškievica, so the difference will continue to exist and the statement that Taraškievica is only used informally or by enthusiasts is no longer true. One significant example is Радыё Свабода (the Belarusian version of Radio Liberty) to which I am subscribed.--Anatoli T. (обсудить/вклад) 06:49, 22 March 2017 (UTC)

So what do you think we need to do about it? --WikiTiki89 15:37, 22 March 2017 (UTC)
I don't know yet but labelling may change, depending where things go in terms of frequency and availability of citations. --Anatoli T. (обсудить/вклад) 19:55, 22 March 2017 (UTC)


Could someone fix the Hindi translation here? There's something wrong with it. ---> Tooironic (talk) 11:46, 22 March 2017 (UTC)

Fixed. --Jan Kameníček (talk) 11:51, 22 March 2017 (UTC)

{{also}} for character entriesEdit

@Haplology, Eirikr, Suzukaze-c Should {{also}} used at the top of character entries include only alternate forms of the character? I've recently noticed pages like and which list all kinds of completely unrelated characters (perhaps only because they are slightly similar in form), and I have been removing any which are not alternate forms. Should I continue to do this as I come across these? For example, had

See also: , , , , , , , , , , , , , , and 𠨰

and I removed all but 𠨰 which is the only one which could be considered an alternate form. Likewise had

See also: , , , , , , and

and I removed , , and and left , and which are the only true alternate forms. Typos corrected. Sorry for re-pinging you all (talk) 18:39, 22 March 2017 (UTC)

{{also}} should be used for visually similar entries, not alternative forms (these should be placed in their own heading).
I, at least, find these helpful since I often use an OCR program for reading Chinese texts (usually one word glosses from dictionaries) and sometimes it can mistake one character for the other. Crom daba (talk) 20:20, 22 March 2017 (UTC)
@Crom daba Thanks for mentioning how you have found these helpful, but Wiktionary is not intended to be an OCR program assistant. I'd like to hear other views on this especially from the Japanese editors I have pinged, but of course I'm interested in what Chinese editors have to say about this too. 馬太阿房 (talk) 06:02, 23 March 2017 (UTC)
I also think putting visually similar characters in {{also}} is OK. —suzukaze (tc) 06:10, 23 March 2017 (UTC)
@Suzukaze-cThanks for your input on this. I just now noticed that the {{also}} template documentation page did say something about how visually similar terms may be included even if unrelated, but then I checked cama, the page that was referenced for the example
See also: čama and сама
and found that it was reverted by a bot and no longer shows the mearly visually similar term.
Personally, I wouldn't mind seeing these under their own heading such as "Visually Similar" or something like that. 馬太阿房 (talk) 06:26, 23 March 2017 (UTC)
I would say that the edit to was exactly the opposite of what should have happened. As others said, alternative forms go in their own ===Alternative forms=== section inside the relevant language section. {{also}} is for visually similar / confusable things, which may not even be in the same language: for example, aca links to acá although the two have no languages or meanings in common. Of course, for alphabetic languages (or just Latin-script ones?) it is relatively simple to decide what counts as "visually similar" (basically, anything that differs only by diacritics, case, some punctuation, or use of another script like a vs а), and the process of adding {{also}} has even finally been automated (yay!). For Chinese characters it might be a bit more subjective; I don't know. But most of the things listed at except the last one which is still there now seem similar enough to list. (I don't think it would make sense to have a headered "Visually similar" section, because it would necessarily not belong in any specific language section...) - -sche (discuss) 06:37, 23 March 2017 (UTC)
Based upon what appears to be popular concensus, even though I haven't heard from a couple of people I pinged on this discussion, I have reverted these entries back to include the visually similar forms in {{also}}. Thanks to all of you for sharing your thoughts on this.馬太阿房 (talk) 15:49, 23 March 2017 (UTC)

Where to record usage of the form "the X"Edit

Should a sense of the form "the X" be covered at [[X]] with a label saying {{lb|en|with 'the'}} or {{lb|en|with definite article}}, or should it be split to [[the X]]? Does it vary, and if so by what criteria? The norm/trend seems to be to put the information at [[X]] with a redirect from [[the X]]: hence, "the weed" (tobacco) is at "weed", "the deep" (sea) is at "deep", and likewise for "the world", "the alliance", "the dead", "the underground", etc. But "the bomb" is its own entry, likewise "the man". See Talk:the pits and Talk:the regions for some old discussion and other examples. The most important thing IMO is that there's a pointer at whichever form we don't lemmatize towards whichever form we do lemmatize, especially a {{only used in}} sense line on [[X]] if we put anything at [[the X]], because most people probably know what [[the]] means and will only look up [[X]]. - -sche (discuss) 16:19, 23 March 2017 (UTC)

Personally, I add the in the head, e.g. ((en-proper noun|head=the Eiffel Tower)). I don't usually include it in the entry title. Equinox 16:21, 23 March 2017 (UTC)
Also see the sex, which I believe prompted this discussion. I would argue that the man, the bomb and the sex all have meaning beyond just the + man etc., whereas the alliance is just the definite of alliance. These are two cases, and a third is when the definite article is obligatory and hence does not change the meaning, as in the Eiffel Tower, the Dead Sea, the Grim Reaper and Det Døde Hav, which was deleted. I am not sure what to do in the latter case.__Gamren (talk) 18:41, 23 March 2017 (UTC)
English proper nouns can be used attributively (White House press conference), in compounds (White House-style), and with other definite determiners (Obama's White House, this White House). It seems a bit misleading to include the, even just in the inflection line, without having a long usage note explaining the exceptions. The "exceptions" are really just part of normal usage of proper nouns, ie, part of grammar. DCDuring (talk) 18:59, 23 March 2017 (UTC)
Users won't know about the "the" unless they see it somewhere, since your examples also work for non-"the" nouns: "Greenpeace press conference", "Greenpeace-style"... Equinox 19:05, 23 March 2017 (UTC)
I agree the "the" should be somewhere. IMO it makes the most sense in the context label when a term has multiple senses (like "the weed", "the man", etc). Perhaps we could even create a label just for that (currently 100+ entries spell it out manually) which would link to an appendix that explained the circumstances under which the article was deleted. When a term has only one sense, and especially in the case of proper nouns, it might make more sense to put it in the head or page-title. - -sche (discuss) 19:48, 23 March 2017 (UTC)

Separate entries for Persian word formsEdit

Is there a reason that Persian word forms don't have their own entries? And, relatedly: that verb forms in conjugation tables aren't clickable? Most verbs are fairly regular, and the adding of these conjugated forms could probably be easily automated. 10:01, 24 March 2017 (UTC)

CAT:Persian non-lemma forms and CAT:Persian verb forms do exist and aren't empty, so there are some such entries. If there aren't more, it's just because no one has bothered adding them yet. The inflection tables would have to be edited to make the terms linkable. —Aɴɢʀ (talk) 10:50, 24 March 2017 (UTC)

Old Russian vs. Old East Slavic; Old Slovak, Old Ukrainian, Old Belarusian, etc.Edit

A few issues related to old Slavic languages:

  1. Should we have a separate language code for Old Russian vs. Old East Slavic? Most sources don't distinguish them, but they use "Old Russian" in place of "Old East Slavic". The problem here is that we give Old East Slavic (10-12th centuries, maybe 13th century?) as an ancestor of all East Slavic languages, whereas Old Russian (13th century and later?) is only the ancestor of Russian. "Old Russian" seems to go up through the 17th century in most sources. We could use zle-oru for Old Russian.
  2. Should we have separate language codes for Old Slovak, Old Ukrainian, Old Belarusian? We already have Old Czech and Old Polish. Old Belarusian in particular uses quite different spelling from modern Belarusian. We could use zlw-osk for Old Slovak, zle-ouk for Old Ukrainian and zle-obe for Old Belarusian. Benwing2 (talk) 17:17, 24 March 2017 (UTC)
At some point, Old East Slavic developed into two literary standards, which we might call Old Russian and Old Ruthenian. Whether that makes them separate languages, I'm not sure. Don't forget that the modern spoken languages (as always) are descended from the dialect continuum of the spoken language and not from either of the two literary standards (although the literary standards did of course have some influence on the modern written languages, which in turn had some influence on the modern spoken languages). Furthermore, as you say, the term "Old Russian" often refers to the entire period of OES up to modern Russian. --WikiTiki89 17:44, 24 March 2017 (UTC)
It has also become a very sensitive topic for Ukrainians and Belarusians. Some view that even the name "Russian" was usurped by Muscovy, then modern Russia. Nevertheless, "Old East Slavic" is called давньору́ська мо́ва (davnʹorúsʹka móva) (the Old Russian/Rusian language) in Ukrainian and similarly in other Slavic languages. Although, the term for "Old Ukrainian" also exists. Note that in Ukrainian ру́ський (rúsʹkyj, of Rus) is different from росі́йський (rosíjsʹkyj, Russian). --Anatoli T. (обсудить/вклад) 04:27, 25 March 2017 (UTC)
OK. What should I do with Old Belarusian and Old Ukrainian terms? For Old Russian starting in the 13th century, I've taken to using language code orv (Old East Slavic) but listing the language as "Old Russian" instead of "Old East Slavic", and giving only Russian as a descendant instead of also including Ukrainian and Belarusian. Should I do the same for Old Belarusian/Old Ukrainian, or use modern language codes uk, be, or create new language codes zle-ouk, zle-obe? Benwing2 (talk) 20:13, 25 March 2017 (UTC)
I think we need to see some cases first. Old East Slavic or Old Russian (meaning "Rusian", of Rus) is definitely the parent of Russian, Ukrainian, Belarusian and Rusyn. The terms that differ between Russian on one side and Ukrainian/Belarusian on the other are normally Old Church Slavonic influences on Russian, Polish influences on Ukrainian/Belarusian or loanwords from other languages influencing any of the three. Is there sufficient material on written Old Belarusian and Old Ukrainian (Ruthenian), anyway? --Anatoli T. (обсудить/вклад) 09:09, 27 March 2017 (UTC)
Supposedly, a lot of state documents of the Grand Duchy of Lithuania were written in Old Russian/Ruthenian/Belarusian and there's also Arab script Ruthenian used by the Tatars, so I'm sure there's some interesting material out there, someone who's into OES should find some of those texts and see if they warrant a split.
@Useigor seems to be the most active OES editor atm, so perhaps his input could be valuable. Crom daba (talk) 11:32, 27 March 2017 (UTC)
@Crom daba I have fixed your WP link. The Belarusian mentioned is pretty much modern Belarusian or almost. The text snippets I see there are heavily influenced by Polish, whose influence is more common with the opposition who try to distance themselves from Russia. There were many scripts floating around, including various Latin alphabets for Belarusian. The current official spelling and word choices have never been completely adopted by everyone. See also WT:BP#Belarusian_Taraškievica. --Anatoli T. (обсудить/вклад) 11:50, 27 March 2017 (UTC)
Thank you. So maybe lump post 13th-century (or at least 16th-century) Belarusian Ruthenian together with modern Belarusian? Crom daba (talk) 11:55, 27 March 2017 (UTC)
Well, that's around the time of the split. At least (modern) Russian is told to have formed by then (by the 15th century?). It's not the same Russian used today of course or even in Pushkin time. Perhaps same with Belarusian. The text from your link can be identified by nothing but Belarusian ("be" language code). --Anatoli T. (обсудить/вклад) 12:26, 27 March 2017 (UTC)

reference on Serbo-Croatian grammar (in particular including tones and accent classes)?Edit

This is a repeat of a request I posted in January. I am looking for a reference on Serbo-Croatian grammar similar to Zaliznyak's Russian grammar [Grammatičeskij Slovar' Russkovo Jazyka], specifically one that would show all the various accent classes. Ideally it would be written in English because I don't speak Serbo-Croatian, but I can probably puzzle out the Serbo-Croatian language using Google Translate. Ideally it would also be a morphological dictionary indicating the accent class of each word, but the following reference might be sufficient: [9] Ideally it would also be available online. Thanks! Benwing2 (talk) 19:06, 24 March 2017 (UTC)

I am growing more certain that such a thing does not exist.
Supposedly the alfanum project has compiled this data for speech recognition purposes, the data here being accentuations of case forms, not an actual classification. However they haven't published this dictionary and I don't know if they will.
Unlike Russian stress, SC accent is a more delicate thing and I'm not sure if accentuation of inflected forms was ever really strictly prescribed by the linguistic authorities. These sort of details are mostly found in dialectological descriptions of particular varieties.
Crom daba (talk) 00:02, 25 March 2017 (UTC)


The commonly used template, {{l}}, creates a link with language tagging around it (<span lang="language_code"></span>), while the template {{ll}} only creates a link with no language tagging.

I have been using the latter template for linking English terms in running text, as it seems inelegant to add language tagging in the middle of English text.

I've also used it once in a headword, to allow the headword to link to a senseid. Using {{l}} in the headword results in redundant HTML. For instance, this is the HTML source code in the Noun section of the entry عَبْد (ʿabd) when the template {{l}} is used inside the headword template:

<b class="Arab" lang="ar" xml:lang="ar">
	<span class="Arab" lang="ar" xml:lang="ar">
		<a href="/wiki/%D8%A3%D9%85%D8%A9#Arabic-slave" title="">أَمَة</a>
Arabic words are enlarged on Wiktionary if they are encircled by two HTML tags both having the class "Arab" and lang attribute "ar".

The <b> and <span> tags both have the class Arab and the lang attribute ar. This is redundant; the <span> tag should be omitted, by using the template {{ll}} rather than {{l}}. (It also causes the Arabic word أَمَة to be enlarged as shown on the right, at least in my browser, due to the CSS. Not quite sure why this is and if it can be easily fixed.)

@CodeCat has been replacing {{ll}} with {{l}} (or removing it altogether, if it is in a headword; examples: 1, 2, 3, 4). She posted on my talk page explaining why: she says it is too complicated to add more linking template, {{ll}}, to the more commonly used templates {{m}} and {{l}}.

I do not agree. I recognize that {{ll}} is not widely used right now, but the HTML code of Wiktionary would be improved if {{ll}} were used more widely in place of {{l}}. We would have less redundancy in language tagging.

I gather that @Wikitiki89 created the template {{ll}}. There has been discussion about why the template is needed on his talk page in 2014, as well as on CodeCat's request for the template to be deleted.

I'm posting here, because the use of {{ll}} is a question of policy: should we widely deploy this template, and formulate clear criteria for where it is to be used, or not? I would argue that it should be used in several cases:

  1. In the inflection form parameters of headword templates, when one wishes to link to a particular sense id for the inflected form.
  2. In English text, where language tagging is not needed.
  3. In running text of another language, when the whole text is language-tagged.

Its use would improve the cleanness of Wiktionary's HTML code. Language tagging should only be added when text in one language is inside of text in another language. Otherwise, there should be a link but no language tagging.

CodeCat doesn't find this reasoning (if it qualifies as reasoning) persuasive, so I guess I'm curious what other editors think. If there is consensus against using {{ll}} because it's too complex to have three basic linking templates, then I will by all means revert my changes adding it. Otherwise, I would like to keep the instances of the template that I have added, and deploy it more widely. — Eru·tuon 03:14, 25 March 2017 (UTC)

Concerning case 1: what is the advantage of using {{ll|id=foo}} instead of {{l|id=foo}}? — Ungoliant (falai) 03:21, 25 March 2017 (UTC)
The same as in case 3, more or less. When languages have CSS that increases the font size, embedding one set of language tags inside another causes the font size to increase twice. I would argue that this is an issue to be fixed with better CSS though, and not with an additional template. Furthermore, it doesn't account for the case in which language 1 appears inside text of language 2; the tagging is necessary here and thus {{l}} is unavoidable, and so is the double size increase. Only CSS can provide a proper fix. —CodeCat 03:30, 25 March 2017 (UTC)
In addition to the CSS-related rationale, look at the example given above, from the entry on عَبْد (ʿabd). Both {{l|id=foo}} and the headword template (in this case, {{ar-noun}}) add script and language attributes. Thus, using {{l}} inside a headword template duplicates these attributes in the HTML unnecessarily. This duplication can be avoided by using {{ll}} instead. — Eru·tuon 03:31, 25 March 2017 (UTC)
I see. That does make sense. — Ungoliant (falai) 03:35, 25 March 2017 (UTC)
Can you expand on the "cleanness of HTML" rationale? What is the benefit of having clean HTML, and what does it mean for HTML to be clean? DTLHS (talk) 03:28, 25 March 2017 (UTC)
By clean HTML I mean adding a particular HTML attribute only to one tag around a given word. I can't give a practical reason why it is beneficial (for instance, why messy HTML would cause problems), except that I prefer to avoid redundancy. — Eru·tuon 03:33, 25 March 2017 (UTC)
To say it another way, clean HTML should have only as many tags as needed to serve a purpose. The code above has a <span></span> tag whose only purpose is to contain the script and language attributes class="Arab" lang="ar". These attributes are already applied by the <b></b> tag, so the <span></span> tag is not needed. To me, it is simply axiomatic that needless things should be removed. That would be done in a Lua module; why should it not be done in entries? — Eru·tuon 05:38, 25 March 2017 (UTC)
What about applying it inside |head= in headword lines of compounds, would that be a valid use @CodeCat? Crom daba (talk) 13:48, 25 March 2017 (UTC)
  • As a possibly naive question, why use this at all? I tried figuring out the use case based on examples, and I could not find any instances where {{ll|TERM}} was preferable to simply using [[TERM]]. In headword templates and {{ux}}, regular square-bracket links are already rejiggered to point to the correct language when not otherwise specifying a different target. I am puzzled why anyone would use templates within the headword template, though I recognize that my use cases for Japanese likely just don't intersect with such needs. ‑‑ Eiríkr Útlendi │Tala við mig 18:12, 27 March 2017 (UTC)
    • Not a naive question: the reason for using {{ll}} in the headword template is to provide a sense id for one of the forms, or for a link within a term consisting of more than one word. Otherwise, you don't need to manually link the forms in the headword, because they're automatically linked.
    • In the example above, from عَبْد (ʿabd, slave), the headword links to the the entry for أمة. The sense id is necessary because there are two entirely different words in that entry (since Arabic entry names do not contain vowel diacritics) – أُمَّة (ʾumma, nation) and أَمَة (ʾama, female slave) – of which the latter is the intended target of the link in the headword template. — Eru·tuon 19:22, 27 March 2017 (UTC)

Vote: Desysopping for inactivityEdit

FYI, I created Wiktionary:Votes/pl-2017-03/Desysopping for inactivity.

Let us postpone the vote as much as discussion requires, if at all. --Dan Polansky (talk) 14:10, 25 March 2017 (UTC)

When did params 4/5 and gloss= get deprecated?Edit

Somewhere recently someone made a decision that param 4 (param 5 in some templates) and param gloss= should be deprecated in favor of param t=. When was this decision made? I don't think I agree with it. Thanks. Benwing2 (talk) 20:23, 25 March 2017 (UTC)

This should be the last public discussion we had on this WT:Beer_parlour/2016/October#Deprecating_glosses_as_the_fourth_positional_parameter_of_.7B.7Bm.7D.7D_and_.7B.7Bl.7D.7D.
Personally, I prefer |t=, but I don't see any value in deprecating alternatives. Crom daba (talk) 21:23, 25 March 2017 (UTC)
Thanks. So it looks like there was no vote, and not even any real consensus established. I think we should un-deprecate those other parameters. If we are to deprecate them, then (a) there should be a vote, (b) if the vote passes, a bot should be run to convert existing uses to use t= instead. Benwing2 (talk) 21:40, 25 March 2017 (UTC)
I think it should be voted on as it may go against the keyboarding habits of so many contributors and few participated in the discussions. DCDuring (talk) 23:52, 25 March 2017 (UTC)
I favor the use of |t=, but I agree with everyone else that there should be a vote, for the additional reason that we need to resolve the frustrating situation where certain editors (such as @Angr) are replacing numbered parameters with |t= and then being reverted. — Eru·tuon 00:01, 26 March 2017 (UTC)
  Oppose I oppose the deprecation of |4=. It is widely in use and, on average, cuts down on a character. @Angr and others should suspend their conversions until it's properly voted upon. --Victar (talk) 04:09, 27 March 2017 (UTC)
It would seem sensible to vote on this - having more than one parameter name for the same argument is never good as it confuses new editors. (I have always used "gloss=" but would happily change to t= if I'd been told!Saltmarsh. 05:04, 27 March 2017 (UTC)
Deprecated doesn't mean you can't use it, only that it is preferable to use |t= now. I don't think this needs a real vote unless we are actually talking about bot replacement and removing support for the old parameters. I think a BP poll should be enough. So far the only people objecting seem to be Benwing and Victar. --WikiTiki89 13:33, 27 March 2017 (UTC)
I   Oppose deprecating without a proper vote. Crom daba (talk) 18:22, 27 March 2017 (UTC)
@Crom daba: Just to be clear, are you referring to the word "deprecating" or to the idea of preferring one parameter over another? I'd be happy to change the phrasing to something like "|t= is the preferred parameter", and I really don't see why doing that would require a formal vote. --WikiTiki89 19:30, 27 March 2017 (UTC)
I simply believe that stating preferences like that holds more weight than it appears, and that having it resolved in a proper vote will make it more acceptable to editors who disprefer it. Crom daba (talk) 21:04, 27 March 2017 (UTC)
I think having a proper vote will give it more weight than it should have. --WikiTiki89 21:11, 27 March 2017 (UTC)

Blocking Wikidata vandalsEdit

If we use Wikidata, and someone vandalizes the data, obviously we won't be able to block them without having special rights in that project.

I don't suppose any of us regular Wiktionary editors is a Wikidata admin too? It would be nice if we got some people with admin rights in both projects eventually.

Apparently we'll need to start using this page to request blocks when needed: wikidata:Wikidata:Administrators' noticeboard. --Daniel Carrero (talk) 12:23, 26 March 2017 (UTC)

One of the dangers of using Wikidata is that if a Wikidata page is vandalized, it will not be visible in Wiktionary Recent changes, and so the vandalism may easily stay unnoticed. Jan Kameníček (talk) 13:48, 26 March 2017 (UTC)
The lag time between vandals being noticed and vandals being blocked is incredibly slow, by our standards. We have vandals that could do a great deal of damage if let loose for an entire hour with no admins around. I had not considered this before, but it really raises a risk that we will not be able to look after our own content effectively. What about questionable edits — Wikidata admins aren't going to have the judgement to know what bad lexicography by well-meaning noobs looks like when they try to reword a basic, like those Daniel suggested putting on Wikidata. —Μετάknowledgediscuss/deeds 16:51, 26 March 2017 (UTC)
@Jan.Kamenicek: You are mistaken about Wikidata showing up Recent Changes or on watchlists. —Justin (koavf)TCM 17:41, 27 March 2017 (UTC)
??? --Jan Kameníček (talk) 18:14, 27 March 2017 (UTC)
@Jan.Kamenicek: I'm not sure what you are asking. You said that Wikidata changes do not appear on Special:RecentChanges. That is not true--they do show up there, and also on watchlists. If you need more help, I will be happy to assist you but I'm not clear on what is confusing. —Justin (koavf)TCM 18:22, 27 March 2017 (UTC)
Chiming in, out of curiosity -- Assuming that Wikidata is included in a Wiktionary page, and that Wikidata is later changed -- do Wiktionary users see any indication on Wiktionary's Special:RecentChanges and watchlists? Or are these changes only visible on Wikidata's wikidata:Special:RecentChanges and watchlists? ‑‑ Eiríkr Útlendi │Tala við mig 18:29, 27 March 2017 (UTC)
@Eirikr: Sorry if I'm somehow being unclear but that is exactly what I am saying, yes--Wikidata changes show up there. They are also published through the syndication feeds as well. Unless you primarily follow pages via email updates, there is basically no chance that you will miss changes to Wikidata. I think I understand your fears but while they are legitimate they are in this instance entirely misguided. —Justin (koavf)TCM 18:33, 27 March 2017 (UTC)
(Also, I have no idea what a "syndication feed" is in this context.) ‑‑ Eiríkr Útlendi │Tala við mig 18:46, 27 March 2017 (UTC)
@Eirikr: Changes made to an entry here which is connected to Wikidata will show up at Special:RecentChanges and on watchlists here, unless you choose to not see them. Syndication feeds are generated for every page in all our wikis. You may be familiar with w:en:RSS? Is this clear enough or is something still confusing? I think at this point, it is simply easiest to show rather than tell if you are having a hard time understanding me. —Justin (koavf)TCM 19:03, 27 March 2017 (UTC)
So, if you change some data on Wikidata which is connected to Wiktionary, it will appear in our recent changes? If that's correct, I was not aware of it yet, but it sounds like good news to me.
Does it work like that on Wikipedia already? I mean, if you change some data on Wikidata which is connected to Wikipedia, will it appear on Wikipedia's recent changes?
For our purposes, if we had to rely just on Wikidata's recent changes (wikidata:Special:RecentChanges), it would be problematic because we would certainly see tons of data changes that are unrelated to Wiktionary. --Daniel Carrero (talk) 19:34, 27 March 2017 (UTC)
@Daniel Carrero: That is exactly correct, yes. And this applies not just to Wikipedia but all other WMF projects as they are all connected now (except the Wiktionaries, Incubator, Old Wikisource, and some of the backend wikis, like outreach:). —Justin (koavf)TCM 19:37, 27 March 2017 (UTC)
If somebody changes the item Albert Einstein on Wikidata, watchers of the only corresponding Wikipedia article Albert Einstein will see it in their watchlist. But the above proposal seems different to me. There is a proposal that Wikidata could be used to store glosses. E. g. the gloss: a domestic canine mammal, Canis lupus familiaris would be stored in some Wikidata item and then used for several different Wiktionary pages: en: dog, cs: pes, de: Hund, pl: pies, ru: соба́ка... Does it mean that watchers of all these English Wiktionary pages would have it in their watchlist if the Wikidata gloss was changed? --Jan Kameníček (talk) 20:00, 27 March 2017 (UTC)
@Jan.Kamenicek If someone modifies d:Q937, then someone who is watching w:en:Albert Einstein and someone watching w:es:Albert Einstein will both see the change in his watchlist. The biggest hurdle is that Wiktionary has two things which more-or-less approximate an interwiki link: both actual interwiki links (like between en:pie and) and a translation (such as between en:foot and). How that will work, I don't know. —Justin (koavf)TCM 21:02, 27 March 2017 (UTC)
There might be anti-vandal benefits to Wikidata, too, by the way. I don't know how the internals work, but on Wikipedia they have some process to detect hard-to-spot data vandalism, like changing a single digit in a chemical formula info-box. Equinox 19:30, 26 March 2017 (UTC)
They have bots with really impressive heuristics to do that sort of work. Presumably they could be deployed on Wikidata as well. There is also quite a bit more work involved in modifying Wikidata data to vandalize Wiktionary, so the number of vandals would be smaller, but the vandals would probably be more savvy. - TheDaveRoss 23:47, 26 March 2017 (UTC)

Euphemistic forms vs euphemismsEdit

Should Category:Euphemistic forms by language (things like what the fudge and f***er) be merged into Category:Euphemisms by language (things like answer the call of nature), or should the two stay separate? A merger was proposed in February of 2014 and attracted no attention, so I'm bringing it up here. They do seem hard to keep separate; I see that a into g is classified as a "euphemism", for example, while p.o.'ed is a "euphemistic form", although they seem to be the same kind of thing. - -sche (discuss) 05:59, 27 March 2017 (UTC)

electric toothbrushEdit

Could someone please fix this error that comes up on the page: Lua error in package.lua at line 80: module 'Module:tracking' not found. Thanks. ---> Tooironic (talk) 02:43, 28 March 2017 (UTC)

I did a null edit on the entry. It seems to be OK now. --Daniel Carrero (talk) 02:45, 28 March 2017 (UTC)