Wiktionary:Grease pit/2015/November

Help someone fix a small bug in your code project: It's Google Code-In time!

Are you a developer and have small, self-contained, "easy" software bugs in your Wikimedia/Wiktionary code that you would love to get fixed?
Does your Wiktionary gadget use some deprecated API calls?
Would you enjoy helping someone port your Wiktionary template to Lua?
Does the documentation of your code need some improvements?
Do you enjoy mentoring to a new contributor fixing small tasks?

Google Code-In (GCI) will take place again in December and January: a contest for 13-17 year old students to provide small contributions to free software projects. Wikimedia will apply again to take part and would like to offer a wide range of tasks. Just one example: Multimedia saw some impressive achievements in last year's contest!

Tasks should take an experienced contributed about two-three hours ("beginner tasks" also welcome which are smaller) and can be of the categories Code, Documentation/Training, Outreach/Research, Quality Assurance, and User Interface/Design. Can you imagine to be a mentor? Check the wiki page and if something is unclear, please ask on the talk page!

Thank you! --AKlapper (WMF) (talk) 16:06, 3 November 2015 (UTC)[reply]

Fixing wanted categories: "Japanese terms spelled with X" and "Japanese terms spelled with X read as Y"

@Atitarev Hello Anatoli et al ... I'm not exactly sure who works on Japanese, maybe you'd know. There are a bunch of missing categories in Special:WantedCategories of the form "Japanese terms spelled with X" and "Japanese terms spelled with X read as Y". I'm wondering if someone could create them who knows how to do it. By looking at existing categories of this form I can get an approximate sense of how to create them but it looks like you need some specialized knowledge, e.g. for "Japanese terms spelled with X" there's a number of some sort (a stroke count?) and for "Japanese terms spelled with X read as Y" there's a value that often shows up as "kun", and sometimes the parameter value corresponding to Y isn't the same as Y itself (perhaps this is a mistake). Whoever does it, can you look at least through the first 250 entries for categories of this sort? Thanks! Benwing2 (talk) 06:45, 4 November 2015 (UTC)[reply]

I know (more or less) how to create them manually, a rather tedious task, but there are too many wanted ctagories. Someone knows some shortcuts - User:Chuck Entz? - some smart templates, which simplify the creation. --Anatoli T. ^{(обсудить}/^вклад) 06:58, 4 November 2015 (UTC)[reply]

For the "Japanese terms spelled with X" entries, you use {{charactercat}}: the first parameter is the language code, the second is the character itself, and there's a named sort parameter, consisting of the radical followed by a 2-digit stroke count. If you go to the entry for the character and look at the Han Character subsection of the Translingual section, there's a {{Han char}} template, which has the radical in the rad= parameter and the stroke count in the as= parameter.

Picking a category at random as an illustration- Category:Japanese terms spelled with 輸:

{{charactercat|ja|輸|sort=車09}}
{{Han char|rn=159|rad=車|as=09|sn=16|four=58021|canj=JJOMN|ids=⿰車俞}}

In case you're interested, 車 is radical 159, with 7 strokes. The rest of the character is 9 strokes, for a total of 16 strokes. The remaining parameters have to do with the values needed for different input methods.

For the "Japanese terms spelled with X read as Y" categories, you would use {{ja-readingcat}}, except I came up with a shortcut called {{jrcez}}. You subst it to produce {{ja-readingcat}} with the kanji and hiragana parameters supplied from the pagename. It's really kludgy, but it does the job. There are two optional parameters, which are the reading types. Kanji can be read quite a number of different ways, and the readings are classified using an etymologically-based system: kun readings are native Japanese, on readings are borrowings from Chinese, with different subtypes depending on when and from which dialect they were borrowed, such as goon, kan'on, etc. there are a few more types based on other criteria, such as nanori and kan'yōon. In some cases there's more than one reading type for a given reading, which is why the template takes two optional parameters.

There's no easy way to supply the reading type: you have to look through the Japanese section and hope you find a reading that matches. Given that contributors don't always correctly match up the syllables with the kanji, the readings on the character pages are incomplete, and there are some kanji that simply refuse to follow the rules, there's no guarantee you'll find anything. When in doubt, omit the reading type, and someone will find it in a cleanup category later and fix it.

