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? —CodeCat19:12, 1 March 2017 (UTC)[reply]
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. —CodeCat20:12, 1 March 2017 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
A very good point. The names of reference templates can be quite hard to remember, and I've made use of this trick myself. —CodeCat14:06, 2 March 2017 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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|head=foobar|page=12}}? I'm not crazy about this idea regardless, but just curious. —JohnC515:16, 20 March 2017 (UTC)[reply]
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)[reply]
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)[reply]
Redirects/aliases, as some have noted, solve some of these issues. Any widely-used or widely-usable reference like {{R:L&S}}, {{R:Duden}} or {{R:MWO}} should have a redirect from a short name (if it does not simply have a short name). In the other direction, any templates that are located at prefixless names could have redirects from the prefixed names to facilitate finding them via the search function mentioned above. For bilingual dictionaries etc, redirects are obvious (e.g. both {{R:en:Some English-Spanish dictionary}} and {{R:es:Some English-Spanish dictionary}} could produce the same reference, one redirecting to the other.) This would also allow us to standardize the "true names" of many references into a format like Victar suggests, while retaining as redirects the shorter names they currently have which people are used to. - -sche(discuss)22:10, 1 April 2017 (UTC)[reply]
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)[reply]
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)[reply]
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. —CodeCat21:12, 2 March 2017 (UTC)[reply]
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)[reply]
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)[reply]
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/deeds04:25, 3 March 2017 (UTC)[reply]
@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)❤T☮C☺M☯05:05, 3 March 2017 (UTC)[reply]
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘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)[reply]
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/deeds06:47, 3 March 2017 (UTC)[reply]
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". DCDuringTALK12:56, 3 March 2017 (UTC)[reply]
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)[reply]
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. —CodeCat17:37, 3 March 2017 (UTC)[reply]
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)[reply]
(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 (t・c) 20:59, 4 March 2017 (UTC)[reply]
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)[reply]
I want to discuss your "non-standard" statement. I assume it arises from my "wāpuro rōmaji" claim. However,
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 ō).
JA romanizations are only ever soft redirects to lemma forms.
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.
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/.
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ð mig16:59, 6 March 2017 (UTC)[reply]
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)[reply]
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.
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.
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.
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)[reply]
@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)❤T☮C☺M☯10:05, 5 March 2017 (UTC)[reply]
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)[reply]
I think it is better when rules are regular from when they have too many exceptions.
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)[reply]
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)[reply]
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)[reply]
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·tuon22:53, 5 March 2017 (UTC)[reply]
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. —CodeCat23:35, 5 March 2017 (UTC)[reply]
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·tuon00:41, 6 March 2017 (UTC)[reply]
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. —CodeCat00:57, 6 March 2017 (UTC)[reply]
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)[reply]
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. —CodeCat19:38, 6 March 2017 (UTC)[reply]
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)[reply]
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? —CodeCat23:19, 6 March 2017 (UTC)[reply]
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)[reply]
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. —CodeCat00:50, 7 March 2017 (UTC)[reply]
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)[reply]
@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)❤T☮C☺M☯02:54, 6 March 2017 (UTC)[reply]
@Ultimateria, Koavf: A possible alternative to linking translations is to merge them. So, wikisaurus:juoppo could be merged into wikisaurus:drunkard, under the existing "Finnish" and "English" headings, just like mainspace entries. Wikisaurus is arranged by concept rather than by the word itself, so there should be no problem in juoppo linking to wikisaurus:drunkard#Finnish (and, if so, the part of speech and sense could be moved above the headings, or merged into {{ws header}}.) Also, instead of a template like {{suffixsee}}, something based on {{seeCites}} seems more appropriate. I've attempted to implement this as {{seeSynonyms}}, and it seems to work (see thief), but I'm not entirely sure about the conventions and policies of this project when it comes to templates. - AdamBMorgan (talk) 18:04, 29 March 2017 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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 :)
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)[reply]
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ What is "arbitrary access"? — SMUconlaw (talk) 07:44, 7 March 2017 (UTC)[reply]
This will allow you to display data from Wikidata directly in any page of Wiktionary. With a short code like {{#label|from=Q81561}} or the item label or any value from Wikidata will be displayed. Lea Lacroix (WMDE) (talk) 13:13, 7 March 2017 (UTC)[reply]
@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)[reply]
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)[reply]
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.
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)[reply]
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·tuon20:02, 13 March 2017 (UTC)[reply]
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)[reply]
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/deeds22:02, 13 March 2017 (UTC)[reply]
@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)❤T☮C☺M☯04:20, 14 March 2017 (UTC)[reply]
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/deeds05:20, 14 March 2017 (UTC)[reply]
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 unattractivefemale sense? What of the coward sense? What of the morallyreprehensibleperson 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ð mig17:32, 21 March 2017 (UTC)[reply]
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)[reply]
@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)❤T☮C☺M☯19:54, 21 March 2017 (UTC)[reply]
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)[reply]
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. --WikiTiki8922:07, 21 March 2017 (UTC)[reply]
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)[reply]
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. --WikiTiki8915:46, 22 March 2017 (UTC)[reply]
@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 unattractivefemale.) 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ð mig00:16, 22 March 2017 (UTC)[reply]
@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)❤T☮C☺M☯02:30, 22 March 2017 (UTC)[reply]
@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)❤T☮C☺M☯17:10, 22 March 2017 (UTC)[reply]
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. --WikiTiki8917:44, 22 March 2017 (UTC)[reply]
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)[reply]
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)[reply]
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 (talk • contribs).
@Suzukaze-c: Hi again, I've just noticed that it does not apply in, for example, category pages, so I'd like to know how if it possible to implement such codes for any term appearing throughout the whole wiktionary, and even wikipedia. Thanks in advance. --Backinstadiums (talk) 13:32, 5 April 2017 (UTC)[reply]
You can also change it globally by changing your browser's font settings. The methods to accomplish this vary by browser, obviously, but I believe that all major browsers allow you to set your own fonts. - TheDaveRoss13:51, 5 April 2017 (UTC)[reply]
I haven't used the extension myself, bummer that it isn't effective. There are other extensions which allow you to use your own custom CSS globally, I have also not used those. - TheDaveRoss15:14, 5 April 2017 (UTC)[reply]
@Suzukaze-c: Hi again, the arabic headwords of dictionary entries have started to be several times bigger than the rest of the script in the entries. Also, tables have increased their size a lot, taking up a lot of space. I'd like them to be the exact size as the rest. --Backinstadiums (talk) 10:00, 13 May 2017 (UTC)[reply]
I responded thinking you were talking about the header at the top of the page, but you said headword. I too am not aware of any changes in the HTML. It might help if you could post a screenshot of a headword with multiple forms, to show what's enlarged. I went with em size for Arabic script rather than percents in my common.css. Percents can cause problems in some cases. — Eru·tuon22:34, 13 May 2017 (UTC)[reply]
@Erutuon: Hi, could you tell me a page where to find CSS code used by wiktionary? I'd like to diminish line and paragraph separation as well, even in the declension tables. --Backinstadiums (talk) 08:24, 14 May 2017 (UTC)[reply]
@Backinstadiums: The language-related CSS is found at MediaWiki:Common.css. Thanks for the screenshot. I dunno, it looks like all your Arabic text is equally enlarged. I would just modify the font-size for the Arab class in your common.css until it looks right to you. 200% is kind of big. — Eru·tuon08:32, 14 May 2017 (UTC)[reply]
Overview #2 of updates on Wikimedia movement strategy processedit
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:
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"
and
(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. --Jerzy•t02:13, 10 March 2017 (UTC)[reply]
@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. --Jerzy•t06:51, 10 March 2017 (UTC)[reply]
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. —JohnC507:04, 10 March 2017 (UTC)[reply]
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. DCDuringTALK19:09, 11 March 2017 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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.
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/201.194.91.183 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)[reply]
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.dittrichwikimedia.de.
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.
@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. —CodeCat16:57, 17 March 2017 (UTC)[reply]
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/deeds04:54, 18 March 2017 (UTC)[reply]
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 SwaziLweti. —CodeCat13:16, 18 March 2017 (UTC)[reply]
We invite you to join the movement strategy conversation (now through April 15)edit
This message, "We invite you to join the movement strategy conversation (now through April 15)", was sent through multiple channels by Gregory Varnum on 15 and 16 of March 2017 to village pumps, affiliate talk pages, movement mailing lists, and MassMessage groups. A similar message was sent by Nicole Ebber to organized groups and their mailing lists on 15 of March 2017. This version of the message is available for translation and documentation purposes
Dear Wikimedians/Wikipedians:
Today we are starting a broad discussion to define Wikimedia's future role in the world and develop a collaborative strategy to fulfill that role. You are warmly invited to join the conversation.
There are many ways to participate, by joining an existing conversation or starting your own:
Track A (organized groups): Discussions with your affiliate, committee or other organized group (these are groups that support the Wikimedia movement).
This is the first of three conversations, and it will run between now and April 15. The purpose of cycle 1 is to discuss the future of the movement and generate major themes around potential directions. What do we want to build or achieve together over the next 15 years?
We welcome you, as we create this conversation together, and look forward to broad and diverse participation from all parts of our movement.
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. —JohnC508:04, 18 March 2017 (UTC)[reply]
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.
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. —JohnC508:21, 18 March 2017 (UTC)[reply]
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)[reply]
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. —JohnC508:31, 18 March 2017 (UTC)[reply]
I created the vote about OCLC. For a discussion on other details, I checked Britannica online article on tiger[1]. 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)[reply]
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)[reply]
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. - TheDaveRoss12:42, 18 March 2017 (UTC)[reply]
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)[reply]
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].
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.
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)[reply]
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)[reply]
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)[reply]
@Smuconlaw, Vahagn Petrosyan: I've actually come around to your opinion that, for logical consistency, the cited entry should come at the end, rather than at the beginning. Let's do away with the "date of retrieval" field, however; it's worse than useless. As for page and column, I prefer the traditional convention for writing those numbers, separated by a slash (e.g. 38/2 = page 38, column 2). Finally, we must consider foliation, complete with recto and verso. — I.S.M.E.T.A.23:34, 15 April 2017 (UTC)[reply]
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.
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. —CodeCat14:49, 18 March 2017 (UTC)[reply]
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)[reply]
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. —CodeCat16:32, 18 March 2017 (UTC)[reply]
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)[reply]
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)[reply]
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). —CodeCat20:39, 18 March 2017 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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·tuon00:08, 19 March 2017 (UTC)[reply]
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)[reply]
I could be mistaken too. I thought I didn't hear /ɛ/ word-finally, but maybe I was mishearing because my English /ɛ/ is opener. — Eru·tuon20:35, 25 March 2017 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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. --WikiTiki8900:43, 20 March 2017 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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. --WikiTiki8915:35, 21 March 2017 (UTC)[reply]
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)[reply]
"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?
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)[reply]
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)[reply]
@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
{{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)[reply]
@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)[reply]
@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
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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. 82.209.150.23410:01, 24 March 2017 (UTC)[reply]
@DTLHS Yes, I consider my knowledge of Persian sufficient, and I have a rather thorough grammar (including verbs, their stems and conjugations) for reference. ✎ HannesP · talk22:54, 2 April 2017 (UTC)[reply]
Old Russian vs. Old East Slavic; Old Slovak, Old Ukrainian, Old Belarusian, etc.edit
A few issues related to old Slavic languages:
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.
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)[reply]
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. --WikiTiki8917:44, 24 March 2017 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
1+1 "ст.-польск." in усторобиться (also in Trubachev comments: поджарый)
0+2 "ст.-укр.": -- (but in Trubachev comments: винтовка, цинга)
ЭССЯ mentions:
"ст.-чеш." in every volume
"ст.-укр." in every volume
"ст.-польск." in every volume
"ст.-блр." almost in every volume
"ст.-слвц." almost in every volume (frequently after 26)
"ст.-русск." / "ст.-рус." in ~3/5 of all volumes (frequently in 14 and after 23)
"ст.-сербохорв." in ~3/4 of all volumes
"ст.-серб." / "ст.-сербск." in ~1/4 of all volumes
"ст.-болг." in ~1/6 of all volumes
"др.-болг." rare (many of them in parantheses beside "ст.-слав.")
few "ст.-хорв."
few "ст.-словен." but frequently since 27 volume
few "др.-чеш."
1 "ст.-серболуж.
1 "др.-польск."
Derksen (from list of abbreviations): Middle Bulgarian, Old Belorussian, Old Czech, Old Polish, Old Russian (in sense Old East Slavic), Old Slovak
Thus probably needing codes for Middle Bulgarian (bgm?), Old Slovak, Old Belorussian, Old Ukrainian, Old Russian, Old Serbo-Croatian (zls-sh?), Old Slovene (zls-sl?). —Игорь Тълкачь (talk) 21:20, 1 April 2017 (UTC)[reply]
@Atitarev There are lots of instances of Old Belarusian, Old Russian, Old Ukrainian in the Reconstruction name space, e.g. for Old Belarusian see Reconstruction:Proto-Slavic/načęti, Reconstruction:Proto-Slavic/mьněti, Reconstruction:Proto-Slavic/měniti, etc. The spelling of Old Belarusian looks like Old East Slavic and not like modern Belarusian. I actually added a hack into Module:be-translit to account for и (no longer in modern Belarusian), on the assumption that Old Belarusian would use the be code; but it probably makes more sense to make Old Russian, Old Ukrainian and Old Belarusian be etymology-only variants of Old East Slavic. (Note meanwhile that Wiktionary actually defines Old Belarusian as "Old East Slavic".) Meanwhile we should probably create a new language code zlw-osk for Old Slovak, since we already have separate codes for Old Polish and Old Czech. Anyone object if I make these changes? Benwing2 (talk) 16:07, 2 April 2017 (UTC)[reply]
@Benwing2: I think it was a mistake to create these codes based on the descendants given on the reconstruction pages, at least without further investigation. For each form given, it needs to actually be verified what period it is from (if it indeed exists) and only then would we have a clearer picture of which language codes need to be created. --WikiTiki8920:36, 3 April 2017 (UTC)[reply]
The need for these codes is real. Old East Slavic, for example, only went through the 13th century per Wikipedia Ruthenian language or at the latest the 15th century per Old East Slavic (although Ukrainian had already split off by the 13th or 14th century). The sources are pretty consistent in saying "Old Ukrainian" and "Old Belarusian" (and often give dates). Benwing2 (talk) 20:52, 3 April 2017 (UTC)[reply]
@Benwing2: Regardless of how you split up the language, the real problem is identifying which words belong to which period of which dialect. I wouldn't trust another dictionary's labeling of "Old Ukrainian", "Old Belarusian", etc. unless that dictionary itself precisely defines what they mean. If the sources give dates, that's a great start (we should add them to the entries so we can keep track better). It would be even better to find actual quotations. --WikiTiki8921:12, 3 April 2017 (UTC)[reply]
I agree. I can imagine it would be quite hard to find sufficient quotations of Old Belarusian or Old Ukrainian, which are different from modern languages and different from Old Russian. --Anatoli T.(обсудить/вклад)23:50, 3 April 2017 (UTC)[reply]
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: [3] Ideally it would also be available online. Thanks! Benwing2 (talk) 19:06, 24 March 2017 (UTC)[reply]
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 Thanks. I'm almost certain that a reference guide for Serbo-Croatian accents exists, since there does exist a standardized language, as found in dictionaries. Benwing2 (talk) 16:09, 2 April 2017 (UTC)[reply]
@Benwing2: You might be interested in Daničić's work, he's one of the key founders of "standard Serbo-Croatian".
In practice, the standard is the pronunciation of the capital cities, Zagreb and Belgrade, there wasn't much need to codify accents beyond that. After all, they aren't written outside of work which specifically deals with them.
There's also the fact that throughout socialist Yugoslavia the Serbo-Croatian project had to walk the tightrope between unitarism and nationalism, and there was no space for monumental works like those done in the 19th century when an entirely new literary language was built from scratch on the basis of a spoken language.
Now of course, 'language experts' are free to play at creating artificial languages to our frustration, so such a dictionary could perhaps be created in near future, except of course, it won't say "Serbo-Croatian" on the cover. Crom daba (talk) 21:21, 3 April 2017 (UTC)[reply]
The commonly used template, {{l}}, creates a link with language tagging around it (<spanlang="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:
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'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:
In the inflection form parameters of headword templates, when one wishes to link to a particular sense id for the inflected form.
In English text, where language tagging is not needed.
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·tuon03:14, 25 March 2017 (UTC)[reply]
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. —CodeCat03:30, 25 March 2017 (UTC)[reply]
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·tuon03:31, 25 March 2017 (UTC)[reply]
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)[reply]
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·tuon03:33, 25 March 2017 (UTC)[reply]
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·tuon05:38, 25 March 2017 (UTC)[reply]
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ð mig18:12, 27 March 2017 (UTC)[reply]
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·tuon19:22, 27 March 2017 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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·tuon00:01, 26 March 2017 (UTC)[reply]
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)[reply]
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)[reply]
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. --WikiTiki8913:33, 27 March 2017 (UTC)[reply]
@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. --WikiTiki8919:30, 27 March 2017 (UTC)[reply]
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)[reply]
Deprecation isn't just about preference but also (more importantly) intent of future removal of a deprecated thing (see our definition) which does call for a vote. --Giorgi Eufshi (talk) 05:52, 28 March 2017 (UTC)[reply]
The vote should mention when and how the params should be deleted/replaced or else the best it is going to achieve is a small-ass note in the template documentation page. --Dixtosa (talk) 19:03, 29 March 2017 (UTC)[reply]
The small-ass note is all I really want, which is why I didn't think we needed a vote. Normally features are deprecated long before it is known when they will actually be removed, so I think it's fine not to mention it. --WikiTiki8919:08, 29 March 2017 (UTC)[reply]
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.
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)[reply]
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/deeds16:51, 26 March 2017 (UTC)[reply]
@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)❤T☮C☺M☯18:22, 27 March 2017 (UTC)[reply]
@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)❤T☮C☺M☯18:33, 27 March 2017 (UTC)[reply]
@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)❤T☮C☺M☯19:03, 27 March 2017 (UTC)[reply]
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?
@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)❤T☮C☺M☯19:37, 27 March 2017 (UTC)[reply]
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)[reply]
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)[reply]
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. - TheDaveRoss23:47, 26 March 2017 (UTC)[reply]
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)[reply]
If this has been discussed, forgive me, but I would love a {{cog}} equivalent for descent trees, maybe {{desc}}. It seems such a waste of time to me to have to always manually type it out, i.e. Dutch: {{l|nl|vrede}}. It's also far more prone to typos and other errors. --Victar (talk) 18:14, 28 March 2017 (UTC)[reply]
@Victar: I've been thinking about making a general linking template that displays the language name before the link in the way that {{cog}} does, but haven't figured out a good name for it. I can fairly easily create the descendant template that you request. — Eru·tuon20:39, 28 March 2017 (UTC)[reply]
@Erutuon: Thanks a ton! And good thinking, @DTLHS. I guess if anyone changes their mind about its validity as a template, they can run a bot to convert them back. --Victar (talk) 21:44, 28 March 2017 (UTC)[reply]
@Erutuon: Does this template accept etymology-only languages? I frequently use specific dialects in a situation where I would use this. —JohnC501:23, 29 March 2017 (UTC)[reply]
It could be done by using the same parameter names that are used in {{affix}} for the components of a word, but I think it's probably unnecessary. — Eru·tuon20:42, 29 March 2017 (UTC)[reply]
It's left over from when we didn't have proto-languages. We'd use the families to group the descendants. When proto-languages were added, it was natural to place the forms after those family names. —CodeCat00:01, 1 April 2017 (UTC)[reply]
Thanks for the background, CodeCat. I think best to just keep to that standard, and if people want to change it in the future, it's an easy change of code. --Victar (talk) 00:07, 1 April 2017 (UTC)[reply]
@Useigor: I could be wrong, but I would just specify one script in {{desc}} and another script in {{l}}: {{desc|sh|ре̑ч|sc=Cyrl}}, {{l|sh|rȇč|sc=Latn}}
If a word has alternate plurals, such as POTUSSES and POTI, should the plurals link to each other as synonyms, or just back to the main entry? Siuenti (talk) 04:40, 31 March 2017 (UTC)[reply]
I generally just link back to the main entry, mostly because I'm too lazy to list the alternative plurals. This is particularly relevant in languages like Welsh, where many nouns have as many as three or four different attested plural forms. —Aɴɢʀ (talk) 15:03, 31 March 2017 (UTC)[reply]
I do the same. The primary purpose of non-lemma entries is to get the user to the lemma page. It is on that page that they can see the full range of inflections. —CodeCat15:30, 31 March 2017 (UTC)[reply]
I agree, and have been specifically trimming down the moderate number of entries along the lines of CACTI: plural of cactus; alternative form of cactuses. Equinox◑15:38, 31 March 2017 (UTC)[reply]
Noé 16:02, 2 March 2017 (UTC)
wikimedia.de.
Oppose I oppose the deprecation of 