Wiktionary:Grease pit

Definition from Wiktionary, the free dictionary
Jump to: navigation, search

Wiktionary > Discussion rooms > Grease pit

Welcome to the Grease pit!

This is an area to complement the Beer parlour and Tea room. Its purpose is specifically for discussing the future development of the English Wiktionary, both as a dictionary and as a website.

The Grease pit is a place to discuss technical issues such as templates, CSS, JavaScript, the MediaWiki software, extensions to it, the toolserver, etc. It is also a place to think in non-technical ways about how to make the best free and open online dictionary of "all words in all languages".

It is said that while the classic beer parlour is a place for people from all walks of life to talk about politics, news, sports, and picking up chicks, the grease pit is a place for mechanics, engineers, and technicians to talk about nuts and bolts, engine overhauls, fancy paint jobs, lumpy cams, and fat exhausts. That may or may not make things clearer... Others have understood this page to explain the "how" of things, while the Beer parlour addresses the "why".

Permanent notice

  • Tips and tricks about customization or personalization of CSS and JS files are listed at WT:CUSTOM.
  • Other tips and tricks are at WT:TAT.
  • Everyone is encouraged to expand both pages, or to come up with more such stuff. Other known pages with "tips-n-tricks" are to be listed here as well.

Grease pit archives edit


August 2016

bot no longer works[edit]

SemperBlottoBot no longer works. This follows [1] that wants me to change HTTP to HTTPS. But nowhere in my code do I have HTTP. I don't know what to do. SemperBlotto (talk) 06:25, 1 August 2016 (UTC)

Perhaps, the library you use needs updating. --Giorgi Eufshi (talk) 07:46, 1 August 2016 (UTC)


Could someone run a bot to fix the alphabetical order for translations into Norman and all other translations that are out of order because of this? One latest example is flannel#Translations. --Anatoli T. (обсудить/вклад) 09:10, 1 August 2016 (UTC)

  • This question has arisen before. I have been resorting them manually whenever I come across them. This job should have been done when the merger was made. DonnanZ (talk) 10:34, 1 August 2016 (UTC)
In that case, perhaps you can ping the guilty party. DonnanZ (talk) 14:42, 2 August 2016 (UTC)


This didn't work when I added it to customs declaration. I have never tried using it before; am I missing something? DonnanZ (talk) 10:41, 1 August 2016 (UTC)

The normal mode that Cambridge's site uses for links has "-" as a word separator rather than a space. Other sites use separators like "_" or "+". Solutions are:
  1. Type {{R:Cambridge|customs-declaration}}, which works now yielding customs-declaration in Cambridge English Dictionary, but needs typing.
  2. Use {{R:OneLook}} which has many dictionaries available, including at least some from Cambridge, which works now without extra typing.
  3. Convince someone to prepare a Lua routine that replaces a space with a character specified in templates like {{R:Cambridge}} or several of the taxonomic reference templates.
  4. Let someone do Lua with a data module that has the separator character for each website in a database DCDuring TALK 11:16, 1 August 2016 (UTC)
  • Solution 1 will be OK as a workaround until the template is adapted. DonnanZ (talk) 21:30, 1 August 2016 (UTC)

Categegory for English Semordnilaps[edit]

I noticed that there is no category for English semordnilaps. I looked at trying to make one, but as I have no worked with modules before, I thought I'd ask first. Could someone please create the category for me, or tell me how to? I hope this is the right place to ask. Thank you! Zumley (talk) 15:46, 1 August 2016 (UTC)

I don't think you need a module to create a category. Just add your new category to an entry (the existing one is [[Category:English palindromes]], so you could create [[Category:English semordnilap]]) and it will appear as a red link at the bottom of the entry. Click that and save the resulting blank page. Thereafter, all pages given the category will appear on that page. I feel a little leery about the term semordnilap, since it's not really standard English (does any mainstream dictionary have it?), but I can't think of any better term for them. It will also be editors' responsibility to add and remove the tag as needed: e.g. if an entry is removed (by failing verification, etc.), that might affect its reverse-spelled entry, needing us to remove the tag from there. Equinox 01:44, 3 August 2016 (UTC)

Symbol ^ is used to capitalise Korean transliterations[edit]

@Wyang Hi. Somebody must have changed the modules again. This - 뽈스까 (ko) ‎(Ppolseukka) should link to the 뽈스까 on the Korean Wiktionary, not ^뽈스까. Symbol ^ is present in the template but not displayed, it only capitalises the first letter of the transliteration. This is a North Korean word for Poland. See the translations section there.--Anatoli T. (обсудить/вклад) 23:03, 2 August 2016 (UTC)

Someone may have fixed this - seems to be working at Poland now. Wyang (talk) 01:40, 3 August 2016 (UTC)
@Wyang I mean the interwiki link (a small "ko") in {{t+|ko}}. Try clicking on the little "ko", it will try to search for ^뽈스까 in the Korean Wiktionary. --Anatoli T. (обсудить/вклад) 02:10, 3 August 2016 (UTC)
Ah sorry I see what you mean Anatoli. Fixed. Wyang (talk) 02:30, 3 August 2016 (UTC)


This was (along with extensive edits to Module:pl-noun to make it work) was created by User:Esszet, who apparently didn't know how to keep it from showing a module error on the template page itself. Can anyone fix it? Chuck Entz (talk) 03:32, 3 August 2016 (UTC)

Fixed. Wyang (talk) 03:52, 3 August 2016 (UTC)
That was quick! Thank you! Chuck Entz (talk) 03:55, 3 August 2016 (UTC)


Can someone rewrite this to allow for the Latin script? Ultimateria (talk) 03:43, 3 August 2016 (UTC)

@Ultimateria I don't see anything obvious in the template that would make it not work with the Latin script. If it's defaulting to Tagbanwa for some reason, |sc=Latn should work. KarikaSlayer (talk) 13:36, 5 August 2016 (UTC)
I thought we could get templates to detect scripts? Ultimateria (talk) 15:09, 5 August 2016 (UTC)
Does it not already allow the Latin script? --WikiTiki89 15:14, 5 August 2016 (UTC)
Is the issue that it adds "Ilocano terms needing transliteration" if the term is already in Latin script? Other than that, it seems to work (i.e. it displays fine). - -sche (discuss) 18:58, 5 August 2016 (UTC)
I fixed that issue, at least. The problem was that the template was manually including the request category rather than letting {{head}} do it automatically. —CodeCat 19:01, 5 August 2016 (UTC)

In an interesting twist, the non-Latin script listed for Ilocano is Tagb (Tagbanwa). The wiki for w:Ilocano language says that Ilocano instead used Tglg (Baybayin) historically. Furthermore, the two Ilocano entries we have in non-Latin script (ᜉᜈᜄ᜔ᜉᜃᜋᜆᜌ᜔ and ᜀᜎ᜔ᜇᜏ᜔) are in Tglg, not Tagb. So, I think we have an error in the language module. Is that correct? —JohnC5 20:52, 5 August 2016 (UTC)

Separately: I suggest we just lemmatize on Latin script, rather than having some entries in Latin script and some entries in another script. - -sche (discuss) 21:28, 5 August 2016 (UTC)


The template is now broken, but a few days ago it still worked. Hopefully it can be fixed.

  • Usage of the template: {{R:L&S|DISPLAY|SEARCH}} or {{R:L&S|1=DISPLAY|2=SEARCH}}
  • Example: {{R:L&S|juxtā|juxta}} displays "juxtā" and should link to "juxta", but now it also links to "juxtā" which gives "No document found" and "We're sorry, but we were unable to find a document matching your query."

-Poskim (talk) 15:03, 3 August 2016 (UTC)

@Isomorphyc: Could you fix this for all Perseus Latin templates? —JohnC5 17:13, 3 August 2016 (UTC)
@Poskim: I believe it has been fixed now. —JohnC5 17:24, 3 August 2016 (UTC)
@Poskim, JohnC5: Fixed; thank you. I didn't mean to break that one. Isomorphyc (talk) 17:28, 3 August 2016 (UTC)
Thank you too. -Poskim (talk) 17:30, 3 August 2016 (UTC)

Special:BookSources issue[edit]

The page "Special:BookSources" contains the text "Learn how to bypass this page and go to the same book source every time", which links to https://en.wikipedia.org/wiki/User:Lunchboxhero/monobook.js. However, this is a page at the English Wikipedia which does not exist here. Thus, creating a monobook.js page at Wiktionary actually does nothing. Could someone either import the script, or remove the misleading text? Thanks. — SMUconlaw (talk) 19:24, 3 August 2016 (UTC)

@Smuconlaw: I've copied the instructions to User:Keith the Koala/common.js User:Keith the Koala/BookSources.js, and the script itself to User:Keith the Koala/externISBN.js. I'd also suggest putting the code in your common.js instead of monobook.js, that way it won't depend on what skin you're using. I don't know how to edit the Special:BookSources intro. Keith the Koala (talk) 10:36, 5 August 2016 (UTC)
Thanks, it's working fine! Hope someone can edit "Special:BookSources" accordingly. — SMUconlaw (talk) 15:11, 5 August 2016 (UTC)

Renaming "SIC" as "sic"[edit]

The template {{sic}} was originally renamed {{SIC}} as sic was an ISO 639-3 code. However, it has since ceased to be one, at least from February 2009 when it was turned into a redirect to {{SIC}}. Does anyone object to making the primary template {{sic}} again, and turning {{SIC}} into a redirect? — SMUconlaw (talk) 20:20, 4 August 2016 (UTC)

I'm fine with it. —CodeCat 20:24, 4 August 2016 (UTC)
A usabiity improvement. DCDuring TALK 21:21, 4 August 2016 (UTC)
I suppose so; though isn't it a bit unwise to use any three-letter lower-case code, if future ISO changes are liable to break it? Equinox 21:24, 4 August 2016 (UTC)
I don't think we need to care about that any more. DTLHS (talk) 21:34, 4 August 2016 (UTC)
Correct, because we no longer have the language codes as templates. (Compare how see is still a valid language code, but we have {{see}}. Indeed, we already have {{sic}}, this is just a proposal to make it the main template and make {{SIC}} a redirect, reversing the current arrangement.) - -sche (discuss) 22:14, 4 August 2016 (UTC)
OK, this seems uncontentious and there were no objections so I went ahead and made the move. Thanks. — SMUconlaw (talk) 17:03, 5 August 2016 (UTC)

I can't see Parser profiling data[edit]

As the title says. Clicking on the triangle to show it reveals an empty expanse with a height of 1em or something. The HTML source shows me an empty table. —suzukaze (tc) 03:39, 5 August 2016 (UTC)

It seems like it was converted to a JavaScript variable [2], but I'm not quite sure how to access it easily... —suzukaze (tc) 03:11, 12 August 2016 (UTC)

Weird hidden category[edit]

Maybe I'm accidently screwing up my entries, but I don't understand why a hidden category – "head tracking/no lang category" – seems to be following me around lately. For instance schior has this hidden category. I always try to make my entries as correct as possible, so this really bugs me. Any advice? --Robbie SWE (talk) 18:51, 5 August 2016 (UTC)

Think @CodeCat answered all my questions :-) --Robbie SWE (talk) 19:05, 5 August 2016 (UTC)

"elements" and "wikipedia" templates[edit]

Is there any way to get {{elements}} and {{wikipedia}} to play nicely together? See ytterbium, where {{elements}} should sit below {{wikipedia}} aligned with the right margin, but refuses to do so. — SMUconlaw (talk) 11:21, 6 August 2016 (UTC)

Yes check.svg Donesuzukaze (tc) 21:35, 6 August 2016 (UTC)
Thanks. So, what's the trick? Did the templates themselves need to be altered in any way? — SMUconlaw (talk) 11:56, 7 August 2016 (UTC)
I did this, which {{wikipedia}} already does. —suzukaze (tc) 01:46, 8 August 2016 (UTC)
Ah, good to know. — SMUconlaw (talk) 03:45, 8 August 2016 (UTC)

Support for head2= in {{suffixcat}}, {{prefixcat}}[edit]

@CodeCat Is it possible to support head2= in these templates? See Category:Russian words suffixed with -клинить, where both -кли́нить and -клини́ть are possible. I'd like to say {{suffixcat|ru|-кли́нить|head2=-клини́ть}} or similar. Benwing2 (talk) 19:32, 6 August 2016 (UTC)

head2= seems inappropriate since this is just a regular link and not a headword. Do you have a better term? —CodeCat 19:35, 6 August 2016 (UTC)
Maybe form2=? Benwing2 (talk) 21:33, 6 August 2016 (UTC)

What are the criteria for a Japanese abbreviation and a Japanese short form?[edit]

@TAKASUGI Shinji, Eirikr, Bendono I'm confused about the difference between the two templates {{abbreviation of}} and {{short for}} regarding Japanese headwords. Apparently, Western loans such as ダイヤ ‎(daiya) or テレビ ‎(terebi) fall into the abbreviation category, while Chinese derivatives such as  (こく) (れん) ‎(Kokuren) belong to the short form category: the former is similar to English abbreviations such as pixel or gym, while the latter which retains Chinese morphemes (Kanji) is more like software lifecycle being short for software development lifecycle. That being said, they are seemingly created in the same fashion: by dropping a couple of morae. So which is which? Which template should I use? ばかFumikotalk 02:20, 7 August 2016 (UTC)

Most of them should be classified as short forms. Abbreviations should be pronounced as a original form, such as Mr.. However, this distinction is not clearly made. See Category:English abbreviations and Category:English short forms. — TAKASUGI Shinji (talk) 02:29, 7 August 2016 (UTC)
@TAKASUGI Shinji What about cases like OL? They're not pronounced like what they stand for too either. ばかFumikotalk 01:48, 9 August 2016 (UTC)
Maybe initialism? Although it takes the first letter of the romanization in a European manner... —suzukaze (tc) 01:54, 9 August 2016 (UTC)
IMO most of them are short forms; abbreviations are , , , etc. —suzukaze (tc) 02:39, 7 August 2016 (UTC)

Entering Translations for Plautdietsch[edit]

When it comes to entering translations for Plautdietsch into the section for translations, I wish I could only enter the masculine, feminine, neuter and plural options, just like one would do for German or Polish. What module (or something else) can facilitate that mechanism? --Lo Ximiendo (talk) 07:40, 9 August 2016 (UTC)

Why would you enter all those forms into a translation table? Translation tables only have lemmas. —CodeCat 21:37, 12 August 2016 (UTC)
I think he's just complaining that there are too many gender checkboxes. --WikiTiki89 21:43, 12 August 2016 (UTC)

AJAX call to retrieve word information from one specific language[edit]

I recently posted this as a question on StackOverflow, and I am hoping that someone with experience in both JavaScript and the Wiktionary API will be able to help me.

Thanks in advance

