Wiktionary:Grease pit/2016/January

Fails on fuir, luire. Hillcrest98 (talk) 16:50, 2 January 2016 (UTC)

@Kc kennylau Can you take a look at this? Benwing2 (talk) 01:47, 8 January 2016 (UTC)

@Hillcrest98, Benwing2: Sure. --kc_kennylau (talk) 14:04, 11 January 2016 (UTC)

@Kc kennylau Thanks! Benwing2 (talk) 17:50, 11 January 2016 (UTC)

Could we have one last push on this, please? Everything I've tried so far with it has worked except you can't specify a second plural or a feminine (specific example: cheval and ioueur will no longer work). If we can fix this, it's ready to go AFAICT. Renard Migrant (talk) 18:23, 2 January 2016 (UTC)

I just tested this and it looks like you can specify a second plural. Can you provide a test example where you get the problem? And I'll fix the issue with the second feminine. Benwing2 (talk) 02:01, 8 January 2016 (UTC)

I misread what you said; I see now you meant the feminine didn't work. Fixed, along with problems with the feminine plural and some other bugs. Benwing2 (talk) 02:24, 8 January 2016 (UTC)

Please see Module:ne-conj. The code at the moment is functioning. However, if I replace it with the code in Module talk:ne-conj and preview Template:ne-conj, it will return "chunk has too many syntax levels". Please help! Thanks. Wyang (talk) 04:34, 5 January 2016 (UTC)

The very first result from Google saying Template:quote/new is applicable.--Giorgi Eufshi (talk) 06:27, 5 January 2016 (UTC)

Thanks, solved (embarrassingly). Wyang (talk) 06:38, 5 January 2016 (UTC)

Can a good Samaritan please remove these message from Mongolian headword templates, like {{mn-noun}}, etc.? Please make it optional.

1. It doesn't look nice.
2. Cyrillic and traditional Mongolian don't always match. Inner Mongolian and Outer Mongolian dialects have big differences.
3. We don't have active editors or available online resources to provide this info.

FYI, @DerekWinters. --Anatoli T. ^{(обсудить}/^вклад) 07:18, 6 January 2016 (UTC)

The idea is that any reader who comes across it and happens to know the Mongolian spelling can add it in. So in my opinion, unless there you are sure that the Mongolian spelling does not exist, the ??? should be left there. For cases in which you are indeed sure that the Mongolian spelling does not exist, we can provide an override. But again, this is only my opinion. --WikiTiki89 15:48, 6 January 2016 (UTC)

I understand the idea but shouting messages have always been frowned upon and were removed from Russian headwords and others. There are much more matches (and resources) between Hindi and Urdu spellings, let alone Serbo-Croatian (Cyrillic and Roman spelling) but the entries don't demand any input from users or editors - the other spelling is and should be optional. --Anatoli T. ^{(обсудить}/^вклад) 22:12, 6 January 2016 (UTC)

They're not demanding input, they are politely asking for it. For Russian, it is less important, specifically because we have more editors and resources. For Mongolian, we have to rely on the chance that a reader who happens to know will see the request and contribute. In other words, without this request, there really is no hope. --WikiTiki89 22:24, 6 January 2016 (UTC)

I agree with Anatoli here — many Mongolian learners will not have any familiarity with this script anyway, and providing it should not be among our primary goals with Mongolian entries. —Μετάknowledge^{discuss/deeds} 00:13, 7 January 2016 (UTC)

I am all for adding the traditional Mongolian spellings but we don't even have enough working examples, let alone reliable data. I think we'll be able to upload it in one go when we have it. --Anatoli T. ^{(обсудить}/^вклад) 01:13, 7 January 2016 (UTC)

It is shouting and demanding and adds correct entries into Category:Mongolian terms needing attention. E.g. бүлэг (büleg) is a correct minimal entry. The editor doesn't need to know the Mongolian traditional script in order to create a Mongolian Cyrillic entry. It puts unnecessary stress to editors (have I done something wrong?) and discourages them, like any mandatory parameters (which are often justified). Besides, it's not visually appealing. I think I won't convince you, so maybe this thing is a matter of a vote or a minivote. There's no proof that these visual requests will add editors input. --Anatoli T. ^{(обсудить}/^вклад) 00:25, 7 January 2016 (UTC)

After seeing that there is an exclamation point and an attention tag (with the red "!!", if you have that enabled), I will agree that it does seem to be demanding. But those can be removed, and it can be made to look much calmer. However, I am not steadfast against removing the request entirely. If you have considered all my arguments and still disagree, that is ok with me. Does this revision look better? --WikiTiki89 00:50, 7 January 2016 (UTC)

For some reason I can't see the change. буга (buga) has the traditional Mongolian spelling ᠪᠣᠭᠣ (boɣo) but I am not able to add it using m=. --Anatoli T. ^{(обсудить}/^вклад) 01:13, 7 January 2016 (UTC)

It's supposed to be added like this (not exactly the best design, but it wasn't me who designed it). Do you still not see the change? You can at least see it at the {{mn-noun}} template itself (which is the only template I changed). --WikiTiki89 19:34, 7 January 2016 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Thanks, I see. My opinion stands. No other language headword demands (asks) for alternative scripts in the headwords. --Anatoli T. ^{(обсудить}/^вклад) 22:14, 7 January 2016 (UTC)

 Done. --WikiTiki89 22:33, 7 January 2016 (UTC)

Thanks. --Anatoli T. ^{(обсудить}/^вклад) 01:51, 8 January 2016 (UTC)

Sorry, was on vacation for a while and just got back. We do have the resources to provide the Mongolian script. www.bolor-toli.com has all the Cyrillic to Mongolian script conversions. I've verified as many as I can and they seem reliable. The Mongolian script uses spellings that more match Classical Mongolian phonology, while the Cyrillic script uses spellings that more match modern Mongolian phonology. DerekWinters (talk) 01:54, 11 January 2016 (UTC)

Modern inner Mongolian words may have different etymologies, even if the words are related. So Хятад (Xjatad) and ᠬᠢᠲᠠᠳ (kitad) have different pronunciations. Outer Mongolians will render the outer Mongolian cognate as Китад (Kitad), the word not used in Mongolia (the reverse can also be true). A number of traditional Mongolian letters don't even have mappings in Cyrillic and Cyrillic letter pairs may be rendered with the same letter in traditional Mongolian, which is less phonetic. --Anatoli T. ^{(обсудить}/^вклад) 02:23, 11 January 2016 (UTC)

Is it right to say that улс (uls) is ᠤᠯᠤᠰ (ulus), which "ulus", not "uls" as in outer Mongolian? --Anatoli T. ^{(обсудить}/^вклад) 02:29, 11 January 2016 (UTC)

I honestly have no clue. DerekWinters (talk) 04:27, 13 January 2016 (UTC)

Can this template be improved, so that two fields have to be entered? For example at instalment "trans-see|instalment|installment" - otherwise it appears as "installment - see installment" which is illogical and aggravating, I think. Donnanz (talk) 13:50, 6 January 2016 (UTC)