I'll just give a very basic example: for Category:Japanese terms spelled with 輸 read as ゆ, {{subst|jrcez|kan'yōon}} will produce {{ja-readingcat|輸|ゆ|kan'yōon}}

Finally, for "Japanese terms read as Y" categories, I just use {{subst:jraez}} with no parameters.

If you ever feel so inclined, you could probably easily add pagename-parsing code to the module(s) to make all the kanji and hiragana parameters unnecessary. Chuck Entz (talk) 10:21, 4 November 2015 (UTC)[reply]

Awesome, thanks very much for the detailed info. I'll try to take a look. In the meantime, if you feel like creating some of these empty categories, please be my guest! There aren't too many in the first 250 entries, and that would be a good start. Benwing2 (talk) 11:25, 4 November 2015 (UTC)[reply]

@Chuck Entz Could you take a look at Special:WantedCategories and take care of some of the Japanese categories? I've dealt with most of the remainder. Benwing2 (talk) 09:04, 13 November 2015 (UTC)[reply]

Module invocation time limit

Is there a cumulative time limit that cuts off module calls on a page? After 181 conjugation tables at User:Wikitiki89/he-verb-test, the 182nd and anything subsequent will result in a strange [[#invoke:he-verb]] link. --Wiki Tiki 89 21:17, 6 November 2015 (UTC)[reply]

A the end of the page in the editing mode - "Parser profiling data: Post-expand include size 2094766/2097152 bytes"

It seems a page cannot have ~2MB wikitext (templates expanded). --Dixtosa (talk) 21:22, 6 November 2015 (UTC)[reply]

Interesting. It seems you're right. I just tried removing some of the text that the module returns and previewing and it fixes the issue. --Wiki Tiki 89 21:30, 6 November 2015 (UTC)[reply]

Although another strange thing is now I have divided the page into subpages which are all transcluded in turn at User:Wikitiki89/he-verb-test, and now much less content fits on the page, with three entire subpages failing to be included. Previously only a small part of what is now the last subpage was failing. --Wiki Tiki 89 21:45, 6 November 2015 (UTC)[reply]

There is a time limit of 10 seconds for script-execution time (愛 would run over it any time background tasks slowed the system down, but this diff seems to have fixed it). As noted above, though, that's not your problem. Chuck Entz (talk) 22:55, 6 November 2015 (UTC)[reply]

Proper noun

The time allocated for running scripts has expired.

1. A female given nameThe time allocated for running scripts has expired.

(Nope, it's baa~ck) —suzukaze (t・c) 03:41, 29 December 2015 (UTC)[reply]

Sauraseni Prakrit

Can w:Sauraseni Prakrit (psu) be listed as having Proto-Indo-Aryan (inc-pro) as an ancestor in Module:languages/data3/p? — This comment was unsigned.

Done - -sche (discuss) 22:48, 14 November 2015 (UTC)[reply]

Thanks! Now I can use {{inherited}} for Hindi! Aryamanarora (talk) 17:17, 15 November 2015 (UTC)[reply]

How do you go from a template boolean value to Lua?

If you pass a value in a template of 1, true, yes, etc, it will be evaluated as true- how can I parse these values as a native boolean in Lua? DTLHS (talk) 21:10, 8 November 2015 (UTC)[reply]

Set the variable value as a string comparison: local booleanvar = (args["parameter name"] == "true" or args["parameter name"] == "1" or args["parameter name"] == "yes"). — Ungoliant ^(falai) 21:21, 8 November 2015 (UTC)[reply]

Thanks, it seems like there should be a built-in way to do this. Do you know of a list of all values in templates that are considered boolean true? DTLHS (talk) 21:23, 8 November 2015 (UTC)[reply]

In the templates I’ve seen using this any value is considered true. This means that you can use simply local booleanvar = (args["parameter name"] ~= nil and args["parameter name"] ~= ""), or even just booleanvar = (args["parameter name"] ~= nil), but this will make {{template|parameter name=}} evaluate as true. — Ungoliant ^(falai) 21:27, 8 November 2015 (UTC)[reply]

Module:parameters does a lot of the work in parsing template arguments for you, including this. —CodeCa t 21:33, 8 November 2015 (UTC)[reply]

Genitive indefinite article for neuter uncountable nouns

I think the article for the genitive indefinite article is supposed to be eines instead of just ein, as seen in Heute, for instance. See {{de-decl-noun-n}} to find the error and fix it. Happy typo fixing. --Lo Ximiendo (talk) 20:44, 9 November 2015 (UTC)[reply]

P.S. Here is the template {{de-decl-noun-table-full}}. --Lo Ximiendo (talk) 02:28, 10 November 2015 (UTC)[reply]

@JohnC5, do you have anything to say about this? --Lo Ximiendo (talk) 07:23, 10 November 2015 (UTC)[reply]

@Lo Ximiendo: Yeah, there was a little copypasta from the accusative cases that never got fixed. Here's the change. —John C5 16:02, 10 November 2015 (UTC)[reply]

Þank ye. --Lo Ximiendo (talk) 20:02, 10 November 2015 (UTC)[reply]

Crash on alert

I'm running Opera 12.16. When I click the alarm bell, the list of notifications pops out, but then the browser crashes. That's new. Korn [kʰʊ̃ːæ̯̃n] (talk) 10:51, 12 November 2015 (UTC)[reply]

roa-jer still works?!

As you can see from my edit to *tropo, roa-jer still works. Is this intentional, if so, why? Shouldn't it add a cleanup category at the very least? Renard Migrant (talk) 23:58, 12 November 2015 (UTC)[reply]

It's still in Module:languages/datax. Perhaps we should add a deprecated = true parameter to the language data modules to make it easier to find and correct uses of deprecated languages before deleting them? --Wiki Tiki 89 00:06, 13 November 2015 (UTC)[reply]

Inconsistent formatting, pos= parameter in Template:m

In the entry misprize, I've edited the etymology like this:

From {{etyl|frm|en}} {{m|frm|mespriser|pos=verb}}, {{m|frm|mespris|pos=noun}}.

I noticed that in the end result, the word "verb" is italicized, but the word "noun" is not. Why is that? --Daniel Carrero (talk) 13:12, 13 November 2015 (UTC)[reply]

It’s because {{pos verb}} exists and {{pos noun}} doesn’t. — Ungoliant ^(falai) 15:11, 14 November 2015 (UTC)[reply]

OK, I created {{pos noun}}, thanks. --Daniel Carrero (talk) 15:23, 14 November 2015 (UTC)[reply]

I think we should delete all those templates and remove the logic that transcludes them. I don't really see any point in them. —CodeCa t 15:45, 14 November 2015 (UTC)[reply]

We can move the logic into the modules. If you meant that you don't see a point in the pos= parameter, then I will have to disagree; it is occasionally useful in disambiguations. --Wiki Tiki 89 16:04, 14 November 2015 (UTC)[reply]

Oh, the pos= parameter is fine. Just not the bit that changes the text when it's a certain string. —CodeCa t 16:16, 14 November 2015 (UTC)[reply]

Then should {{m|en|foo|pos=n}} display n or noun? I think {{m|en|foo|pos=n}} and {{m|en|foo|pos=noun}} should mean the same thing and display the same thing, whether that same this is n or noun. --Wiki Tiki 89 16:20, 14 November 2015 (UTC)[reply]

Definitely "noun". If Wiktionary:Todo/unhelpful abbreviations is any indication, we should avoid abbreviations in entries. (gender and number abbreviations would be exceptions: m, f, p...) --Daniel Carrero (talk) 16:56, 14 November 2015 (UTC)[reply]

Suggestion: "term -> m" by bot

I wonder if a bot could turn all instances of {{term|xxx|lang=yy}} into {{m|yy|xxx}}. Probably that's not urgent work, since the end result in the entries is the same, but it would make the code look more consistent.

Sometimes, people do it manually.[1] When I find {{term}} without a language code, I turn it into {{m|xx}} with the apropriate language code, but when I find {{term}} with the code already, usually I do nothing because I assume a bot could fix it easily. --Daniel Carrero (talk) 14:32, 13 November 2015 (UTC)[reply]

I would be for this. I imagine CodeCat would too. Benwing2 (talk) 14:36, 13 November 2015 (UTC)[reply]

User:CodeCat has tried to do this before, but User:Dan Polansky complains that this is a misuse of the botting policy because there is not enough consensus for the use of {{m}}. --Wiki Tiki 89 14:46, 13 November 2015 (UTC)[reply]

I think this proposal would have a fair chance of passing a vote, I plan to create it later: "Allow bots changing {{term|xxx|lang=yy}} into {{m|yy|xxx}} in all entries."

{{m}} does all the job of {{term}} and is shorter to type. The only difference is that you are required to use a langcode with {{m}} or else it's going to generate a module error. With {{term}}, you could omit the langcode if you wanted and the template would still work, albeit without any functionality associated with langcodes. --Daniel Carrero (talk) 00:04, 14 November 2015 (UTC)[reply]

For reference: Wiktionary:Votes/2014-08/Migrating from Template:term to Template:m. On a favorable reading of that vote, there is 60.9% support for the migration. I think such a vote could have run for a year to get best chance and become even more representative, but some editors wanted the extensions to end so I stopped extending the vote. Even so, it run for 6 months and is probably fairly representative. --Dan Polansky (talk) 08:57, 14 November 2015 (UTC)[reply]

Thank you for linking to that vote. 9 months passed since it ended. I wonder if more people started to get used to {{m}} since. It has been pointed out in the vote that {{m}} has the problem of being a former gender template, but I guess nobody thinks of it as a gender template anymore, or tries to use it as a gender template (it would generate a module error anyway). I note that @Angr and @Lo Ximiendo are 2 users that I have seen replacing {{term}} by {{m}} which did not participate in that vote.

It has been pointed out in the vote that the parameters of {{term}} and {{m}} are not compatible. This is because of the reason I said, {{term}} can be used without language codes. Now that I am currently adding the langcode in all entries lacking it, the transition should be seamless, if people want it. --Daniel Carrero (talk) 10:38, 14 November 2015 (UTC)[reply]

You first need evidence that people want the migration. I certainly don't object to your creating another vote. I would actually cast a support vote since, for this kind of rather arbitrary disagreement about wikicode markup, I consider 60%-majority large enough to be decisive.

Your adding language code everywhere is unlikely to be supported by consensus, but I don't have the energy to raise this as an issue and I don't care enough, so you'll probably succeed with adding lang code everywhere. --Dan Polansky (talk) 10:45, 14 November 2015 (UTC)[reply]

Using {{term}} without a language code places the affected article in a cleanup category, so I don't see why you think adding a language code to it would be unlikely to be supported by consensus. I cannot think of a single coherent reason to object to the practice, and I'm actually paying Daniel to do it. —Aɴɢʀ (talk) 10:49, 14 November 2015 (UTC)[reply]

Placing it in the cleanup category is part of the action that I do not think has consensus, but I am not sure. The fact that you are paying is irrelevant; when that paying remark comes from a person who claims that votes are evil, it is actually pretty amazing. --Dan Polansky (talk)

I'm paying him for it because it's work that urgently needs to be done, unlike starting pointless votes on every tiny aspect of editing. —Aɴɢʀ (talk) 11:13, 14 November 2015 (UTC)[reply]

"work that urgently needs to be done": oh really? Wow. --Dan Polansky (talk) 11:23, 14 November 2015 (UTC)[reply]

In Wiktionary:Beer parlour/2013/April#Template term and lang parameter, most people supported making lang= mandatory in {{term}}, but many opposed showing "???" in the entry when there was no language code, which I personally agree would be a bad idea. I noticed that in that discussion, you (Dan Polansky) opposed making the lang= mandatory for English.

Adding the langcode to {{term}} is just adding more information to the entry. How controversial can be turning an unformatted, unanchored link to a Spanish word into a formatted, anchored link to a Spanish word, provided I make the effort to add the language codes accurately?

The discussion about doing it as a paid job happened at Wiktionary:Beer parlour/2015/October#Boring cleanup work for money. There, aside from Angr, @Metaknowledge too (I suppose I can count @Jberkel as well; not sure about @Panda10) demonstrated support for the idea and nobody opposed it. --Daniel Carrero (talk) 11:37, 14 November 2015 (UTC)[reply]

I don't oppose paid edits per se; I actually quite like the idea. But I oppose paid non-consensual edits. I would argue that when the edits are paid, the degree of scrutiny and skepticism about there being consensus needs to be higher, and any doubt needs to be taken even more seriously than with unpaid non-consensual edits.

Can you please post a list of the editors from that BP discussion who you think support making lang= mandatory? --Dan Polansky (talk) 11:51, 14 November 2015 (UTC)[reply]

I'm going to say I wasn't part of that discussion but I support

making lang= mandatory for {{term}}, and fixing all existing instances;
converting all instances of {{term}} to {{m}}, or all those that have a language code if (1) isn't possible;
deprecating {{term}}, and removing it once all instances have been converted;
I also think similar things should be done for certain other templates, e.g. {{cx}} -> {{lb}}, but that's another issue. Benwing2 (talk) 12:07, 14 November 2015 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ We already had a 6-month long vote on your item 2 so I don't see why you are saying that in this discussion. This discussion is not a vote and cannot replace the 6-month vote. We also had a vote on your item 4 with no consensus in either direction.

@Daniel Carrero: Can you please post a list of the editors from that BP discussion who you think support making lang= mandatory? --Dan Polansky (talk) 12:11, 14 November 2015 (UTC)[reply]

Yes, "urgently needs to be done". All text not in English must be labeled with its language code in order for the HTML to be correct, so that fonts render correctly and screen readers work properly. If any non-English text is not labeled with its language code, it is an error. —Aɴɢʀ (talk) 12:21, 14 November 2015 (UTC)[reply]

I forgo comment on this; the matter is hopefully as obvious to the reader as it is to me. I still hope to get a response from Daniel. --Dan Polansky (talk) 12:24, 14 November 2015 (UTC)[reply]

Maybe Daniel's count will be different from mine, but when I peruse Wiktionary:Beer parlour/2013/April#Template term and lang parameter, I see 7 editors supporting the obligatoriness of the lang parameter (CodeCat, Mzajac, Ruakh, Atitarev, Msh210, ZxxZxxZ, PalkiaX50), 6 editors taking no position on the obligatoriness of the lang parameter (Widsith, Liliana-60, Chuck Entz, Metaknowledge, Mglovesfun, and KYPark), and only 1 editor opposing the obligatoriness of tha lang parameter (Dan Polansky). Add to that the participants in this thread who support obligatory lang (Daniel Carrero, me, Benwing2), plus the supporters of Wiktionary:Votes/2014-08/Migrating from Template:term to Template:m (who can be assumed to support obligatory lang for {{term}} since the language code is obligatory for {{m}}, though opposition to that vote cannot be taken as opposition to obligatory lang), and I'm left with the distinct impression that you're the only Wiktionarian who doesn't want the lang parameter of {{term}} to be obligatory. —Aɴɢʀ (talk) 12:58, 14 November 2015 (UTC)[reply]

Dan Polansky, I see no problem in @Benwing2 saying their opinion. Even though I agree that this alone does not have the power to overthrow a vote by itself, it demonstrates more support in the direction of using {{m}}. Benwing is another person supporting {{m}} over {{term}} who did not participate in that vote, which leads me to believe that if the issue of "Template:term X Template:m" were voted again, it could pass.

Sure, I don't mind making the list you asked. You said "that discussion", but we have 2 discussions:

Discussion One: Wiktionary:Beer parlour/2013/April#Template term and lang parameter
Discussion Two: Wiktionary:Beer parlour/2015/October#Boring cleanup work for money

The first is about the lang= parameter, the second is about my work.

My list (From Discussion One): @CodeCat, Mzajac, Ungoliant MMDCCLXIV, Ruakh, Atitarev, msh210, ZxxZxxZ, PalkiaX50.

The first 6 people explicitly said along the lines of "I support making langcodes mandatory."

The other two (ZxxZxxZ and PalkiaX50) said "I support the change", which I believe amounts to "I support displaying an error message in the lack of a language code".

I did not count @Chuck Entz, because I am not sure about him. He spent that discussion expressing his opposition to the "???" appearing in entries as a warning and suggesting other ways of displaying the error. It could perhaps constitute a support towards making lang= mandatory, but I don't really know.

When you said "that discussion", did you want me to count how many people said they support lang= being mandatory in the Discussion Two? This would have been pointless. Consensus for a mandatory lang= has already been established in the previous discussion, so I didn't ask people to repeat their positions in the second discussion. It's interesting to note that you yourself said you would cast a support vote for the migration of {{term}} -> {{m}}, so I wonder what is your motivation for questioning the consensus or the legitimacy of the projects mentioned here. --Daniel Carrero (talk) 13:06, 14 November 2015 (UTC)[reply]

Thanks for the ping. On that page, I supported migration to a template that requires a lang parameter for non-English only, which is not how my opinion was represented here. Even if consensus is to require lang for all languages, conversion from {{term}} to {{mention}} can only take place for words whose language is known (since {{mention}} technically requires a lang parameter). If we require lang for all languages and we manage to convert all uses of {{term}}, then that means we know the language of every word that now uses {{term}} (great!); and then the documentation for {{mention}} should note that, for the future, terms in unknown languages should simply not use a template. (We used to use {{Hebr}} et al. for those, but, alas, those are no longer; now there's no way afaik to represent them in the right script.)—msh210℠ (talk) 23:13, 18 November 2015 (UTC)[reply]

No way to represent what in the right script? —CodeCa t 23:16, 18 November 2015 (UTC)[reply]

@msh210: {{m|und|term-in-unkown-language|sc=Script}} ("und" is the code for "Undetermined language"). --Wiki Tiki 89 00:35, 19 November 2015 (UTC)[reply]

For the record, I now support moving {{term}} to {{m}}, as well as {{context}} to {{label}}. —Μετάknowledge^{discuss/deeds} 17:42, 14 November 2015 (UTC)[reply]
The other vote, actually poll, is Wiktionary:Votes/2014-08/Templates context and label. I encourage people to post to the poll even now, but indent their votes so they are clearly marked as late. Wiktionary talk:Votes/2014-08/Templates context and label contains some preferences estimated from actual editing in the mainspace. --Dan Polansky (talk) 17:50, 14 November 2015 (UTC)[reply]

q with tilde

Is there any way to render this? It's a variant of Old French and Middle French que, it's more like a short hand as compared to tẽps where the tilde replaces the letter m, in this case it just replaced the rest of the word. Unlike ẽ for est (“(it) is”) I haven't found a way to enter it. I tried copying and pasting a combining tilde and it didn't work. Renard Migrant (talk) 18:07, 16 November 2015 (UTC)[reply]

I recently added the combining diacritics to the character insertion box under Miscellaneous. Clicking the tilde after typing a q gives q̃. Is that not what you want? —Aɴɢʀ (talk) 18:44, 16 November 2015 (UTC)[reply]

@Angr: Could you also add the combining Ancient Greek accent marks under Greek? I find editing the edit tools very frustrating, especially with combining marks. —John C5 00:35, 17 November 2015 (UTC)[reply]

Do you want any of them besides the macron and breve? I think all of the others have precomposed characters that are already listed under Greek. —Aɴɢʀ (talk) 15:20, 17 November 2015 (UTC)[reply]

Sometimes combining characters are an easier way to input precomposed characters, since they are normalized by the wiki software and you don't have to look through long lists of the same letters. --Wiki Tiki 89 15:43, 17 November 2015 (UTC)[reply]

@Angr: Currently all length-specified characters must be of the order vowel with length mark (ᾰ, ᾱ, ...) + combining accent mark and not the other way around. So I don't need the macrons or breves but I do need all the others. —John C5 15:59, 17 November 2015 (UTC)[reply]

OK. I use the macrons and breves for the w= parameter of {{grc-IPA}}, where the order of the diacritics doesn't matter (ά + combining macron works just as well as ᾰ + acute accent). I'll add them later today. —Aɴɢʀ (talk) 16:16, 17 November 2015 (UTC)[reply]

Has {{grc-IPA}} been fixed so that it accepts combining breves? Formerly you had to add the non-combining macron or breve character after the relevant vowel. —John C5 16:37, 17 November 2015 (UTC)[reply]

I guess it must have been; at any rate, I always use the combining breves and macrons in it and it works. —Aɴɢʀ (talk) 16:42, 17 November 2015 (UTC)[reply]

@JohnC5: Re. "Currently all length-specified characters must be of the order vowel with length mark (ᾰ, ᾱ, ...) + combining accent mark and not the other way around.": I think the wiki software normalizes this as well. Try inputting it the wrong way and press preview and see if it changes to the right order. --Wiki Tiki 89 16:54, 17 November 2015 (UTC)[reply]

@Wikitiki89: So, the problem does appear to be fixed for {{grc-IPA}} in the form “vowel with length + accent mark” as seen here (no accent appears):

(5^th BCE Attic) IPA^(key): /ský.los/
(1^st CE Egyptian) IPA^(key): /ˈsky.los/
(4^th CE Koine) IPA^(key): /ˈscy.los/
(10^th CE Byzantine) IPA^(key): /ˈscy.los/
(15^th CE Constantinopolitan) IPA^(key): /ˈsci.los/

As for linking, the order “vowel with accent + length” does not link or display correctly (σκύ̆λος (skúlos)) whereas “vowel with length + accent mark” does (σκῠ́λος (skúlos)). If we could get {{grc-IPA}} to accept the “vowel with length + accent mark”, that would be great, though there are already a heap of things that need to be fixed in {{grc-IPA}}. —John C5 17:14, 17 November 2015 (UTC)[reply]

Oh, strange that the wiki software does not normalize it. It does with other combinations. --Wiki Tiki 89 18:14, 17 November 2015 (UTC)[reply]

OK, there are now combining diacritics listed in the Greek section. —Aɴɢʀ (talk) 19:07, 17 November 2015 (UTC)[reply]

W00t! —John C5 19:40, 17 November 2015 (UTC)[reply]

It is annoying that the headword display and the pronunciation template take different orders, because it would be so easy to just copy the headword display and paste it into {{grc-IPA|w=}}, but I just learned at νίκη that it doesn't work (so what I said above about the order not mattering is wrong!): the headword display has "ῑ + acute accent", while the pronunciation template has to have "ί + macron" or it won't display correctly. —Aɴɢʀ (talk) 20:28, 17 November 2015 (UTC)[reply]

It seems to me that the best solution is to get {{grc-IPA}} to support the headword order. —John C5

Thank you. Renard Migrant (talk) 11:18, 18 November 2015 (UTC)[reply]

Category for pi-decl-noun

{{pi-decl-noun}} needs to be documented. Over. --Lo Ximiendo (talk) 07:26, 18 November 2015 (UTC)[reply]

@CodeCat, if you're busy or not, feel free to do what you have to do. --Lo Ximiendo (talk) 16:06, 19 November 2015 (UTC)[reply]

Why don't you do it? —CodeCa t 16:26, 19 November 2015 (UTC)[reply]

Plurals and diacritics for ha-noun

As stated on my userpage, I wish {{ha-noun}} is similar to {{ar-noun}} when it comes to diacritics and plural forms. --Lo Ximiendo (talk) 07:28, 18 November 2015 (UTC)[reply]

UPDATE: I remodeled {{ha-noun}} to make it similar to {{ang-noun}}. --Lo Ximiendo (talk) 01:52, 22 November 2015 (UTC)[reply]

@CodeCat The display for the plural looks messed up, as seen in lacca. Could someone add a parameter for a third plural, just in case? --Lo Ximiendo (talk) 02:20, 22 November 2015 (UTC)[reply]

@CodeCat: Never mind, I fixed it. --Lo Ximiendo (talk) 02:59, 22 November 2015 (UTC)[reply]

suffixsee and a weird newline

In the entry -iero, somehow the template {{suffixsee}} is generating an additional newline below it, causing the section "Usage notes" to be further down in the text. Perhaps it's something in Module:compound. Could someone fix that, please? --Daniel Carrero (talk) 11:00, 18 November 2015 (UTC)[reply]

MW:Extension:CategoryTree parser function is the culprit. We could add this .CategoryTreeTag + p br:first-child{display:none;} to global CSS before developers fix it. --Dixtosa (talk) 11:42, 18 November 2015 (UTC)[reply]

@Dixtosa Did it, thanks. --Daniel Carrero (talk) 23:43, 18 November 2015 (UTC)[reply]

Remove link to nonexistent Old Irish Wiktionary

Category:Old Irish language links to sga.wiktionary.org but that Wiktionary does not exist. Please fix the link, thanks. --Daniel Carrero (talk) 23:40, 18 November 2015 (UTC)[reply]

That's the case for every language that doesn't have a Wiktionary. --Wiki Tiki 89 00:40, 19 November 2015 (UTC)[reply]

This happens because lang:getWikimediaLanguages(), called in Module:category tree/langcatboiler line 9, is returning a value. That in turn happens because "sga" is a valid WikiMedia language code. I don't know if there is a way within Lua to test if there is specifically a Wiktionary for that language. —CodeCa t 00:48, 19 November 2015 (UTC)[reply]

Apparently it is possible to test for valid interwikis, but they only give us a list of Wiktionaries. So we can't use it to test if a language has a Wikipedia or any other project. —CodeCa t 00:57, 19 November 2015 (UTC)[reply]

But we don't really need to check for Wikipedias, do we? Only for Wiktionaries. --Wiki Tiki 89 01:19, 19 November 2015 (UTC)[reply]

I agree with Wikitiki89. If there's a test for valid Wiktionaries, that sounds perfect.

On that note, there are 174 Wiktionaries according to meta:Wiktionary. I would suggest manually listing all the 174 in a module if everything else fails. We have Module:wikimedia languages specifically for the weird stuff, such as the existence of "zh-min-nan.wiktionary.org" and the separated sh/bs/hr/sb Wiktionaries. --Daniel Carrero (talk) 10:03, 19 November 2015 (UTC)[reply]

Change in Watchlist options box on Watchlist page

On my watchlist page there now appears a pulldown box for the time period to be covered by the watchlist. This apparently replaces the blue numbers for the number of hours or days to be covered by the watchlist. This change would be of little consequence were it not for the fact that the pulldown box doesn't have any effect. Of course I can change the day-fraction in the url to achieve finer selection that either of the ways presented in the watchlist options box, but one would expect the user interface to work. I don't understand why someone (I wonder who) felt compelled, entitled, and sufficiently skilled to make the change properly. DCDuring TALK 01:38, 19 November 2015 (UTC)[reply]

Did you try pressing "Go"? But I still think that it's a rather pointless change. --Wiki Tiki 89 01:46, 19 November 2015 (UTC)[reply]

"Go" works, but my habit was using the page refresh. Like many pointless changes, it has negative value because it disrupts user habits. Had there been a vote, this would not have succeeded. I note that my WP watchliust does not have the change, so it must have been local. Will anyone 'fess up? (I don't think so.) DCDuring TALK 02:26, 19 November 2015 (UTC)[reply]

Checking RecentChanges, restricted to the Mediawiki namespace, the only pages which have been edited in the past five days are MediaWiki:Common.css and MediaWiki:Edittools, neither in a way that would affect the watchlist. It seems it was a software update. RecentChanges still has the links like the watchlist used to have (which I too prefer). We could probably re-add links, however, in the same way that we added the Votes box. - -sche (discuss) 02:56, 19 November 2015 (UTC)[reply]

The devs tend to use us a Guinea pigs and roll things out here before Wikipedia. --Wiki Tiki 89 16:03, 19 November 2015 (UTC)[reply]

We are alpha testers you should be proud xD --Dixtosa (talk) 18:07, 19 November 2015 (UTC)[reply]

If they were to be testing for user response - and actually listened - I'd be happy. In the case of this watchlist box, the position of the "go" button, below the line, can be interpreted as meaning that it has nothing to do with what is above the line. (That is what I assumed initially and is what I based my habits.) I keep on making the apparently unwarranted assumption that the MW user interface designers are so good that one never has to second-guess the UI: whatever method is subconsciously led to do by the UI is the best method for accomplishing the task, with obvious exceptions. DCDuring TALK 18:21, 19 November 2015 (UTC)[reply]

I think I see what they are trying to do: bias the refresh process to favor one hour, presumably to lower the load on the server. No matter what interval one has selected, the dropdown box seems to default to 1 hour for the next "Go". DCDuring TALK 20:53, 19 November 2015 (UTC)[reply]

I have it set to default to 3 days in prefs, so the dropdown box does default to 3 days. Maybe if you have the pref set to the default (which is 7 days), then it ignores it and defaults to the first item in the dropdown list. Silly bug, but I would not put it past the devs. They do seem to be completely disinterested in the users' opinions. --Wiki Tiki 89 20:58, 19 November 2015 (UTC)[reply]

I tried it in Edge (first use thereof) and the behavior seems to be that it remembers whatever choice was last made, provided it is one of the dropdown choices, except for 2 hours, which, together with any other choice, whether made on preferences or in the url, leads the dropdown default going to 1 hour. Sloppy. DCDuring TALK 22:22, 19 November 2015 (UTC)[reply]

Cleanup category

Is it possible to have {{R:DIL}} put an entry in a cleanup category whenever its first positional parameter is absent or consists of anything other than numbers? For example {{R:DIL}} with no parameter, {{R:DIL|foo}}, and {{R:DIL|2 bar}} would all put the entry into (say) Category:RDIL needing cleanup, but {{R:DIL|123}} would not put the entry to the category. —Aɴɢʀ (talk) 20:34, 21 November 2015 (UTC)[reply]

There would need to be some Lua support. In Lua, your question would be simple, just mw.ustring.match(text, "^[0-9]+$"). I have been thinking that it would be relatively trivial to create a module that exposes the standard Lua string functions to templates. However, these would also open up the possibility of unknowing editors using these functions in a rather inefficient way (templates are slower and less efficient than modules), which would then end up weighing heavier on the system. So while I think it's a helpful idea, I don't know if it would be a good idea. —CodeCa t 20:39, 21 November 2015 (UTC)[reply]

If you could make a module for this template, I'd be very grateful. The online Dictionary of the Irish Language recently changed the way the URLs of entries work, so I've had to change the template so the links work. But there are over 800 transclusions of the template and I'll lose track of what's already been fixed if I simply go through WhatLinksHere. —Aɴɢʀ (talk) 20:57, 21 November 2015 (UTC)[reply]

Apparently, we already have Module:string. It's not really very well documented though. —CodeCa t 20:59, 21 November 2015 (UTC)[reply]

OK, but I don't know how to use it to do what I'm asking for. —Aɴɢʀ (talk) 21:14, 21 November 2015 (UTC)[reply]

Maybe you'd be better off asking someone to generate a cleanup list that you can edit to mark the ones that are done. Depending on the recentness of the dump it's based on, the number of false positives might not be too bad. Chuck Entz (talk) 21:20, 21 November 2015 (UTC)[reply]

Done How does that look as a first approximation? --Catsidhe ^{(verba, facta)} 01:09, 22 November 2015 (UTC)[reply]

It works great, thanks! And thanks @Catsidhe and @Embryomystic for helping the cleanup efforts! —Aɴɢʀ (talk) 14:01, 22 November 2015 (UTC)[reply]

Edit request: interwiki link

Could someone please add a wikilink to [[sv:Wiktionary:Stilguide/Vilka ord skall tas med]] on Wiktionary:Criteria for inclusion? Skalman (talk) 22:10, 21 November 2015 (UTC)[reply]

Done --Wiki Tiki 89 22:16, 21 November 2015 (UTC)[reply]

Proto-Norse translitteration

All {{mention}}s of Proto-Norse seem to trigger superfluous translitteration: e.g. *fō. Presumably this is for the sake of the handful of attested words written in runes; but is there any way to disable this for reconstructed words? --Tropylium (talk) 23:48, 21 November 2015 (UTC)[reply]

The only way I see to do this is to add Latn as a script for the language. But then it would also end up in the list of the language's scripts. —CodeCa t 00:04, 22 November 2015 (UTC)[reply]

Well, theoretically at least adding a distinct "Proto-North Germanic" should be possible… --Tropylium (talk) 02:10, 22 November 2015 (UTC)[reply]

Adding "Latn" as one of the scripts (and then suppressing transliteration of it) seems like the better option. - -sche (discuss) 23:04, 22 November 2015 (UTC)[reply]

Latn is never transliterated, the modules already have exceptions for that. —CodeCa t 23:11, 22 November 2015 (UTC)[reply]

You can always suppress transliteration with tr=-, so {{m|gmq-pro|*fō|tr=-}} renders as *fō. That's a few keystrokes fewer than {{m|gmq-pro|*fō|sc=Latn}}, which also renders as *fō. —Aɴɢʀ (talk) 10:24, 23 November 2015 (UTC)[reply]

I think the intent was adding Latn as one of the default scripts, so that {{m|gmq-pro|*fō}} by itself will automatically not be transliterated. --Wiki Tiki 89 14:57, 23 November 2015 (UTC)[reply]

I wonder if it would be desirable to change script detection so that, if all else fails, it tries Latn regardless of whether it was included in one of the language's scripts? —CodeCa t 15:49, 23 November 2015 (UTC)[reply]

Sounds like a decent idea to me. I know there are occasional m and l links labeled "Russian" but with Latin characters, and I imagine it must be the same for at least some other languages. Benwing2 (talk) 08:31, 24 November 2015 (UTC)[reply]

Yes, that occurs from time to time for Ancient Greek too. —John C5 14:49, 24 November 2015 (UTC)[reply]

For Russian, there are occasional legitimate cases of this, but for Ancient Greek, I don't think there are. I really don't think this is a good idea. It's not a bad idea, but it's not a good idea either. --Wiki Tiki 89 14:55, 24 November 2015 (UTC)[reply]

tr=- seems like a sufficient solution for the type of cases I had in mind for now (i.e. as long as we're not going to work on a separate Proto-Norse appendix). --Tropylium (talk) 20:40, 25 November 2015 (UTC)[reply]

But that still leaves it with the wrong script tag, which may not be a visible problem, but it is still a problem. Better to use sc=Latn. --Wiki Tiki 89 22:48, 25 November 2015 (UTC)[reply]

aller conjugation table

Somebody bugged the conjugation template, making the word conjugated to display as "allaller". Hillcrest98 (talk) 02:19, 25 November 2015 (UTC)[reply]

@kc_kennylau will you take a look at Module:fr-verb? —Aɴɢʀ (talk) 10:31, 25 November 2015 (UTC)[reply]

Best guess: data = m_core.make_ind_p_e(data, "all"), though when you go to edit and search for that, it's not even there. Renard Migrant (talk) 11:11, 25 November 2015 (UTC)[reply]

My apologies for my carelessness. --kc_kennylau (talk) 13:01, 25 November 2015 (UTC)[reply]

Any generous soul fancy Lua-cizing frm-noun and frm-adj?

This is from ridé

==Middle French==

===Adjective===
{{frm-adj|ridee|ridez|ridees}}

# [[wrinkled]]

Surely this would be easily Lua-cized (just I don't know who and no I don't want to learn particular. I don't have to be able to do everything). Also parent which has the plural parens; -ts can always be reduced to -s at the end of a word, and -és can always be converted to -ez (see above). Renard Migrant (talk) 10:55, 25 November 2015 (UTC)[reply]

Sure, I can help. Do I understand it correctly, you want to automatically build the plural and then delete the manually inflected forms from the template call? – Jberkel (talk) 14:41, 2 December 2015 (UTC)[reply]

@Renard Migrant, Jberkel: Do I have any way of checking the declensions? It seems that ridé is an exception, as aysé seems to be declined with the normal aysés. --kc_kennylau (talk) 12:38, 14 January 2016 (UTC)[reply]

Template:dum-decl-ppron

I notice on si#Middle Dutch that the Descendants header, which is present if you look at the source code, has been 'eaten' by the {{dum-decl-ppron}} template. I've had a look at its code and I can't see an obvious error, the number of <div>s matches the number of </div>s for instance. Can anyone work this one out? Renard Migrant (talk) 14:27, 25 November 2015 (UTC)[reply]

This looks different on different browsers: Firefox (Mac) has no problem with it, but Safari (Mac) has the problem you're describing. I notice that the TOC sees the Descendants section, so it's not really absorbed by the declension section. When I look at it using the browsers Inspector tool, the Descendants header is scrunched off on the right side. I don't know the finer points of HTML formatting, but I notice that the template has <div class="NavFrame" style="float: left; width: 100%;">. Is there a reason to have "float" for something that takes the whole width? Chuck Entz (talk) 16:42, 25 November 2015 (UTC)[reply]

Templates confix, prefix, affix sorting differently

It seems {{prefix}}, {{confix}} and {{affix}} sort entries in different ways.

See Category:English words prefixed with oxy-. The entries under "O" use {{confix}}. Current entries:

A

oxyacetic
oxyacetylene
oxyacid
oxyammonia
oxyamphetamine
oxyanion
anoxaemia
anoxybiosis

B

oxybarbiturate
oxybenzene
oxybenzoic
oxybiodegradable
oxybromic
oxybutyric

C

oxycamphor
oxychloric
oxychrysazin
oxycymene

H

oxyhaemocyanin
oxyhalide

I

iodoxybenzoic

M

oxymethylene
oxymuriatic
oxymuriatic acid
oxymyoglobin

N

oxyneurine
oxynitrate
oxynosema

O

oxycline
oxygnathous
oxyl
oxylophyte
oxyphilic

P

oxyphenol
oxypnictide

Q

oxyquinoline

R

oxyresveratrol

S

oxysalt
oxyselenide
oxysophocarpine

T

oxytelluride
oxytetracycline
oxytetrafluoride
oxytoluene
oxytonic

--Daniel Carrero (talk) 20:37, 25 November 2015 (UTC)[reply]

@Daniel Carrero: How do you suggest they be sorted? --kc_kennylau (talk) 12:40, 14 January 2016 (UTC)[reply]

Adding Mandarin translations

When I type cmn into the translation helper thing, the box below the input for words shows "script code" instead of "transliteration" (unlike yue/Cantonese, which does show "transliteration"), and I have to click on "more" to get to the transliteration input field. Is this supposed to happen? —suzukaze (t・c) 04:46, 26 November 2015 (UTC)[reply]

Play with buttons "more" and "less". I think it'll remember your last selection. For some languages transliteration should be expanded by default.--Anatoli T. ^{(обсудить}/^вклад) 06:50, 26 November 2015 (UTC)[reply]

I think that [2] has something to do with it. —suzukaze (t・c) 06:42, 31 December 2015 (UTC)[reply]

WOTD image link

Is anyone willing to replace all occurrences of [[File:PointingHand.svg|20px]] on Template:WOTD with [[File:PointingHand.svg|20px|link=]]? This will mean that the hand icon is no longer linked, which is confusing, distracting, and unnecessary (as it is a public-domain image). I can't make the change myself, as the page is under permanent cascading protection. This, that and the other (talk) 12:11, 26 November 2015 (UTC)[reply]

Formatted Arabic and Urdu are not displayed correctly on iPad's and iPhone's

See this discussion where I have described the problem. --Anatoli T. ^{(обсудить}/^вклад) 01:58, 27 November 2015 (UTC)[reply]

BTW you can screen capture on an iPhone by pressing the big round indented button at the bottom front at the same time as the on/off button. Benwing2 (talk) 03:01, 27 November 2015 (UTC)[reply]

It's a bit fiddly but if it's important, I will try to post the screenshot somewhere. I am sure someone with iPad or iPhone could confirm. --Anatoli T. ^{(обсудить}/^вклад) 04:58, 27 November 2015 (UTC)[reply]

This is the screenshot of my own post: Screenshot. The unformatted مجلة is OK but templatised مجلة looks disconnected. --Anatoli T. ^{(обсудить}/^вклад) 05:06, 27 November 2015 (UTC)[reply]

They both look fine on my iPhone 6S with iOS 9.1 in both Safari and Chrome. What version of iOS are you running? --Wiki Tiki 89 19:11, 30 November 2015 (UTC)[reply]

Mine is 5S, iOS 9.1 on Safari. --Anatoli T. ^{(обсудить}/^вклад) 22:41, 30 November 2015 (UTC)[reply]

Problem is caused by Arial Unicode MS in some versions of iOS. Placing Damascus (default Apple Arabic font guaranteed to exist on iOS) in the stack ahead of it fixes the problem. — Radix^cc 📞 01:34, 10 July 2017 (UTC)[reply]

Request to modify cs-adv template

May I ask somebody who knows how to do it, if the template {{cs-adv}} could be modified, so that it automatically fills the category:Czech uncomparable adverbs if the first parameter is "-", e. g.: {{cs-adv|-}}, similarly as the template {{cs-adj}} does? See for example the entry poočku. Thanks! Jan Kameníček (talk) 22:22, 30 November 2015 (UTC)[reply]

It's done. —CodeCa t 22:35, 30 November 2015 (UTC)[reply]

Thank you! Jan Kameníček (talk) 23:25, 30 November 2015 (UTC)[reply]