Wiktionary has no API. You will have to write your own function to split the page by language section (always level 2 headings). DTLHS (talk) 18:56, 10 August 2016 (UTC)
We could make one, though. Lua/Scribunto is capable of retrieving the page wikicode and parsing its contents. —CodeCat 19:01, 10 August 2016 (UTC)
That would be very useful. Let's do it. DTLHS (talk) 19:02, 10 August 2016 (UTC)
The problem would be dealing with malformed page content. I've made efforts to standardise the format further, but not everyone is going to stick with it. I think at best, we can try to parse just sections for now. —CodeCat 19:07, 10 August 2016 (UTC)
Agreed. We should start with the top-level part of a page that everyone agrees on: the language sections, interwikis. If it catches on we can start going deeper and eventually make it part of WT:ELE that the page should conform to the module. DTLHS (talk) 19:10, 10 August 2016 (UTC)
We do already have WT:NORM which was made for this kind of thing, but since it was made optional for non-bots, it somewhat defeats the purpose. —CodeCat 19:20, 10 August 2016 (UTC)
I think the module should be able to output a canonical version of the page that conforms to WT:NORM. If we could do this it would make it very easy to write an autoformat bot. DTLHS (talk) 19:22, 10 August 2016 (UTC)
  • I have written a Wiktionary wikitext parser that converts it into xml, if anyone's interested. This is the result of one xmlization of Table with wrapInterwikis, wrapCategory options set.

--Dixtosa (talk) 19:16, 10 August 2016 (UTC)

There's also mwparserfromhell, written for Python, which I use a lot for bot edits. My preference is for a server-side implementation though. —CodeCat 19:20, 10 August 2016 (UTC)
mwparserfromhell is a good thing. I use it a lot too. Benwing2 (talk) 06:01, 13 August 2016 (UTC)

Unpatrolled edits are no longer red[edit]

Using Chrome, in Recent changes the exclamation mark for unpatrolled edits is no longer red but black. What changed? DTLHS (talk) 19:59, 10 August 2016 (UTC)

Adding support for theoretical forms to headwords?[edit]

@CodeCat What do you think about adding support for theoretical inflections to Module:headword? I'm thinking of supporting this in Russian declension tables, and it would be nice if the headword matches. This would mean there would be a flag to turn this on when specifying an inflection, and it would display the inflection italicized, unlinked and preceded by a *. Benwing2 (talk) 20:36, 12 August 2016 (UTC)

