We should absolutely not use hard redirects. fukyo could easily be a word in another language, and aren't other languages besides Standard Japanese (e.g. Ryukyuan languages) also written in hiragana? If so, then ふきょ could potentially also be a word in another language. And while fukyo/ふきょ may have only one kanji reading, consider cases like fu/ふ where there are five different associated kanji. —Mahāgaja (formerly Angr) · talk21:28, 2 December 2017 (UTC)[reply]
Absolutely NOT! Rōmaji entries link to kana readings - usually one but can be a few. The kana entry (hiragana and katakana) serves as a disambiguation page, it can link to a large number of kanji entries. kōsō -> こうそう(kōsō). Please read the policy on Japanese entries in WT:AJA and stop messing around. @Eirikr, TAKASUGI Shinji. --Anatoli T.(обсудить/вклад)13:26, 3 December 2017 (UTC)[reply]
Actually one should mithe to access the Roman transcriptions in the first place, isn’t it? Probably you should learn to use an IME. But it displays the true state of things if one has to click twice if one uses a transcription of a transcription.
The problem is that there's no guarantee that someone won't add more kanji for the pronunciation, and if they only add them to one or the other, but not both, the pages go out of synch. It's hard enough to get all the readings reflected where they should be without requiring updating of another page every time. Like many of Backinstadium's ideas, this is based on the premise that the dictionary is a finite, finished product that merely needs to be rearranged, rather than a dynamic entity that's constantly being edited by people who don't know what anyone else is doing on other pages. Chuck Entz (talk) 16:01, 3 December 2017 (UTC)[reply]
@Chuck Entz, Atitarev: I was told in past discussions, I think about the Simplified/Traditional redirect issue, that it was the structure used for the wikis the one that limited the implementation (in your example just sinchronizing two pages). Secondly, I've never thoutht of a lexicographic resource as a finished product; rather I prioritize enhancing the user experience, especially for beginners, even if that means extra work. --Backinstadiums (talk) 17:21, 3 December 2017 (UTC)[reply]
Dude, just compare the time you have talked here with the time lost by this disenhancement of you having to click twice. The editing work needed for the enhancement is completely disproportionate to the enhancement gained: Either editors would have to check for rearrangements constantly or complicated templates would have to be used on the Hiragana pages whereby the Romaji pages would autofetch the Chinese. It is better to create some new entries. Palaestrator verborum (loquier) 17:32, 3 December 2017 (UTC)[reply]
We currently only have one entry for the Hlai language, which is nom³. This entry is in some sort of IPA. However, Hlai does have a written language in the Latin script, based on Ha. Should we move nom³ to noms, based on the newest orthography (2005)? — justin(r)leung{ (t...) | c=› }22:01, 2 December 2017 (UTC)[reply]
Yes, definitely. -sche has created many such entries, usually basing the orthography on whatever linguistic materials they have access to. Whenever I come across these and they need to be moved to an orthography that's actually used, I fix the entry (and the translation at water#Translations) and create a short about page that documents the orthography I have selected. —Μετάknowledgediscuss/deeds22:10, 2 December 2017 (UTC)[reply]
Yes, thank you! :) I try to find if there is any standard orthography for each language (at the time I create the entry and in periodic re-checks of previously-created entries), but sometimes I can't find any. For Hlai, searching for a standard orthography was complicated by the fact Hlai has many varieties. - -sche(discuss)02:54, 4 December 2017 (UTC)[reply]
@-sche It is certainly an issue that Hlai has many varieties. With the standard orthography, I'm not sure how the various dialectal differences can be shown. On a related note, I've also noticed that you have also created "water" entries for different varieties of Zhuang using IPA. Should these all be deleted, since most of our Zhuang coverage doesn't distinguish between dialects? The same issue occurs here with Zhuang, where I'm not sure how the standard orthography can be used to represent varieties other than the the standard register and the Wuming dialect. — justin(r)leung{ (t...) | c=› }04:39, 6 December 2017 (UTC)[reply]
Are the varieties of Zhuang so similar that they should not be considered separate languages, i.e. we should retire the separate codes we currently have for them? (WT:LT says as much, but there does not appear to have been any discussion of it — if you can confirm that we should treat Zhuang as one language, we can add a link on WT:LT to this discussion.) In that case, the entries we currently have, to the extent they show that e.g. Yang Zhuang uses ham⁴, could be migrated into the ===Pronunciation=== section of the "standard Zhuang" term, it would seem to me. Whereas if the varieties should be considered separate languages and the problem is just that only one has a standard orthography, it seems like a tolerable interim solution to leave the others at the best orthography we have access to, even if that is an IPA-ish orthography. - -sche(discuss)00:20, 7 December 2017 (UTC)[reply]
@-sche: Traditionally, these varieties were considered to be one language by the Chinese government (since they are grouped under the Zhuang ethnicity). I think situation is similar to Arabic or even Chinese, where the varieties have very limited to no mutual intelligibility but speakers generally think they are speaking the same language. That is why there is only one standard for all these varieties. See these two files for more information: [1][2] — justin(r)leung{ (t...) | c=› }02:21, 7 December 2017 (UTC)[reply]
@Justinrleung: I'm sorry for the late reply. As long as the dialectal differences (at least, the ones we already have, i.e. the dialectal pronunciations we currently have entries for) can be preserved / presented, like they are for Chinese, I don't see a problem with merging the Zhuang varieties, if that is how they are usually treated. (WT:LT already says to do that.) The entries we currently have could be migrated into the pronunciation sections of the "standard" Zhuang entries, as I have done with "water". - -sche(discuss)19:58, 18 January 2018 (UTC)[reply]
A lot of the space in the edit tools is taken up by precomposed characters like á, ē, ằ, ѝ etc. These aren't actually needed on Wiktionary, because the software automatically converts everything to composed normal form whenever you save a page. It would be perfectly fine if you entered a regular letter a followed by a combining acute accent, the end result is exactly the same. So I propose removing these precomposed characters from the edit tools, and instead making a special tab with all combining diacritics. That would give a lot more flexibility and allow editors to enter combinations that were not previously possible. —Rua (mew) 13:16, 3 December 2017 (UTC)[reply]
the software automatically converts everything to composed normal form whenever you save a page – that’s important information, because the upcoming IPA keyboard layout heavily relies on combining characters. I thought before that maybe I have to use precomposed characters.
As for me, the whole bar can be disabled, as all is accessible via dead keys and the compose table and appropriate keyboard layouts or direct Unicode input and charmaps. A web table under an editing area for such seems like a relict from 2004 and a very lame way of input, also the selection is arbitrary, like Ð ð but not Đ đ; dictionary editors can be expected to use appropriate input methods. Or @Anglish4699, do you need that bar?
For myself at least, I have never used that bottom tool bar, but I have used the top one above the edit workspace. That one does come in handy much of the time. I would not be against the more flexible diacritic table (as that may be more helpful to others), but I think more input from the users is needed here. Anglish4699 (talk) 20:26, 3 December 2017 (UTC)[reply]
I used to use the Greek menu, but now I use the template {{chars}}. I still sometimes use the menu for non-Greek characters, though.
I don't know if I've ever used the "Special characters" menu on top. It groups things by Unicode block (I guess), which is somewhat less helpful for scripts such as Greek that are located in multiple blocks, and it doesn't contain all the characters that I would want to type (for instance, punctuation-type characters such as §, ’, ◌). — Eru·tuon20:55, 3 December 2017 (UTC)[reply]
Template:neutral I'd like to see a simulation. Will inserting combining characters work on virtually all the systems that people are using to edit Wiktionary? Especially with monospace fonts in the edit box, I'm not sure if the combining characters will show up correctly on many systems. I find the box quite useful, however.--Prosfilaes (talk) 11:44, 5 December 2017 (UTC)[reply]
They may not appear exactly right in the edit box, but that should go away once you save the page. It might even go away just by previewing the page, but someone will have to test that. —Rua (mew) 15:23, 5 December 2017 (UTC)[reply]
Yes, when I enter a + ◌́ (U+301, acute accent, minus the dotted circle) and press "show preview", this sequence changes to á (U+E1, Latin small letter a with acute) in the text box. — Eru·tuon19:16, 5 December 2017 (UTC)[reply]
I would support some combining characters being removed. That is, when the menu is not for an orthography in which letter + combining character is considered a letter. For example, I think it would be an improvement if the Vietnamese menu gave the letters ă, â, ê, ô, ơ, ư as precombined characters, but listed the tones ◌̀, ◌̉, ◌̃, ◌́, ◌̣ as combining characters. And perhaps the Arabic menu should list the diacriticked letters that are used to transliterate Arabic consonants, but it should give a combining acute accent instead of vowel + acute combinations. (Either that or the acute accent should be removed.) The rationale is that the tonal diacritics and acute accent are separable symbols that represent a phonemic or phonetic unit in themselves, while the other diacritics do not represent a unit in themselves, but only in combination with a letter. — Eru·tuon21:26, 5 December 2017 (UTC)[reply]
But for "Latin", everything is a diacritic. I don't think this is a particularly meaningful distinction. The point of the change is to make it easier for people to use diacritics and not having a list of precomposed characters. If everyone and their dog wants their own custom set of "letters" in the menu, then it defeats the point entirely. —Rua (mew) 21:35, 5 December 2017 (UTC)[reply]
Vietnamese is written in the Latin script. None of the precomposed characters in its menu are needed, all can be created with combining diacritics. —Rua (mew) 21:48, 5 December 2017 (UTC)[reply]
Of course, but it's less convenient to select from a huge long list of diacritics (which are in a difficult-to-understand order) than from a short list of diacritics or letter–diacritic combinations used in a particular orthographical system. — Eru·tuon21:55, 5 December 2017 (UTC)[reply]
When visually similar diacritics are involved, it might help to have a menu specific to an orthographical system. Some people confuse háček or breve, circumflex or inverted breve, ogonek or cedilla or comma. Then again, we do not have a menu for every orthography that uses some of these diacritics and I'm not really arguing for that. And they would probably be confused by a minority among active contributors. — Eru·tuon22:10, 5 December 2017 (UTC)[reply]
I've included Unicode names and codepoints in the title text of the new diacritics submenu. That will hopefully help people decide which is the right one. —Rua (mew) 22:17, 5 December 2017 (UTC)[reply]
All these confusions are a reason why such a menu should not exist at all 😒. If you use Gucharmap or Fcitx Unicode Input you see more information about the characters you try to give in, and these application also update their data without manual intervention by a Wiktionary coder. Perhaps we should just disable the menu entirely for some time and look who complains. If it goes unnoticed, you’ll can rub your hands because you have less bothering and a new argument for that bug being fixed.
But as this extreme step will not be performed, it slowly becomes more desirable that that bug be fixed. There isn’t a specific script that I can block with uBlock Origin, I can only hide the bar with the element picker. Palaestrator verborum (loquier) 23:55, 5 December 2017 (UTC)[reply]
Because not everyone is using a Linux box with xkbconfig and without Gnome IBus overriding all other keyboard interfaces and ignoring ~/.XCompose configurability as too hard. And sometimes people need to use a character that's not in the keyboards they have configured, or for which they haven't memorised the <dead_circumflex><compose><shift><hyphen><j> dance to get ʲ. If you want "It works for me therefore everyone else is doing it wrong", you know where to find systemd. This "extreme step" of removing alternate and accessible ways of entering characters beyond 7-bit ASCII will not be performed because it is arrogant and wrong-headed. --Catsidhe(verba, facta)01:36, 6 December 2017 (UTC)[reply]
Well the first step was already done, making a separate section with only combining and spacing modifiers. I would like to know what people's experiences are with this. —Rua (mew) 17:51, 26 January 2018 (UTC)[reply]
I find the combining characters a little hard to click because they are seated on a space. The space is the character that is clickable, but sometimes the combining character, which is visible, is on the right edge of the space, so that the hitbox (so to speak) is a little off. And many of the combining characters are kind of narrow even if the hitbox isn't off. They would be easier to click if they were seated on the dotted circle (◌) instead: ̅ → ◌̅. That would require modifying MediaWiki:Edit.js so that only the combining character will be inserted. — Eru·tuon00:05, 27 January 2018 (UTC)[reply]
@Erutuon: I like that idea. Personally I was wondering if we could either use CSS to increase letter-spacing (I tried, with meh results, but maybe I'm doing it wrong) or find non-combining equivalents of all the diacritics (probably impossible) —suzukaze (t・c) 00:33, 28 January 2018 (UTC)[reply]
While working on Wikipedia I noticed that they use IABot (InternetArchiveBot)
to automatically replace dead links with a version stored on archive.org. The project
is a joint effort between the Internet Archive and the WMF (more in this
blog article).
The project has funding, is developed in the open
(github) and has already been deployed
on a few Wikipedias. As far as I know it hasn't been used on a Wiktionary instance
yet. We don't generate the same amount of external links / references as other Wikis
but I think it doesn't hurt to make sure what we have is valid and usable.
We need to establish a consensus first so I'd like to get your opinions. – Jberkel (talk) 10:25, 4 December 2017 (UTC)[reply]
I like this idea. I would also like it if we had more external links, especially in areas like etymology, reconstructed languages, etc. - TheDaveRoss14:32, 4 December 2017 (UTC)[reply]
Are there any guidelines about the preferred ordering for Chinese? I cannot find any info. at About_Chinese, and after searching in Category:zh:Grammar I realized how chaotic radical ordering can be, especially when treating simplified and traditional versions individually. I would always include some (alternative) pinyin ordering, which has helped increase literacy a great deal since its implementation. --Backinstadiums (talk) 11:24, 6 December 2017 (UTC)[reply]
@Backinstadiums: There are many ways to order Chinese characters. Radical ordering is the common way before the advent of bopomofo and pinyin, and is still the common way for traditional Chinese dictionaries. In recent years, ordering by pinyin has become more common, especially in Mainland China. However, most dictionaries would also have an index ordered in alternative ways. For instance, a traditional Chinese dictionary with radical ordering often has a 難查字表 for characters whose radicals are not apparent. It may also include a pinyin/bopomofo index.
The reason why Chinese categories are ordered by radical here in Wiktionary is because Chinese is not only used for Mandarin, making pinyin/bopomofo sorting unreasonable. The categories for specific Chinese lects, e.g. CAT:Mandarin lemmas and CAT:Cantonese lemmas, are sorted according to their respective romanizations. — justin(r)leung{ (t...) | c=› }17:37, 6 December 2017 (UTC)[reply]
@Justinrleung: Except if a true semantic conversion were intended, at least traditional and simplified forms should be treated as a single unit for purposes such as ordering, (currently) the traditional one being used as common lemma. Regarding Pinyin, since nowadays it's the most used romanization (and transliteration) system regardless of one's native Chinese lect, it would be truly beneficial to add it as much as possible to spread Chinese literacy. --Backinstadiums (talk) 18:01, 6 December 2017 (UTC)[reply]
Oppose
1. Someone looking for 刘 won't find the traditional lemma of 劉 because of the drastically different number of strokes. Sort them independently to accommodate users of both.
2. Not every character has a Mandarin pronunciation. Use Category:Mandarin lemmas to search by pinyin.
One additional wrinkle is that the MediaWiki software backend appears to only allow sorting by one index key per category. Sorting a given Chinese character by each of the various possible pinyin representations would require a change in the underlying database software, one that the MW devs seem uninterested in tackling.
We've run into this issue with Japanese entries, where a given Chinese-based spelling often entails multiple phonetic realizations, and thus ideally multiple sortings -- see 柄 for instance, where we would want the entry to appear in Category:Japanese_nouns, etc., under all of these indices: え (e), かび (kabi), かい (kai), から (kara), つか (tsuka), つく (tsuku), and ほぞ (hozo). Due to how the MW software is programmed, this 柄 character only appears indexed under the last reading, hozo.
Categorizing Chinese characters separately by lect would work for indexing by pinyin reading. But categorizing Chinese characters in a single category, and trying to index by the pinyin readings for all of the lects at once within that one category, is currently barred by baked-in technical difficulties. ‑‑ Eiríkr Útlendi │Tala við mig18:38, 6 December 2017 (UTC)[reply]
I think that it may be of interest, especially for English learners, to see a compendium for words or locutions that don’t mean what they would imply. To start, we have: strawberry, Rhode Island, East River, funny bone, prairie dog, French braid, Boston cream pie and Hawaiian Pidgin (amongst many other candidates, but I don’t want to exhaust room here). I can’t think of any possible objections at the moment, though some may find the topic too trivial or too uninteresting to merit a category, but I’d like to see others’ thoughts here first. — (((Romanophile))) ♞ (contributions) 19:01, 6 December 2017 (UTC)[reply]
There will inevitably be disputes about what in particular goes into it but yes, I think that it's fine to have some listing of counter-intuitive words. It may be better suited to an appendix. —Justin (koavf)❤T☮C☺M☯19:16, 6 December 2017 (UTC)[reply]
Perhaps even single words that are used in a non-literal sense, depending on how you define "what they would imply". — Eru·tuon00:10, 7 December 2017 (UTC)[reply]
* A pidgin and a creole are technically distinct, but nobody but a linguist really cares; it's not really confusing.
* A prairie dog is a sort of dog-like creature that lives on the prairies. It's a wonder of clarity compared to the robin, which can refer to any number of distantly related species of bird.
What I'm getting at, is that it seems pretty vague and broad as a category, and given the examples you gave, I don't think it would be terribly helpful to an English learner.--Prosfilaes (talk) 09:58, 7 December 2017 (UTC)[reply]
Strawberries aren’t berries, prairie dog aren’t dogs (though all robins are at least birds), and French braids did not originate in France. Even so, I do see that it has the potential to be too big of a category unless we made up some special rules for it. — (((Romanophile))) ♞ (contributions) 03:40, 11 December 2017 (UTC)[reply]
berry, sense #1 is "A small fruit, of any one of many varieties.". Many things we call berries aren't botanical berries and some things, like grapes, that are botanical berries we don't call berries. French practically needs a definition of "fancy" (though apparently they're called tresse française in French.) Also, French doesn't necessarily mean "originated in France"; it could mean it was "popular in France" or even "associated with France". Also, cf. pineapple braid (another name for the Dutch braid or inverted French braid.) The extreme here is the "canoe wife", a name in English tabloids for a woman whose husband allegedly drowned in a canoe accident (body never found), who moved to Brazil with the insurance money and lived the good life with her husband, until she was extradited back to England for insurance fraud. Hence, "canoe wife". Adjectives have to communicate clearly to the audience, not necessarily make good literal sense.
I'd see a category of things like prairie dog, where the root word is clearly a misnomer in normal English--that is, most people would agree that a prairie dog is not a dog. That seems a reasonable enough and possibly useful category.--Prosfilaes (talk) 16:37, 11 December 2017 (UTC)[reply]
Unusual English pronunciations categorized as 1 syllable words
As part of ongoing maintenance and cleanup work, @Mahāgaja recently made this change to the Japanese 光 entry, replacing a call to {{IPAchar}} with {{l|und}} instead. This was due to the inclusion of <sub> tags in the string formerly contained by {{IPAchar}}. Talking things over with him, I understand his reasons and have no objection. (That thread is here for those interested.)
One issue that remains, however, is font formatting. {{IPAchar}} results in text at 15.4pt, while {{l|und}} produces 14pt. I could manually add in a <span> tag specifying class="IPA" to do that, but I wanted to ask first if anyone is aware of some other template that would apply a 110% font size?
(And if this query should go in the Grease Pit instead, I'm happy to move it.)
I don't know if it is correct to consider this notation IPA, even though all but the subscripted vowels at least belong to the IPA character set. Perhaps it would be better to consider it as Old Japanese text (though it is a transcription system for the actual man'yougana used to write Old Japanese), tag it as Old Japanese ({{m|ojp||...}} or {{m|ojp|...}} depending on whether there will be entries), add Latin as a script for Old Japanese in Module:languages/data3/o, and assign the desired styles to Old Japanese written with Latin script in MediaWiki:Common.css? — Eru·tuon22:59, 7 December 2017 (UTC)[reply]
Apologies, I'm not married to the idea of IPA-ness at all -- I merely want the text to appear in the same font and at the same scaling as the /slash-transcription phonemic string/ IPA text that follows it on the same line. The w:International Phonetic Alphabet article describes using ⟨angle brackets⟩ for non-/phonemic/ and non-[phonetic] transcriptions meant to indicate the ⟨original-language orthography⟩, which would seem to make sense for Old Japanese strings like this with the numeric subscripts -- but as Mahāgaja argued, we probably don't want to use {{IPAchar}} for angle-bracket orthographic strings (which makes sense to me).
What are these pronunciations? What system do they follow? Does that system have a name? What symbols can and can't appear in them? If there are multiple answers to these questions multiple templates should be created. DTLHS (talk) 00:53, 8 December 2017 (UTC)[reply]
@DTLHS: One system, symbols used would be a subset of ASCII lower-case letters, whitespace, and subscripted 1 and 2 to indicate differences apparent in w:Jōdai Tokushu Kanazukai and apparently indicating phonemic differences lost in the Japanese language during the w:Heian period (roughly the 900s-1000s CE).
Not sure why we'd need multiple templates; all I need is something that formats the font, and that is ideally more elegant in the wikicode than <span class="IPA">using raw HTML</span>.
You may only need something that formats the font, but other people may appreciate knowing explicitly how some string of symbols is to be interpreted and what its source is. DTLHS (talk) 01:11, 8 December 2017 (UTC)[reply]
I'm pretty sure that {{IPA}} and {{IPAchar}} and other pronunciation templates are the only ones add the IPA class. But once again, I do not think it is correct to label this transcription IPA. It would be better to tag it as Old Japanese written in the Latin script, and to apply the desired styles to that language–script combination. — Eru·tuon01:27, 8 December 2017 (UTC)[reply]
I realize I've confused the issue. I'm happy using some other class -- class="IPA" just happens to be the only one I know of right now that I'm sure applies the font styling I want. Looking at the rendered HTML in Chrome's "Inspect" view, I don't think this CSS class does anything to label the text as IPA: it just sets font and line height styling. I have no interest in labeling the romanized OJP text as IPA; Mahāgaja's arguments against doing so have already convinced me of that. :) My reservation about using something like {{m|ojp|...}} is that, in my specific use case (including romanized OJP to show phonetic development through to modern JA, as at 光#Japanese), I want the font to match the IPA strings that immediately follow on the same line, and this font configuration might not be the ideal for other use cases. ‑‑ Eiríkr Útlendi │Tala við mig20:07, 8 December 2017 (UTC)[reply]
@Eirikr: It should be fine to assign an IPA-like style to {{m|ojp|<Latin text>}} if this is the only Latin-script orthography or transcription system for Old Japanese that will be used on Wiktionary. Then, the combination of lang="ojp" and class="Latn" can be given the style you desire in MediaWiki:Common.css, with no conflict. It occurs to me that a transliteration in {{m|ojp|<man'yougana>|tr=<Latin text>}} would have this combination of language and script. But it would be easy to select ojp transliterations in the CSS and disable the styles for them, if necessary. — Eru·tuon06:49, 21 December 2017 (UTC)[reply]
I’d support the creation of such a template; it’s also needed for Egyptian entries like tꜣwj, where the reconstructed pronunciation is generally IPA but also includes a wildcard V for unreconstructible vowels. — Vorziblix (talk · contribs) 14:44, 11 December 2017 (UTC)[reply]
Actually, the error messages seem to suggest IPAchar is complaining about the numbers, not the HTML: invalid IPA characters (1). —suzukaze (t・c) 00:36, 8 December 2017 (UTC)[reply]
For reasons of both aesthetics and consistency, I'd rather this ojp transliteration used the Unicode subscript numerals ₁ and ₂ rather than normal 1 and 2 with subscript markup, but since ₁ and ₂ are also not valid IPA characters, doing so won't solve the immediate problem. —Mahāgaja (formerly Angr) · talk13:27, 8 December 2017 (UTC)[reply]
Hmmm, I find that the Unicode subscripts are too small -- I have trouble seeing them clearly, and my eyes aren't that bad. I also find they scan less well -- 1 extends below the line somewhat, thereby standing out better, whereas ₁ is mostly within the line of the text and thus (in my opinion) too unobtrusive. Either way though, as you note, we need to find something other than {{IPAchar}}. ‑‑ Eiríkr Útlendi │Tala við mig20:07, 8 December 2017 (UTC)[reply]
@Eirikr: By chance I was reading Unicode subscripts and superscripts on Wikipedia. Apparently most fonts design the superscripts and subscripts for use in fractions, making them too small to be used for their intended purpose, chemical and mathematical formulas (and transcription systems). — Eru·tuon06:53, 21 December 2017 (UTC)[reply]
@Erutuon: Ya, that page also has an informative image showing layout lines and where the different glyphs should ideally fall -- with superscript and subscript clearly extending beyond the cap line or baseline, while the fraction figures stay within those bounds. It seems the font used for Wiktionary is guilty of this same flaw, using fraction glyphs for the superscript (Unicode glyph vs. sup-taggged: ¹ 1) and subscript (Unicode glyph sub-tagged: ₂ 2). For others reading this thread, one key quote from the WP article:
Most fonts that include these characters design them for mathematical numerator and denominator glyphs, which are smaller than normal characters but are aligned with the cap line and the baseline, respectively. When used with the solidus, these glyphs are useful for making arbitrary diagonal fractions (similar to the ½ glyph).
This was not the intended use of these characters when Unicode was designed. The intended use was to allow chemical and algebra formulas to be written without markup. Proper appearance of these requires true superscript and subscript. H2O with subscript markup may look better than with a Unicode subscript (H₂O) in a font that has repurposed the Unicode subscripts for fractions.
You are focusing too much on the details. It's great that you are looking up reference phonetic material on the pronunciation of Mandarin, but as a learner of Mandarin, please bear in mind that the '3-3 → 2-3' tone sandhi in Mandarin is a natural process that even native speakers may not be able to notice or characterise. For '3-3' words with non-obligatory toneless second syllables, there is nothing that will make you un-understandable by pronouncing the tones clearly without sandhi. In fact, if your tones are accurate (which is absolutely paramount for learners), pronouncing the words 小姐 and 表姐 slowly and clearly, without sandhi, will give the unfamiliar listener the impression that you are a learned speaker. The sandhi will come naturally when you have become sufficiently familiar with pronouncing full '3-3' sequences such as 表姐; it should not precede the latter. Actually, intentionally pronouncing '3-3' as '2-3' as a learner would lead to confusions. e.g. 網友 could be understood as 王友, especially considering that learners generally tend to enunciate the syllables very slowly. When the second syllable of a '3-3' sequence is optionally reduced, both the 3-3 and 2-3 forms can be weakened, resulting in 3-· and 2-·, the former used in careful speech and the latter in fast speech. In normal speech it is probably somewhere in between the two. I don't really think it needs to be further explained- learners should try to use the unreduced pronunciations unless the word is obligatorily toneless like 姐姐. Plus please avoid the word 小姐 altogether because of its negative connotations. Wyang (talk) 14:03, 8 December 2017 (UTC)[reply]
Sometimes there are matters that strongly affect the user experience, and it would be valuable to ask the ordinary users what they want. I therefore propose that we implement an option to hold public polls, which are shown to all users who visit Wiktionary, whether logged in or not. In these polls, we would ask simple questions such as "which layout do you prefer" or "do you think this feature is valuable". There would be a maximum of one public poll at a time, and they would run for a duration of two months (subject to discussion of course). Starting a public poll should not require majority consensus, to prevent reactionary users from sabotaging the process.
But a poll is quite different. It would involve saving people's answers somewhere, and also remembering who voted. —Rua (mew) 23:14, 8 December 2017 (UTC)[reply]
Are you suggesting that the poll be in the header? I am suggesting that the site notice have a link to a poll and that is documented elsewhere. —Justin (koavf)❤T☮C☺M☯23:42, 8 December 2017 (UTC)[reply]
Hmm. I figured that the poll would be directly located on the page somewhere, like in the bar on the left. That way users can just click their option without being taken away from where they want to be. —Rua (mew) 23:57, 8 December 2017 (UTC)[reply]
Ah. I see what you mean now. MediaWiki can certainly have polls and record user answers--e.g. see Wikia. Not sure if it's desirable or if we want some barrier to entry of some kind but it's definitely possible. —Justin (koavf)❤T☮C☺M☯00:04, 9 December 2017 (UTC)[reply]
Good idea. Probably the best we can do and still continue to bend over backward to convey the idea that WMF projects respect and guard user privacy. Would we limit participation to registered users? Would a checkuser be available and willing to make sure there wasn't sock-puppetry skewing the results?
"Majority consensus" conflates two decision principles. Consensus usually means well more than a simple majority. In practice, we have had various levels for "consensus" here, varying over time and across types of decisions. I would think that a simple majority would suffice for something like this. We could start with no vote required and see how it goes. DCDuring (talk) 15:35, 9 December 2017 (UTC)[reply]
I don't know if this has been discussed already but why do so many of the quotes for English terms have to reference very vulgar or obscene sexual material, often from homosexual novels and the like? Is this just meant to be provocative and "edgy" for the sake of it, or to show that it's okay and normal, or to push the envelope? Is it part of some agenda? Is it some statement about the nature of this site being one where people can freely contribute? I don't get it. Not that I have anything against homosexuality but some of these passages (equally including those that reference straight interactions) are a bit much for people to read if they're just casually looking at a dictionary, and I feel it may make some people take Wiktionary less seriously, making it rather juvenile and akin to something like Urban Dictionary. Word dewd544 (talk) 04:50, 9 December 2017 (UTC)[reply]
In some cases Wonderfool has added this kind of thing for a joke (e.g. the erotic passages from Fanny Hill, and I remember a news article about a kitten being microwaved). In other cases (slang) some words just tend to appear in these contexts. I try to favour "neutral"-feeling citations where possible. Equinox◑04:55, 9 December 2017 (UTC)[reply]
I definitely think we should give a strong preference for non-shocking quotations (cf. w:en:WP:EGG). There is no reason for vulgar or graphic quotations for words other than vulgar and graphic ones. —Justin (koavf)❤T☮C☺M☯05:00, 9 December 2017 (UTC)[reply]
It might be worth saying: we're not a corpus, and we don't have an obligation to keep any particular quote if it can be replaced and if it's not notable in some way, like the first known usage of a word. DTLHS (talk) 05:01, 9 December 2017 (UTC)[reply]
Vulgarity seems to cast too wide a net. To clarify what I imagine is the intent: Don't we mean "obscene", "disgusting", and/or "not suitable for small children"? I've felt and mostly repressed the urge to remove such quotes.
A problem arises with certain polysemous terms which have many ordinary definitions but some that are disgusting or luridly sexual. For such problematic definitions a practice of not having any usage examples (which display by default) and no excessively disgusting citations (which are hidden by default) might suffice. DCDuring (talk) 15:50, 9 December 2017 (UTC)[reply]
I could add much more vulgar quotes as I use to hear rap music, like I have done on dog bone.
I think the general solution is to move quotations to citation pages – I don’t want a moral cleansing to be started because “we don't have an obligation to keep any particular quote”. Do not be a puritan. Sexual references form a great part of what people talk and have useful subtile differences. The measurement line might be: A reference should not be moved because of being boorish, but if it is contra bonos mores, as would be enough for a contract to be void. Palaestrator verborum (loquier) 16:37, 9 December 2017 (UTC)[reply]
Ah yes, wrapping oneself in the flag of free expression. I think we lavish much more attention on some "subtle" differences for sexual terms than on, say, those involving a word like, say, seem. I suspect that the entire reason for the differential attention is a differential in hormonal response within the contributors to the prospect of working on the two types on entries. I rather doubt that any consideration of the users of an entry, especially those of an age different from the contributor becomes involved. DCDuring (talk) 18:23, 9 December 2017 (UTC)[reply]
I am not sure what you mean with those hormonal responses and with the “free expression”. If I hear rap music I, I add quotes from rap music, and users who hear Pop add Pop music quotes. The former is even more valuable because there are the gaps of Wiktionary whilst there is else hardly an English word found not in Wiktionary (consider Grime or Drill with Multicultural London English). But I am not free to change what music pleases me and I doubt that you know much about how hormones lead the editing habits of Wiktionarians. And what I am particularly not free in is to choose the sources which I stumble upon. Better give that durable quote for dog bone than to leave it out because some people are more sensitive and there could be a less edgy one. There should be more cases when people should be thankful for seeing the quote than pitying themselves for having endeavored to read it – and disgust can also be mixed with thankfulness for having read an example. That is another way how you could discriminate the cases considering the user. Palaestrator verborum (loquier) 22:31, 9 December 2017 (UTC)[reply]
I also dislike censorship but I think the point here is to avoid vulgarity if it is unnecessary, e.g. when citing an everyday word like "umbrella". Equinox◑06:22, 10 December 2017 (UTC)[reply]
Sorry, I meant excessive obscenity rather than vulgarity. That more accurately describes what I'm getting at here. I actually had a feeling much of it was part of some kind of practical joke by some user a while ago and then no one really bothered to change them. It doesn't really bother me that much personally (in fact I'm far from puritanical in my daily life and don't hesitate to use some of this language) but I could see how that would annoy some people and draw them away from the project. It almost seems like some of the editors were purposely going for shock value. I could also invoke the whole "not safe for work and not safe for kids" thing, but realistically, it's hard to keep kids away from seeing certain kinds of content online. And yes, of course words that are meant to be obscene by definition would obviously have these kinds of quotes, but I do recall coming across several where it was uncalled for. I'll have to go and find some specific examples. And I also get that there is freedom of speech, which is perfectly fine, but this is still a user-modified project, like Wikipedia, one in which a consensus of informed people generally decide on what ends up being presented. Word dewd544 (talk) 07:06, 12 December 2017 (UTC)[reply]
Doubt about recent Persian, Middle Persian, Yaghnobi, Tajiki and Arabic entries and edits
@Kaixinguo~enwiktionary Me too, even though I don't speak Persian, Hindi entries need good Persian entries for etymology. I think @Rajkiandris should explain himself, since he has added thousands of Yaghnobi, Tajik, and Persian stubs with incorrect formatting and etymologies, and now he doesn't respond to queries on his talk page. Some of his edits are, frankly, totally wrong.
So what are you worried about in Arabic entries? The increase in quality I have felt for Arabic since I have registered two months ago has been according to my gut-feel 30%. I have always patrolled the edits in Arabic, corrected the template usage (even added and edit reference templates), added many good etymologies (see ت ر ج م(t r j m), this has not been seen before), removed the {{etyl}} completely from it, emptied Category:Arabic entries needing vocalization (though this some random IP did too), Category:Arabic terms needing Arabic script, Category:Arabic form-I verbs with missing non-past vowel in headword, and added about 400 additional entries of high quality belonging to the 9200 in Category:Arabic lemmas now, and almost 200 quotes with translations, and a significant number of images. I use all sources available and as a rule add only words I read.
I had on that occasion also cleaned up some Persian etymologies. Today you have changed the transcriptions of the Persian in إِبْرِيق(ʔibrīq) and its reborrowed descendant ابریق but I have only copied the transcription of the Persian word as it was found before, this plays surely a role in that you talk here now. I don’t know Persian to say what transcriptions are good and Wiktionary:About Persian#Transliteration does not say anything meaningful about it. Perhaps you should mention the minimum standards in it. I have just three days ago cleaned it up from some instructions that were wrong, and I have much improved Wiktionary:About Arabic. Also, who will clean up {{etyl}} in Persian? Now I have removed it from Arabic it can’t be used anymore, but Persian? You seemingly refer to edits Rajkiandris (talk • contribs) but I have not seen him adding Arabic. @Kaixinguo~enwiktionaryPalaestrator verborum (loquier) 22:55, 9 December 2017 (UTC)[reply]
I'm not referring to those romanisations; that kind of thing happens all the time. No one can monitor everything that's going on, perhaps it was wrong to include Arabic. I'm just talking about a general impression. I am sorry if I have given you the impression that I am referring to you. Kaixinguo~enwiktionary (talk) 23:26, 9 December 2017 (UTC)[reply]
Ok, I let it go, but your submission is still underspecified. I don’t know what you want people to do. People probably prefer not to extract the notions you know but others don’t. You won’t get sudden contributors proficient in those languages who will perform some thorough reviews of the language treatment. Palaestrator verborum (loquier) 00:06, 10 December 2017 (UTC)[reply]
@Atitarev: See User talk:Rajkiandris and Special:Contribs/Rajkiandris. While most of the entries and edits don't have wrong definitions per se, the quality of edits is not up to par (not using templates, wrong Proto-Iranian reconstructions, incorrect sorting of descendants, no transliterations for Middle Persian, etc.). Combined with the massive volume of edits that (s)he has done, the overall quality of Yaghnobi and Tajik entries especially has deteriorated. Also, much like Gfarnab, they edit in languages that don't even know anything about; I had to revert a dozen Konkani entries of his a while ago. —AryamanA(मुझसे बात करें • योगदान)00:33, 10 December 2017 (UTC)[reply]
We should require @Rajkiandris to proffer some quotations with translations in Yaghnobi or at least Tajik where he should find enough – I mean, speaking to @Rajkiandris, you should add quotes with translations. If you do, you can affirm an impression of knowledge of these languages; if not, it is also good, for Wiktionary, because it only increases the notion that you only copy linguistic material without sufficient exposal to the language itself, and we can ostracize you. So add quotes if you want to be taken seriously and your entries to have a long life. For now it is in the realm of the possible that “created by Rajkiandris” will be an argument in itself in proposals for deletion. Palaestrator verborum (loquier) 01:34, 10 December 2017 (UTC)[reply]
Synonyms under corresponding senses - stop of switching
In Wiktionary:Beer_parlour/2017/May#Poll: putting "nyms" directly under definition lines, there is a preliminary consensus for using a new synonym format but only under the condition that the synonyms become hidden, meaning collapsible. There is not consensus, not even a supermajority, for non-collapsible synonyms under corresponding senses. An example entry that I think currently looks horrible due to the new format is cat.
I agree with cat looking horrible. However it would not be a solution to use the synonyms section. It looks bad too and would look worse without {{syn}}. This template kin need fixed. And before a hiding can be made, it would work out well to decrease font-weight and font-size. But {{sense}} + synonyms looks worse than {{syn}} with arguments does.
If I apply the arguments consequently, I reason that we should not list synonyms at all in pages as long as they are not hidden in the Thesaurus namespace or in a drop-down menu. Thesauri are else separate products from dictionaries that are not included even in the greatest dictionaries. Palaestrator verborum (loquier) 15:29, 10 December 2017 (UTC)[reply]
What’s so complicated? Currently both the synonyms section and {{syn}} look bad. If these things are hidden, they look better. Thus there is an argument for not adding synonyms at all as long as {{syn}} is not fixed (for one does not make a Thesaurus entry for all things either). Which does not mean that other reasons – the usefulness – outweigh the aesthetic argument leading to the conclusion to use a synonym section or {{syn}} anyway. Palaestrator verborum (loquier) 15:57, 10 December 2017 (UTC)[reply]
Re. "Thus there is an argument for not adding synonyms at all as long as syn is not fixed:" There is no such argument. I am not proposing to stop adding synonyms. I am proposing to continue the original practice of adding synonyms to their dedicated sections, as still codified in WT:ELE. I am proposing that all switching should stop until collapsibity is implemented, consistent with the referenced poll. I said these things above. --Dan Polansky (talk) 16:02, 10 December 2017 (UTC)[reply]
Help me test nym-hiding by adding the following line to your custom javascripts:
Yes, I think that these are reborrowings. The word reborrowing presupposes the identity of the language, because the prefix “re” signifies retreat to a state the subject had, i. e. when it existed as such. So words which English has from the Latin spoken in Gallia cannot be reborrowings because French does not represent the successor of Latin; but if Old English has taken a word from Old French it can be a reborrowing, because French represents the successor of Old French (the people then thought of Old French as French, it has the same identity, though we shall see it ex post) – not relevant if English is the sole successor of Old English –, and words which Indo-European has borrowed from Proto-Semitic cannot be “reborrowed” by Arabic. Palaestrator verborum (loquier) 22:26, 10 December 2017 (UTC)[reply]
That argument makes no sense. There is no notion of successors with languages the way there is with countries. Basing it only on the name is unlinguistic. There is nothing that entitles French to more than say, Walloon. Both are linguistically descendants of the same language. —Rua (mew) 23:00, 10 December 2017 (UTC)[reply]
Which illustrates the difficulty of deciding what is the same language and what isn't. Proto-Italic was passed on from parent to child in an unbroken chain from about 3500 years ago to today. It picked up some changes along the way, so that the current language looks very different from the language of 3500 years ago. There is no point in any of this time where speakers started speaking another language. Our modern way of splitting things into stages and dialects and languages is completely arbitrary. And with this, the concept of a reborrowing is also fuzzy and arbitrary. I would consider borrowing of any PIE term from one PIE language into another PIE language a reborrowing. After all, the word once existed in the history of the borrowing language, and now it is entering the language also from another source. Thus, I would call genus a reborrowing, since this word once existed natively in the history of English too. —Rua (mew) 14:18, 15 December 2017 (UTC)[reply]
There's also the option of temporarily giving your account a flood flag, though you're certainly experienced and responsible enough to have AWB enabled. Chuck Entz (talk) 04:02, 13 December 2017 (UTC)[reply]
Can and should we document these? I feel like Sully should link to Sullivan in some way, but I don't know how I'd format it. We have Murph (Murphy) as a diminutive surname, but every example I think of is (I believe) a distinctly masculine nickname. There's also Coop (Cooper), Murr (Murray), and probably a handful more. Ultimateria (talk) 19:30, 14 December 2017 (UTC)[reply]
In my experience, it's simply more common for guys to use other guys' last names as a nickname than it is for girls/women to do so, or for men to call women by their surnames. That might be where the perception that they are masculine nicknames comes from, and it may well be that it's unusual for a female to be called Murp or Coop. (An example from my personal experience: I was often called Sheeds or Sheedster during my early teens, but it's hard to imagine my sisters receiving the same nickname.) Andrew Sheedy (talk) 15:13, 18 December 2017 (UTC)[reply]
Less common, perhaps, but it does happen. In Roman Holiday, Audrey Hepburn's character introduces herself as Anya Smith, and Gregory Peck's character calls her "Smitty". It happens in real life too, of course. —Mahāgaja (formerly Angr) · talk16:21, 18 December 2017 (UTC)[reply]
"from en.wiktionary.org (Terms of Use)" at the bottom of the main page
I could well make use of it. For many culture languages it is a sport to replace foreign intruders with native coinages. For German, one can ascribe many words to the Fruitbearing Society, specifically Philipp von Zesen, not few to Joachim Heinrich Campe, and I know Eduard Engel (Germany’s foremost, most thorough purist) well to know that he has invented a word when I read him. Many words in the administrative area also have been invented by the legislator, basic ones like volljährig (earlier they said mayorenn, Mayorennität). It is surely also useful for Turkish, where coinages have been made after the fall of the Ottoman Empire to go back to Turkish, but others can tell you more about it. One just has to think to which entities one can ascribe words. German legislator, Hessian legislator etc. seems to be working, as one hardly ever finds out the one official who invented it. Palaestrator verborum (loquier) 08:18, 15 December 2017 (UTC)[reply]
As for German coinages, they aren't rarelly attributed to wrong persons or are attributed to different persons. E.g. Mundart (for Latin dialectus) is sometimes attributed to Zesen and sometimes to Schottel; and Gesichtserker created by anti-purists is incorrectly attributed to various purists like Zesen or Campe. Making secondary sources (where some people, especially linguists, write about older coinages or purism) mandatory wouldn't be enough to prevent such misattributions. Making primary sources (where e.g. Zesen, Schottel or Campe used or mentioned a word) mandatory would reduce misattributions, but wouldn't proof who coined it and would only proof that the person used/mentioned it (while others could have used/mentioned it before him). Additionally, there could be the problem that the coiner didn't use the term. For example the coiner could have made a word list which only has mentionings. The etymology section should than have a line like "Coined by Person A in Year X and first used by Person B in Year-(X+y)". -84.161.40.4915:45, 15 December 2017 (UTC)[reply]
This is nothing more of a problem than etymologies usually are; it is even better than the probability jugglery that has to be practised with ancient languages and is often really wild but necessary (consider the lack of resources mentioned in Wiktionary:About Arabic). And your examples even confirm that it is feasible to attribute words to coiners, as it is a well and long known misattribution that von Zesen invented Gesichtserker. Palaestrator verborum (loquier) 15:59, 15 December 2017 (UTC)[reply]
It's often more of a problem. It's easy to see that Mundart is Mund + Art and that it translates Latin dialectus. But to find out who coined it and when isn't so easy. Gesichtserker is still sometimes attributed to Zesen (even by linguists), and even if it were universally known that he didn't coin it, what about the attribution to Campe? -84.161.18.9315:05, 16 December 2017 (UTC)[reply]
I meant to create a template for this a year ago but forgot all about it. I think it would be a good idea to add a parameter that would block categorization in cases where the entity coined only a single term. Crom daba (talk) 16:16, 15 December 2017 (UTC)[reply]
Seems a good idea. We may need to define what we mean by "coinage" in one of the glossary appendices (if we don't already), to ensure it's used properly. Equinox◑13:29, 16 December 2017 (UTC)[reply]
I believe we need some kind of general guideline or policy on how to treat the titles of works in citation. It is insane to me that in some cases they are three or four lines long, much longer than the actual sentence being cited. I think we should be saying, for instance, "1722, Daniel Defoe, A Journal of the Plague Year, London: E Nutt, p. 247" – but that work is currently being given as follows:
1722, [Daniel Defoe], A Journal of the Plague Year: Being Observations or Memorials, of the Most Remarkable Occurrences, as well Publick as Private, which Happened in London during the Last Great Visitation in 1665. Written by a Citizen who Continued all the while in London. Never Made Publick before, London: Printed for E[lizabeth] Nutt at the Royal-Exchange; J. Roberts in Warwick-Lane; A. Dodd without Temple-Bar; and J. Graves in St. James's-street, OCLC 745119358, page 247:
I have been trimming many of these as and when I come across them, but I am just getting reverted so perhaps we can decide – for instance – to cite works in most cases "without subtitles", or to specify that saying "printed for" is unnecessary, or in some other way to codify what I would have thought was a common sense idea of how to present the key information. Or alternatively to clarify if the current approach is what the community wants. Ƿidsiþ12:27, 16 December 2017 (UTC)[reply]
Sometimes the subtitle is short and useful, for disambiguation or to suggest what kind of work is being cited. I generally try to use the WP title of the work if there is a WP article. I also skip many of the publication details, including only enough to sufficiently disambiguate editions. DCDuring (talk) 16:33, 16 December 2017 (UTC)[reply]
Even worse, the long cites are redundant if repeated in other entries. Once it is ready it might be a good application for WikiCite (the main use case is scientific publishing at the moment). – Jberkel18:56, 18 December 2017 (UTC)[reply]
Not to categorise. The last few times I used it for non-English entries I've never needed to link to English entries from within the def. But maybe that's not a common case, I'll leave it as is. – Jberkel18:33, 18 December 2017 (UTC)[reply]
@Jberkel, I think you should be using {{m}} or {{l}} instead of plain links if the words you're linking to are not English. Those would link the words to the right section. A lang parameter makes it confusing if you're linking to both English words in the explanatory text and non-English words. — justin(r)leung{ (t...) | c=› }20:01, 18 December 2017 (UTC)[reply]
This is not related to the discussion above, but it was inspired by it. When you look at how many other templates redirect to {{non-gloss definition}}, there's quite a few. I propose cutting this back to only one, simple shortcut. My preference goes out to {{ngd}} as the shortcut to use: a hyphen is a little bit more difficult to type than g, and ngd is also a perfect initialism of the full name, which makes it easier to memorise. A bot can then convert all existing uses of any of the other names, including the full {{non-gloss definition}}, to {{ngd}}. This is in line with what we already do for other templates with "official" shortcuts. —Rua (mew) 20:18, 18 December 2017 (UTC)[reply]
I don't see why we have to limit ourselves to a single short name. Why can't we just keep both {{ngd}} and {{n-g}} (and maybe even add {{ng}}) and allow people to use whichever one they like best? —Mahāgaja (formerly Angr) · talk16:36, 19 December 2017 (UTC)[reply]
The more names we have, the more editors have to learn and memorise in order to understand our code. If our code and naming is kept straightforward, there's less of a mental load. I would like to stick by the Python principle: there should be one, and preferably only one, obvious way to do it. —Rua (mew) 18:06, 19 December 2017 (UTC)[reply]
That’s probably why they constantly change the syntax for Python. But one must be very silly if one struggles with “learning” that {{n-g}}, {{ngd}}, {{non gloss}}, {{non-gloss}}{{non gloss definition}} mean the same. I fear it is an exaggeration to speak of a mental load. In any case if you put all the abbreviations into the documentation this argument vanishes because one learns about all forms to call it, which are very vernacular ones, if one learns about the template itself. However I don’t care if you want to standardize the usage, it is also not much mental load to use one only. Palaestrator verborum (loquier) 18:30, 19 December 2017 (UTC)[reply]
>a hyphen is a little bit more difficult to type than g
"Some people here think every character is one too much, clarity be damned." -- By contrast, some people here think the opposite, and are getting increasingly concerned by the "form-over-usability" mania for obfuscated short names for everything.
I'd like to also point out Rua's comment above about Python, and emphasize: "I would like to stick by the Python principle: there should be one, and preferably only one, obvious way to do it." Let's not forget the "obvious" portion here. {{ngd}} is very non-obvious to me, and I suspect to others as well. If we are to limit ourselves to only using one name for all templates, I propose we cleave to this obviousness principle and avoid ambiguous and obscure abbreviation. I.e., {{non-gloss definition}} instead of {{ngd}}, {{label}} instead of {{lb}}, {{compound}} instead of {{com}}, {{prefix}} instead of {{pre}}, etc. etc.
If we are to allow multiple names for any given template via redirection, then I see no reason to remove redirects, short of naming collisions. If we're worried about the multitude of template synonyms causing confusion and making the wikicode harder for humans to understand, then let's set a bot to work on a regular interval and task it with turning the synonyms into the canonical template name -- ideally something obvious and easily understandable, as noted above.
Wiktionary:Voting policy § Voting eligibility couples the right to vote to the start time of the vote. A teleological interpretation of the prescriptions suggests that the provisions referring to the start time of the vote have to be applied by analogy to the times of vote extensions, the ratio legis of the provisions being to deter overruns of votes by meatpuppets as has happened with Yugoslavs, while extended votes are those which demonstratedly do not concern the interests of which the voting system is protected by the self-same provisions and each of such extended votes as well can be seen as two votes, the second one being a repetition of the first vote with the old castings of votes taken over with the rebuttable presumption of continuity.
In accordance with these reasonings, I consider myself who has performed his first edit on Oct. 4th 2017 and has collected fifty edits in an immaterial time after it eligible to vote in Wiktionary:Votes/2017-07/Templatizing topical categories in the mainspace 2 which started on Aug. 6th 2017 but has been extended on Nov. 26th 2017. However I want to point out this unfortunate wording lest votes that need voters have fewer legitimate participants than they could have because of legitimate voters being bedazzled by the wording of the provisions about voting eligibility. In case of inaction concerning the voting policy wording I have here at least laid down reasonings for reference. Palaestrator verborum (loquier) 17:31, 19 December 2017 (UTC)[reply]
The extension changes the end of the vote, not the start. Doesn't seem at all unclear to me. A vote which was scheduled to start at one time and had that start delayed for some reason is possibly open to interpretation, but not an extended vote. - TheDaveRoss19:21, 19 December 2017 (UTC)[reply]
You say this because it has become common to speak of extension in that thing and not of starting. But the concept of extension does not exclude a restart, nor does the appellation change the nature. This is why I say that the expressions do not help here, just the telos. Palaestrator verborum (loquier) 19:50, 19 December 2017 (UTC)[reply]
The practice, letter, and spirit of the rules are all in accord here; the start of the vote is the start, extensions do not alter the start time. - TheDaveRoss19:58, 19 December 2017 (UTC)[reply]
Of course they don’t alter the start time – but they can add one, as the concept of extension does not exclude a restart. Meaning then there are two start times. I have already supra disproven that the spirit of the rules harmonizes with their wording. Palaestrator verborum (loquier) 20:04, 19 December 2017 (UTC)[reply]
I would be interested to hear if anyone else agrees with your interpretation; I think the concept of an extension is clear and does not alter the start time, or add additional start times, or change anything else about the start time or the eligibility criteria. - TheDaveRoss20:20, 19 December 2017 (UTC)[reply]
Even if you do not say there is a second start time (which is implicit if it is) there is still the possibility of analogical application. Because why shouldn’t it be? As I have read the archives, the eligibility policy has been devised to prevent that the whole Balkan votes even though mostly never having appeared before in working on the dictionary and things like that. But if a vote is extended, there has been no voting rush and it is as if there were a clean start. Palaestrator verborum (loquier) 20:31, 19 December 2017 (UTC)[reply]
If it is unclear, I suppose that it could be reworded in some way to make it more clear, but in all similar circumstances that I can think of an extension does not involve a restarting, but a continuation. That is actually a fundamental component of the word extension as I know and use it. If this whole discussion is simply a very long-winded way of asking if you can be made eligible to vote in the vote you linked to above, I would say no. - TheDaveRoss20:51, 19 December 2017 (UTC)[reply]
That I can be made eligible is of course not possible. Either I have been from the beginning or I am not. This is just a exposition of my thoughts favoring casting the vote which itself is not very relevant, but it shan’t be thought about too late, as the unclearness is seen and is not beseeming in such a matter. I have instantly thought what start time means on such occasions when I thought about the vote. If afterwards one talks about extension or whatever hardly matters because what matters are of course the factual occurences to which the rules are applicable, not how they are called. We need to hear a bit more what people think about the clearness of the wording. Hey @Wikitiki89, I find your judgement interesting, for you have on some occasions complained about unclear wordings. Palaestrator verborum (loquier) 21:27, 19 December 2017 (UTC)[reply]
So if a professor gives a student an extension on a paper, does that mean that they've reassigned it? I think your interpretation of the word "extend/extension" is idiosyncratic, so there's no worry about ambiguity.... Andrew Sheedy (talk) 21:08, 19 December 2017 (UTC)[reply]
But if an administrative authority extends or modifies an administrative act, or even a different (higher) authority does it, it does never matter, the whole arrangements affecting a claimant are then attacked in court in any case. We can surely find many more similes and the matter becomes even more blurry. Usage differs across topics. And again, how it is called does not change its nature. An authority can issue a “notice” and it might be a legal act. Palaestrator verborum (loquier) 21:27, 19 December 2017 (UTC)[reply]
Extension or modification of an administrative act is distinct from extension of time. I cannot think of an extension of time where it would mean the event is restarted. — justin(r)leung{ (t...) | c=› }05:32, 20 December 2017 (UTC)[reply]
Here Framawiki requested that I gain community consensus in order for the task to be done. Basically, I want PyWikiBot to not "cleanup" headers by adding spaces to the beginning and end (==This== to == This ==). From what I have seen the convention of having no starting/ending spaces in the header is a universal convention across this wiki, so consensus should be easy to get. -Xbony2 (talk) 00:16, 20 December 2017 (UTC)[reply]
Is anyone interested in helping to transcribe The Art of Grammar over at Wikisource? I'm happy to start the project but don't want to do it entirely on my own. I also need some help with Ancient Greek (it's an English translation but has many untranslated words in it). The transcription would make a nice complement to some of our entries here. – Jberkel13:52, 21 December 2017 (UTC)[reply]
@Jberkel: I can help too. I've long wished there was a translation easily accessible. (I had to translate some passages for Wikipedia in the past.) — Eru·tuon18:14, 21 December 2017 (UTC)[reply]
Thanks for your offer to help, that's great. There's also a proofreading stage at the end for those who want to help but don't want to transcribe. @Per utramque cavernam: it's not on Wikisource yet, I'll create the project skeleton and let you know once it's ready. – Jberkel23:35, 21 December 2017 (UTC)[reply]
We could institute the practise of grandfather clause: experienced users would be allowed to use whatever shortcut they're used to, which would be converted by bots like DTLHS suggested, but new users would be compelled to use the official shortcut or name. --Per utramque cavernam (talk) 16:16, 22 December 2017 (UTC)[reply]
Deleted. As Rua says, you've only created a sub-sub page of Related terms. Even if you could create a new namespace, you would want the structure to parallel that of the entries, which goes by spelling, then by language. On top of that, the only way such a scheme could possibly work is if there were only one "Related terms" section per language. Once you get into multiple "Etymology" sections, each with their own "Related terms" section, you run into the problem of "Etymology "sections being added, merged, deleted, rearranged and renumbered, without any way to guarantee that the corresponding "Related terms" entry will be moved, and with the messiness of moving without admin rights. The moral of the story: don't try to rearrange the structure of the site without discussing it here, first. Chuck Entz (talk) 04:07, 23 December 2017 (UTC)[reply]
is that work useless and unwelcome? look at related terms of переговорный ("negotiations"): there is говорун, which is related (etym), but it means "person who talks a lot", so it has almost nothing to do there. this is problem with Russian where you have long lists of related (etym) words on every entry, because there is no centralised place. But they are distracting because the meaning is very different. --Пикап (talk) 13:19, 23 December 2017 (UTC)[reply]
We are currently running a discussion on Wikidata about what the ideal data import process looks like. We want to get the thoughts of people who work on different Wikimedia projects who have different needs and knowledge of different kinds of data to make it our roadmap as inclusive as possible, please take a look.
This edit raises the question about the proper formatting of cognates in languages that use more than one script. As a result of the edit, the designation of the language is currently duplicated on kabát, revealing it thereby as conducive to suboptimal appearance. Two approaches that crossed my mind were settling for nothing more than square brackets for the lemma with the second script (undone by the edit) or replacing in these cases Template:cog with Template:m which does not duplicate the designation of the language. Other ideas? Examples for such languages are Serbo-Croatian (Cyrillic and Latin), Kurdish (Arabic and Latin), Kazakh (Cyrillic and Latin) etc. The uſerhight Bogormconverſation19:00, 25 December 2017 (UTC)[reply]
I prefer to what I did in the first place, which is just choose one script rather than redundantly showing both of them. Erutuon's solution is my second choice. —Mahāgaja (formerly Angr) · talk19:15, 25 December 2017 (UTC)[reply]
I don't like the amount of duplication we have for Serbo-Croatian. Most entries are copies of each other. We should choose Latin script as the main one and turn Cyrillic into alternative forms or some other designation. Latin script is the most used, so it makes sense. —Rua (mew) 19:55, 25 December 2017 (UTC)[reply]
That would be somewhat politically incorrect, although we already redirect British spellings to American, so maybe it's not a big deal, it would simplify things massively. Crom daba (talk) 21:13, 25 December 2017 (UTC)[reply]
Chinese is a better example. We could also go the opposite way and split them into Serbo-Croatian Knjižni Jezik and Serbo-Croatian Novosrpskohrvatski. —Rua (mew) 21:17, 25 December 2017 (UTC)[reply]
We don't really redirect "British" spellings consistently, and that definitely isn't a policy, although some editors may choose to do so. DTLHS (talk) 21:19, 25 December 2017 (UTC)[reply]
I use {{cog|sh|ка̏ва̄д}}/{{m|sh|kȁvād}} consistently – don’t know how easy it is for normies to write both alphabets in quick succession (I have a rare setup), but that (currently least objectionable) usage is the reason why the Cyrillic is not automatically transcribed. Ignore politics, but aesthetically the Cyrillic script has no wrong to be ignored. Serbo-Croatian in Cyrillic is so fair! And for the reason that nj and lj kann be нј and лј as well as њ and љ though rarely it could even be chosen as the main script for technical reasons. We could then develop some template that is placed in the Latin page and does nothing but converting the whole Cyrillic page for readers of Latin – no double-creating anymore, only creation in Cyrillic and after each instance of it placement of a template at the Latin entry; I have already suggested a conversion mechanism for the translation tables in Wiktionary:Grease pit/2017/December § Bring Serbo-Croatian entry and translation additions technically up to date to accelerate the treatment of the language. Something similar can be made with Ijekavian and Ekavian (too bad Serbo-Croatian does not just use glorious ѣ, then we would not have this problem). Redirects of course do not work as some spelling could be a word in another language.
I have in the case of the Kazakh alphabets said that the dictionary can of course make editorial decisions for alphabets no to be bothered by governmental whimsies, but this would not even be so radical because we would still show both alphabets but have less work for editors (unless one needs to learn to write Cyrillic first, which technically is necessary anyway for those who create Latin Serbo-Croatian entries without the corresponding Cyrillic ones [a huge annoyance]) Palaestrator verborum (loquier) 22:04, 25 December 2017 (UTC)[reply]
Emoji as translingual "translations" of normal words
They are not wrong, but perhaps we want a template to show the emojis on a different place – except we already have a fitting one, which I do not know about. Or maybe we should use the emojis as parts of the glosses 😅? It is perhaps better than a {{wikipedia}}-style mention for cases where want to translate words for feelings to emojis or else where there is no 1-to-1 match but a rough one. Though I warn that Wiktionary will look retarded if we will use emojis for glossing. On the other hand it is perhaps an accessibility plus. Simple English Wiktionary would probably do it. Palaestrator verborum (loquier) 22:19, 25 December 2017 (UTC)[reply]
One reason why they don't seem like "translations" is that a symbol and a word may exist for the same concept in the same language (e.g. blue letter P for "parking"): not all symbols are translingual. But it's also odd to call them "synonyms" when they are not (generally) substitutable into a written sentence. Equinox◑22:30, 25 December 2017 (UTC)[reply]
That little word “generally” is revealing. It means they are substitutable if the rules of style permit it – yeah, oral speech falls completely out for these signs and much other speech because one does not generally want to use it, as long as one does not exert oneself to think in emoji. The only requirement is analytic grammar, though yeah, I like to put Russian endings after writing Latin words, so I could write: “Не ешь моего 🍍а.” But it appears to me that such dependence on endings inhibits usage of emojis at least somewhat, and that the Japanese not having many of them is the reason why emojis have gained the most prominence with them.
For the word “translation”, it is only the general idea that it takes place between different languages while we even fail to distinguish the borders of a language. This way one can translate J. M. E. McTaggart for analytical philosophers or similarly between sub-languages, to show an exaggerated example. Palaestrator verborum🎢 sis loquier 🗣22:51, 25 December 2017 (UTC)[reply]
I would say that that is wrong. Just because ideographs have become more common lately due to Emoji, it does not change the fact that one could theoretically draw a picture of anything to try and convey an idea, that is exactly not language. The cases where I think Emoji might merit inclusion are those where the image has taken on a secondary meaning, e.g. the eggplant. A picture of a taco as a translation of taco should be avoided. - TheDaveRoss13:55, 27 December 2017 (UTC)[reply]
See Category:Translingual translations for all entries that have Translingual translations. I suggest removing all of these Translingual translations and keeping this category empty forever. Even the word Japan is is currently "translated" as "🗾" (which is just a map of Japan encoded as an emoji). I also suggest using the "see also" section in normal word entries to link to emoji. I support using the "see also" this way in all entries where a word can be reasonably linked to an emoji. --Daniel Carrero (talk) 15:25, 27 December 2017 (UTC)[reply]
Oops! I wish to make a correction: some Translingual translations are about taxonomic names of species. The entry rufous-bellied kookaburra has this Translingual translation: Dacelo gaudichaud. I only support removing all emoji translations. In my opinion, the taxonomic translations can stay. --Daniel Carrero (talk) 01:01, 28 December 2017 (UTC)[reply]
I was initially bold about this, then decided it was probably better to ask first. There are a number of things included at the top of the watchlist page, including {{votes}}, {{smallest discussions}}, a bunch of "utility" links, and the "not counted" message. Personally I would prefer to remove all of these links from the default page, and allow people to add them to their own watchlist if they would like to. I feel that the watchlist is an "opt in" page, and should have as little content forced on the user as possible. Can we remove some or all of the extraneous content from the default page view? It would be easy for individuals who would like the content to restore it using their .js page or a gadget. - TheDaveRoss16:38, 26 December 2017 (UTC)[reply]
I suggest keeping at least the {{votes}} there by default. Reason: votes can cause major changes in the website, so in my opinion it's best to let everyone know, by default, what are the present votes. I'm perfecly fine with letting people use CSS and/or JS to hide the box if they want. --Daniel Carrero (talk) 15:38, 27 December 2017 (UTC)[reply]
That template is already included on several other high-traffic pages. The watchlist is an opt-in page in all other regards, why should we impose what we think others should see on their own watchlists? - TheDaveRoss16:03, 27 December 2017 (UTC)[reply]
I, for one, rarely see the top of RfD, RfV, TR, RfC and other similar high-traffic pages. As we obviously don't want too much democracy in our votes, we wouldn't want to have some kind of more aggressive push notification (eg, e-mail notices to all opted-in users for just-started or about-to-close votes). Thus, we need some form of conspicuous, yet discriminatory, notification. For this watchlist notification is pretty good, not being obviously undemocratic. DCDuring (talk) 16:21, 27 December 2017 (UTC)[reply]
The votes are shown in the watchlist as per consensus in Wiktionary:Beer parlour/2015/September#Should we display the active votes in the watchlist?. Maybe it's correct that we are imposing what "we" think others should see on their own watchlists -- but "we" is not you and I; "we" is the community consensus, which may either change or persist. In my opinion, that's a good thing, in addition to the other reason I gave in my message above.
Dave, the template is not at the top of BP. What are the other high-traffic pages you mentioned? In Special:WhatLinksHere/Template:votes, I see the template is mostly linked in a few BP discussions. Or maybe would you suggest we should add the template in any other pages that don't have the template yet?
Plus I don't think it's actually true that the watchlist is an opt-in page in all other regards. These things are shown there by default: the "utilities" (logs, new, cleanup, etc.) and the wanted entries.
I support automatically sending an e-mail to all Wiktionary users whenever a vote page is created. Or just opted-in users. Who can make this happen? --Daniel Carrero (talk) 16:42, 27 December 2017 (UTC)[reply]
As I'm sure you know, Wiktionary:Voting policy#Voting eligibility has some eligibility restrictions. Personally, I support that, which seems to be a measure against people who never edited Wiktionary just coming here to vote and then going away without making any actual contributions. That's the second best system for making decisions I can think of. The best one would be making me King of Wiktionary, enabling me to unilaterally make decisions just by issuing royal decrees. --Daniel Carrero (talk) 17:00, 27 December 2017 (UTC)[reply]
One alternative to populist democracy is that we try to put a good product out there, with a highly select, but mostly self-selected, group of active contributors being the participants in votes. We then let the users decide whether or not they like the product. That's pretty much what we do now. We could go the extra mile and take the trouble to actually find out what users, including lurkers and passive users, actually use, but we seem to like relying on our own whims most of all. DCDuring (talk) 17:32, 27 December 2017 (UTC)[reply]
No one, including me, spends much time looking at WT:FEED, though perhaps we should. What I think we would usually want is answers to the questions that might inform our efforts, as to both form and content. As surveys are nearly as selective as voluntary random feedback, they're not enough. Someone with the technical chops to count clicks using the squid(?) server could help. DCDuring (talk) 19:00, 27 December 2017 (UTC)[reply]
E-mails? It’s like those Wikipedias that automatically sent me an e-mail just when I visit a single page on one of them via interwiki links. Hugely annoying. Also not targeted enough. So only opt-in is acceptable. As for {{smallest discussions}}, I do not see any use in it. Meseems however that {{votes}} is at its most appropriate place. Palaestrator verborumsis loquier 🗣17:16, 27 December 2017 (UTC)[reply]
@Daniel, sorry about the BP comment, it is linked to but not transcluded, my mistake. Re the "consensus" in the link you shared, it looks like a few people were OK with the idea and a few weren't, and it happened. I wouldn't call it consensus per se. I agree that there is a lot of stuff on the watchlist which is not opt-in, my suggestion is to remove all of that so that the watchlist returns to being in the control of the user. Put these types of things in the community space, on BP and TR etc. - TheDaveRoss18:48, 27 December 2017 (UTC)[reply]
Enable "If you have time, leave us a note." for everyone, not just the anons
In other words, it enables the person to post a new message at WT:Feedback.
My point is: I only see the sidebar message when I'm not logged in. When I'm logged in, the message disappears. Apparently, all logged users are unable to see that link to leave feedback, aren't they? I would suggest leaving the sidebar message on at all times. As we know, some users might have created accounts on Wikipedia and other projects and may not have any experience with using Wiktionary.
I thought it worth drawing attention to this vote which is due to end within the next 24 hours. If the vote passes, it will have an effect on most entries and yet only a small proportion of editors have voted on it so far.
I have only just started editing here again after a break, and I've noticed that there have been moves to add templates to entries where there was none before, with little obvious benefit but the obvious disadvantage of creating a backlog of thousands upon thousands of edits that need to be made to bring entries in line with whichever new standard has been introduced. It creates a situation where where only a small proportion of words represent the latest standard and most will never be updated before yet another template is introduced, or if ever at all. Kaixinguo~enwiktionary (talk) 21:50, 27 December 2017 (UTC)[reply]
Lately I've started to place topical categories before the senses they apply to, like we already do with labels. It makes more sense that way. —Rua (mew) 22:55, 27 December 2017 (UTC)[reply]
OK, thanks for the example. It does demonstrate a potential advantage to the change to a template. I would still rather see the word 'category' used as I feel that 'C' alone is not self-explanatory. Regarding other templates, amongst the words on my watchlist I have noticed the the recent introduction of a template for alternative forms (template:alter), template:l being used around English translations, the template for categories mentioned in this vote, and also template:syn suddenly introduced for synonyms with synonyms being moved in the page as well.Kaixinguo~enwiktionary (talk) 23:10, 27 December 2017 (UTC)[reply]
I know- if I can't keep up with the changes in the templates then I will just have to stop editing or choose a task that doesn't need any understanding of templates. That may be for the best, I just wanted to raise this point. Kaixinguo~enwiktionary (talk) 23:17, 27 December 2017 (UTC)[reply]
On the contrary, I think it would be detrimental to use a template with a name that does not reflect its purpose. By voting against the name, I am helping to keep template naming clearer. —Rua (mew) 23:53, 28 December 2017 (UTC)[reply]
I think we have ended up with no consensus for both {{c}} and {{cat}}, so users should be free to choose, {{topics}} is doomed, and {{Category}} wiil be around for a long time yet. I hope DP doesn't ask for another extension. DonnanZ (talk) 00:10, 29 December 2017 (UTC)[reply]
I know this is a bit meticulous. But I was reading the header for Wiktionary:Information desk, and I noticed something that was a bit off. It says:
Welcome to the Information desk of Wiktionary, a place where newcomers can ask questions about words and about Wiktionary, ask for help, or post miscellaneous ideas that don’t fit in any of the other rooms.
I don't think this is necessarily true. The wording of the sentence suggests that only newcomers should ask questions about things at ID. I ask questions there a lot, and I've been here for almost 4 years. I saw Equinox ask a question in ID recently, for instance, too, and he's an admin and been here since 2009. I understand that it may be mainly newcomers coming to the ID, but the only problem I have with this wording is the sort of conclusion that some might come to with this wording that people who aren't newcomers shouldn't ask questions if they have trouble. I know it's not suggesting this necessarily, but still it gives off the wrong feeling.
I propose that it should be reworded to:
Welcome to the Information desk of Wiktionary, a place where users can ask questions about words and about Wiktionary, ask for help, or post miscellaneous ideas that don’t fit in any of the other rooms.
If it is necessary to mention newcomers, how about:
Welcome to the Information desk of Wiktionary, a place where newcomers or others users can ask questions about words and about Wiktionary, ask for help, or post miscellaneous ideas that don’t fit in any of the other rooms.
Right now there are lots of non-lemma entries that have gender and/or number information in the definition, but then also have this same information in the headword line for no apparent reason. I find this ugly and unnecessary, so I propose a new rule: if information is already presented in the definition, that information should not also be present on the headword line. The headword line isn't there to give definitions, and if we're already duplicating gender and number information there, what's next, cases? For the simple fact that we don't place cases in the headword line if they are in the definition, we shouldn't do so with gender or number either. —Rua (mew) 20:46, 31 December 2017 (UTC)[reply]
For anyone who wants example cases, I found a few from Rua's contributions. diff, diff.
As for my opinion, I without a doubt support this. I find this annoying myself, as it's unnecessary to mention this for inflected forms; only in the lemma entry. It's always been an afterthought for me, though, and I can't recall ever making a fuss about it, but huge thanks for bringing this up. A fuss needed to be made. PseudoSkull (talk) 22:52, 31 December 2017 (UTC)[reply]
Oppose I do find that including gender in inflections is useful, particularly when a noun has more than one gender. In Norwegian the inflections for words that are both masculine and neuter can be pretty confusing, so introducing a rule like this would be a backward step, and achieve absolutely nothing. DonnanZ (talk) 23:44, 31 December 2017 (UTC)[reply]
Note that the proposal only concerns cases where the gender is already mentioned in the definition. With noun forms this is not usually the case, so the gender would be kept there, although number would be removed. I'm not personally in favour of keeping gender in that position either, since it still duplicates information from the lemma. But I'm leaving it unchanged in this proposal. —Rua (mew) 00:51, 1 January 2018 (UTC)[reply]
I somehow fail to imagine cases when the grammatical gender, i. e. the noun class and not the number is in the definitions.
But I can imagine the genders in the heads of plural entries of Arabic removed. أقطان says about the forms they are masculine plural though plurals of inanimate masculine nouns agree with the feminine singular in Arabic. Palaestrator verborumsis loquier 🗣01:59, 1 January 2018 (UTC)[reply]
I agree that in headword line of a non-lemma, we shouldn't be repeating information that is either in the definition or in the corresponding lemma entry. --WikiTiki8916:39, 16 March 2018 (UTC)[reply]
Oppose I noticed that you had unilaterally changed {{pt-pp}} so that it no longer showed gender, number, or infinitive in forms other than masculine singular. I don't think that your finding it ugly and unnecessary is sufficient reason to change things, personally. I'd be okay with the omission of the infinitive, but there's really no reason to omit the gender and number information, even if it is redundant. It's 1-3 extra letters, not a paragraph of explanation. embryomystic (talk) 23:02, 12 September 2018 (UTC)[reply]
Thank you @Erutuon. (I speak of greek) Yes, I asked for noun-gender at headword of forms, but I do not repeat it at definition line. I need it instantly visible (δημοκρατίας). If gender absent, I, the user, would assume it does not apply at all for the specific language (democracies#English).
Repeating the gender in the same page, is just a mistake. Repeating the gender as in the lemma page, is a helpful reminder and indispensable to the noun personality. It is also used at Derived terms, at Related terms (as at λευκός), at Translations. I would be delighted if it were written out full, as in french (eau).
A frequent mistake happens at pluralia or singularia tantum, marked e.g. g=n-p: which does not add the word at the Category:xxx pluralia tantum. We need to add a label, and forget to erase the -p. Then, at the form we mechanically copy our usual definition line (second repetition). I confess guilty, Rua, and I am correcting (Ἀθήναις)
Support —suzukaze (t・c) 21:15, 3 December 2017 (UTC)
Noé 11:52, 13 December 2017 (UTC)
Oppose
Done — justin(r)leung { (t...) | c=› } 07:15, 25 December 2017 (UTC)