Two fields can already be entered. But the idea is that "if you mean 'installment', then see the translations at 'installment'", so it is perfectly logical that they are the same. --WikiTiki89 15:51, 6 January 2016 (UTC)

The spellings aren't the same, that's what I'm on about - it can look rather silly. I realise that one can already enter two fields, but a lot of editors have neglected to do this, all except me it seems. After I wrote the above I came across usage in translation tables where there's more than one sense, where two fields are not necessary, so I suppose my idea is dead in the water. At least I have highlighted the problem. Donnanz (talk) 18:13, 6 January 2016 (UTC)

I disagree that there is a problem. I think that "installment - see installment" is the right thing to say and that "instalment - see installment" is wrong. --WikiTiki89 18:29, 6 January 2016 (UTC)

Well, I disagree with you, and there was absolutely no need to revert the edit. Has anyone else got an opinion? Donnanz (talk) 18:35, 6 January 2016 (UTC)

The way it's supposed to work is that the part before the dash clarifies which sense the see link is talking about, and the part after points to another page. "Instalment" is not defined as "instalment", that would be redundant and nonsensical. Let me give you a better example: teetan. "Teetan" is defined as "pipit", so the translation table says essentially, "for the sense "pipit", see "pipit", even though there is only one sense. --WikiTiki89 18:47, 6 January 2016 (UTC)

I agree with Wikitiki on this. However, in this specific case, we're dealing with an alternative form, which requires additional considerations. Should alternative forms even have translation sections? —CodeCat 18:56, 6 January 2016 (UTC)

Now that I think about it, they probably shouldn't. --WikiTiki89 18:58, 6 January 2016 (UTC)

We obviously don't share the same philosophy. The entries are for instalment and teetan respectively, not installment and pipit, and there is only one sense for both. Don't you get it?

As regards translation sections under alternative forms, that idea is bound to be a non-starter, and severely jumped on by some. Donnanz (talk) 19:16, 6 January 2016 (UTC)

Take a look at dumbledore and you will see what I'm trying to say. Yes, the entry is for "dumbledore", but that is already known by the reader. The part before the dash just disambiguates which sense is referred to. The fact that some entries only have one sense does not mean we should abandon the standard format. --WikiTiki89 19:31, 6 January 2016 (UTC)

Yes, it makes sense in that case. That is what I was referring to above (where two fields are not necessary). But it doesn't always make sense to stick to your "standard format" in other cases. Donnanz (talk) 19:43, 6 January 2016 (UTC)

I don't see how it suddenly stops making sense when there is only one sense. Yes, it may be a little redundant, but why does it not make sense? --WikiTiki89 19:52, 6 January 2016 (UTC)

If there were a specific idea about, for example, how to improve the wording or to clean up the translations at alternative forms (or even about new reasons to have duplicate translations), we could have a more productive discussion. Personally, I somewhat dislike the wording as it is now and so would be favorably disposed to a good alternative. DCDuring TALK 22:31, 7 January 2016 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Duplications are much worse than having to decide where to host translations - at color or at colour. While it's not possible to keep both entries in sync, we should maintain translations at one entry. (Synonyms are also a problem for synchronising translations.) --Anatoli T. ^{(обсудить}/^вклад) 04:25, 8 January 2016 (UTC)

Where there's different Am. and Br. spellings the translatons section usually ends up under the Am. spelling. Is that just a coincidence? But with synonyms it's probably easier to have one translations section under the more common version, unless there's a good reason for not doing so. Donnanz (talk) 16:44, 8 January 2016 (UTC)

• I have found a baffling example where child prodigy has been shunted off to wunderkind. Why on earth? Donnanz (talk) 13:15, 12 January 2016 (UTC)

  I agree that was probably not a good decision, but what does that have to do with the text of the template? --WikiTiki89 15:49, 12 January 2016 (UTC)

  It's a bit off-topic and should be dicussed in the Tea Room, but I mentioned it as an example of the use of the template. Donnanz (talk) 16:48, 12 January 2016 (UTC)

Is there a way to write templates into a module or even invoke modules directly in the mainspace? It seems pointless to have separate pages for templates like this one, which consists of a single line of code. Esszet (talk) 18:29, 7 January 2016 (UTC)

I'm not sure what you mean by "write templates into a module", can you explain? As for invoking modules directly from userspace, that can certainly be done, but it's discouraged. Preferred practice is to create a template, exactly as in this case, and in many cases it's required because of the way the module is written -- many modules look at the parent arguments, i.e. the arguments of the template invocation that called the module, and not the arguments of the module invocation itself. Benwing2 (talk) 01:45, 8 January 2016 (UTC)

I mean take the code from the template, put it into the module, and create the template from within the module itself. Is that possible? Esszet (talk) 03:22, 8 January 2016 (UTC)

If what you mean is invoking a template from a module, yes this is possible using frame:expandTemplate() or frame:preprocess(), although it's discouraged, probably because it's slow. Generally, preferred practice is for the modules that implement a template to provide interfaces for both template calls and calls from other modules. If you're worried about having lots of templates like {{la-decl-1st}}, I think a better idea is to have a single interface named e.g. {{la-decl-noun}} (or maybe just {{la-decl}}), which takes the declension type as the first argument. (At one point I suggested an interface of this sort that auto-detected the noun class as much as this is possible, e.g. it would assume that nouns in -us are 2nd declension unless told otherwise ... although it's possible the Latin editors might prefer to have the declension always explicitly notated.) Benwing2 (talk) 05:22, 8 January 2016 (UTC)

It is discouraged also probably because it is nice to have "what links here" list all of the usages of the template. I also prefer one interface. --Giorgi Eufshi (talk) 06:25, 8 January 2016 (UTC)

You still don't get what I'm trying to say; I mean use the module to create the template. Is that possible? Esszet (talk) 14:55, 8 January 2016 (UTC)

Creating a template dynamically? How would you use it?--Giorgi Eufshi (talk) 16:04, 8 January 2016 (UTC)

I don't know exactly what you mean, but you'd use it by calling it just as you would any other template. Esszet (talk) 17:36, 8 January 2016 (UTC)

Sorry, I'm not sure what you mean by using a module to create a template. Can you give me an example? Do you mean to do what a user would do in creating a new template like Template:la-decl-1st? Modules can't do edits like this. Benwing2 (talk) 19:52, 8 January 2016 (UTC)

No, I mean:

• taking the code {{#invoke:la-noun|show|1}} (or something similar)
• putting it in the module
• adding additional code to the module to create the template from there

Is that possible? Esszet (talk) 21:40, 8 January 2016 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ You can invoke template code from inside a module by calling frame:preprocess(). In the case of the invoke code you quoted above, there's no need to do so because you could just call the function directly, but if there were other sorts of template code, you could potentially do this. I still don't understand what you mean by "create the template". The only way to invoke code in a module is through {{#invoke:...}}. You either wrap this in a template or call it directly from user code; there's no other way. Benwing2 (talk) 22:09, 8 January 2016 (UTC)

However, I still don't quite understand *why* you want to do this ... Benwing2 (talk) 22:10, 8 January 2016 (UTC)

I'm using very crude code here, but I mean something like:

function:create template(la-decl-1st)

{{#invoke:la-noun|show|1}}

That way, you would be able to call the template from the module as opposed to its own page, and we could thus get rid of separate pages for templates that could easily be written into modules. Esszet (talk) 00:42, 9 January 2016 (UTC)

I think you're misunderstanding the way the system works: at an early stage in the interpretation of the wikicode by the system, the system temporarily (or permanently, if there's a "subst:") replaces {{examplexyz}} in the wikicode with the result of executing the code at ]. Likewise, modules can only produce text, which is fed back to whatever executes the module. It's only when the system processes the wikicode for the entry after it's been modified by the templates and modules that anything shows up on the actual page. A module can't create anything by itself. It can only call existing templates and modules and then feed the resulting text to whatever called it. What you're proposing would be like a TV program creating a television to show itself on.

By the way, I think the reason why accessing templates from modules is discouraged is because the part of the system that executes modules has to create a simulation of the part of the system that executes templates and execute the template within that simulation, which adds layers of system overhead in terms of all kinds of system resources, not just execution time. Chuck Entz (talk) 03:40, 9 January 2016 (UTC)

Alright then, I guess it isn't possible. Thank you. Esszet (talk) 15:40, 9 January 2016 (UTC)

Someone reported a sorting bug here: Wiktionary:Feedback#Category:English_words_prefixed_with_mono-

I've called attention to this on the confix template page itself, but nothing seems to be happening, so I'm reporting it here as well.

Would it be possible to turn off the "no references tag" warning ("Warning: You're trying to save page with a <ref> tag but no <references/> tag!", etc.) if {{reflist}} is used instead of "<references/>", or if a section of a page is being edited (because the tag would be elsewhere on the page)? Smuconlaw (talk) 16:17, 9 January 2016 (UTC)

Why do we need {{reflist}}? It should be deleted IMO. —CodeCat 17:39, 9 January 2016 (UTC)

I guess that's a separate issue – perhaps it's useful to create columns in "References" sections? Anyway, I've been using it since it exists, and I'm used to using it at the English Wikipedia. In any case, as indicated in my original posting, the warning seems unnecessary when a section of a page is being edited. Smuconlaw (talk) 17:48, 9 January 2016 (UTC)

Module_talk:ja-headword#Latin-script_in_entry_spelling —suzukaze (t・c) 02:34, 11 January 2016 (UTC)

The headword should use katakana, to render the pronunciation correctly and the head parameter can use fullwidth Roman letters, which fit in better in a Japanese text. Fullwidth characters are not allowed for entries but they can be used for visual effect. They are used in Japanese books when Roman letters are mixed with Japanese kana and kanji. I've also answered on the link. The Japanese module won't know how to transliterate Roman letters, that's why you have to "help" it, e.g. "シーディー" is the actual Japanese reading of CD#Japanese and "セックス" is the reading of SEX#Japanese. --Anatoli T. ^{(обсудить}/^вклад) 02:42, 11 January 2016 (UTC)

I suppose, although seeing CD romanized as "shīdī" feels plain wrong. —suzukaze (t・c) 02:43, 11 January 2016 (UTC)

That's what was decided at the time. Unlike Chinese, Japanese will have an equivalent katakana spelling for each word in Roman letters, even if the frequency may differ.--Anatoli T. ^{(обсудить}/^вклад) 02:56, 11 January 2016 (UTC)

I found a mistake in quis#Latin. The ablative feminine singular should be quā, not quō. That page links to Template:la-decl-irreg. But that doesn't show any obvious way to indicate the change. Where should I look to find out how to make the change? (Please don't fix it for me. I'd like to learn how to do it.) —BenKovitz (talk) 15:44, 11 January 2016 (UTC)

It's right the way it is. Although the feminine ablative singular of quī is quā, there's no difference between the masculine and feminine forms of quis. —Aɴɢʀ (talk) 19:09, 11 January 2016 (UTC)

If you're curious what's under the hood, the code for Template:la-decl-irreg has an invoke statement, which calls the Lua module Module:la-adj. The code there links to Module:la-adj/data, which contains the actual data for quis. Benwing2 (talk) 09:48, 12 January 2016 (UTC)

@BenKovitz, Angr, Benwing2: (I was the one who made the declension table of "quis") This source lists "quo" as the abl.f.sg. form of "quis". This source contains sentences with the abl.f.sg. form "quo". --kc_kennylau (talk) 06:21, 14 January 2016 (UTC)

Your ping didn't work for some reason. And yes, quis doesn't distinguish masculine and feminine. Which makes sense if you think about it: if I ask "Who did you talk to?" I don't know if it's a man or a woman. —Aɴɢʀ (talk) 14:45, 14 January 2016 (UTC)

It seems that some changes were made to the template:quote-journal after which the parameter "date" stopped working and the current date appears instead of the date provided. See e. g. mechovka obecná, with date=2008-05-12, but "2016 January 11" apearing instead. --Jan Kameníček (talk) 19:39, 11 January 2016 (UTC)

@Smuconlaw You made the change, can you comment? Benwing2 (talk) 09:51, 12 January 2016 (UTC)

That's strange. I'm checking. Smuconlaw (talk) 11:31, 12 January 2016 (UTC)

There was a wikitext error, which I've fixed. You may have to reload the page to see the change. Sorry about that, and thanks for highlighting the issue. Smuconlaw (talk) 11:37, 12 January 2016 (UTC)

Now it is OK. Thank you for fixing it. Jan Kameníček (talk) 23:05, 12 January 2016 (UTC)

Mainly |1={h|k|hk|kk|etc.} for {{ja-noun}} , {{ja-adj}} , {{ja-verb}} , {{ja-pos}} (possibly more?). It seems like this parameter indicated the scripts the entry's spelling used for categorization purposes, but this is now automatic.

Replacing |hira= and |rom= with |1= would be nice too, but the output would have to be checked against the old manual romaji; for example |hira=やよい|rom=yayoi straightforwardly becomes |やよい, but |hira=そんざいしょうめい|rom=sonzai shōmei becomes |そんざい しょうめい (the romanization is generated from the kana, with half-width spaces in the kana stripped from the headword line's "|head=" but converted to spaces in the romanization) —suzukaze (t・c) 03:34, 13 January 2016 (UTC)

This is something I might be able to do. You'd have to give me some more info here:

• First, you want 1= stripped from {{ja-noun}}, {{ja-adj}}, {{ja-verb}}, {{ja-pos}} if it equals h, k, hk, kk, any more? What happens to the remaining numbered parameters? Do they get moved down by one (so that 2= becomes 1=, 3= becomes 2=, etc.)? What's the maximum number of numbered parameters, is it less than, say, 10 or 20?
• As for converting hira= to 1=, what I could do for the moment is one of two things:

1. Either: Generate the romaji from the hiragana in hira=, and if it's equal to the romaji in rom=, change hira= to the proper numbered param and remove rom=. There are 3 issues here: (1) To do this I'd need to know the proper template/#invoke statement to convert hiragana to romaji. (Is it {{xlit|ja|FOO}}?) (2) Should I ignore case when comparing the romaji? E.g. hira=やよい would presumably generate yayoi but for proper nouns the rom= is written Yayoi. (3) I'd also need to know what the proper numbered param is to put the hiragana into. Will it always be 1= for {{ja-noun}}, {{ja-adj}}, {{ja-verb}} and 2= for {{ja-pos}} (assuming that I've already removed the h/k/hk/kk code), or is it more complicated? E.g. will there ever be an h/k/hk/kk code still present?
2. Or: Alternatively, I could just check if there's a space in the rom=. If so, leave things alone, otherwise, change hira= to the proper numbered param and remove rom=, as above. This depends on there not being any special cases where a single-word hiragana has an unusual romaji that needs to be left alone. To do this, I'd still need to know what the proper numbered param is to put the hiragana into, as above.

Benwing2 (talk) 18:36, 14 January 2016 (UTC)

Examining the old code of these templates, it seems like possible input for |1= was r, h, ka, k, s, ky, and kk. They don't have any effect on the template anymore, and in addition it seems like the templates ignore any pure Latin text that is given as an unnamed parameter if it isn't a recognized part of speech.

|2= would become |1= upon removal of the old useless |1=. It doesn't look like ja-pos has any limits except for script execution time.

Romaji can be generated like this:

• {{#invoke:ja|kana_to_romaji|きたちょうせん の すいばく じっけん}}

I think that in most cases capitalization can be ignored, but particles (which may appear in a proper noun, I suppose) are not usually capitalized and needs manual overriding.

It looks like {{ja-pos}} prefers |2=pos ({{ja-pos|にほん|proper}}), but |1=pos ({{ja-pos|proper|にほん}}) is also fully acceptable (see the template code).

For {{ja-noun}} and friends, all unnamed parameters (numbered parameters?) are for kana readings. It's similar for {{ja-pos}}, except part of speech must be included as either |1= or |2=. —suzukaze (t・c) 06:47, 15 January 2016 (UTC)

Don't remove "ky"! It's still needed to show kyūjitai forms.--Anatoli T. ^{(обсудить}/^вклад) 07:26, 15 January 2016 (UTC)

The documentation for {{ja-pos}} talks about it, but 國際#Japanese (and shinjitai 浜#Japanese) seems to be displaying fine without it...? :s —suzukaze (t・c) 07:30, 15 January 2016 (UTC)

@Atitarev Looking through Module:ja-headword, I can't find anywhere that pays attention to a first parameter with a value of ky. Benwing2 (talk) 07:42, 15 January 2016 (UTC)

@suzukaze-c

1. I think I will have to expose the function kana_to_romaji in Module:ja-headword to properly know whether it's safe to remove romaji.
2. I think what I will do when converting hira= to a numbered parameter is to put the hira= value after any existing numbered parameters rather than replacing any of them, in case there are existing kana values. It looks like that should work fine.
3. If I end up leaving the romaji, is it OK to still convert hira= to a numbered parameter? I think this should be fine from looking at the code, but I can't tell for sure. Benwing2 (talk) 07:53, 15 January 2016 (UTC)

1. i don't know what that means, i don't know much about lua/normal coding. whatever works...
2. As in {{ja-noun|k|hira=にほんご|rom=nihongo}}→{{ja-noun||にほんご}}? ←It works, but in my opinion it looks odd.
3. 天叢雲剣 has {{ja-pos|proper|あま の むらくも の つるぎ|rom=Ama no Murakumo no Tsurugi}} and it works fine.

—suzukaze (t・c) 08:10, 15 January 2016 (UTC)

Sorry for not updating the documenation... The templates ignore s and ky. Module:ja (used by all ja- templates) displays the term as shinjitai if the kyu named parameter is set and kyūjitai if the shin parameter is set. Unless something has been altered recently, all of the templates ignore anything that is not kanji or kana, including h,ka,k,kk,r,s, or ky. The current situation is exactly the same as if they were all removed tomorrow. The templates also ignore which choice of hira or kata is used: the user can make a mistake like

<code>hira=ミス</code>

and it will be displayed correctly (this happens sometimes.) Therefore hira and kata could also be removed with no visible change.

The manual Latin transliterations or romaji could be replaced with automatic transliterations (the code for romanizing Japanese kana is in Module:ja) with the exceptions of these: Category:Japanese terms with romaji needing attention, but those could also be replaced if the kana were tweaked. You could set the template to ignore rom= stuff and nothing would change except for the terms in that category. --Haplogy (話) 08:12, 15 January 2016 (UTC)

@suzukaze-c As for #2, no, it would be {{ja-noun|にほんご}}. After removing the k parameter, there would be no numbered parameters left, so the hira= value would end up in parameter 1. Benwing2 (talk) 08:17, 15 January 2016 (UTC)

The original sentence confused me >_< —suzukaze (t・c) 08:24, 15 January 2016 (UTC)

@Haplology Thanks! This definitely helps. So you're saying that I can safely remove rom= unless the page is in Category:Japanese terms with romaji needing attention? That would probably avoid the need to expose and call kana_to_romaji in Module:ja-headword. Benwing2 (talk) 08:20, 15 January 2016 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Apologies, I meant "kyu", not "ky". Try removing "|kyu=" from 中国 and 中國 is not displayed any more. Equally, "shin=" is needed on kyūjitai entries. --Anatoli T. ^{(обсудить}/^вклад) 08:45, 15 January 2016 (UTC)

|kyu=FORM is staying; what will be removed is |ky (as in this diff). —suzukaze (t・c) 08:58, 15 January 2016 (UTC)

@suzukaze-c The code is written and I did a small testing run. Can you look at Special:Contributions/WingerBot around 00:51 and 00:52 UTC time on January 16 and check out the changes to see if they look OK? Benwing2 (talk) 00:54, 16 January 2016 (UTC)

@Benwing2 It looks great! It also reminded me that |hidx= is also useless and can be safely removed. (I see this parameter so infrequently that I've forgotten about its existence...) It used to be for category sort keys, which is also now fully automatic. —suzukaze (t・c) 20:23, 16 January 2016 (UTC)

@suzukaze-c The run should be done in a couple of hours or so. Hopefully nothing got messed up. Benwing2 (talk) 12:15, 17 January 2016 (UTC)

Could someone figure out a way to add language-code checking to the translation adder so it doesn't spew module-error text into the translation sections if someone uses a bad language code? Chuck Entz (talk) 14:36, 14 January 2016 (UTC)

I found a number of Wiktionary entries that cite Usenet posts apparently from this year. These pages (e.g. fandumb), when calling {{quote-newsgroup}}, specify both "year" and "date", with "date" set to something like "11 May", which does not include the year. A change by @Smuconlaw affected the way this is handled by converting the template to a wrapper around {{quote-web}}. Now the "year" argument ("2003") is ignored, and the "date" argument is passed through the #time parser function. PHP assumes the date is in the current year, so "2016 May 11" shows up instead of "2003 11 May".

The same change removed the "group" alias for the "newsgroup" parameter, so the Usenet citations on grouse are also broken in another way.

Could these issues be fixed? PleaseStand ^(talk) 16:13, 14 January 2016 (UTC)

OK, let me look into it. Smuconlaw (talk) 16:15, 14 January 2016 (UTC)

I think the problem has been fixed. You may need to reload the pages to see the changes take effect. Thanks for pointing the issues out. Smuconlaw (talk) 17:30, 14 January 2016 (UTC)

@Smuconlaw Thanks. I took a look at your fix and may have found a small problem. Right now, the current year (2016) is a leap year. Because only the "date" argument is passed through #time when converting it to Y-m-d format, PHP would assume the date is in the current year, so next year (2017), "February 29" would become "March 1". One simple way I can think of to handle this is to add a space, then the year, to the date before parsing it, so both "29 February " and "February 29 " would work. However, I have not tested this, particularly with pages that actually specify a full date in some format along with the year (e.g. bright shiny object). There would also still be pages with broken, unparsable dates (e.g. Citations:batpoop). PleaseStand ^(talk) 19:02, 16 January 2016 (UTC)

I'll have another look at the template. However, I don't think it can be expected to deal with situations where editors provide the parameters with unexpected values such as in the examples you provide (bright shiny object – both year and full date provided; Citations:batpoop – en dash inserted into date). These will just have to be manually corrected. Smuconlaw (talk) 21:23, 16 January 2016 (UTC)

Tried your suggested fix; it seems to work. Thanks. Smuconlaw (talk) 21:29, 16 January 2016 (UTC)

Is there any way to format multiline usage examples without doing so manually? I can't see how to do this using {{usex}} or {{ux}}. (If it matters, this is for Russian, where translit needs to be supported.) Benwing2 (talk) 05:40, 15 January 2016 (UTC)

1. -ჳე გოტ ჳეედ

#:-ტჰატ'ს ტიგჰტ

-wie goṭ wieed #:-ṭhaṭ's ṭighṭ

(c) john mean doe

--Giorgi Eufshi (talk) 06:35, 15 January 2016 (UTC)

Thanks! That seems to work fine. Benwing2 (talk) 07:45, 15 January 2016 (UTC)

@Benwing2 You can also use <br> :

1. -ჳე გოტ ჳეედ
   -ტჰატ'ს ტიგჰტ

   -wie goṭ wieed
   -ṭhaṭ's ṭighṭ

   (c) john mean doe

- -sche (discuss) 02:09, 17 January 2016 (UTC)

Thanks. Benwing2 (talk) 02:12, 17 January 2016 (UTC)

On sceptical, specifying both British and UK both display 'Britain', leading to the rather stupid looking Britain standard spelling of. Renard Migrant (talk) 16:13, 16 January 2016 (UTC)

@Renard Migrant For spellings (cases like this), the labels "British spelling" and "American spelling" and "Canadian spelling" should be used: {{standard spelling of|foo|from=British spelling|lang=en}} = British standard spelling of foo.. The difference in appearance also happens if you use these labels in {{label}} (or {{context}} before it): {{label|en|Britain|British|UK|British spelling}} = (British, UK, British spelling). (Note that "Britain" and "British spelling" also link to two different Wikipedia articles.) It would be nice if the template could interpret "Britain" or "British" or "UK" in the from= field the same as "British spelling", but I don't know if that's technically feasible. - -sche (discuss) 02:03, 17 January 2016 (UTC)

I have been working on bringing some coherence to the {{cite-}} and {{quote-}} templates. Essentially, the former are now for citing references in "Reference" sections and on talk pages, whereas the latter are for quotations in dictionary entries. I would like to propose that {{cite meta}}, which is used by many of the {{quote-}} templates, be renamed {{quote-meta}} for consistency. Smuconlaw (talk) 18:18, 16 January 2016 (UTC)

@Smuconlaw Good idea. Thanks for sorting out our messy and messily named cite-/quote- templates. If no-one raises substantive objections or boldly moves this template, ping me in a few days and I'll move it. - -sche (discuss) 02:07, 17 January 2016 (UTC)

Great! Will do. Smuconlaw (talk) 16:57, 17 January 2016 (UTC)

I've moved it, leaving a redirect so that existing uses (in 24 templates) still work. - -sche (discuss) 03:25, 21 January 2016 (UTC)

OK, thanks. I'll be changing those existing uses as well. Smuconlaw (talk) 06:05, 21 January 2016 (UTC)

There are many entries that provide this parameter now showing up as module errors. However, the original module code (before I made any changes) did not implement this parameter. So it's a no-op. Should it just be removed from these entries? —CodeCat 15:00, 17 January 2016 (UTC)

Hmm, is the parameter useful? If so maybe it should be implemented. Benwing2 (talk) 20:33, 17 January 2016 (UTC)

No, it's not useful. DTLHS (talk) 20:46, 17 January 2016 (UTC)

A couple of ideas, what do people think?

1. Adding a lit= param to {{ux}} to specify the literal meaning. I'm surprised this isn't there already.
2. Creating a {{uxi}} template that is the same as {{ux}} but has inline=y auto-specified; that parameter is too long. (Or alternatively I suppose we could supply i= as an alias.)

Benwing2 (talk) 20:35, 17 January 2016 (UTC)

Both seem nice. Enosh (talk) 20:45, 17 January 2016 (UTC)

I still think it would be better to reduce the need for inline=, by making the module choose it automatically based on the length of the text. —CodeCat 21:01, 17 January 2016 (UTC)

I agree, but how do we do this? Benwing2 (talk) 21:14, 17 January 2016 (UTC)

We just need to decide on a threshold length. If the usex is longer, inline is turned off, otherwise it's on. —CodeCat 21:20, 17 January 2016 (UTC)

I think we ran into this issue before ... ideally, it should never do inline if on a cell phone, and otherwise it should depend on the size of the browser window. There's the @media CSS directive that's supposed to be used for this ... unfortunately I'm not a CSS wizard so I don't quite know whether this can be inserted into an inline CSS directive and more generally how exactly to structure this for Wiktionary but I imagine it should be possible. Benwing2 (talk) 22:50, 17 January 2016 (UTC)

BTW could you implement the lit= param when you have a chance? There are a bunch of Russian usage examples where it would come in very handy. Benwing2 (talk) 22:54, 17 January 2016 (UTC)

This should only be done if it is possible to do it with CSS. This should not be done by counting characters or anything silly like that, since character counts cannot predict the display size. --WikiTiki89 16:40, 18 January 2016 (UTC)

Here's another idea for {{ux}}: A |sub= parameter that allows for (non-displayed) phonetic substitutions prior to transliteration. The idea is to phonetically respell words that have irregular pronunciations, so that their transliteration shows up correctly without the need to manually transliterate the entire expression--especially useful for long quotations and such. I implemented this for Russian {{ru-ux}}, where it takes the form FROM/TO,FROM/TO,... where FROM and TO are as in Lua patterns (but will usually be fixed strings); but I imagine it would be useful for Yiddish (e.g. to respell Hebrew words), Arabic (e.g. to specify places where -ة is pronounced /t/) and other languages where automatic transliteration is possible but there are exceptions. Benwing2 (talk) 22:37, 18 January 2016 (UTC)

I've been thinking about that myself for Yiddish and it never occurred to me that it should be generalized, but I guess there's nothing wrong with that. One problem is that it won't solve everything. For example מקדש spells both "mekadesh" and "mikdesh", and could be used within the same usex. I'm sure the same can happen with Russian, and especially with Arabic. But such cases are probably fairly rare overall. --WikiTiki89 00:15, 19 January 2016 (UTC)

The |lit= parameter was causing module errors in two places at a, so I temporarily added it to the list in Module:usex/templates of parameters for Module:parameters to ignore. I'm not sure if that will interfere with anything- if it does, you know where to find it. Chuck Entz (talk) 06:29, 21 January 2016 (UTC)

Category:Vietnamese nouns without classifiers is a useful category for nouns having classifiers, however, not all nouns do have classifiers (aka measure words, counters). E.g.:

hai con ếch ― two frogs

hai bệnh viện ― two hospitals

The first noun ếch needs a classifier but not the second one bệnh viện (most if not all Sino-Vietnamese nouns don't require classifiers). Such nouns could use a different parameter, e.g. "cls=-", which could add them to a different (unhidden) category to separate nouns, which don't have classifiers because nobody added them from those, which don't need them. @Fumiko Take, do you think it would be useful. What should be the name of the category? --Anatoli T. ^{(обсудить}/^вклад) 23:09, 17 January 2016 (UTC)

drepen#Middle Low German asks for a documentation subpage in the entry. It's template Template:gml-conj-st2a is a 1:1 copy of Template:gml-conj-st1 whose test entry riden#Middle Low German does not ask for a documentation subpage. Help. Korn (talk) 00:09, 18 January 2016 (UTC)

Fixed both. —CodeCat 00:54, 18 January 2016 (UTC)

But the error at drepen seems to remain. Korn (talk) 01:08, 18 January 2016 (UTC)

I did a null edit, and it went away. Chuck Entz (talk) 01:23, 18 January 2016 (UTC)

Discussion moved from Wiktionary:Beer parlour/2016/January#Module errors on the vote box.

Planned, running, and recent votes

(see also: timeline, policy)

Ends	Title	Status/Votes
Nov 11	User:Svartava for admin	passed
Nov 27	Excluding trivial present participial adjectives	0 4 1
Dec 24	Word of the Year	starts: Nov 28
(=3)		(=22)

The vote box currently has 2 module errors. I won't be able to fix them right now because I'm at my new job and I'll be busy for a few hours. :)

Reasons:

• Unsigned vote at Wiktionary:Votes/2015-11/term → m; context → label; usex → ux by User:DCDuring.
• Unsigned line starting with # at Wiktionary:Votes/pl-2015-12/Translations by User:DCDuring. (signed in the line below)

In both cases I'm not blaming User:DCDuring, the vote box should behave gracefully even in those events. I'll fix the vote box to accept these things later when I have the time. --Daniel Carrero (talk) 19:39, 16 January 2016 (UTC)

I fixed the issue with unsigned votes, although the code in question should also be defensive about properly formatted links (e.g. a link with a colon but no vertical bar may cause issues). Benwing2 (talk) 19:58, 16 January 2016 (UTC)

In one case I forgot to sign. My bad.

In the other case I signed after a multi-paragraph explanation of my vote, which put a couple of newlines between the template and the signature. Is that a bug or a feature? Even if it is a bug, is it worth fixing? DCDuring TALK 20:01, 16 January 2016 (UTC)

This is a bug, as far as I'm concerned. At the moment, people don't have the ability to sign only after a multi-paragraph vote and have their vote counted in the vote box. People have to sign in the same line they start with a single #, as you have noticed.

But I don't think it could get fixed so easily. Consider this mock vote:

Proposal: Rewrite Wiktionary completely in Morse code.

Vote:

1. Support I want to use Wiktionary on my telegraph, Foo made her case and convinced me.

   You guys should listen to her, too. --Bar (talk) 00:00, 1 January 2016 (UTC)

The problem is that the module looks for the last user link in the vote line. The actual voter linked to another user, so the module would interpret this as a vote by the linked user. I'm not really sure how to fix this, maybe looking for the "(UTC)" in the end. --Daniel Carrero (talk) 02:16, 17 January 2016 (UTC)

You can paper over the problem with a few extra words on the vote instructions. Not ideal, but good enough. DCDuring TALK 02:49, 17 January 2016 (UTC)

I think what you said is the only available option, really. Here's another flaw in the logic that would probably happen if we tried to fix the code. Suppose the first voter forgot to sign the vote and somebody else responded to him.

Proposal: Add translation tables in all foreign-language entries.

Vote:

Oppose And remove translation tables from English entries, too.

• You shouldn't say that, that's going too far. --Voice of reason (talk) 00:00, 1 January 2016 (UTC)

If the module recognized the unsigned vote line and looked for a signature in the next lines, then the module would interpret this as a vote by the user who replied to the actual voter. --Daniel Carrero (talk) 03:24, 17 January 2016 (UTC)

@Daniel Carrero: This is WT:GP material. --WikiTiki89 16:29, 18 January 2016 (UTC)

@Wikitiki89 Moved it from WT:BP. --Daniel Carrero (talk) 17:21, 18 January 2016 (UTC)

For some reason, when I load pavus, the edit links next to the section headers are not surrounded by angle brackets and are the same size as the section text. Does this happen to anyone else, and if so, why does it happen and does it happen on any other page? —JohnC5 20:46, 18 January 2016 (UTC)

@JohnC5: I have been noticing this as well. It seems to have been some kind of wikitext processing glitch that confused the mobile interface with the desktop interface, which has since been fixed but left residue in the cache. To fix these pages, just purge or null edit them. Disclaimer: my explanation is pure speculation. --WikiTiki89 20:50, 18 January 2016 (UTC)

@Wikitiki89: Yep, that worked. Weird. Sometimes I imagine what it would be like if we hard purged all of Wiktionary at once. That would be very exciting. —JohnC5 20:55, 18 January 2016 (UTC)

It was happening intermittently to me before; I've noticed that the link structure of the edit links are reminiscent of the VisualEditor (!?), but nothing happens when you click on the links, probably because the VisualEditor isn't enabled... —suzukaze (t・c) 20:56, 18 January 2016 (UTC)

It's been happening to me today too. —Aɴɢʀ (talk) 21:40, 18 January 2016 (UTC)

Ah, so this wasn't just me. Andrew Sheedy (talk) 00:46, 21 January 2016 (UTC)

It's happening again today. Andrew Sheedy (talk) 02:21, 2 February 2016 (UTC)

Is there any plan to merge Module:category tree/topic cat/data/Place names and Module:category tree/topic cat/data/Place names old? --KoreanQuoter (talk) 12:31, 19 January 2016 (UTC)

The template {{pi-noun}} needs a parameter for a second gender, such as for the noun mitta. --Lo Ximiendo (talk) 23:41, 22 January 2016 (UTC)

@Lo Ximiendo: Done. --kc_kennylau (talk) 12:51, 23 January 2016 (UTC)

Now it seems to place all Pali noun entries into the category for Pali nouns in Latin script, as I noticed from editing तरु (taru). (Also, what just happened to {{pi-alt}}?) --Lo Ximiendo (talk) 21:50, 4 February 2016 (UTC)

The abuse filter no-L2-L3 prevents changing entries to the simplified format (since it has no L3 headers) and messy things must be done. It's problematic. Can an exception be made if {{zh-see}} is present? —suzukaze (t・c) 05:15, 23 January 2016 (UTC)

Yes, please. Anonymous users can't create or edit Chinese simplified form entries.--Anatoli T. ^{(обсудить}/^вклад) 05:20, 23 January 2016 (UTC)

A related vote on the structure of Chinese simplified entries: Wiktionary:Votes/pl-2014-12/Making simplified Chinese soft-redirect to traditional Chinese --Anatoli T. ^{(обсудить}/^вклад) 10:23, 23 January 2016 (UTC)

Well yes, here's the text of the vote: "Making simplified Chinese soft-redirect to traditional Chinese. Thus, hosting definitions and other content in traditional Chinese entries, and no longer in simplified Chinese entries." Assuming that the vote passed (which by my lights it did not), the vote does not stipulate that soft-links are the miniature markups that we now see in Chinese simplified entries. --Dan Polansky (talk) 10:37, 23 January 2016 (UTC)

The Beer Parlour discussion linked to in the vote seems to once have featured example entries that use {{zh-see}}, such as User:Wyang/历史. It looks like voters knew fully well what they were voting for. —suzukaze (t・c) 22:56, 23 January 2016 (UTC)

Maybe it's time simplified Chinese entries start honoring our proven practices, along the lines of the vote Wiktionary:Votes/pl-2013-03/Romanization and definition line. Format like the following does not fit the results of the vote:

==Chinese==
{{zh-see|多納特羅}}

Yes, the vote was about Japanese romanization entries, but one would guess the voters would also support that Chinese entries follow the standard format. --Dan Polansky (talk) 09:41, 23 January 2016 (UTC)

One would guess, but Chinese isn't as similar to Japanese as one would expect. Simplified forms aren't romanizations; compare tā and 他. Besides, I believe the Chinese entry layout has been voted on already (correct me if I'm wrong). —Aryamanarora ^{(मुझसे बात करो)} 00:28, 2 February 2016 (UTC)

That's about it, really. 209 results as of 10:51, 22 January 2016, but almost all of them categorized. It used to be a really useful tool to find broken formatting, now it's almost unusable. There are probably about 20 uncategorized pages in there, but which ones? And why is this happening? Renard Migrant (talk) 11:55, 26 January 2016 (UTC)

I am not certain, but I think it has to do with the fact that they were created through the API and never "touched" which allowed them to fall through the categorization cracks. - TheDaveRoss 14:12, 26 January 2016 (UTC)

I don't think this is a real-time list.

The first three that I looked at were created on January 23. I suspect that the master list of category-entry associations was created before then, but the list is created as a subtraction of entries with such associations from all entries as of January 26. The hypothesis could be tested by inspecting a list of pre-January-26, post-January 23 new entries to see whether they are on the page in question. DCDuring TALK 15:19, 26 January 2016 (UTC)

The ones I looked at were mostly created before the listed cache date. - TheDaveRoss 15:23, 26 January 2016 (UTC)

What is the API? Renard Migrant (talk) 15:43, 26 January 2016 (UTC)

The API is the interface which bots (and any other methods which are not using the Mediawiki interface) use to interact with the database. Here is a lot of information about it. - TheDaveRoss 15:55, 26 January 2016 (UTC)

Any item on any cached special page must have been around before the time of the caching. I was wondering whether the process of list creation had latency delays. On further inspection I could show my hypothesis to be mostly wrong. I didn't find many latency delays based on my limited inspection. I did find that many of the entries on the list show 0 wikilinks, which probably has something to do with the means the bots used to create the entries (API?). Those entries also did not appear on Special:NewPages. The bot-created entries were mostly Russian and French. The other entries seem to be on the list by reason of not having an inflection line template. But some entries defy my explanations, such as Bakuninist. DCDuring TALK 15:47, 26 January 2016 (UTC)

The links to Wikspecies and WikiCommons aren't working. Attempts to reach either by urlname don't seem to be working. Any information on why? DCDuring TALK 19:09, 26 January 2016 (UTC)

Thanks for reporting this. There are multiple issues which are currently being investigated by the Operations team of the WMF. The corresponding bug report is phab:T124804. --AKlapper (WMF) (talk) 19:29, 26 January 2016 (UTC)

Thanks for monitoring this page. I don't have enough reason to try to get the hang of IRC. DCDuring TALK 20:24, 26 January 2016 (UTC)

Can someone make it so that when you search in the Greek script, accented and unaccented characters show up in each other's results? (Like we have in Latin script.) For example, if I see a Greek word written in Latin as "pethainw" and I search "πεθαινω", there are zero results or hints that would point me to the correct word, "πεθαίνω", which is only an accent mark away. Ultimateria (talk) 19:46, 26 January 2016 (UTC)

I think that this should be reported on Phabricator as a feature request for CirrusSearch. —suzukaze (t・c) 19:48, 26 January 2016 (UTC)

(e/c) Unfortunately, this is something only the devs can do. We've already requested it in the past at least for Cyrillic, but no luck. Maybe if enough people complain to them... --WikiTiki89 19:50, 26 January 2016 (UTC)

Here is an old related bug if you would like to roll it into your new one: Devanagari and Arabic combining character handling - TheDaveRoss 21:24, 26 January 2016 (UTC)

Similar issues exist for Cyrillic with accented vowels too, although the accents are generally separate combining characters in that case. If you search for unaccented Cyrillic, it will not find any accented Cyrillic on the same page. This is actually a much bigger problem since the major Cyrillic languages are generally not written with accents, unlike Greek. —CodeCat 21:27, 26 January 2016 (UTC)

I think we should complain a lot more vigorously about this one. Otherwise it makes the whole foreign-language component of enwikt much harder to use. Benwing2 (talk) 22:35, 26 January 2016 (UTC)

Yes, fully agree. This has been bugging me, for Russian searches should include words spelled with е and ё. It also applies to Arabic words with and without diacritics, Hindi words with and without nuqta and "chandra". --Anatoli T. ^{(обсудить}/^вклад) 23:56, 26 January 2016 (UTC)

Oops, I just realised that this is about my old complaint. --Anatoli T. ^{(обсудить}/^вклад) 23:58, 26 January 2016 (UTC)

We already track at least some instances of "form of"-type templates linking to a redlink, e.g. Category:Plurals with a red link for singular. If it wouldn't be too "expensive", I think it would be useful to also track cases where something is defined as an alternative form of a redlink: e.g. praedaturus currently defines itself as an "Alternative form of praeurus", which is currently a redlink. It seems like every case would need attention, either to create the linked-to entry or to clean up the linking entry. It could also be useful to track inflected forms ("third person singular", etc) of redlinks. - -sche (discuss) 03:56, 27 January 2016 (UTC)

Good idea, and I don't think this is too expensive to do. Benwing2 (talk) 05:46, 27 January 2016 (UTC)

It should probably be done with all form-of templates, shouldn't it? —CodeCat 22:31, 4 February 2016 (UTC)

Yup, I agree. Renard Migrant (talk) 22:32, 4 February 2016 (UTC)

Yes. It would be especially good (but not absolutely necessary) if we could figure out how to stop entries like Appendix:Proto-Algonquian/mehɬali from going in the category, or at least if we could put non-NS:0 pages into a separate subcategory. - -sche (discuss) 22:48, 4 February 2016 (UTC)

Can't this be done from the dump rather than in near-real time? Then it imposes no cost on the servers, except for the download. DCDuring TALK 00:47, 5 February 2016 (UTC)

In the watchlist, pages with new changes are highlighted in bold. Recently I've noticed that the bold formatting is removed when I click an item (i.e. it suddenly goes "unbold"). Since I often middle-click, to open pages in separate tabs, this can be a bit disconcerting. Bug? Equinox ◑ 17:03, 27 January 2016 (UTC)

I think this was intended to be a feature, not a bug (since after clicking, it's no longer a new change). But I too find it very annoying and would like this feature removed. --WikiTiki89 18:52, 27 January 2016 (UTC)

Yeah, it's bad for usability because it unexpectedly changes the size of a click target. Equinox ◑ 18:58, 27 January 2016 (UTC)

I want to create an entry for C|N>K (computing slang for "coffee through nose to keyboard", i.e. laughing hard at a posted message); cf. snark, splork. The pipe character | cannot be used in page titles. What should I call the entry? Equinox ◑ 23:19, 28 January 2016 (UTC)

Probably this: Unsupported titles/C vertical line N greater than K. (short link: C|N>K)

Compare: Unsupported titles/Vertical line and Unsupported titles/Greater than. --Daniel Carrero (talk) 23:27, 28 January 2016 (UTC)

I don't really like that: "greater than" is not what the sign means here. Perhaps "C through N to K" is better. But I still don't get how to do it. How do I give the page its proper display title, since I can't put | inside the template? And how do I make {{en-intj}} display it properly? Equinox ◑ 23:33, 28 January 2016 (UTC)

1. Create the page with the descriptive title starting with Unsupported titles/, like in the examples we discussed. I don't mind if you use Unsupported titles/C through N to K.
2. You can use {{en-intj|head=C{{!}}N>K}}, I tested it. {{!}} generates the | usable in templates.
3. Edit Template:unsupported imitating the entries already there. They are redirects from the normal form (C|N>K) to the descriptive entry name (C through N to K). I suggest setting up "CNK" as a usable shortcut. If you do this, then later people can use {{unsupported|CNK}} which would be the same as ].
4. Edit MediaWiki:Common.js, look for the list that starts with "Left_curly_bracket" and add the new entry there. This changes the displayed entry title. Clean your cache (Ctrl+F5 or whatever) to see the results.
5. Also list the new entry in Appendix:Unsupported titles.

--Daniel Carrero (talk) 23:54, 28 January 2016 (UTC)

Done steps 1 and 2. Did not understand step 3 so stopped there. Equinox ◑ 23:59, 28 January 2016 (UTC)

I'll explain. See this line from Template:unsupported:

|.|period|full stop = ]

It means that people are able to use ".", "period" and "full stop", yielding the same result: a link for the right page, with the right title.

• {{unsupported|.}} = .
• {{unsupported|period}} = .
• {{unsupported|full stop}} = .

So you can add a line like this:

|CNK|C{{!}}N>K|C through N to K| = ]

This would make these three template calls work:

• {{unsupported|CNK}}
• {{unsupported|C{{!}}N>K}}
• {{unsupported|C through N to K}}

--Daniel Carrero (talk) 00:08, 29 January 2016 (UTC)

Coo. I never thought I'd see an uglier programming language than mIRC script! Equinox ◑ 00:18, 29 January 2016 (UTC)

LOL. That should probably be Luaziced at some point. --Daniel Carrero (talk) 00:30, 29 January 2016 (UTC)

It would be faster too. Large switches are rather slow, I remember that from the pre-Lua days. —CodeCat 00:39, 29 January 2016 (UTC)

I've been trying, but I cannot get {{unsupportedpage}} to actually display C|N>K as the title of the page. Any ideas? —Aɴɢʀ (talk) 16:36, 29 January 2016 (UTC)

@Angr:  Done. I used MediaWiki:Common.js as explained above. {{unsupportedpage}} is just a {{DEFAULTSORT}}, it does not appear to be able to change page titles anywhere. --Daniel Carrero (talk) 16:50, 29 January 2016 (UTC)

In that case, it's unfortunate that its documentation says, "The effect is to change the displayed header on the page". —Aɴɢʀ (talk) 16:52, 29 January 2016 (UTC)

You're right. That template should probably be orphaned+deleted, but I don't have much time to look into it carefully right now. For the moment, I edited the documentation to remove false information. --Daniel Carrero (talk) 17:10, 29 January 2016 (UTC)

i don't know if i'm missing something, but it seems like the template:pl-noun doesn't have a parameter to display a plural form, like the english entries do. if the layout policies say that foreign language entries shouldn't have such an option, please correct me, but i think it would be beneficial (at least a little bit). that said, i'm not really skilled in writing templates, only some simple wikipedia ones, so should we decide that it will be implemented, someone will have to do it properly.

profesjonalizm • reply 06:35, 30 January 2016 (UTC)

@Profesjonalizm: I think it is not there because it can be found in the declension tables. --kc_kennylau (talk) 07:23, 30 January 2016 (UTC)

@Kc kennylau: ok, you're right, thanks for the info profesjonalizm • reply 09:47, 30 January 2016 (UTC)

For Russian, we include gen sg and nom pl in the headword line (as well as gender and animacy); that's done because these two forms help relatively experienced speakers figure out the rest of the declension. Perhaps for Polish the gender and animacy is enough; one of the main things the gen sg and nom pl help with is pinpointing the accent pattern, which doesn't really have an equivalent in Polish. The nom pl also helps with the many nouns that have irregular nominative plurals; perhaps such nouns aren't so common in Polish? (I don't know Polish so I can't say.) Note that Russian entries also come with a full declension table. Perhaps some additional forms should be added to the Polish noun headwords? Benwing2 (talk) 06:59, 1 February 2016 (UTC)

I have been experimenting in a few languages with a different format, in which the inflection table doesn't fully collapse but shows only the principal parts. It's currently used for Dutch, Finnish, Northern Sami and a few more Finnic languages. —CodeCat 22:26, 4 February 2016 (UTC)

I've even been planning to use CodeCat's new format for Yiddish adjective declension tables. --WikiTiki89 01:14, 5 February 2016 (UTC)