How would this differ from a reconstructed form? —CodeCat 20:45, 12 August 2016 (UTC)
It's sort of the opposite of reconstructed. It means the forms don't exist, but could have existed and/or could be created ad-hoc, and this is what they would look like. Something like this:
те́мя ‎(témja) ‎(genitive те́мени, plural *темена́, genitive plural *темён)
--WikiTiki89 20:55, 12 August 2016 (UTC)
So like a defective verb? I don't think we usually use an asterisk for this- what about coloring them gray? DTLHS (talk) 20:56, 12 August 2016 (UTC)
Not quite like a defective verb, but more like a verb that just happens to be used usually only in the present tense or with a particular person/gender/number, but theoretically could be used in the future or another person/gender/number. --WikiTiki89 20:58, 12 August 2016 (UTC)
I agree with Wikitiki here. The use case is Russian nouns in particular that normally appear only in the singular, but which potentially have plurals, e.g. молоко́ ‎(molokó, milk); the plurals occasionally appear but are considered затруд. = "difficult", which we normally render as "rare and awkward" or something similar. It could also be used for the many verbs that have similarly rare/awkward past passive participles (although these probably won't appear in headwords).
I would make it display something like this:
те́мя • ‎(témja) ‎(genitive те́мени, plural *темена́, genitive plural *темён)
Or maybe
те́мя • ‎(témja) ‎(genitive те́мени, plural *темена́, genitive plural *темён)
Benwing2 (talk) 22:44, 12 August 2016 (UTC)
I don't think this makes much sense. Either they're used or they're not. The usage frequency doesn't come into play. For English, the template allows for an extra message to say the noun is mostly uncountable. —CodeCat 23:50, 12 August 2016 (UTC)
This kind of stuff makes sense in Russian. See [3] for example. If you don't like it I'll add the support myself. Benwing2 (talk) 00:02, 13 August 2016 (UTC)
The intended use is when the plural is not attestable to our standards (or at least not in every grammatical case), but nevertheless could exist. This has nothing to do with countability. It could be a countable noun but nearly always used in the singular. The plural declension is not as straightforward as just adding an -s like in English, so it would be useful for readers to show how the plural is formed should they ever need to use it. --WikiTiki89 00:32, 13 August 2016 (UTC)
If it's not attested, then to show it would be a reconstruction. We don't need a special notation. Even the Russian page shows it as a reconstruction. —CodeCat 01:25, 13 August 2016 (UTC)
This makes no sense to me. If it's a reconstruction we do need special notation. In any case, Russian grammars like Zaliznyak distinguish between missing forms and затруд. forms. Benwing2 (talk) 02:09, 13 August 2016 (UTC)
I'm not convinced that this is a good idea, but if you do it, I suggest that instead of having the forms be unlinked, it would be helpful if you had them all across the board link to an appendix or WT:ARU where you explain why they're listed but marked with asterisks. Alternatively, if you use superscripts or asterisks, I would suggest that instead of spelling out the full note in every entry and having individual entries be given slightly different notes that might lead someone to think there was a difference between them, it would be better to have a parameter like difficultplural=1 which, when set, would generate the note. The note could also link to a section of WT:ARU where you go into more detail on how some words are difficult and have accepted theoretical plurals that are simply not used. - -sche (discuss) 03:58, 13 August 2016 (UTC)
I support the inclusion of unwikified theoretical forms in the headword. They are not reconstructions. The forms nominative plural *темена́ and genitive plural *темён are grammatically correct forms of темя, even though they are not used. If someone asked me, what the plural form of те́мя ‎(témja) is, the correct answer is "темена́", even if these are considered "awkward" (the Russian grammarians use the term "затрудни́тельный") and almost never used in the real life. "темена́" is also different from missing or proscribed forms, e.g. there is no 1st person singular future for победи́ть ‎(pobedítʹ), any theoretical form in this case would be incorrect. There are many examples of theoretical forms. One can make diminutives almost from every noun or form verbal nouns from verbs. There may be no attestations for them but these may still be considered standard Russian terms or forms. --Anatoli T. (обсудить/вклад) 04:52, 13 August 2016 (UTC)
@Equinox The current system using asterisks/superscripts and footnotes is not the ideal way to handle these forms. Your suggestion is not a bad one, although I'd still want them to not be made blue like normal links, so they stand out more. Benwing2 (talk) 05:59, 13 August 2016 (UTC)
  • My long-term position is that unattested inflected forms should not have entries or at least should have entries that mark them as hypothetical, but I have not seen consensus to support that position. My similar position is that unattested inflected forms should not be shown on such a prominent place that is the headword line. I do not see what "theoretical" means in the above discussion other than "hypothetical", meaning "such that it could exist but does not actually exist", and I oppose extensive inclusion of hypotheticals in the English Wiktionary. --Dan Polansky (talk) 06:10, 13 August 2016 (UTC)

Getting mw.log() to work[edit]

Inserting mw.log() into module code to get console output has never, ever, ever worked for me. Not in Chrome, not in Safari. (Mac OS X 10.9) As a result I've been reduced to debugging 5000-line modules using error() ... hardly very convenient. Does this work for anybody? If so, how? Benwing2 (talk) 03:03, 13 August 2016 (UTC)

It (used to) output to an area under Templates used in this preview called Parser profiling data. Now the output has been moved to a JavaScript variable that can be seen by using View source on the webpage (somewhat conveniently all the way at the bottom): Module:Sandbox, [4]suzukaze (tc) 03:12, 13 August 2016 (UTC)
Yuck. That's quite inconvenient. And it means the text "Use mw.log() in module code to send messages to this console." that appears near the debug console is totally wrong. Benwing2 (talk) 05:55, 13 August 2016 (UTC)

Automatic creation of English alternative forms.[edit]

Is there a bot or a gadget somewhere that can do this? I understand that a lot of the rare English terms that I add have a hyphened alternative form of it that is also attested. I'll tell you, it is really, really annoying to have to create the main form and the hyphen forms and their non-lemma forms as well. Is there a way to autocreate these? If not, is there someone who could possibly make something like this? Conrad.Irwin hasn't been online for 3 years. Philmonte101 (talk) 04:30, 13 August 2016 (UTC)

I'd say bots shouldn't do this because it needs a human to confirm that the alt form really does exist. Equinox 05:29, 13 August 2016 (UTC)

Invisible Template:premature[edit]

For some reason, {{premature}} is invisible to me in Android, instead of generating a yellow box saying that a vote is premature. Is there a problem with the template? --Daniel Carrero (talk) 21:30, 14 August 2016 (UTC)

It seems like class="metadata" is hidden on mobile. —suzukaze (tc) 21:35, 14 August 2016 (UTC)
I've removed the class. This template seems like data about the vote which we'd want people on mobile to be able to see. - -sche (discuss) 22:21, 15 August 2016 (UTC)

Newest/oldest requests not displaying in categories[edit]

I haven't tracked down another category to see if this is a universal problem, but in Category:Translations to be checked (French), the box that shows the newest and oldest additions to the category isn't displaying any words. Andrew Sheedy (talk) 18:43, 15 August 2016 (UTC)

I purged the page and it seems to be working now. --WikiTiki89 19:02, 15 August 2016 (UTC)

Unhide bot edits on the Watchlist when they are hidden in preferences[edit]

I noticed that when I have bot edits hidden from my Watchlist in preferences, trying to temporarily unhide them by unchecking the box on the Watchlist page does not work. Unhiding them in preferences does work. Anyone experience this too? Is this something that should be reported at phabricator? --WikiTiki89 22:07, 15 August 2016 (UTC)

Language-specific alphabetization?[edit]

Since this did not attract answers here, I shall ask again here: Is it technically possible to have categories, derivative tables and other lists of terms from a single language sort with a different scheme than the default? I find that the incorrect sorting detracts from the quality of the dictionary.__Gamren (talk) 09:03, 16 August 2016 (UTC)

You have to add a sort key manually. For example, "[[Category:Stuff|Nonsense]]" will sort the page on which this category is placed under "Nonsense". Is this what you meant? — SMUconlaw (talk) 09:20, 16 August 2016 (UTC)
No, not really. Categories and the template {{der2}}, to take two examples, automatically alphabetize the terms they are given. This results in incorrect sorting for some languages. What I mean is, can we make these appliances recognize what language they are working with, and sort differently for different languages?__Gamren (talk) 09:59, 16 August 2016 (UTC)
I'm not really understanding what you mean by "Categories and the template {{der2}} ... automatically alphabetize the terms they are given" (maybe you can give an example). However, in general, I don't think there is a way to make a template like {{der2}} automatically recognize the language of a entry to which it is applied. The template would have to be edited to allow editors to add a language code manually, e.g., {{der2|en}}. — SMUconlaw (talk) 10:33, 16 August 2016 (UTC)
Sure thing. Consider the following:
and [5] and compare them to Appendix:Latin_script/alphabets#Danish_alphabet. See that the template reorders the terms. Clear now?__Gamren (talk) 11:40, 16 August 2016 (UTC)
We can add a sort key to Module:languages/data2 that will modify the sorting order in everything that uses that module. We just need to know the correct order of all the letters. Chuck Entz (talk) 13:44, 16 August 2016 (UTC)
@Gamren: oh, yes, I see what you mean. Chuck has answered your question – I didn't know this was possible. Chuck, see "Appendix:Latin script/alphabets#Danish alphabet" that Gamren referred to above. — SMUconlaw (talk) 13:53, 16 August 2016 (UTC)
@Gamren I created {{Template:der3-u}}, which is identical to {{der3}} except it does not automatically sort the arguments. Sorting is difficult and even if the proper sort keys are added it may not work correctly. DTLHS (talk) 14:21, 16 August 2016 (UTC)
I had seen that page before, but thought it could only modify which characters are seen as distinct, not completely change the ordering (which no language seems to do). Is the syntax just sort_key = {"a", "b",snip"z", "æ", "ø", "å"},?
__Gamren (talk) 14:35, 16 August 2016 (UTC)
It's not possible to change the ordering of characters in a category. This is a huge shortcoming, which the developers somehow seem to ignore. Per-category custom collation orders are an absolute necessity. —CodeCat 14:41, 16 August 2016 (UTC)
For those categories added by templates, it should be possible to include a sort key in most cases. Categories added by hand, or those with both hand-added and template-added members, no such luck. Chuck Entz (talk) 02:46, 17 August 2016 (UTC)
So, uh, would someone do that? The page is protected.__Gamren (talk) 10:53, 20 August 2016 (UTC)
I use {{der3-u}} for Norwegian and the results are quite satisfactory. You have to do the alphabetical sorting yourself, of course, but the balancing is done automatically. DonnanZ (talk) 11:07, 20 August 2016 (UTC)
It was discussed here [6]. DonnanZ (talk) 11:42, 20 August 2016 (UTC)
@Gamren Which template do you want modified? Benwing2 (talk) 18:54, 20 August 2016 (UTC)
der3-u seems to be okay (actually-sorted lists are easier for editors, anyway). I had no idea this had come up before (and so recently, even!). There is still the matter of categories, however. @Chuck Entz, would you add the sort key you describe?__Gamren (talk) 17:09, 30 August 2016 (UTC)

Wiktionary offline[edit]

Hello, I am sometimes in locations without connectivity to the internet, but I'd still like to have access to Wiktionary for reference. How can I set up a local copy for offline reference? Thanks. Codeofdusk (talk) 15:54, 17 August 2016 (UTC)

I don't know an easy way. You can download the whole project here [7] but (i) it's very large and (ii) this just gives you the data (in raw wikitext markup), not a browsable Web site. Unlike Wikipedia, we don't publish offline CD/DVD versions. Equinox 12:37, 19 August 2016 (UTC)
I haven't used it, but the Kiwix tool has most Wikimedia projects available for offline viewing. I think the en.wiktionary version is about 2gb. Edit - if you do end up using it, please let us know how it goes. - TheDaveRoss 15:22, 19 August 2016 (UTC)
User:Matthias Buchmeier's user page details his method of creating downloadable dictionaries for offline use. If you're interested in a single language that isn't already listed on his user page, you could ask him if he had time to create it for you. - -sche (discuss) 15:26, 19 August 2016 (UTC)
  • If you have a computer that can run Java, I would recommend Xowa. Xowa is the only (free open-source) application I know of that allows you to keep an up-to-date offline copy of Wikimedia sites, including userpages, talkpages, and multimedia. To save space, you can choose to download only the text without multimedia. With compression, all of Wikipedia including images supposedly can fit onto a 128-GB flash drive, and Wiktionary is much less than that. I have only tried downloading Simple Wikipedia myself with Xowa, but it worked great. http://www.xowa.org/ Nicole Sharp (talk) 07:41, 31 August 2016 (UTC)
  • Xowa allows you to dump directly from the Wikimedia servers, so has more up-to-date content than Kiwix, and also allows you offline access to userpages and talkpages which often contain important and/or useful content (such as templates, lists, discussions, etc.). Xowa can also be used both offline and online, and can be integrated to serve wikipages to Firefox, so if your internet goes out while browsing Wikipedia (or any other Wikimedia site), you can continue browsing the site offline right in your web browser, with the wikipages being served from your offline Xowa archive instead of the internet. Nicole Sharp (talk) 08:19, 31 August 2016 (UTC)

Langcatboiler and no script specified languages[edit]

Category:Kalasha language- linking to Category:No script specified script. Is this the desired behavior? Are we going to create this category? DTLHS (talk) 16:19, 17 August 2016 (UTC)

New words to be added[edit]

I've come across the word "scotography", meaning radiography and the word "vapography" in context of photography, in late 19th century literature. Can this word be please added to Wiktionary? Thanks. Ineuw (talk) 03:37, 19 August 2016 (UTC)

It's better to place requests for entries at Wiktionary:Requested entries (English). "Scotography" appears to have quite a few meanings, including thermography, radiography, some process of producing images with a silver plate, and the production of images of ghosts. DTLHS (talk) 04:13, 19 August 2016 (UTC)


Will there be an update to Unicode 9.0 for this page? -- Pedrianaplant (talk) 11:29, 19 August 2016 (UTC)

Module:es-pronunc: bug[edit]

Something went wrong with that module: implementing the template {{es-IPA}}, it doesn't always display Latin American pronunciation when this is different (namely, /θ/ > /s/ and /ʎ/ > /ɟ͡ʝ/):

  • (Castilian) IPA(key): /esˈtaʎo/, [esˈt̪aʎo]
  • (Latin America) IPA(key): /esˈtaɟ͡ʝo/, [esˈt̪aʝo]

Could anyone find the bug and fix it? Thanks! [ˌiˑvã̠n̪ˑˈs̪kr̺ud͡ʒʔˌn̺ovã̠n̪ˑˈt̪ɔt̪ːo] (parla con me) 22:10, 21 August 2016 (UTC)

Why is /ɟ͡ʝ/ being used to represent [ʝ]? That's very weird. Also, [ʎ] in Spain is recessive and characteristic only of rural speakers in Northern Spain. I think the module should display [ʝ] for this instead, even in Spain. Benwing2 (talk) 00:22, 22 August 2016 (UTC)
Maybe we could change that in Castilian phonetic transcription, but I would keep the traditional phoneme /ʎ/; and I would also display y as [ʝ]. However, before we do that, there's this matter above to solve. Is the mistake in the module or in the template? [ˌiˑvã̠n̪ˑˈs̪kr̺ud͡ʒʔˌn̺ovã̠n̪ˑˈt̪ɔt̪ːo] (parla con me) 08:24, 22 August 2016 (UTC)
I think it's a template bug. The template code is pretty nasty and should be moved to Lua. It looks like it's not generating the Latin American version when the Spain version has the same phonetic and phonemic display. Benwing2 (talk) 16:25, 22 August 2016 (UTC)
@Kc kennylau Can you take a look? Benwing2 (talk) 16:28, 22 August 2016 (UTC)
If Castilian and Latin American IPA transcriptions are the same, the template isn't even supposed to display both, and just gives a general transcription without {{a}}:
But when they're supposed to be both displayed and only the Castilian is given, then it appears with the accent specification, as above. [ˌiˑvã̠n̪ˑˈs̪kr̺ud͡ʒʔˌn̺ovã̠n̪ˑˈt̪ɔt̪ːo] (parla con me) 16:35, 22 August 2016 (UTC)
Wait a second: I think I found the bug. When phonemic and phonetic IPA are identical, the template only displays the former; but, in such a case, if Castilian phonemic transcription is different from Latin American phonemic transcription, the latter doesn't display. Can anyone fix this? [ˌiˑvã̠n̪ˑˈs̪kr̺ud͡ʒʔˌn̺ovã̠n̪ˑˈt̪ɔt̪ːo] (parla con me) 16:40, 22 August 2016 (UTC)
@IvanScrooge98, Benwing2 Fixed. --kc_kennylau (talk) 20:21, 22 August 2016 (UTC)

Show/Hide not appearing[edit]

Once more the what is concealed by {{rel-top}}, {{trans-top}} and their relatives cannot be displayed. See [[moss]]. I haven't tried any other entries yet. DCDuring TALK 22:48, 21 August 2016 (UTC)

Intermittent problem that slows multiple edits of the same page. No problem on first accessing page. DCDuring TALK 23:05, 21 August 2016 (UTC)
What browser? What does your error console say? DTLHS (talk) 23:39, 21 August 2016 (UTC)
This is usually a problem with your browser: the box is added by javascript running on your browser, then the "show" tabs are added. If something interrupts the javascript after the box is added, but before the "show" tabs are added, the result is as you're describing it. More often than not, it's just a matter of things not loading right, and clicking "refresh" or "reload" on your browser will fix it. Sometimes, though, there can be a problem with a gadget or something else that uses javascript, in which case you'll need to troubleshoot it further. Chuck Entz (talk) 00:09, 22 August 2016 (UTC)

New Vulgar Latin template[edit]

I've created User:KarikaSlayer/VL-noun (backended by Module:User:KarikaSlayer/VL-noun and VL-translit) as a replacement for {{VL-decl}}. The phonetic notation has been updated to match WT:AVL (including stress markings, something that is missing from the current template). Any ideas/criticism welcomed. KarikaSlayer (talk) 03:00, 24 August 2016 (UTC)

It's not quite correct. Latin -um gave -u in the second declension, and the nasalisation was lost already. I also believe that b merged into v by this time ("brabium non bravium"). I'm not sure why the second declension genitive would be -ei, given that short i was not lowered before another vowel but indeed short e was raised in this position ("vinea non vinia"). So -ii would just coalesce into -i, like in Italian. I'm also very unsure about the change of -dj- to -j-, is this really pan-Romance? Finally, there's a third group with respect to vowel outcomes: Sardinian. Sardinian merged all short and long vowels, even i and ī. —CodeCat 12:47, 24 August 2016 (UTC)
All of these should be fixed. About -dj-, Herman 1967 (1997 translation) says: "On the other hand, inscriptions from the second century A.D. onward show more and more confusions in spelling between the following letters and digraphs, which seem at times to have appeared to be interchangeable: i when it represented [j], as in maior; di when it represented [dj] before a vowel; g when before [e], [i], or [j]; and even the letter z, which had been borrowed from the Greek alphabet." I'm not sure about the exact environments, though: *absedium shows no trace of palatalization, while podium and *appodiō do. KarikaSlayer (talk) 18:46, 24 August 2016 (UTC)
-dj- in medius has a different outcome from -j- in maior in Italian, while radius shows yet another outcome. Also consider the two distinctive outcomes of maior in French: the nominative has the regular change -or > -re, and this prevented the fortition of the preceding j, while fortition did happen in the oblique form, from maiōrem. So I'm not sure this change had a single consistent outcome in all Romance languages. The French outcome in particular suggests that j was not fortified phonemically in the earliest individual history of French. I'd be interested to see what happens to Latin words ending in -dior if there are any. —CodeCat 19:09, 24 August 2016 (UTC)
Words ending in -dior (that I can find at least) seem to be limited to passives and third declension comparatives (so no direct Romance descendants). KarikaSlayer (talk) 19:34, 24 August 2016 (UTC)
Any with -gior then? —CodeCat 20:20, 24 August 2016 (UTC)
No, same as before. KarikaSlayer (talk) 00:12, 25 August 2016 (UTC)
Perhaps it has something to do with dissimilation from a preceding non-high back vowel, combined with the position of primary and secondary stress. It wouldn't explain everything (Latin meliōrem/Spanish mejor/French meilleur comes to mind), but it might add to other sources. Chuck Entz (talk) 01:39, 25 August 2016 (UTC)

Blue M doesn't always appear[edit]

When viewing a user's list of contributions, the unpatrolled ones get a blue M ("click to mark as patrolled"). I've noticed that this M never appears if I am working in a different tab when the page loads, and later switch back. Is this by design, or does it relate to how Chrome sometimes deprioritises inactive tabs? Equinox 20:46, 24 August 2016 (UTC)

Watchlist page strangeness[edit]

When I click on the "watchlist" tab, the page I get has search, navigation and tools on the left (under the logo), but none of the links there are clickable. Any ideas? SemperBlotto (talk) 06:44, 25 August 2016 (UTC)

Fixed ✔ —suzukaze (tc) 11:14, 25 August 2016 (UTC)
Thanks. I had abandoned using the grouping of changes on the watchlist page because the icons to expand a pages changes no longer appeared. DCDuring TALK 12:05, 25 August 2016 (UTC)

Z bug, diphthong bug with Spanish IPA[edit]

A couple of problems with Module:es-pronunc:
1. Latin American Z is treated as a full S, which is wrong (that is because the change θ > s comes before the stress rules, which imply S as different from Z):

  • (Castilian) IPA(key): /beˈxeθ/
  • (Latin America) IPA(key): /beˈxes/ (vejez, should display as /beˈxes/)

2. some vowel clusters are considered diphthongs when they clearly aren't:

  • IPA(key): /reˈal/ (real, should display as /reˈal/)

Could this be fixed? Thanks. [ˌiˑvã̠n̪ˑˈs̪kr̺ud͡ʒʔˌn̺ovã̠n̪ˑˈt̪ɔ̟t̪ːo] (parla con me) 14:56, 25 August 2016 (UTC)

LatAm z should be fixed. KarikaSlayer (talk) 15:37, 25 August 2016 (UTC)
Fortunately, I was able to solve the second bug myself. Now everything's alright. [ˌiˑvã̠n̪ˑˈs̪kr̺ud͡ʒʔˌn̺ovã̠n̪ˑˈt̪ɔ̟t̪ːo] (parla con me) 13:32, 26 August 2016 (UTC)

Translation editor problem[edit]

I'm trying to add a Dutch translation for take time, which is tijd nodig hebben. Note that this is not a fully idiomatic term, at least I don't consider it one: it's made up of nodig hebben ‎(to need), which is an idiom that already has an entry, and tijd ‎(time). But when I try to enter the translation as [[tijd]] [[nodig hebben]], which is the correct way to notate it, the editor refuses, saying: "Please don't use wiki markup ([]{}#|) in the translation.". This is a mistake, it should allow SoP translations that link to terms individually. —CodeCat 21:11, 25 August 2016 (UTC)

You can enter it the old-fashioned way. But the editor's behavior forecloses the desired treatment of SoP translations. DCDuring TALK 12:37, 26 August 2016 (UTC)
Not really a mistake: using square brackets to link to parts in a translation is a relatively new practice. I don't think {{t}} was even able to handle it at the time the translation editor was written. Still, I think the translation editor should be updated to allow it (but not links to other wikis). Chuck Entz (talk) 19:10, 26 August 2016 (UTC)

Condensing the Table of Contents for Entries[edit]

What would it take to have our tables of contents display only L2 headers by default, with L3 headers and below being hidden until the L2 is expanded? In other words, to have them look like they do on Wiktionnaire (compare a with a). If there's a gadget or something that does this already, could it be on by default, to make the tables more navigable? 99% of the time, I just want to click down to the language of the word I want to look at, not the POS or another L3/L4 header, and to have to scroll down the table of contents is a pain. It also increases the distance between the top of the page and the actual content, which is not helpful to users.... Andrew Sheedy (talk) 04:03, 26 August 2016 (UTC)

For some of the large entries we could use {{TOC limit}}. It does not allow expanding though. --Giorgi Eufshi (talk) 05:42, 26 August 2016 (UTC)
The TOC can be hidden of course, but that's not the solution. Maybe the TOC could contain just the name of each language, clicking on that would bring up both the full TOC for the language and the entry for the language. Just an idea, but I don't know whether it's workable. DonnanZ (talk) 10:00, 26 August 2016 (UTC)
FWIW it seems to be a gadget: fr:MediaWiki:Gadget-SommaireDeveloppable.js. It's probably possible for you to import it in Special:MyPage/common.js, but I'm not a JavaScript person. —suzukaze (tc) 10:03, 26 August 2016 (UTC)
I feel like this should be the default, like on the French Wiktionary. There, the TOC for entries that aren't as long doesn't collapse the section for French (see tres). In general, the TOC's look far neater over their than they do here, and I think we would be well off to set that as the default. It would be a simple step towards making Wiktionary more usable, and I can't think of any arguments against implementing it. Andrew Sheedy (talk) 14:18, 26 August 2016 (UTC)
There's a Tabbed Languages gadget under Preferences that does more or less the same thing? Keith the Koala (talk) 11:13, 26 August 2016 (UTC)
For now, I oppose the idea. I like to see all the contents at once when I load up the page. I think this helps me as an editor, to see if there's something wrong with the entry. I might change my mind later. --Daniel Carrero (talk) 14:55, 26 August 2016 (UTC)
Note that I am proposing having English (and maybe Translingual) sections partly expanded by default; only collapsing other language sections to make both the entry and the TOC's themselves more navigable. Right now, I edit and read Spanish and Tagalog entries, both of which are near the bottom of most entries, and I find that I often have to scroll and scroll just to get to the bottom of the TOC! Not to mention that the TOC's can be a bit overwhelming when there are 50 different L2 headers, each with a number of subsections and sub-subsections which turn the TOC into a formidable wall of text. Andrew Sheedy (talk) 15:03, 26 August 2016 (UTC)
I agree totally. I don't think anyone is saying that the TOC should be dispensed with entirely, which may allay Daniel's fears. But I don't think it should be expanded by default for any language, not even English, as English TOCs tend to be quite lengthy. DonnanZ (talk) 15:12, 26 August 2016 (UTC)
Either way, this is the kind of thing that needs a vote, IMO. Please don't implement this without a vote. --Daniel Carrero (talk) 15:29, 26 August 2016 (UTC)
Having the gadget doesn't need a vote. Making it the default should. As for your objection: we're talking about defaults, here. As a gadget, it should be possible to opt out of it in your preferences. As long as it's made clear that the unexpanded state is incomplete and can be expanded, I'm all for it. It would be also nice to allow expansion of only one language: if I want to see the French section of a in the TOC, for instance, I don't want to have to scroll past all the English subsections and subsubsections, which take up two full screens on my computer. The gadget at Wiktionnaire does that quite well. Chuck Entz (talk) 18:53, 26 August 2016 (UTC)
This could be made to tie in to the gadget that lets you select preferred languages for translations. —CodeCat 19:02, 26 August 2016 (UTC)
I support what Chuck Entz said: "Having the gadget doesn't need a vote. Making it the default should." --Daniel Carrero (talk) 19:24, 26 August 2016 (UTC)
Tabbed Languages restructures display of the entire entry, not just the TOC- that's another matter entirely. Chuck Entz (talk) 18:57, 26 August 2016 (UTC)
I seem to recall reading in old discussions that the reason we didn't import fr.Wikt's system in the past was that it required using templates in the headers and that prevented editing particular sections and required editing the whole page all at once. That is evidently not the case any more, since I can edit e.g. specific noun sections of fr.Wikt pages. If we can bring over their gadget on an opt-in basis, and without needing to switch our headers to use templates, I'm all for it. - -sche (discuss) 19:21, 26 August 2016 (UTC)
I didn't realize it depended on the templatization of the headers. Hopefully that's no longer the case? (Unfortunately, I'm not very technologically minded, so I'll have to leave it up to others to sort out the details of implenting a Wiktionnaire-like system for TOC's....) Andrew Sheedy (talk) 03:32, 27 August 2016 (UTC)
Is anyone able to confirm whether this is in fact possible or not? Andrew Sheedy (talk) 01:43, 28 August 2016 (UTC)


Hello. I copy headword module to Azerbaijani Wiktionary. I have some problem with categories. Let me explain. I found first category on line 390. This code put word to category as "lang-code lemmas" (For example "English lemmas"). But I can't find line for lexical category such as nouns, verbs and others. For example in English Wiktionary Category:English nouns. How I can change it as Kateqoriya:İsim (İngilis dili) or Kateqoriya:İngilis dilindəki isimlər --Aabdullayev851 (talk) 08:00, 27 August 2016 (UTC)

Those categories are either provided as parameters to {{head}}, or as a parameter by the language-specific modules that call it, such as Module:en-headword. —CodeCat 12:16, 27 August 2016 (UTC)
Hi CodeCat. What about Afar language? There is not any {{head}} or Module:aa-headword. I think I can't explain my problem clearly. I want change category in this module for all languages. I change line 390 as :

In English Wiktionary :

table.insert(data.categories, data.lang:getCanonicalName() .. " lemmas")

In Azerbaijani Wiktionary :

table.insert(data.categories, data.lang:getCanonicalName() .. " dilindəki sözlər")

By this change words automatically categorized to "Category:XXX dilindəki sözlər" It is OK. Now I want explain my problem again. This module automatically categorized words by part of speech. For example put apple to "Category:English nouns" and sevmek to "Category:Turkish verbs". Right? I want change this section. If you have any question please let me know. --Aabdullayev851 (talk) 05:07, 28 August 2016 (UTC)


For some reason it's displays a genitive of bulleuntis in the head word template. Parameters look correct, so the participle template seems to be to blame. Renard Migrant (talk) 19:29, 27 August 2016 (UTC)

Fixed. It was the parameters: the word was divided bull|iens instead of bulli|ens, which made the template think the word was a compound of iēns ‎(going) (compare abiēns, whose genitive really is abeuntis). —Aɴɢʀ (talk) 07:34, 28 August 2016 (UTC)
A French entry? Too bad. I thought these were bullying aliens. --Dan Polansky (talk) 07:38, 28 August 2016 (UTC)
A Latin entry, actually, but I do like the idea of an English portmanteau "bullien" for a bullying alien. —Aɴɢʀ (talk) 07:43, 28 August 2016 (UTC)

Wiktionary data access requests in IRC[edit]

It is fall in the northern hemisphere, and we are beginning to get the annual migration to IRC of fledgling developers working on academic projects in need of a dictionary for whatever. It would be nice to have an information page a bit more expansive than the FAQ's entries. Here is a coarse draft which might be useful, but definitely needs more expertise/expansion: User:Amgine/Wiktionary data & API. - Amgine/ t·e 18:14, 28 August 2016 (UTC)

Fall (or autumn) doesn't start until September 22 this year. It's not even past Labor Day in the United States!
I smiled at the reference to XSLT. --MZMcBride (talk) 04:26, 29 August 2016 (UTC)
It’s still summer only in the U.S. In the UK, they have a different arrangement for the four seasons. I think the British consider the solstices and equinoxes to be the midpoints in the seasons, whereas Americans consider them the starting points. —Stephen (Talk) 04:53, 29 August 2016 (UTC)
Lughnasadh, or "the season related to the beginning of school term", or something even less precise than that. - Amgine/ t·e 04:58, 29 August 2016 (UTC)

Lua error in Module (error message)[edit]

I've come across this twice today, I managed to clear one, but at bade it's affecting four separate languages, and won't go away. DonnanZ (talk) 19:00, 29 August 2016 (UTC)

My bad, yet again. I fixed it before you posted this though. --WikiTiki89 19:03, 29 August 2016 (UTC)
Cheers, I couldn't have refreshed the page, DonnanZ (talk) 19:07, 29 August 2016 (UTC)
Also my bad just now. Guess I should read more carefully. —JohnC5 19:10, 29 August 2016 (UTC)

periodic-table translations[edit]

Just crossposting here from "Appendix talk:Chemical elements#Other languages" in case my original post is missed. I think it would be really great if we can create a series of appendices listing the names of chemical elements in each language (sorted by atomic number), with an index of the languages available for the individual appendices. Way outside my expertise, but it might be possible to program a bot to take the translations already available on Wiktionary and compile them into appendices for each language, which would save a ton of labor from manually copying and pasting. Element names are usually grouped together in the periodic table, so it is good to have the translations listed together in a single appendix, otherwise each element-name translation has to be looked up manually one by one (for over 100 elements). Nicole Sharp (talk) 20:03, 30 August 2016 (UTC)

I wonder if a "chemical element" translation data module for each language would be useful, allowing for both centralized data and easy data reuse. —suzukaze (tc) 06:48, 31 August 2016 (UTC)

Module:form of[edit]

Hello again. I want ask question about Module:form of . In line 106 :

return export.format_t(inflections[1] .. " of", terminfo)

This code output like that : plural of amo But I want output like that : amo of plural (for Azerbaijani Wiktionary). Can anybody can help me? --Aabdullayev851 (talk) 21:20, 30 August 2016 (UTC)

You need to change the order of concatenations in export.format_t and change line 106 like this:
return export.format_t("of " .. inflections[1], terminfo)
Benwing2 (talk) 22:05, 30 August 2016 (UTC)
Like this:
function export.format_t(text, terminfo)
		"<span class='form-of-definition-link'>" .. m_links.full_link(terminfo, "term", false) .. "</span>" .. " " ..
		"<span class='form-of-definition'>" .. text ..
Benwing2 (talk) 22:06, 30 August 2016 (UTC)
Benwing2 This code didn't work. --Aabdullayev851 (talk) 22:15, 30 August 2016 (UTC)
You have to tell me why it didn't work (e.g. did you get an error and stack trace?) or I won't have any idea how to help. Benwing2 (talk) 03:39, 31 August 2016 (UTC)
Hello again Benwing2. When I change line 106 like that :
return export.format_t(text, terminfo)
Error is : Lua error in Module:form_of at line 11: attempt to concatenate local 'text' (a nil value). How I can change change the order of concatenations? --Aabdullayev851 (talk) 11:29, 31 August 2016 (UTC)

September 2016

Can WT:ACCEL generate entries with two forms?[edit]

As some of you will know, -sche recently decided to cripple our coverage of Danish adjectives by deleting the template we used for a particular form, such that we are now supposed to pretend that there exist "definite forms" and "plural forms" (unlike every other major dictionary). In the process, they disabled the creation rule for that form, meaning new entries must now be made manually. If we absolutely must introduce this artificial and pointless distinction, can we at least bring back accelerated editing?__Gamren (talk) 12:09, 1 September 2016 (UTC)

Previous discussion is at Wiktionary:Requests_for_deletion/Others#Template:definite_and_plural_of, where there is no consensus for your idiosyncratic and only recently-introduced interpretation of the forms in a handful of (<90) entries. In Danish grammar and da:Dansk grammatik, I see that the indefinite singular, definite singular, indefinite plural and definite plural all have different endings; I see no two forms which could be combined by the template you were using as "definite and singular". Perhaps you thought you were using a Template:singular definite of/Template:definite singular of coordinating with a Template:plural definite of/Template:definite plural of? that wording is what was found in entries prior to your edits, e.g. at pesten and huset. - -sche (discuss) 17:21, 1 September 2016 (UTC)
Once again, you demonstrate a staggering ignorance on the subject. Nouns are inflected with respect to definiteness and number. pesten and huset are nouns, and I have never even edited any of those entries. I am talking about adjectives, which have a form that is used for definite plural, indefinite plural and definite singular (the latter, only when used attributively). If you scroll down, you will find that adjectives have (up to) three positive forms, of which one is called the e-form or plural / definite by the Wikipedians. I also did not add that form to {{da-adj}}; it was already there, back in 2014, long before I made my first edit. And as I have noted on the page you linked to, the interpretation I advocate is used by Den Danske Ordbog, Ordbog over det Danske Sprog (which is quite old by now), Retskrivningsordbogen (which is published by a government agency) and Nudansk Ordbog. It is not in any way idiosyncratic.
However, if you refuse to listen to reason, can we, as I requested, at least make editing easy again?__Gamren (talk) 08:11, 2 September 2016 (UTC)

Morse code images not showing up in mobile view (but are showing up in mobile edit previews)[edit]

For example at .--. (mobile version). Can one of the devs perhaps explain this nonsense? --WikiTiki89 15:10, 1 September 2016 (UTC)

Your link is working great to me. I'm accesing in on my notebook, so I'm not using an actual cell phone. I suppose you already fixed the problem? Or should we try accessing the page with an actual cell phone? Or is it still broken in actual cell phones? (edited for tone) --Daniel Carrero (talk) 19:56, 1 September 2016 (UTC)
I did not fix the problem. It still doesn't work for me, neither on my iPhone (in chrome, safari, and firefox), nor on my Windows computer (in chrome). --WikiTiki89 20:02, 1 September 2016 (UTC)
I don't know what would help. I would suggest cleaning the cache, (?) but since it is not working in any of the 4 mobile+navigator combinations you mentioned, my suggestion would probably be pointless. The Module code looks okay to me. --Daniel Carrero (talk) 20:09, 1 September 2016 (UTC)
Hmm... It's working now on my computer and my phone. Interestingly, it loads as invisible and then fades into view. Perhaps that fade is what wasn't working before. --WikiTiki89 11:51, 2 September 2016 (UTC)
Do other images load on your phone? Do they fade in/ behave like the Morse code does? I wonder if it matters that the same image is being loaded multiple times: try viewing [8]. Or perhaps the issue is that the images are being loaded by a template, especially one which I gather is fetching the page name in order to decide what images to load, which may be taking time (too long, so that it gets shut off?). - -sche (discuss) 04:41, 3 September 2016 (UTC)
"Loads as invisible and then fades into view" sounds like lazy loading. (also, why don't we get Tech News here) —suzukaze (tc) 04:58, 3 September 2016 (UTC)
I wonder if it's possible to explicitly exempt certain small images from lazy loading, or at least disable the fade-in. @-sche, yes those and other images show up but also fade in. --WikiTiki89 18:05, 5 September 2016 (UTC)

Anagram format[edit]

Since the vote on anagram format (can anyone dig this up? Circa 2011) the format has never actually been implemented. I have initially tried to implement it for French and it's a bit too difficult for me to do. And that's just for French before starting on other languages.

I suppose ideally all the anagrams on the whole wiki need updating. I mean, why do we only do some languages and not all? But just updating the format without updating the words would be a good start. The format is

* {{l|en|instar}}, {{l|en|sartin}}, {{l|en|strain}}

The old format was

* [[instar#English|instar]]
* [[sartin#English|sartin]]
* [[strain#English|strain]]

Renard Migrant (talk) 20:17, 3 September 2016 (UTC)

I would prefer to use a single template: {{anagrams|en|instar|sartin|strain}}, since this section is almost never edited by humans. Of course this would require someone willing to run a bot to update all the entries. DTLHS (talk) 20:28, 3 September 2016 (UTC)
I oppose showing them all on one line. If we're going to use a list item, we should show them all in a list, as in the old format. —CodeCat 14:01, 4 September 2016 (UTC)
I would have separate lines for separate orders of letters, but keep things that are identical except for capitalization and diacritics on a single line, thus:
* {{l|en|ees}}
* {{l|en|ese}}
* {{l|en|see}}, {{l|en|See}}, {{l|en|sée}}
(I know most of the above aren't actually English words, it's just to illustrate my suggestion.) —Aɴɢʀ (talk) 20:56, 5 September 2016 (UTC)
The votes was Wiktionary:Votes/pl-2011-11/Update ELE anagram format (although language anchors were already in use then, so I don't know why I didn't include them in the example text). I've no objection to reviewing the anagram display format, although I don't think it's the most productive thing we could be doing. I'm not seeing a lot of appetite to change it. Renard Migrant (talk) 12:23, 9 September 2016 (UTC)


A point of usability: the selection links (All, None, Invert) on this page are dangerously close to the big Delete button. Can we add more space? Equinox 09:21, 4 September 2016 (UTC)

(How does one edit a special page, anyway?) Equinox 16:57, 17 September 2016 (UTC)
I have no idea. I imagine they are hardcoded into the software. —CodeCat 16:59, 17 September 2016 (UTC)
Apparently; at least, someone has previously had to ask the devs when they wanted the text changed (despite the comment "Looking at the i18n file for Nuke.. Those look like localised messages..."). - -sche (discuss) 17:41, 17 September 2016 (UTC)
I have no idea what is going on, but it seems like someone moved the button to the bottom of the page, which is not perfect (it's still very close to the lowermost tickbox) but better. Who did this?! Own up. I'm gonna keep the whole class in, until someone admits it. Equinox 05:44, 27 September 2016 (UTC)

Rundi error[edit]

  • I get the following error message when attempting to add a Rundi (ISO 639-3 RUN) translation: "Lua error in Module:languages/templates at line 28: The language code 'rn' is not valid.: Lua error in Module:parameters at line 110: The parameter "<strong class" is not used by this template." Nicole Sharp (talk) 13:57, 4 September 2016 (UTC)
  • Attempting to add the translation manually via template also provides: "Lua error in Module:translations at line 30: The language code "rn" is not valid." Nicole Sharp (talk) 14:02, 4 September 2016 (UTC)
  • Wiktionary:Language treatment: "Rwanda-Rundi is treated as a single language with the code rw. The ISO had coded the dialects separately, using rw for "(kinya)Rwanda" and rn for "(ki)Rundi", etc." DTLHS (talk) 14:04, 4 September 2016 (UTC)
    • Yes, I just saw that. There is a Rwanda-Rundi translation, with Wikipedia listing Rundi and Rwanda as being dialects of Rwanda-Rundi as opposed to individual national languages. However, there is no ISO language code for Rwanda-Rundi, only for the national lects. The translation module should be programmed then to display translations entered as RN under "Rwanda-Rundi," similar to how translations entered as BS (Bosnian) display under "Serbo-Croatian." Nicole Sharp (talk) 14:12, 4 September 2016 (UTC)
  • It should also be noted that the Rwanda and Rundi lects have separate Wikipedias: http://rn.wikipedia.org/ (493 articles in Rundi) and http://rw.wikipedia.org/ (1789 articles in Rwandan). I personally do not know how mutually intelligible the two are, but if they warrant separate Wikipedias, I think it might be helpful to be able to list via ISO code which words are from which dialect. Nicole Sharp (talk) 14:38, 4 September 2016 (UTC)
    • Browsing the Wikipedias, here is at least one notable difference between the two: "Africa" is either "Afurika" (Rwandan) or "Bufurika" (Rundi). Putting both translations under RW could be confusing. Nicole Sharp (talk) 14:49, 4 September 2016 (UTC)
      • The name of the language, "Rwanda-Rundi", should minimize that confusion; users see names more than codes. The rationale of and discussions which led to the merger are documented at Wiktionary talk:Language treatment/Discussions#The_Rwanda-Rundi_lects. Thanks for pointing out that there is a mechanism for automatically switching codes for sh; I had forgotten about it. I'll see if I can adapt it to also work for other mergers, like this and Moldovan. - -sche (discuss) 16:22, 4 September 2016 (UTC)
  • Here is another one I just noticed: "republic" is either "repubulika" (Rwandan) or "republika" (Rundi). I would advise allowing translations to be entered under both codes (RN and RW), and then having the dialectal differences in spelling listed separately as we do for Norwegian Bokmal (NB) versus Norwegian Nynorsk (NN), e.g. "Norway#Translations." Nicole Sharp (talk) 16:55, 4 September 2016 (UTC)
    The split of Norwegian into three languages (Bokmal, Nynorsk, and "Norwegian" for dialectal forms that belong to neither standard or forms that another standard) is controversial and not to be imitated. The small differences you have pointed out are hardly enough to hamper mutual intelligibility (and they rarely follow the lines denoted by the codes Ethnologue set up), which is indeed what a native speaker said when Metaknowledge consulted them before we merged the lects, following the linguistic literature which mostly treats Rwanda, Rundi, Vinza etc as dialects of one language. You may note that Serbian, Croatian, etc also have separate Wikipedias, but this is not an impediment to the merger of them, either. - -sche (discuss) 17:02, 4 September 2016 (UTC)
    • Words that are unique to only one of the Rwanda-Rundi dialects should be tagged with the {{lb}} template. Right now, {{lb|rw|Rwanda}} would put terms into "Category:Rwandan Rwanda-Rundi", which sounds ridiculous. Is there some way to edit Module:labels/data/regional to categorize into "Category:Rwanda" instead (and also have {{lb|rw|Rundi}} categorize into "Category:Rundi"), while still correctly categorizing CAT:Rwandan French and CAT:Rwandan English? But wait! Come to think of it, do we even want CAT:Rwanda to be for terms in the Rwanda variety of Rwanda-Rundi? Because Rwanda is also a country, and other categories named for countries are top-level topic categories, e.g. CAT:Thailand. So maybe we should keep CAT:Rwanda for the country and find some other name for "Rwandan Rwanda-Rundi". Suggestions? CAT:Kinyarwanda for the dialect? —Aɴɢʀ (talk) 21:09, 5 September 2016 (UTC)
      • I propose renaming the top-level topical categories instead, so we never have this problem. —CodeCat 21:37, 5 September 2016 (UTC)
        • Renaming them to what? —Aɴɢʀ (talk) 23:20, 5 September 2016 (UTC)
          • The suggestion has been to incorporate a "topic:" prefix into the topic categories' names, and "set:" into the set categories' names. (Somewhat relatedly, in discussions in 2014, May 2015 and August 2015 there was support for renaming the dialect categories to "[language] of [place]" ("French of France"). At the time it wasn't implemented because e.g. "German of Austria" was felt to be unpretty, but the current naming scheme keeps causing problems.) - -sche (discuss) 04:42, 6 September 2016 (UTC)
      • @Angr, -sche: Yes, that needs to be dealt with. The dialects should display the name of the country in the label, but simply categorise as CAT:Kinyarwanda and CAT:Kirundi, in my opinion. (And the other lects merged into rw should be handled similarly.) —Μετάknowledgediscuss/deeds 00:14, 6 September 2016 (UTC)
        • The categories "Rwandan French" and "Kinyarwanda" are of the same type (both dialect categories, rather than e.g. one being a topic category), which complicates matters. Perhaps someone could add code that would make category names language-specific; this would also be useful for distinguishing e.g. "South Bavarian" (bar) from words hypothetically limited to "South Bavarian German" (de). Failing that, we could just use a different label "Kinyarwanda" to put terms into the Kinyarwanda category, and make "Rwandan Rwanda-Rundi" a cleanup category. - -sche (discuss) 04:42, 6 September 2016 (UTC)

A bot job request[edit]

Can please someone run a job to convert all transliterations to lower case for languages where transliterations should only be in lower case?

There were previous agreement on this but please comment if you object to this. Some casual editors still capitalise Persian and Hebrew transliterations.

Obviously, Cyrillic, Greek and Armenian capitalisations should match the native spelling and they use mostly automatic transliterations, anyway.

Languages, which DON'T use capital letters in their scripts but capitalised transliterations are allowed are only:

  1. Some Chinese lects - Mandarin, Min Nan, Min Dong, Hakka but not Cantonese, Wu, etc.), Japanese and Korean. No need to to do anything with these languages.

My request is mainly for these:

  1. Capital letters for Arabic, Hindi, Bengali and various Indic languages (e.g. Dravidian group) have a different phonetic value but they are mostly converted and largely rely on automatic transliterations. Arabic entries have been mostly fixed by User:Benwing/User:Benwing2
  2. Persian, Hebrew, Yiddish, Pashto still use capital letters. They all need to be turned to lower case in entries and translations, including proper nouns.

--Anatoli T. (обсудить/вклад) 07:14, 5 September 2016 (UTC)

Perhaps Gothic should be added to this list. There's the added complication that the transliterations have entries, and they're often capitalised even though the original script had no such distinction. But I believe that we shouldn't be inventing case distinctions, not just for Gothic but for any language. This includes Japanese, Chinese, as well as old European languages written before casing was a thing. —CodeCat 21:40, 5 September 2016 (UTC)
We've discussed this before. For Chinese and Japanese, the case distinctions are invented for us by the language governing bodies, and while I still don't like it, it's still more acceptable to me than inventing case distinctions ourselves. --WikiTiki89 22:50, 5 September 2016 (UTC)
Ok, if they're official, then leave it. What about the rest, though? There's no official spelling for Old English; Englisc was not written with a distinct capital letter in any manuscript. It's an anachronism based on modern English spelling. —CodeCat 22:54, 5 September 2016 (UTC)
For the rest I agree. The problem with languages like Latin, however is that the capitalization rules changed throughout the history of what we consider to be Latin. In Classical Latin, there was only one lettercase, but later on (well, much much later on) capitalization did develop. But I also guarantee that for most of our early modern languages, the attested capitalization is different from our capitalization. It's a big mess and most people seem to be against solving it. --WikiTiki89 00:21, 6 September 2016 (UTC)
  • Don't forget Georgian either. In official use, Georgian is unicase, but it is still acceptable to capitalize using Asomtavruli letters. For languages that have optional capitalization like Latin and Georgian, I would say to definitely keep the capitalized transliterations, even if the translation does not use capitalization. Nicole Sharp (talk) 03:55, 8 September 2016 (UTC)
    • No, not true. Modern Georgian does not have optional capitalization. Anyways, Asomtavruli has its own unicode range, so optional capitalization can be handled by the module.--Giorgi Eufshi (talk) 09:24, 9 September 2016 (UTC)
      • Look, it's pretty simple, transliterations should keep capitalization of the original script if it has any and not add any new capitalization (or remove any capitalization). There's no more theory to it than that. Whichever Georgian entries are entirely in the unicase Mkhedruli, as (nearly?) all of them are, should have unicase transliterations. If we are transliterating text that uses Asomtavruli as capitals, then the Asomtavruli should be transliterated as capitals. --WikiTiki89 13:46, 9 September 2016 (UTC)
The easiest (only) way this is going to happen is with lots of tracking categories: for each language and for each template that needs to be converted. DTLHS (talk) 14:06, 9 September 2016 (UTC)
Or with a bot, which is the purpose of this thread. --WikiTiki89 14:27, 9 September 2016 (UTC)
Yes, a bot that is fed with tracking categories. DTLHS (talk) 14:30, 9 September 2016 (UTC)
It doesn't need to be fed with tracking categories. It can just do a dump analysis, which is easier and faster. --WikiTiki89 14:32, 9 September 2016 (UTC)
Categories will allow us to detect the problem even after the original bot run is complete. DTLHS (talk) 15:06, 9 September 2016 (UTC)
Sure, but we don't need the categories for the original bot run. That's all I wanted to say. --WikiTiki89 15:10, 9 September 2016 (UTC)

French IPA module error[edit]

On brancher, Joconde and a couple dozen other pages there is the following error: "Lua error: bad argument #1 to 'lc' (string expected, got table)/, /Lua error: bad argument #1 to 'lc' (string expected, got table)" - -sche (discuss) 04:53, 7 September 2016 (UTC)

Sorry, my breakage. Fixed. Benwing2 (talk) 08:13, 7 September 2016 (UTC)
Thanks. - -sche (discuss) 18:05, 8 September 2016 (UTC)


Can anyone figure out why this is in Cat:Pages with module errors? No error is displayed and there's nothing obviously wrong with the code to my admittedly untrained eye. Chuck Entz (talk) 12:26, 7 September 2016 (UTC)

Fixed. The module errors were hidden in the if statements (essentially {{#ifeq:[module error]|...}}) and therefore not displayed. --WikiTiki89 14:01, 7 September 2016 (UTC)

Image sizes[edit]

What image sizes can be used? I found "350px", are there others? DonnanZ (talk) 09:35, 8 September 2016 (UTC)

What do you mean can be used? Any size can be used. --WikiTiki89 10:11, 8 September 2016 (UTC)
I meant what sizes are recognised by the system, obviously 350px is one. DonnanZ (talk) 10:32, 8 September 2016 (UTC)
Any size is recognized by the system. --WikiTiki89 10:36, 8 September 2016 (UTC)
Right. (But for the record, the default sizes "thumb" and "upright" should be used in most cases so that users' preferences for what size they want images to display at are respected, unless there is a specific reason to deviate, such as that a non-SVG image is designed to appear at a smaller size than the usual thumbnail size.) Wikipedia has a tutorial, which notes that you can even specify a size like upright=1.35 to display something at 1.35 times the user's preferred base size. - -sche (discuss) 18:05, 8 September 2016 (UTC)
I will have to do some experimenting on this. I did scale down one image I filched from Nynorsk Wikipedia (satellittbilete) from the given 350px as I felt it was too big, but on the other hand I used 350px to scale up the image at tramshed, which I think gives a better result. DonnanZ (talk) 18:20, 8 September 2016 (UTC)
Don't forget that everyone has a different screen size, so if you adjust it to look good on your screen, it might make it worse on other people's screens. That's why it's better to stick with the default as much as possible. --WikiTiki89 18:28, 8 September 2016 (UTC)
Yeah, my screen is about 18.5", but I guess anyone can alter an image size if they aren't happy with it. DonnanZ (talk) 18:45, 8 September 2016 (UTC)
It's not only the inches but also the resolution and just the size that the browser window happens to be. People also use Wiktionary on mobile devices. I hope by your comment you're not expecting every user who is unhappy with image sizes to edit the page himself. --WikiTiki89 18:53, 8 September 2016 (UTC)


diff. What the Hell's actually changed here? I've copied and pasted both of them and they both go to English. Renard Migrant (talk) 20:09, 8 September 2016 (UTC)

Two characters of U+FFFC (OBJECT REPLACEMENT CHARACTER) were inserted on either side of the word "English". No idea why. --WikiTiki89 20:12, 8 September 2016 (UTC)
They were trying to get around Abuse Filter 52. I created it to deal with a very specific type of vandalism (I won't go into detail here for obvious reasons), but it catches some very interesting other types, including a misconfigured bot that seems to be hunting out insecure servers to post gibberish from. So far, only one false positive and no one's figured it out yet. Chuck Entz (talk) 02:57, 9 September 2016 (UTC)

Audio recording now working in Chrome[edit]

As of the latest Chrome update I have received (version 53.0.2785.101 m), the audio recording functionality is now working: the "Add audio pronunciation" appears within entries (it didn't before) and recording and playback are working. I haven't tried saving one yet because my Webcam audio is a bit noisy; I'll try it with a headset at some other point. Equinox 21:15, 9 September 2016 (UTC)

My headset won't record properly (it's very quiet, barely audible, and I've tried everything, e.g. changing USB ports, setting vol to 100% with boost, reinstalling drivers...). Should I record loads of pronunciations with my Webcam even though it's a bit hissy? No point bothering if the files will need replacing. Or can we build in a noise/hiss filter into the recording gadget (LOL I doubt it). Equinox 17:58, 11 September 2016 (UTC)
Maybe upload the quiet ones, then [ask someone to] reprocess them with another external audio editing program...? (just an idea) —suzukaze (tc) 18:04, 11 September 2016 (UTC)
I have tools to do noise reduction myself, but then I can't use the gadget and there's the awful ten-step process of licensing, uploading, linking... So I think I won't bother for now. I'll try my headset on another PC and see if it's actually broken, though I think it's some deep obscure issue with my specific computer. Equinox 19:32, 15 September 2016 (UTC)

VL-verb module[edit]

I've created Module:User:KarikaSlayer/VL-verb (demo: User:KarikaSlayer/VL-verb/test) as a replacement for {{VL-conj}} and family. The module is set up to show separate tables for different Romance branches along with forms unique to that branch (instead of just Italo-Western Romance). Any thoughts/criticism? KarikaSlayer (talk) 03:30, 10 September 2016 (UTC)

Manichaean transliteration[edit]

@Vahagn Petrosyan: I've made a Manichaean transliteration module at Module:Mani-translit. I guess I should make a transliteration appendix too. Do you have any comments on this? I'm not sure whether I like all the specific transliteration (for instance, the transliteration of the aayin 𐫚 ‎(ʿ̈ )). —JohnC5 04:55, 10 September 2016 (UTC)

@JohnC5: Thank you for making the module. I prefer c instead of č and x instead of . That is what DMMPP uses.
I have two concerns about using the native script for Manichaean. As far as I know, no font supports Manichaean, which is why we have been using the Latin transliteration. Also, if we use the module with automatic transliteration, where would the transcription go? For languages with defective writing systems, such as Manichaean or Pahlavi, both transliteration and transcription should be shown. That is how the academic literature does. Currently we cheat and give the transcription in place of transliteration, like this: Manichaean Middle Persian bzyšk ‎(bizešk). We should probably have an additional parameter for transcription, so that {{m|xmn|𐫐𐫢𐫏𐫉𐫁|transcription=bizešk}} renders like 𐫐𐫢𐫏𐫉𐫁 ‎(bzyšk /bizešk/). That would also solve the problem with Thai transliteration/transcription about which people have been fighting. --Vahag (talk) 10:42, 10 September 2016 (UTC)
That would be a very interesting idea that would also help out with things like Mycenaean Greek, Hittite, Old Persian, and numerous other abjads and syllabaries. Let me pull in @CodeCat, Wyang, Dan Polansky, Chuck Entz. —JohnC5 15:01, 10 September 2016 (UTC)

Page layout problem[edit]

The page stitch up displays incorrectly in IE and Edge. There is a large blank space at the top of the page to the left of the picture, and all the text content is pushed down below the picture. It is a consequence of the combination of "was wotd" with "File:" The page displays correctly in Chrome. I'm not sure whether it is a browser glitch or whether Wiktionary is generating badly-formed HTML that Chrome handles gracefully but the other browsers do not. The following fixes the problem, but it seems a bit of a hack:

<div style=float:right> {{was wotd|2016|May|27}} [[File:Fotothek df roe-neg 0000071 001 Portrait einer jungen Frau mit Nähzeug.jpg|thumb|A young woman with her sewing kit in Germany in the 1940s]] </div>

Is there any better way to work around this? 17:29, 10 September 2016 (UTC)

Here is a minimal example that looks fine in Firefox and Chrome but not in IE or Edge. It seems to be a combination of the two divs with "clear: right; float: right;" and the heading with "overflow: hidden;". I'm not sure what the solution is from our point of view - presumably there are other affected pages? Edit: indeed there are: adder, adhocracy, anneal, alabaster, acheiropoieton (continued ad infinitum...) Keith the Koala (talk) 19:04, 10 September 2016 (UTC)


I notice that the module which supplies transliterations of OCS/Glagolitic does not transliterate Ⰼ ⰼ ‎(Đ đ) (or, transliterates it as itself). Presumably it should transliterate it to Latin script, regardless of whether we lemmatize words on that spelling, since mentions words spelled with this letter. How should it be transliterated? - -sche (discuss) 18:28, 10 September 2016 (UTC)

Perhaps Đ/đ? --WikiTiki89 19:40, 10 September 2016 (UTC)
I have implemented my own suggestion. --WikiTiki89 15:39, 12 September 2016 (UTC)
@Wikitiki89 Thanks. The character is hard to search for, so I couldn't find any works that used/transliterated it at the time I posted. I've now managed to find a few books which transliterate it, including the Handbook of Old Church Slavonic of G. Nandris, as edited (translated?) by Robert Auty, and Horace Gray Lunt's Old Church Slavonic Grammar, which both transliterate Ⰼ as ǵ. Is a switch to that transliteration in order? The different Old Cyrillic ‎() of the same name ("djerv") may equate to đ, per WP, but indeed the etymology of the entry suggests that a g-like transliteration for the Glagolitic letter may be more appropriate for it (in words it seems to have come to be represented by г/ѓ in some languages, per Lunt). - -sche (discuss) 17:33, 17 September 2016 (UTC)
The letter ѓ is only used in Macedonian, in which it represents historically the same phoneme as Serbo-Croatian đ/ђ (the latter Cyrillic character is actually derived ultimately from the Old Cyrillic character Ꙉ that you mentioned). The phoneme itself is is a reflex of Proto-Slavic *-ď- < *-dj-. --WikiTiki89 20:18, 17 September 2016 (UTC)

Template:R:The Bokmål Dictionary, Template:R:The Nynorsk Dictionary[edit]

These have a new Internet address, and searches are now being affected by the change. The new address is http://ordbok.uib.no, probably due to the recent move from Oslo University to Bergen University. DonnanZ (talk) 14:03, 12 September 2016 (UTC)

What needs to be edited is Module:Template:R:The Bokmål and Nynorsk dictionaries, though I'm not sure how. —Aɴɢʀ (talk) 14:18, 12 September 2016 (UTC)
I wish it was as easy as amending the address in Favourites on my computer... DonnanZ (talk) 20:11, 12 September 2016 (UTC)
I think I've fixed it (tested successfully with onsdag), but all entries may need the "null edit" to update their template usage. Equinox 20:16, 12 September 2016 (UTC)
The fix will propagate without null edits. Null edits and purgues just force it to happen immediately. --WikiTiki89 20:18, 12 September 2016 (UTC)
Yes, it's working for onsdag, but not for hånd and hånd-, so maybe æ, ø and å need special treatment. DonnanZ (talk) 20:27, 12 September 2016 (UTC)
It's working for me at hånd and hånd-. --WikiTiki89 20:34, 12 September 2016 (UTC)
They are now, I null-edited them both, so the system has to catch up. Thanks to Equinox. DonnanZ (talk) 20:37, 12 September 2016 (UTC)

Collapsible nested tables[edit]

I have an experimental template {{hu-possessive}} with nested collapsible tables based on the possessive forms table {{qu-poss-noun}}. When the table is first opened, six rows are displayed. I'd like to add more information to the six header rows besides the current "first-person singular", etc. I'd like to display the nominative row's singular and plural entries, so it would say: first-person singular | emberem | embereim. Is this technically feasible? Is there a better solution for collapsible tables, perhaps using mw-collapsible? Thanks. --Panda10 (talk) 15:30, 12 September 2016 (UTC)

That's not just feasible, but actually quite easy; the first-person singular actually appears as such in the template definition, and it's easy to edit it to add other stuff there. But that template doesn't yet support showing declensions of different words on different pages, which is certainly the most basic requirement for a declension template; so it seems premature to be worrying about niceties like you describe. —RuakhTALK 06:43, 17 September 2016 (UTC)

History merges: Are they worth it?[edit]

I found on Wikipedia how to merge the histories of two pages when merging two pages. I tried it a couple times today, for example when merging бєз into без. If you look at the history of the page без, you will see a bunch of edits that seemingly remove large amounts of text; those are the edits that were merged from бєз. So I'm wondering: Is it worth preserving the history of the old page despite the strange way it shows up? --WikiTiki89 21:09, 13 September 2016 (UTC)

Isn't the idea that we preserve the whole history of all contributions? I thought it was part of the wiki religion, not to be questioned on utilitarian grounds. DCDuring TALK 22:23, 13 September 2016 (UTC)
Well we already don't do that absolutely always. But still don't you think that the history merge makes the history a little confusing? --WikiTiki89 22:28, 13 September 2016 (UTC)
(e/c) The resulting merged history is hard to make sense of because of the way it's linearized; I would probably say it's not worth it for this reason. If you hadn't told me that this was the result of a history merge, I'd have a hard time figuring out what the hell was going on. It's unfortunate that the merged history can't be displayed in a more sensible way. Benwing2 (talk) 22:34, 13 September 2016 (UTC)
They are certainly worth it when required by the licenses, when they aren't required they are probably not worth it. - TheDaveRoss 23:43, 13 September 2016 (UTC)
@TheDaveRoss: When are they, and when are they not, required by licenses? --WikiTiki89 02:27, 14 September 2016 (UTC)
All content created by contributors must be attributed. This is best done via the edit history, but I've seen it done for interwikis by a listing on the talk page, and even an edit summary will suffice for something like copying from one entry to another, where it's just a matter of pointing to the location that has the edit history. Content from non-copyrighted sources doesn't require attribution as far as licensing goes, and edit histories aren't attribution in such cases anyway. I believe content that has been permanently removed wouldn't require attribution, either. Chuck Entz (talk) 03:43, 14 September 2016 (UTC)

R:World Wide Words[edit]

Can someone help figure out what is wrong (if anything) with {{R:World Wide Words}}? I used it on on the wagon, but it produces the link http://www.worldwidewords.org/qa%2Fqa-wag1.htm (note how the "/" is replaced by "%2F"), which generates an error and does not load the correct page http://www.worldwidewords.org/qa/qa-wag1.htm. Thanks. — SMUconlaw (talk) 18:19, 14 September 2016 (UTC)

@Smuconlaw: Fixed. Isomorphyc (talk) 17:05, 15 September 2016 (UTC)
Great, thanks! — SMUconlaw (talk) 17:15, 15 September 2016 (UTC)

NavFrame question[edit]

I created a new template to replace the current Hungarian possessive template in order to contain all inflected forms instead of only a few. The new table uses NavFrame and because of that it looks slightly different than the old one. Please see both tables here: {{hu-infl-pos-table-comparison}}. The name of the collapsing links are different: more/less vs show/hide. NavFrame works better for long tables in Mobile view because it keeps the table collapsed, while in the current solution tables are always open in Mobile view and are not collapsible at all. The other reason for the exact match is that Hungarian entries use two declension tables, one for regular declensions (generated by a module), the other for possessives. The two tables should look the same in collapsed mode. Is there a way to achieve that with NavFrame? Thanks. --Panda10 (talk) 19:22, 14 September 2016 (UTC)

Did you try mw:Manual:Collapsible_elements? This is a way better alternative, if only because it is in the core of Mediawiki, so it is tested and stable (=works on mobile). — Dakdada 13:28, 15 September 2016 (UTC)

Interwikis after page moves[edit]

Do any of the current interwiki bots remove interwiki links to the wrong page name after a page is moved? I have found instances where the interwiki bot just adds the new interwiki links below, leaving the old incorrect interwiki links there. It would be nice if the bots could do this sort of cleanup, since it is very tedious to do by hand when moving multiple pages. --WikiTiki89 19:44, 14 September 2016 (UTC)

@Ruakh, Thibaut120094, Whym, Octahedron80, Udo T. (pinging people who run interwiki bots). --WikiTiki89 22:40, 14 September 2016 (UTC)
I lately did that on other projects. When running on English Wiktionary, the result is my OctraBot got blocked few days ago. Because admin said it's okay to keep redirects (even they're moved). So I don't care this issue. I now look forward to new Wikidata approach that is going to collect Wiktionary interwiki links declared yesterday. The problem will begone with this. --Octahedron80 (talk) 00:35, 15 September 2016 (UTC)
@Octahedron80: I see in your bot's block log that TAKASUGI Shinji said "Wiktionary allows an interwiki link to a redirect". This is true. I am talking about a different issue: When I move a page here from X to Y, the page at Y now contains links to X on other wikis. For example, I moved сєдмь to седмь, but now седмь currently still has links such as [[fr:сєдмь]], which should be removed. As far as I can tell, no bot seems to be removing these, although I may be wrong. --WikiTiki89 01:05, 15 September 2016 (UTC)
That case when you move a page, you can just delete old iw's all. Some time later a bot will visit the page and re-create clean iw's for it. --Octahedron80 (talk) 01:40, 15 September 2016 (UTC)
@Octahedron80: I know I can. But like I said in my original post, when I am movig a lot of pages, it becomes very tedious. --WikiTiki89 01:44, 15 September 2016 (UTC)
Any pywikibot can do this. But it uses the same parameter as my bot got blocked (-force) so nothing we can do better than adding new iw. (-cleanup) --Octahedron80 (talk) 01:49, 15 September 2016 (UTC)
I guess you're not the type to meddle with the code. Maybe someone else will be up to the task. --WikiTiki89 01:58, 15 September 2016 (UTC)
I don't want to mess other's codes or I can't update new version. Sorry. ;( --Octahedron80 (talk) 02:08, 15 September 2016 (UTC)
Is there really no option to treat redirects as normal pages? That would solve the problem you were blocked for. --WikiTiki89 02:10, 15 September 2016 (UTC)
As I research at this point, still no. phab:T111136 --Octahedron80 (talk) 03:16, 15 September 2016 (UTC)
Well of course if you use -force and let your bot running without checking its edits, it will get blocked, lol. -force remove everything including mismatches and other things that should be dealt with manually. --Thibaut120094 (talk) 06:57, 15 September 2016 (UTC)
I've done such cleanup runs before, but it's not part of the usual behavior of Rukhabot's interwiki-updater. I'll look into adding it. (No promises, though; so if someone else wants to do it, they should go right ahead.) —RuakhTALK 04:50, 15 September 2016 (UTC)
Addendum: I've now added this functionality to Rukhabot's monthly interwiki-updater. [example edit]   Note that, at least for now, it's pretty conservative, only removing ones that seem (on the basis of a few heuristics) like they were really intended to be interwiki-links. (These heuristics should, at least, cover any cases where an interwiki-link was added by a bot but then invalidated by a page-move.) After the first monthly pass, I'll check to see if there are any pages that have bad interwiki-links that Rukhabot ignored, and re-assess the heuristics accordingly. —RuakhTALK 04:11, 18 September 2016 (UTC)
With pywikibot it is possible to remove links automatically (except "disambiguation mismatch and namespace mismatch") with -cleanup. Haven't tried it yet, I don't know if I'll add it to the normal routine but I'll give it a try. Regards. --Thibaut120094 (talk) 06:57, 15 September 2016 (UTC)
Welp, -cleanup was working well until it removes redirects, so I can't run my bot unattended to remove the links. :(
Do you guys keep the pywikibot devs updated about our specificities? Maybe I should learn Python and create my own scripts. I raised the priority of phab:T111136, I hope it will get fixed. --Thibaut120094 (talk) 07:31, 15 September 2016 (UTC)
@Wikitiki89: I think I updated all the pages you moved. Regards. --Thibaut120094 (talk) 08:47, 15 September 2016 (UTC)
@Thibaut120094: Thank you! Just note that I am not done moving pages, and people will always be moving pages, so I hope you can make that part of your bot's routine to cleanup moved pages. --WikiTiki89 11:46, 15 September 2016 (UTC)

Alphabetical sorting in categories[edit]

Category:1000 basic French words isn't sorting properly. Diacritics should be ignored rather than listed under separate headings. Andrew Sheedy (talk) 03:08, 15 September 2016 (UTC)

The category is outside of automated language structure controlled by modules so it is certainly not sorted. 😅 --Octahedron80 (talk) 03:51, 15 September 2016 (UTC)
Not quite true: it's sorted by the order of its encoding. The only way to fix this is to add a sort key to the category reference in the entry, as in [[Category:1000 basic French words|etre]] or [[Category:1000 basic French words|e^tre]] (you could also use DEFAULTSORT in the entry, but that affects sorting for everything on the page). Chuck Entz (talk) 04:00, 15 September 2016 (UTC)
@Chuck Entz. User:Octahedron80 must be referring to Thai (Lao, Khmer, etc.) entries. The default sort is poor or wrong. French diacritics is a small problem in comparison. That's why many Thai entries use {{DEFAULTSORT|CUSTOMSORT}}. Please see more of my ranting in Wiktionary:Votes/2015-03/Templatizing topical categories in the mainspace. --Anatoli T. (обсудить/вклад) 06:05, 15 September 2016 (UTC)
User:Wyang has created categories with sorting with Module:zh-cat for Chinese. I don't know if {{catlangcode}} does a better job for Japanese. Apparently, you still need to pass a kana reading for kanji terms. --Anatoli T. (обсудить/вклад) 06:16, 15 September 2016 (UTC)

@Atitarev By the way, I have sort keys for Thai and Lao waiting in Module:languages/data2 talk page --Octahedron80 (talk) 07:04, 15 September 2016 (UTC)
@Octahedron80 I'll add per your request but I have some doubts it'll fix topical categories. --Anatoli T. (обсудить/вклад) 07:16, 15 September 2016 (UTC)
It should do too. Leave the system clear their cache for some time. Nope it doesn't work with manual categorizing. It works only POS cats.--Octahedron80 (talk) 07:19, 15 September 2016 (UTC)
(Before E/C) @Octahedron80 เกรปฟรุต ‎(gréep-frút) is sorted correctly in Thai nouns and lemmas categories but if you open Category:th:Fruits, เกรปฟรุต ‎(gréep-frút) is now sorted under "เ" not the expected "ก". Even [[Category:th:Fruits|กเรปฟรุต]] doesn't seem to help. Do you think I need to give it some time? --Anatoli T. (обсудить/вклад) 07:29, 15 September 2016 (UTC)
(After E/C) Yes, something like Module:zh-cat is required for a number of languages. --Anatoli T. (обсудить/вклад) 07:31, 15 September 2016 (UTC)
Having template 'th-cat' can solve this. But it will be unable to use HotCat any more. --Octahedron80 (talk) 07:34, 15 September 2016 (UTC)
HotCat is not smart enough for this and it doesn't add in the proper language section either. --Anatoli T. (обсудить/вклад) 07:37, 15 September 2016 (UTC)
Module:th-cat would be a good idea. This and Module:zh-cat need to be invoked by the central sorting functionalities to ensure templates such as {{lb}} used with the language codes 'th' and 'zh' are properly sorted too. Wyang (talk) 07:45, 15 September 2016 (UTC)
We would not waste so much time with this if we had category-specific sorting. See the open bug: phab:T30397. I wish there was a way to put some weight on this kind a critical request. — Dakdada 13:39, 15 September 2016 (UTC)
At Thai projects, we already set to sort pages by Unicode collation algorithm (UCA) so we get rid of this problem almost completely. phab:T50097, some charts The pitfall is that CJK characters need another sorting method. [9] But we also solve this with user script. Perhaps you (users) could think about this to apply on English Wiktionary either. --Octahedron80 (talk) 14:08, 15 September 2016 (UTC)
PS. I forgot which page we discussed about UCA at Thai Wikipedia. Forgive me. --Octahedron80 (talk) 14:19, 15 September 2016 (UTC)

e-form of Danish adjectives[edit]

As shown here - hermafroditisk. If this is the standard form now, I'm not impressed. Does anyone understand what it means, apart from me? DonnanZ (talk) 16:30, 15 September 2016 (UTC)

I wouldn't have a clue. —CodeCat 16:34, 15 September 2016 (UTC)
I don't like it, but can you think of anything better? I've had to do something similar with Yiddish "dem-forms" (see מיט). --WikiTiki89 16:38, 15 September 2016 (UTC)
Inflection tables, of course. —CodeCat 16:44, 15 September 2016 (UTC)
It means the definite singular and plural form, and if I remember correctly the wording originally read "definite and plural", so I think someone has tampered with the template. DonnanZ (talk) 16:51, 15 September 2016 (UTC)
Yes, it's the definite for all genders/numbers and also the indefinite plural. This is why it's hard to define concisely. --WikiTiki89 17:36, 15 September 2016 (UTC)
"when definite or plural" perhaps?​—msh210 (talk) 17:43, 15 September 2016 (UTC)
It's really not that hard to make an inflection table to avoid all of this. Compare groot, which has a similar inflection to Danish, and stor, which is also quite close. If it works fine for those languages, it can work fine for Danish too. —CodeCat 18:20, 15 September 2016 (UTC)
No objection from me. I was merely pointing out a (I think) clearer wording for the headword line than those already mentioned, in case headword-line inflection is desired.​—msh210 (talk) 18:30, 15 September 2016 (UTC)
Note in particular that the Swedish and Danish inflections of stor differ on only one point: where Swedish has -a, this becomes -e in Danish. —CodeCat 18:24, 15 September 2016 (UTC)
Except that Swedish itself has an -e in the masculine singular. Anyway, there's nothing wrong with an inflection table, but it would be nice to have this in the headword line as well in some concise form. --WikiTiki89 18:31, 15 September 2016 (UTC)
Personally I'm not in favour of inflection tables. Has anyone checked the template to see if it has been altered lately? DDO doesn't help with its presentation (see reference I attached to the entry); it may be OK for Danes, but not for us. DonnanZ (talk) 18:38, 15 September 2016 (UTC)
And I'm not in favour of stuffing it all into the headword line. Inflection tables, having two dimensions to work with, can present information a lot clearer, and can also present a lot more information than a headword line. Where did we even get the idea of putting inflections in two different places? —CodeCat 18:42, 15 September 2016 (UTC)
Maybe you haven't noticed the English presentation of adjectives and verbs. DonnanZ (talk) 18:46, 15 September 2016 (UTC)
Yeah, whose idea was that? I think it was a bad idea. Anyway, I created a basic inflection table for Danish adjectives: {{da-infl-adj}}. It needs some work, in particular in recognising when to use -est for the superlative and when -st. —CodeCat 19:08, 15 September 2016 (UTC)
Don't forget some adjectives are indeclinable, others don't have comparatives and superlatives, and that -ere and -est, -st / -este, -ste endings for comparatives and superlatives don't always apply, mere and mest are also used. Maybe the addition of comparatives and superlatives should be optional, otherwise you're getting into a minefield. DonnanZ (talk) 20:35, 15 September 2016 (UTC)
Generally adjectives of one syllable have -est / -este for the superlative, and those of two syllables use -st / -ste. DonnanZ (talk) 22:02, 15 September 2016 (UTC)
For now, I'm only doing the uncomparable adjectives, I'll do the comparable ones later. I think I'll just include a parameter to specify whether the superlative has the e or not, it's easier than including a rule that only works half the time. However, I have a question: are there any adjectives that have a superlative but no comparative, or vice versa? If not, then there could just be a parameter to specify the superlative suffix, and that would automatically infer that there is a comparative as well. A word like billig would be specified as just {{da-infl-adj||st}} then. The first parameter indicates a stem change, like in e.g. grøn or forloren. —CodeCat 22:49, 15 September 2016 (UTC)
To answer your question, I think there are a few without comparatives or vice versa, but I think they are usually shown in DDO. It's always a useful reference. DonnanZ (talk) 23:02, 15 September 2016 (UTC)
I am the one who "tampered" with the template. My impression was that "definite and plural" caused a lot of confusion, and I felt that "e-form" would be conciser and more recognizable. If someone had asked me for the "plural and definite singular attributive" form of grøn, I do not think I would have known what to say. I do feel that we should have at least the most commonly-used forms on the headword line, for the convenience of users, but six forms may be too much. And yes, sometimes the expected comparative form simply isn't attestable, even when the superlative is.__Gamren (talk) 11:12, 16 September 2016 (UTC)
Well, I'm afraid you got that wrong, it's not understandable unless you're "in the know". The previous form was better despite its poor wording. DonnanZ (talk) 13:44, 16 September 2016 (UTC)
I think a concise name with a link to a description of what it means is better than confusing wording. (HINT: We should add a link to a description of what it means.) --WikiTiki89 15:10, 16 September 2016 (UTC)
I support the new adjective template, but please do not delete Template:e-form of. I personally think it was a really good idea. PseudoSkull (talk) 22:35, 16 September 2016 (UTC)
It's a terrible idea if passive users can't make head or tail of it. DonnanZ (talk) 22:51, 16 September 2016 (UTC)
It includes a link to the entry that explains exactly what it is. PseudoSkull (talk) 22:58, 16 September 2016 (UTC)
What does? The template itself doesn't make any sense. DonnanZ (talk) 23:12, 16 September 2016 (UTC)
Template:e-form of links to e-form#English, which states in its second definition; "2. (linguistics, of the Danish language) The definite singular and plural form of adjectives, which often end in -e." PseudoSkull (talk) 23:32, 16 September 2016 (UTC)
Oh my giddy aunt, how is anyone meant to work that out? DonnanZ (talk) 08:50, 17 September 2016 (UTC)
I really don't see what's so bad about it. It seems pretty simple to me; you click a link and see the definition. @User:Gamren, you might be interested in this discussion, as this is your template that you created. PseudoSkull (talk) 17:39, 17 September 2016 (UTC)
I created it, but nothing here is "mine". I wouldn't mind if someone found a better wording; just keep in mind that "definite and plural" confused even experienced editors enough to start deleting templates. Maybe the table layout that CodeCat is working on will make this clear without requiring overly-long designations?__Gamren (talk) 17:58, 17 September 2016 (UTC)
It would be better if we linked to an Appendix page with a more thorough explanation, rather than to the dictionary entry of a term so obscure we thought we made it up. --WikiTiki89 20:10, 17 September 2016 (UTC)
As much as I like the idea of grammar appendices, WP has a page on w:Danish grammar, so it might be less info-duplicating to just link to that, like we do with e.g. {{IPA}}.__Gamren (talk) 06:33, 18 September 2016 (UTC)
We don't have enough control over WP's content to force them to keep their section in the same place and specifically mention the obscure term e-form. --WikiTiki89 11:28, 18 September 2016 (UTC)
"Overly long" designations are sometimes necessary. Consider "third person singular simple present indicative form" of English verbs. That's what I call a long designation. DonnanZ (talk) 11:45, 18 September 2016 (UTC)
So why don't you change it?__Gamren (talk) 17:10, 19 September 2016 (UTC)
I'm not sure that I should if it's correct. DonnanZ (talk) 19:05, 19 September 2016 (UTC)
Well, I've changed the wording now (and updated WT:About Danish accordingly). Feel free to move it, too, but please leave a redirect.__Gamren (talk) 12:05, 21 September 2016 (UTC)

Creating per-sense links[edit]

This is a long-standing desire, and is implementable solely within the project via a not-nice-but-functional kluge: create UUIDs for each sense, and use # {{anchor|$UUID}}$term_sense_here. There are a range of possible methods for generating non-rfc-compliant but unique UUIDs, for example using the zero-padded page id as the leading 9+ characters. The point is it can be done, now, and without further dithering. Discussion? - Amgine/ t·e 18:14, 16 September 2016 (UTC)

What's the advantage of an unreadable computer-generated UUID over a human-generated descriptive UUID? --WikiTiki89 18:35, 16 September 2016 (UTC)
  • Uniqueness
  • Translingual
  • Machine-readable
  • Existing tools/transportability/reusability
  • Predictability
  • Automatable (although this may also be considered a drawback)
But a human-generated descriptive UUID which is actually unique without excess processing (e.g. having to parse the page to discern Language/Etym/POS/UUID structure) would work as well. - Amgine/ t·e 19:30, 16 September 2016 (UTC)
Uniqueness and machine-readable also apply to human-generated IDs. I'm not sure what you mean by existing tools/transportability/reusability. But you have me at translingual if that means we'd be able to have the same ID used on all languages' Wiktionaries for the same sense. --WikiTiki89 19:34, 16 September 2016 (UTC)
Maybe we can start with cross-language suffixes and prefixes. English -cide, Portuguese -cídio, Spanish -cidio, etc. could all use the same ID meaning "act of killing", and a separate ID for "killer". --Daniel Carrero (talk) 19:41, 16 September 2016 (UTC)
I 100% oppose using these IDs for senses of different languages. The only translingual aspect can be definitions in different languages of the same sense in the same language. --WikiTiki89 19:46, 16 September 2016 (UTC)
I agree: this issue came up in much more detail in another discussion (on Meta?), didn't it? Equinox 10:34, 17 September 2016 (UTC)
Even if the two senses are identical? For instance, an easy example, the element helium. The first sense "a colorless, inert gas..." could be used in scores of other language entries, preventing the need for a gloss/click-through/discernment process by the reader. - TheDaveRoss 11:44, 17 September 2016 (UTC)
I like this idea. Editing the single sense would change "Helium" in all languages. --Daniel Carrero (talk) 14:56, 17 September 2016 (UTC)
Human-generated descriptive IDs sound better. The only advantage of unreadable computer-generated IDs I am thinking is that they can probably be filled quickly for all entries. But they would probably be a pain to copy elsewhere and use. --Daniel Carrero (talk) 18:40, 16 September 2016 (UTC)
Where is the documentation about how this could be used? What is the relationship to {{senseid}}? Oh, I'm sorry. I'm dithering. DCDuring TALK 18:42, 16 September 2016 (UTC)
One way would be to use {{#invoke:UUID|full}} (which generates "383f6946-86ec-433a-977e-41ee7b98ec9d31") and I think there is a version making its way into core MediaWiki. If it were up to me I would build a template around each sense which creates a transcludable section that can be referenced by the UUID. Even better would be if each of those senses lived on its own entry in a sense namespace so that it makes the machine-readability much higher, and creates a real opportunity to shift senses to a relational database at some point. We can do the same thing with any other piece of data, sense is just an obvious choice since it is central to everything we do here. - TheDaveRoss 19:44, 16 September 2016 (UTC)
But we would have to have that ugliness in the wikitext... --WikiTiki89 19:46, 16 September 2016 (UTC)
Sure, but we could also leverage it to reduce the necessity of actually editing the wikitext. - TheDaveRoss 19:48, 16 September 2016 (UTC)
Anyway, regardless of how you generate the UUIDs, the biggest problem is that every time you merge or delete senses, you have to go and update all the links. Will there be an easy way to solve that problem? --WikiTiki89 18:43, 16 September 2016 (UTC)
merge senses -> allow a single sense use multiple old IDs?
delete senses -> ignore the ID forever or generate a category for entries linking to bad IDs?
--Daniel Carrero (talk) 18:47, 16 September 2016 (UTC)
And I forgot splitting senses. --WikiTiki89 18:49, 16 September 2016 (UTC)
split senses -> keep the old ID as a group ID whose children are the multiple separate IDs; if a link points to the group ID, it highlights all the multiple applicable senses... ? --Daniel Carrero (talk) 18:53, 16 September 2016 (UTC)
And how are we supposed to enforce any of that? DTLHS (talk) 19:48, 17 September 2016 (UTC)
  • I'd say let's wait and see what Wikidata's and Wiktionary's cooperation has to bring on the table first. --Dixtosa (talk) 11:46, 17 September 2016 (UTC)
    As discussed on Wikidata, there is no expectation at the moment to support per-sense links on Wiktionary. (Which motivated me to bring this kluge up here.) - Amgine/ t·e 14:51, 17 September 2016 (UTC)
The problem with sense IDs has never been technical. The problem is we have no way to track these kinds of dependencies. If we start giving English entries sense IDs we make them dependent on all the other languages that want to link to them. Now if I want to change an English sense do I have to know all of those languages and possibly change their links if the new sense no longer applies? Glosses don't have this problem. DTLHS (talk) 20:05, 17 September 2016 (UTC)
The sense ID has uses beyond links - that is simply the most obvious use. However, from the point of view of its use as a link, if you alter a sense, the ID should not necessarily change (I would expect it should not change, actually.) The real issue is when a sense is deleted since the the ID should be eliminated from possible recreation. (And an OCD person might figure out how to generate a 410 status code for links to deleted sense IDs at some point.) That is, the issue you raised is not actually an issue. Editing the sense ID itself, however, would be a problem and is why a contextual UUID is probably better than a human-generated UUID. - Amgine/ t·e 05:43, 18 September 2016 (UTC)
The solution to the possible problem of editing a human-generated sense ID is to retain both the old and the new IDs as anchors, as Daniel Carrero suggested above. But I can see where unusual cases might result in very large blocks of anchors in the wikitext. - Amgine/ t·e 05:50, 18 September 2016 (UTC)
We could also insist on having exactly one ID per sense, with no old IDs and no IDs standing for multiple senses, but we would have some way to mark bad IDs, (either having an actual list of bad IDs; or a huge list of good IDs, where absence on the list means an ID is bad) and the link would not go anywhere. If we have a list of "bad ID -> good ID", we could have a bot replace all links that point to bad IDs. --Daniel Carrero (talk) 05:54, 18 September 2016 (UTC)
  • This looks to me a lot like we're inventing our own problems. ‑‑ Eiríkr Útlendi │Tala við mig 17:14, 27 September 2016 (UTC)
    In which way? The problem of being able to uniquely identify individual senses is a long-standing one, but there may be other issues with the concept. (This kluge, on the other hand, has lots of eventual issues. Since the previous one has been unaddressed for more than a decade and planned coverage specifically does not address the problem it may be time to implement something, however flawed.) - Amgine/ t·e 18:18, 27 September 2016 (UTC)


Would anyone be able to fix User:Hippietrail/nearbypages.js? I really liked it, but it hasn't worked for a long time. It's supposed to add a little horizontal bar of previous and next entries, so you can see where you are in the current language. For example, at the entry for equinox, I would see something like equinity - equinoctial - equinox - equip - equipage. Equinox 16:56, 17 September 2016 (UTC)

Looks useful! The backend url in the js is no longer valid, and I can't find it on the new tool server. – Jberkel (talk) 19:46, 17 September 2016 (UTC)
Like so many toolserver addresses, this one has been mothballed. The code is apparently still available via special request, and can be set up to run via labs, but someone will have to do the legwork to get it running again, and update the script as necessary. - Amgine/ t·e 05:55, 18 September 2016 (UTC)
Where is the code? Jberkel (talk) 12:28, 18 September 2016 (UTC)
Apparently I was wrong; the toolserver archives were only kept until 2014. So I am asking Hippietrail about xyr source. - Amgine/ t·e 16:55, 18 September 2016 (UTC)
I'm curious how this was implemented. Given that we now have categories for lemmas, that category can be used for such a list where it was not possible before. —CodeCat 17:06, 18 September 2016 (UTC)
You may recall that Hippietrail implemented many tools based on dump parsing. This was one of them, apparently. The benefit of dump parsing is the complete population - poorly structured and all. The drawback is its brittleness/high maintenance cost. - Amgine/ t·e 19:38, 18 September 2016 (UTC)
  • I've changed it a little bit to use MW API. Unfortunately MW API does not have option for reverse ordering in the API query. So it only displays the next 5 lemmas under the language header. scri. --Dixtosa (talk) 19:00, 18 September 2016 (UTC)

UlaanBaatar -> Ulaanbaatar[edit]

Hey everyone,
I made a spelling mistake and foolishly repeated it a hundred times by copying. I wrote "UlaanBaatar" instead of "Ulaanbaatar" in a lot of Mongolian accent templates, could someone with a bot change it to proper capitalization if it's not too much of a hassle? —This unsigned comment was added by Crom daba (talkcontribs) at 14:14, 18 September 2016.

This search should find all uses (there are supposedly 112 of them). If no one does this by bot, it shouldn't be too hard to do by hand. --WikiTiki89 13:11, 19 September 2016 (UTC)

Gadgets and page loading time[edit]

Originally I thought my main problem was that the HotCat gadget seemed to be load very slowly. I disabled it and that didn't help much. I disabled a number of other gadgets that I use rarely, but still note that the tab in Firefox shows that something is still loading. At the end of the loading the page seems to jump a bit. Why is this? Are we overloading our pages with scripts? Can the scripts be emended to reduce (eliminate?) this effect? DCDuring TALK 17:09, 18 September 2016 (UTC)

Is the "jump" the annoying delayed insertion of the citations tab (causing the other tabs to change places, so that my mouse clicks always miss)? Yes, we must fix that monstrosity. Equinox 18:28, 19 September 2016 (UTC)
A few things jump. Now that I think of it, the visual editor would do the same thing, until I disabled that, too. It was particularly annoying as the inserton-jump happened just as I was starting to edit. I've read that visual editor is considered a great success. I hope I can always opt out of such successes, at least so long as the implementation is in a slow-to-load-and-execute script. DCDuring TALK 18:51, 19 September 2016 (UTC)
Unfortunately, you still get that junk when editing as an IP. If that had been the case when I first found Wiktionary (which I edited anonymously for months before making a user name) I just wouldn't have come back. The horrid "Media Viewer" on Wikipedia is another case of horrific usability failure: indeed, if I type "media viewer wikipedia" into Google, the predictive search suggests "terrible". Equinox 18:56, 19 September 2016 (UTC)
For me, the QQ tab pushes the History and Edit tabs leftwards as it loads. Also, the toolbar above the editing frame (can that be removed?).__Gamren (talk) 10:41, 20 September 2016 (UTC)
Sheesh, sorry, I found it.__Gamren (talk) 10:56, 20 September 2016 (UTC)
For me the most annoying thing is when the clock gadget loads at the top right (if you have it enabled, it's pretty useful), it pushes everything to the left, putting "Log out" in the place of "Contributions", so frequently I try to go to my contributions and end up logging out (which then logs me out on all my devices). --WikiTiki89 14:40, 20 September 2016 (UTC)
add UTCLiveClockConfig = {};UTCLiveClockConfig.nextNodeId = "pt-userpage"; to you common.js if you want it to appear before your username... --Giorgi Eufshi (talk) 08:26, 21 September 2016 (UTC)
Learning the keyboard shortcuts is probably a good idea if nobody is going to fix this. Equinox 15:41, 21 September 2016 (UTC)
For the unenlightened: w:WP:Keyboard shortcuts (Thank you for giving me cause to seek this, Equinox).__Gamren (talk) 10:34, 22 September 2016 (UTC)
Thanks from one of the unenlightened. DCDuring TALK 11:06, 22 September 2016 (UTC)
On the watch list, I noticed that the main culprit for post-load shifting of page contents is the "News for editors" link. Why is that even implemented with JavaScript? Can it please be removed and placed somewhere more sensible? The links on the left seem like a much better place. —CodeCat 00:30, 24 September 2016 (UTC)
The link above the entry? You can remove that with the [dismiss] button.__Gamren (talk) 07:21, 24 September 2016 (UTC)
That's only temporary, and it doesn't stop the JS itself from loading. —CodeCat 12:18, 24 September 2016 (UTC)
There has to be some JS in order to work with cookies. BTW, how do you measure what's taking what time? --Dixtosa (talk) 16:40, 24 September 2016 (UTC)

Lua performance question[edit]

Since strings are not mutable in Lua, there can be all kinds of optimisations done on them. One thing I wonder in particular is whether taking a substring of an existing string causes any copying in memory, or if the same data is used with just different pointers to start and end. This is significant when the strings are large, both for performance and for memory usage, which is why I ask. —CodeCat 23:05, 22 September 2016 (UTC)

Making new string always uses more memory. When you make substring and modify it, it will not modify its original string. However, any unused or no-longer used variables will be revoked at the end of their scopes. --Octahedron80 (talk) 00:55, 23 September 2016 (UTC)
I think this file should be helpful: https://www.lua.org/gems/sample.pdf
Look for the section "About strings" in the page 8. --Daniel Carrero (talk) 01:03, 23 September 2016 (UTC)
I found that, but it didn't really answer my question. My question is this: let's say a string variable is created with the contents "abcdefgh", and I then take a substring of that, "cdef". Does this actually create a new memory area where the second string's data is stored, or is it reused from the original one? This is a trivial example of course, but it matters more when the original string and the substring are both rather large, many kilobytes in size. If the data is not copied but merely has a new reference created for the substring, then it's more efficient in both memory and in speed. What I wondered is whether Lua actually does this, or whether it takes the slow approach by copying the substring over to a new data buffer. —CodeCat 01:13, 23 September 2016 (UTC)
My guess is that the substring function doesn't copy anything. They'd be crazy not to have implemented it that way. Of course, when you concatenate, it must copy everything. I wonder if a chain of .. operators is reduced to a single operation. --WikiTiki89 01:29, 23 September 2016 (UTC)
Yes, see [10]. Benwing2 (talk) 05:03, 23 September 2016 (UTC)
BTW you are probably right that substring doesn't copy but it's not completely crazy to do so. Lua uses garbage collection, and allowing a string to point to the middle of another string makes garbage collecting strings more complicated. For example, it might require that string metadata objects contain an extra slot to point to the beginning of the string that is subsetted, so that if the main string gets garbage-collected but the substring still remains, its contents don't get garbage-collected out from under it. This would also imply that if you take a small substring of a very large string, the very large string has to sit in memory as long as the substring remains, even if it otherwise could be garbage-collected ... so taking a relatively small substring might well be implemented with a copy. Benwing2 (talk) 05:11, 23 September 2016 (UTC)
In garbage collected environments, you never keep a real pointer to anywhere other than the beginning of an array. Instead, you keep a pointer (to the beginning) and an offset (and in this case also a length). Garbage collection does pose a separate problem, that if you keep a short substring of a large string, the entire large string must remain in memory. Interning small strings (which CPython does, for example) has a side effect of alleviating this problem (because the short substring will point to an interned copy, rather than the string you took it from). I have no idea whether Lua interns small strings or does anything else to alleviate this problem. --WikiTiki89 13:26, 23 September 2016 (UTC)
But note that if you use mw.ustring.sub, it will still take linear time, so it really doesn't matter if it copies it, except for memory efficiency. --WikiTiki89 01:37, 23 September 2016 (UTC)
Create a single-purpose module or two with two functions that would act the same if the system works one way, but would act differently if it works the other, then create a template for each function and transclude them both precisely a gazillion times on one page, then "view source" to compare the stats for memory and time usage. Chuck Entz (talk) 04:02, 23 September 2016 (UTC)

Coloured emoji obscure red/blue link colour[edit]

A recent update to Chrome (or to Windows?) means that emoji now render in full colour, e.g. the smiley faces are yellow. This means that, viewing a page like Appendix:Unicode/Emoticons, it is impossible to see which are "red" links and which are "blue" links. Any suggestions? Equinox 12:34, 25 September 2016 (UTC)

My Google Chrome is "Version 53.0.2785.116 m", on Windows 7. The browser is up to date, according to the "About" screen. The emoticons listed at Appendix:Unicode/Emoticons are being displayed as normal blue/red linked text to me. There should be a checkbox or something to allow/disallow full-colored emoticons. --Daniel Carrero (talk) 14:27, 25 September 2016 (UTC)
Daniel: thanks, but ideally I'd like to keep the coloured emoji (they look okay!) but still see the red/blue status. I might be asking too much. Equinox 05:28, 27 September 2016 (UTC)
I have Firefox on a Mac,and I see emoji colors (why do I hear Haley Joel Osment saying that?). If the Javascript can easily detect emoji characters, I believe Common.js could be changed to put a red border around them when they're redlinked (it might require giving them a separate redlinked-emoji css class). Chuck Entz (talk) 15:29, 25 September 2016 (UTC)
From an accessibility point of view we should definitely not have to treat these characters differently, and it's pissing me off. This is a much wider issue than just Wiktionary. Did nobody realise that adding coloured characters to displayed fonts, when displayed fonts already have colour as a property, might be an issue? I am going to stab them in the knee. Equinox 05:38, 27 September 2016 (UTC)

Request for minor Hangul syllable cleanup[edit]


{{ko-symbol-nav}} runs solely on the magic of Lua now, so I would like to request the removal of parameters from wikitext. —suzukaze (tc) 04:47, 27 September 2016 (UTC)

Excellent job! Wyang (talk) 22:55, 27 September 2016 (UTC)


{{ko-syllable-hangul}} now automatically displays Revised Romanization only, so I would like to request the removal of numbered parameters from wikitext. —suzukaze (tc) 05:02, 27 September 2016 (UTC)

Template:Hangul Syllables character info[edit]

At some point this was redirected to {{character info/new}}. Which is bad, because {{character info/new}}'s |1= overrides the codepoint to display, and {{Hangul Syllables character info}} used to use |1= for other things. It looks like it is safe to replace {{Hangul Syllables character info}} with {{character info/new}} per User:Kephir's tinkering here. —suzukaze (tc) 05:02, 27 September 2016 (UTC)

Other minor question[edit]

{{character info/new}} seems to be able to do what {{ko-defn-hangul}} does manually (display the composition of a syllable). Could someone automate {{ko-defn-hangul}}? —suzukaze (tc) 05:39, 27 September 2016 (UTC)

Underscore in unsupported titles?[edit]

Is there a way to include an underscore in an unsupported page title? I've created Unsupported titles/-_-, but I can't get the underscore to appear, even with the magic word. Smurrayinchester (talk) 08:05, 27 September 2016 (UTC)

Underscores always convert to spaces. This is the limitation of MediaWiki. You must rename to words instead. See also Unsupported_titles/Low_line --Octahedron80 (talk) 08:29, 27 September 2016 (UTC)
Naah, he only needs to get MediaWiki:Common.js updated accordingly. --Giorgi Eufshi (talk) 08:53, 27 September 2016 (UTC)
The link title is double dashes that does not make sense. Should be renamed like Unsupported titles/low line interfix. The script surely fixes display. --Octahedron80 (talk) 09:01, 27 September 2016 (UTC)
Thanks. Could someone make the change to MediaWiki:Common.js? Just need to add 'Low_line_interfix'  : '-_-', Smurrayinchester (talk) 08:34, 28 September 2016 (UTC)

Editing tools at the top of the page[edit]

As in when editing above the editing box, starting with B I (etc.). Is there anyway to avoid loading these? They're taking ages at the moment, like over a second. Renard Migrant (talk) 11:25, 27 September 2016 (UTC)

I wouldn't miss them either, but I can imagine they're useful for new people. —CodeCat 14:00, 27 September 2016 (UTC)
Try unchecking Preferences:Editing:"Show the edit toolbar (requires JavaScript)". DCDuring TALK 16:56, 27 September 2016 (UTC)

Who broke the transliteration on term, m, etc?[edit]

Right now the transliteration of Ancient Greek ἀποϕυγή ‎is showing up as apoϕugḗ instead of apophygḗ. Adding at |tr= doesn't help, since someone decided to override manual corrections. Needs fixing, wherever the transliteration code is hidden. — LlywelynII 02:28, 29 September 2016 (UTC)

The person who used the wrong phi broke it. It should be ἀποφυγή ‎(apophugḗ), which transliterates correctly. —Μετάknowledgediscuss/deeds 02:32, 29 September 2016 (UTC)