Wiktionary:Grease pit

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

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 [1]. 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 formatEdit

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 errorEdit

  • 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 requestEdit

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 errorEdit

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 sizesEdit

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 ChromeEdit

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 moduleEdit

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 transliterationEdit

@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 problemEdit

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 DictionaryEdit

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 tablesEdit

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 WordsEdit

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 questionEdit

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 movesEdit

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 categoriesEdit

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. [2] 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 adjectivesEdit

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 linksEdit

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)
  • Thanks, that is better than nothing! Is it possible to show perhaps 10 entries instead of five? Equinox 19:20, 29 September 2016 (UTC)
    Yes, alter the value of window.NearbyPagesConfig.quantity like so before the line where you import nearby.js. --Dixtosa (talk) 14:07, 2 October 2016 (UTC)
  Done Dixtosa's script is as good as the old one. Yeah!! Equinox 21:02, 5 October 2016 (UTC)

UlaanBaatar -> UlaanbaatarEdit

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 timeEdit

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 questionEdit

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 [3]. 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 colourEdit

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 cleanupEdit


{{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 infoEdit

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 questionEdit

{{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)
Done. Benwing2 (talk) 14:34, 30 September 2016 (UTC)

Editing tools at the top of the pageEdit

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)
The wrong phi (it was the mathematical phi symbol U+03D5 instead of the Greek small letter phi U+03C6) was being used at congé. I've fixed it now. —Aɴɢʀ (talk) 12:36, 30 September 2016 (UTC)

Strange description at Category:Old Irish verbs by inflection typeEdit

There's a strange description with Arabic characters showing up at this category. Can this be fixed/removed? —CodeCat 15:16, 29 September 2016 (UTC)

@CodeCat: Someone added Pashto-specific descriptions to "simple verbs" and "simple intransitive verbs" in Module:category tree/poscatboiler/data/lemmas. Maybe you can figure out better than me the best way to fix this, while having this information still show up in the Pashto categories (Category:Pashto simple verbs and Category:Pashto simple intransitive verbs). --WikiTiki89 15:38, 29 September 2016 (UTC)
I think that having this category in poscatboiler isn't really appropriate. The principle of poscatboiler is that it contains categories applicable equally across all languages. Creating a category for just one language goes against that. —CodeCat 15:42, 29 September 2016 (UTC)
Ok, then we should remove it from there. We should probably have a template that can be used in categories for language-specific parts of speech that will still add in all the usual boilerplate such as the default parent categories, TOC, descriptions, oldest/newest entries, and all the rest of the stuff. --WikiTiki89 15:55, 29 September 2016 (UTC)
I have considered something like that. It would basically be an ad-hoc category that has all the data provided manually instead of being taken from the modules. But we have to account for the possibility that an ad-hoc category may one day be turned into a global one. —CodeCat 16:10, 29 September 2016 (UTC)

Lag when focusing edit window on large pageEdit

This has been happening for a while now and it's really annoying. Basically, if I open the edit page and there is a lot of text in the edit window (a lot being an entire monthly BP page or something like that, but not just a section), when I focus the edit window for the first time, there is a 10-second-or-so-lag during which I believe a ton of unnecessary javascript is being run, does anyone know what the culprit could be? --WikiTiki89 21:45, 29 September 2016 (UTC)

I've never had anything like 10 seconds. What are your OS, CPU speed, and browser? Equinox 22:27, 29 September 2016 (UTC)
So the lag doesn't occur when you have javascript disabled? - TheDaveRoss 22:45, 29 September 2016 (UTC)
I Windows 7 with a crazy good CPU and Windows 10 with an i7. Both with Chrome. I haven't tried disabling JS, but will do as soon as I get back to a computer. --WikiTiki89 23:01, 29 September 2016 (UTC)
Actually, just tried on my Windows 10 and there seems to be no issue. It could be a Chrome bug that got fixed and my Windows 7 hasn't been updated. I'll have to wait till tomorrow to find out. --WikiTiki89 23:14, 29 September 2016 (UTC)

October 2016

Be consistent about template 'lang' parametersEdit

To take one example: (suffix|en|...) and (suffix|...|lang=en) both work, but (lb|en|...) does not. Can this kind of thing be made consistent one way or another? Equinox 15:51, 1 October 2016 (UTC)

The lang= parameter is supported for backwards compatibility because there hasn't been an agreement to bot-fix all the entries and remove the parameter. —CodeCat 15:52, 1 October 2016 (UTC)
Mostly because it is a bad idea. We should be moving in the direction of transparency not obscurity. - TheDaveRoss 17:24, 1 October 2016 (UTC)
I haven't seen you propose ideas of that kind, rather than merely complain about changes that benefit editors' ability to improve the dictionary. —Μετάknowledgediscuss/deeds 18:19, 1 October 2016 (UTC)
It is all subjective, but I have opined against proposed changes which result in general obfuscation of the wikitext. I don't agree that fewer characters is de facto easier on editors, especially on newer or lower-volume editors. It is nearly impossible to keep up with the correct order of parameters in all templates, and it is harder to use a template if you have to go look up the order before you can use it. I get the appeal of typing |en| instead of |lang=en|, but that sometime convenience is outweighed in my view by the long term frustration that unnamed parameters can result in. - TheDaveRoss 18:30, 1 October 2016 (UTC)
Which is exactly why it makes sense to use {{suffix|en}} everywhere, because having the first parameter be the language is a standard practice. To learn which templates need lang= and which don't is a lot more complicated to editors. They should all be changed to conform to the same standard so that there is less confusion. —CodeCat 18:46, 1 October 2016 (UTC)
I agree here. I don't think a new user is going to have an easier time with a lang= parameter than a required first parameter. If anything, it may be harder because their instinct will be to leave out the lang= parameter and then they'll get confused by the resulting error message. Having the language as the first param makes it very clear that it's required. Benwing2 (talk) 19:18, 1 October 2016 (UTC)
Sure. However if you are not sure and type |lang=en| then you will not break anything, whereas if you type |en| then it may or may not work, may throw module errors, may create incorrect display text... - TheDaveRoss 20:07, 2 October 2016 (UTC)
Can we have our cake and eat it too? Does our software have to be so fragile? If a user were to include a lang= parameter anywhere among the arguments, couldn't we make sure that the template does not take the first unnamed parameter as a language code?
We can make all of the templates much more complex and accomplish that, or MediaWiki could be modified to accomplish that, or a module could be created to accomplish that. I think just using named parameters does it with a lot less fuss, and also results in template source which is easier to read, as well as wikitext which is easier to decipher. Currently if the lang parameter defaults to the first unnamed parameter, and the lang parameter is explicitly defined, it seems to ignore the first parameter altogether. - TheDaveRoss 12:49, 3 October 2016 (UTC)
We seem to always default to what is easier to program, rather than what is easier for ordinary users, which, I venture, is part of what discourages new users. DCDuring TALK 13:47, 3 October 2016 (UTC)
In OOP land there is the concept of an interface. For example, if a template implemented the Language interface, it must be able to support input with lang= or the first parameter. Or if a template implemented a Transliteration interface, it must be able to support input with tr= or translit= or transliteration=. We would have to come up with some way to enforce this on the module side. DTLHS (talk) 13:59, 3 October 2016 (UTC)
(ec) I think that may be the case in some instances, but I don't think that is the case here. I think that making templates easier to read and modify is a boon to editors, especially new editors. I don't think it impacts readers either way (except that they may become editors more readily). All of the arguments I hear about unnamed parameters being preferable are about editing being more laborious, either via increased volume of wikitext or additional keystrokes while entering templates (which could probably be worked around via bots if it was truly a concern). - TheDaveRoss 14:02, 3 October 2016 (UTC)
I think of three classes of contributors: module and template mavens, frequent editors, occasional editors (close to "normal" users). Occasional editors are the ones who might benefit from named parameter like lang=; frequent editors benefit from brevity, ie, a numbered parameter; mavens benefit from just doing one or the other, not both. A supermaven might have standard code for accepting either numbered or named parameters to be applied where beneficial. Less skilled template authors (eg, me, a template copier/adapter) are happy to get a functioning template without regard to ease of use for anyone other than themselves, let alone normal users. We less skilled would need to be handed the means for allowing both named and numbered parameters on a silver platter.
All benefit from consistency across templates, Equinox's original point. Having code that supported both for language code use in templates would allow all template users to have the consistency that Equinox is seeking. DCDuring TALK 17:50, 3 October 2016 (UTC)
I agree with you (and Equinox) that consistency is a desirable outcome. I disagree that removing the lang= parameter is the right direction to take. I think we should add the parameter names where they don't exist, instead of removing them where they do. Requiring that all templates be behemoths with layers upon layers of case statements or module integration does not seem like a solution which would improve things for anyone whose primary concern is anything but minimizing the length of template calls in wikitext. - TheDaveRoss 17:59, 3 October 2016 (UTC)
I don't think new users are baffled at all by unnamed positional parameters, provided (1) the first positional parameter is reliably the language code, and (2) the template has an informative documentation subpage. Unfortunately, there are currently some 50,000 Templates and modules needing documentation, and that, I submit, is what makes using templates confusing to newcomers. —Aɴɢʀ (talk) 21:00, 3 October 2016 (UTC)
The templates which need work are a red herring in this case, since nothing under discussion proposes to change the documentation either way. I agree that it would be better if more templates, especially oft-used ones, were documented. My position is that named parameters are easier to decipher, even if sometimes unnamed parameters are decipherable. - TheDaveRoss 21:36, 3 October 2016 (UTC)

"Sense" categorisation using the "label" templateEdit

The template {{lb}} often categorises an entry.

(1) Shouldn't {{lb}} behave in the same fashion with each descriptive.

(2) Don't we need two types of category "Category:Greek terms with xxxx senses" and "Category:Greek xxxx terms"?

And a way of labelling each? — Saltmarshσυζήτηση-talk 06:06, 3 October 2016 (UTC)
Per Wiktionary:Votes/2011-04/Lexical categories, which was voted and approved in 2011, it should be "Category:English archaic terms". --Daniel Carrero (talk) 06:30, 3 October 2016 (UTC)
I don't think that answers my point - what about terms where ONE sense is dated/archaic? — Saltmarshσυζήτηση-talk 06:34, 3 October 2016 (UTC)
@Saltmarsh Personally, I would prefer having a single category for everything that is archaic. Why make people navigate between two separate "archaic" categories? Splitting the "archaic" category (and "dated", "rare", etc.) in two would require us to work hard in editing all entries, and I'm not sure the benefits justify it. It would require continuous maintenance: an entry with only 1 sense that is archaic would have to be transferred to the other category as soon as it gets a second, non-archaic, sense. Instead of doing it, we could just have Category:English archaic senses and that's it. The sense is being categorized, not the sense in relation to the other senses. In my opinion, having two categories Category:English archaic terms and Category:English terms with archaic senses is like splitting Category:English nouns into Category:English terms that are only nouns and Category:English terms that are nouns as well as other parts of speech. But it may be just me. --Daniel Carrero (talk) 21:38, 6 October 2016 (UTC)

Perhaps a solution to the problem regarding archaic terms versus terms archaic senses would be wider use of {{term-label}}. {{term-label}} (which is placed at the end of the headword line) should be used to categorize things in, for instance Category:English archaic terms, while {{label}} should categorize in Category:English terms with archaic senses (or Category:English archaic senses). Then, to switch from one category to the other, you simply switch templates (and of course the position of the template), while the label remains the same. I suppose the current form of Module:labels does not allow this, though... — Eru·tuon 21:47, 6 October 2016 (UTC)

@Erutuon - I've been away - I was originally drawing attention to the differing behavour of {{lb}} depending upon whether archaic or dated is used, ie a technical problem. I'll take up the matter elsewhere. (@Daniel Carrero, Erutuon - I think discussion on the appropriate categorisation belongs elsewhere.) — Saltmarshσυζήτηση-talk 05:48, 16 October 2016 (UTC)

Stuff's going to break in 2017Edit


  1. Someone/some page at this project should probably be subscribed to m:Tech/News.
  2. The announcement in the most recent edition about mw:Parsing/Replacing Tidy is going to affect Wiktionaries, too.

More details:

w:HTML Tidy is a tool that the devs have been using to silently compensate for some typos in HTML and wikitext code after a page has been saved. Tidy is being removed (but not during 2016) as part of a multi-year plan to update the parsers and improve accessibility.

To give a simple example, </br> is an invalid HTML code (it should be <br> instead). This currently displays as if it were correct because Tidy cleans it up. You can see the pages affected by this particular error by searching for insource:/\<\/br\>/ in the regular search box. There are only about 35 pages in the mainspace and about 15 templates at the English Wiktionary that have this particular error, but that's only one of the errors.

More information, and a list of the major changes, is available at mw:Parsing/Replacing Tidy. In (probably) December, there will be a tool that you can use to visually check previews on pages that you're concerned about (it'll probably be available in Special:Preferences, but turned off by default). In the meantime, there is a list of known errors at mw:Parsing/Replacing Tidy that you may want to review and check your wiki for. I also recommend dropping by w:Wikipedia talk:WikiProject Check Wikipedia and watch for information about scripts and tools. Much of this work can be handled with scripts or bots, but some of the changes (e.g., where to close a table that is missing the |} code to signal the end of the page) will require human judgment.

Most of the information about projects like this is delivered via m:Tech/News. However, nobody at this wiki is subscribed to that weekly newsletter. If you aren't reliably getting this information via another wiki or mailing list, then you may want to subscribe and start watching for announcements like this.

I expect formal announcements about this change to go out later, but I thought you'd want to know about this sooner rather than later. Also, if you work at any other project, please share this information. If you have questions or information to share with the devs about this project, please feel free to {{ping}} me. Whatamidoing (WMF) (talk) 17:19, 5 October 2016 (UTC)

@Whatamidoing (WMF): This kind of post should go to the WT:Grease pit, not the WT:Tea room. --WikiTiki89 17:40, 5 October 2016 (UTC)
Moved accordingly. —Μετάknowledgediscuss/deeds 17:44, 5 October 2016 (UTC)
@Whatamidoing (WMF): Pinging again since the discussion was moved. --WikiTiki89 17:58, 5 October 2016 (UTC)

Disabling the character boxEdit

I'm not using the huge character box when editing pages, and it always takes a small moment to load as a full list and then collapse, which bothers me. Can I disable the character box somehow? I didn't find anything at "Preferences" and the character list does not seem to be stored at a module or template. --Daniel Carrero (talk) 22:39, 5 October 2016 (UTC)

Why does the headword module generate such sortkeys?Edit

It appends 0x0a (newline) and the headword again. This is not a WM thing as you can see here - French Table only the lemma category is affected not proper nouns which was added manually.

This is also true for English, but not for Georgian. One difference I have noticed about these three languages is that Georgian has an empty _rawData.sort_key property while the other two do not.

Bonus question: why does Module:languages make sortkey uppercase in the Language:makeSortKey function. We could save some time by not doing a pointless conversion, right? --Giorgi Eufshi (talk) 11:33, 6 October 2016 (UTC)

Table has a sortkey of Table\nTable, which may seem a meaningless duplication, while Amérique has Amerique\nAmérique : [4]. It guarantees multi-level sorting. Making uppercase was necessary when Wiktionary didn’t automatically do it. Now it can be deleted, if there is no problem in handling σ and ς. — TAKASUGI Shinji (talk) 12:29, 6 October 2016 (UTC)
The makeSortKey function converts to lowercase, and it does so because the custom per-language sorting rules expect the input to be all lowercase. Removing it would break the sort key generating rules for any entries containing uppercase letters that need to be modified. For example, for German, Ä would no longer be converted to plain A. —CodeCat 18:39, 6 October 2016 (UTC)

Changing Ancient Greek prepositions to prefixes in etymologiesEdit

Could this be done by bot? There are a lot of Ancient Greek etymologies in which prepositions – for example, ἐκ ‎(ek) – need to be changed to prepositional prefixes – for example, ἐκ- ‎(ek-) – and I was doing it manually, but it occurs to me that it's such a trivial task that a bot could do it.

I don't know if this is helpful, but I was using the following regex on gEdit: m(\|grc\|\w{2,3})(\|)\|([\w ]*)\}\} \+ \{\{m\|grc(\|\w*\|)\|([\w ]+) > affix\1-\2t1=\3\4t2=\5. Wouldn't work in all cases, but it is a start. — Eru·tuon 18:28, 6 October 2016 (UTC)

@Erutuon: Why do we even need to have them as prefixes? Why not just treat them as compounds? ObſequiousNewtGeſpꝛaͤchBeÿtraͤge 21:22, 7 October 2016 (UTC)
@ObsequiousNewt: Well, sometimes the prefixes have a similar meaning to one of the prepositional phrases composed of the corresponding preposition and the genitive, accusative, or dative, or the corresponding adverb: for instance, when when ἐκ- ‎(ek-), κατα- ‎(kata-), συν- ‎(sun-), and μετα- ‎(meta-) mean "out", "down", "with" and "after". In other cases they don't: for instance, when ἐκ- ‎(ek-), κατα- ‎(kata-), and συν- ‎(sun-) are just intensifiers, or when μετα- ‎(meta-) expresses the idea of change of state. And the prefix can never have all the meanings expressed by the preposition. So either a set of meanings associated with the prefix has to be appended to the end of the entry on the preposition or adverb, or a separate entry for the prefix has to be created. I favor the separate entry, because it's neater – and then you don't have to decide which POS to put the prefix definitions under: for instance, whether the definitions of μετα- ‎(meta-) should go in the Preposition or Adverb section of the μετά ‎(metá) entry. — Eru·tuon 21:56, 7 October 2016 (UTC)
@Erutuon: Ah, yes, I hadn't considered that. So, yeah, that sounds like a good idea. Make sure you don't apply it to adverbs, though, where the preposition itself is going to be the root. ObſequiousNewtGeſpꝛaͤchBeÿtraͤge 22:33, 7 October 2016 (UTC)
Also, treating them as prefixes allows categories like CAT:Ancient Greek words prefixed with μετα-; we don't have any infrastructure for a category like "Ancient Greek words compounded with μετά". —Aɴɢʀ (talk) 22:55, 7 October 2016 (UTC)

Module:grc-translit is messing up iota+rough breathing combinationsEdit

Example: ‎(hi) ‎() ‎() ‎(). All these are showing as ih with an accent on the h, when it should be hi accented on the i. Even weirder things happen if you combine them (not that this is ever needed, but I tried to do it just now writing this post): ἵ ἳ ἷ ‎(hí hì hî). This bug doesn't seem to be affecting any other vowels, or even capital iotas: ‎(Hi) ‎() ‎() Ἷ ‎() are fine. 18:56, 6 October 2016 (UTC)

@ObsequiousNewt: any ideas? —Aɴɢʀ (talk) 18:28, 7 October 2016 (UTC)
In the quotation at Θεός, ὁ is currently being transliterated as oh instead of ho; yet when I link ‎(ho) by itself, its transliteration is correct. —Aɴɢʀ (talk) 18:48, 7 October 2016 (UTC)
Another similar bug, capital letters with rough breathings don't come out with the correct capitalization if they're not at the start: e.g. οἱ Ἕλληνες ‎(hoi Héllēnes). (I guess with this one that the is what the algorithm spits out, and there's a check for miscapitalization that only looks at the first two characters rather than the whole string.) 21:02, 7 October 2016 (UTC)
I'm aware of this; working on fixing it. ObſequiousNewtGeſpꝛaͤchBeÿtraͤge 21:25, 7 October 2016 (UTC)
Done. I feel confident in saying this fix should work for everything; the code is much more robust now. ObſequiousNewtGeſpꝛaͤchBeÿtraͤge 22:30, 7 October 2016 (UTC)
You should probably write some testcases. DTLHS (talk) 22:32, 7 October 2016 (UTC)
Done. ObſequiousNewtGeſpꝛaͤchBeÿtraͤge 18:54, 8 October 2016 (UTC)

I just noticed that the Ionic form ἑωυτοῦ ‎(heōutoû) in ἑαυτοῦ ‎(heautoû) is transliterated as heōytoû. Seems odd. ωυ is a diphthong, and so the second element should be u. Or is ōy supposed to be the Attic and Koine pronunciation, because Athenians or worldwide Greek speakers wouldn't recognize ωυ as a diphthong? — Eru·tuon 08:51, 8 October 2016 (UTC)

Whoops, I missed that. Fixed. ObſequiousNewtGeſpꝛaͤchBeÿtraͤge 18:54, 8 October 2016 (UTC)
Why was the transliteration of υ changed to y? I've reverted it, per WT:GRC TR. —CodeCat 19:10, 8 October 2016 (UTC)
y is a more accurate representation of the fronted pronunciation of the monophthongs ῠ, ῡ in Classical Attic, Ionic, and Koine than u. However, it's probably not accurate for Aeolic or Doric, though unfortunately there isn't as much information on them. Boeotian (an Aeolic dialect) apparently had a back , since it was sometimes written as ου in an Attic-influenced spelling system. Perhaps, then, there should be an Attic–Ionic–Koine transliteration that uses y and a transliteration for other dialects that uses u. — Eru·tuon 19:19, 8 October 2016 (UTC)
Transliterations don't have to be phonetically correct, and the consensus was arrived at by people who were aware of the phonetic facts. This isn't the place to debate it. More urgently, @ObsequiousNewt, the recent edits have resulted in module errors in dozens of entries. Chuck Entz (talk) 19:56, 8 October 2016 (UTC)
Fixed; dumb error. I changed ⟨u⟩ to ⟨y⟩ because ⟨y⟩ always appears in Latin (and so in French, English, etc.), because /y/ is the sound which υ represents in Attic (and presumably Ionic/Epic as well, and together those make up the vast majority of the Greek corpus) and is not the same sound that appears in diphthongs, and because the transliteration of υ as ⟨u⟩ is an idiosyncracy which I have only seen elsewhere in beta code. ObſequiousNewtGeſpꝛaͤchBeÿtraͤge 23:20, 8 October 2016 (UTC)
It's also worth noting that in Boeotian, /u/ was spelled ⟨ου⟩ upon the adoption of the Ionic alphabet (as occasionally in some other dialects, which is partly how we know that they had /u/ to begin with), and οι, which had become a front rounded monophthong (probably /ø/), was often spelled ⟨υ⟩. ObſequiousNewtGeſpꝛaͤchBeÿtraͤge 00:57, 9 October 2016 (UTC)
I support using y in transliterations, at least for Attic, Ionic, Koine, and Medieval Greek words. I suppose using u for /y/ wouldn't be totally nonsensical, because after all that's its pronunciation in French, but it's misleading to use the same symbol for the second element of diphthongs and for the independent vowel when they have different pronunciations. ObsequiousNewt, I think W. Sidney Allen said Ionic also had /y/ based on a borrowed word in Herodotus, though I don't have his book on hand. I'm not sure how we would know if the language at the time of the writing of the Iliad and Odyssey did; at the very least, the form of the text that we have is heavily influenced by Attic, so it makes the most sense to use an Attic pronunciation. I would rather use u for whichever dialects didn't have a fronted pronunciation, though I am not sure how that would be implemented... by creating language codes for Ancient Greek dialects, perhaps? — Eru·tuon 03:05, 14 October 2016 (UTC)

l-self and Modern GreekEdit

I recently edited {{el-nF-η-ες-1}} to use {{l-self}} rather than bare links. Unfortunately, it's causing things to break in inflection tables whenever the generated form is identical to the page name (i.e. exactly the circumstances under which it's supposed to present boldface and no link rather than roman face and a link). See the declension table at αρχή#Declension, for example. Is there something at {{l-self}} or one of the modules it uses that needs to be fixed? —Aɴɢʀ (talk) 18:27, 7 October 2016 (UTC)

  Fixed; {{el-decl-noun}} is what should have been edited. --WikiTiki89 18:41, 7 October 2016 (UTC)


@ObsequiousNewt or anyone else who feels up to the task: {{grc-conj}} or Module:grc-conj is having a problem with the passive of the liquid/nasal futures. {{grc-conj|fut-ln|X|Y}} is causing the future passive of all verbs to appear as ήσομαι instead of as -ήσομαι suffixed to Y. See πίνω ‎(pínō), for example, where the template says {{grc-conj|fut-ln|πῐ|ποθ|form=mp}} but the table is showing the future passive as ήσομαι rather than ποθήσομαι. —Aɴɢʀ (talk) 22:07, 7 October 2016 (UTC)

@Angr Fixed. ObſequiousNewtGeſpꝛaͤchBeÿtraͤge 23:58, 7 October 2016 (UTC)

I've done a big dumpEdit

Hoho. I've just finished the overnight processing of all the English-language mainspace entries, so that I can do some of my todos, like creating missing etymologies and plurals. Any other statistics etc. that anyone needs on these entries? I might be able to do that. (Provisos: there are literally just three or four entries I had to skip over, because my code choked on a handful of rare symbols like the Hawaiian okina.) Equinox 09:33, 8 October 2016 (UTC)

It would be useful to see if there are any entries with English headers that aren't in either CAT:English lemmas or CAT:English non-lemma forms. If categories are a problem, then look for English entries lacking headword templates. Chuck Entz (talk) 18:06, 8 October 2016 (UTC)
Category links don't seem to be present in the page dumps, so I would have to deduce this by checking for the presence of any headword template (as you say). Where would I get a list of all valid headword templates? Sounds like quite a parsing challenge. Equinox 11:38, 9 October 2016 (UTC)
Might be easier to grab the category links dump. I think it is sql only (no xml) but you wouldn't have to reinvent the wheel if you are running a SQL server or want to just parse the query. - TheDaveRoss 18:09, 21 October 2016 (UTC)
@Equinox, find circular definitions. That'd be great.--Dixtosa (talk) 19:34, 22 October 2016 (UTC)
I wonder if one could prove a fixed point theorem or something in graph theory for lexicography, demonstrating that there must be circular definitions. Also, see w:Circular_definition#Circular_lexicographic_.28dictionary.29_definitions at WP.
I think that circular definitions that involve cycles of four or more definitions would not be noticed by users. I don't know about 3-definition circularity. Two-definition circularity defintely seems like a problem. Perhaps circular definitions of 3 or more headwords with the same stem (eg, quick, quickly, quickness, quicken) would be noticed. DCDuring TALK 23:12, 22 October 2016 (UTC)
Every graph that is not a tree contains a cycle. If the dictionary was structured as a tree there would be words without definitions. Therefore there will always be circular definitions. DTLHS (talk) 23:23, 22 October 2016 (UTC)
D'oh. But the only ones users notice are the one's involving the smallest of cycles? DCDuring TALK 00:14, 23 October 2016 (UTC)

Where's the English word count?Edit

On our front page, we give our total entry count ("4,915,340 entries with English definitions from over 2500 languages") and we show the word counts for Wiktionaries in other languages, but we don't list how many English words we have in en.wikt. Is that trivial to add? I wanted to compare it with the results of my dump script, which generated 675,738 English entries on my computer. Equinox 11:37, 8 October 2016 (UTC)

@Equinox: Category:English lemmas yields 443,225 entries. That category seems to be a pretty good handle on the English term count. I agree that English term count seems to be a more interesting number than the total number of lemma and non-lemma entries since the latter very much depends on our coverage of non-lemmas of highly inflected langauges, and therefore, it would be cool to see the number of English lemmas on the front page. --Dan Polansky (talk) 13:11, 8 October 2016 (UTC)
Hm, I wonder why the disparity. What English entries don't go into English lemmas? (head|en|noun) does (e.g. moules marinières) and so do symbols (e.g. the verb ). I did not keep redirects since they have no language header. Anyway, everything I've got seems to look okay. Equinox 13:25, 8 October 2016 (UTC)
Oh, haha, I'm an idiot. My list includes non-lemmas, which... kind of aren't lemmas. Equinox 13:26, 8 October 2016 (UTC)
And Category:English non-lemma forms yields 240,611 items, which, together with the lemma count, adds up to 683,836. I kind of do not think of non-lemmas as words; to me, words are lexemes. --Dan Polansky (talk) 14:17, 8 October 2016 (UTC)
Since there are entries such as wound that are both lemmas and non-lemmas, that can only be an approximation. Chuck Entz (talk) 17:55, 8 October 2016 (UTC)
Good point. The sum can still serve as some sort of a quick sanity check for a number determined by other means. --Dan Polansky (talk) 12:53, 15 October 2016 (UTC)
If words were lexemes then we wouldn't really need the word "lexeme"... Equinox 18:09, 8 October 2016 (UTC)
@Equinox: We would, to remove ambiguity. Scientists like to coin specialized terminology that is less ambiguous. If someone asks me what is the number of words covered in a dictionary, I expect them to ask about the number of lexemes. Others may differ. Similarly, if someone asks what the number of words a language has, I expect them to be talking about lexemes. --Dan Polansky (talk) 12:53, 15 October 2016 (UTC)
The number comes from Special:Statistics. That particular number is the "number of content pages". Perhaps we should give 2297446 as the total number of "gloss1 definitions" (Footnote: "1 The number of gloss definitions a language has is the number of senses the words in that language have. Inflected forms which are merely defined as "plural of x", "past tense of x", etc are not included in the count of gloss definitions, while they are included in the count of total definitions."). --WikiTiki89 17:56, 10 October 2016 (UTC)
  • All interesting stuff. The lemma to non-lemma figures can swing the other way in foreign languages compared to English. In Bokmål currently 12176 lemmas and 31739 non-lemmas, and some of those can be both as Chuck Entz mentioned. DonnanZ (talk) 18:57, 14 October 2016 (UTC)
  • Another thought. I don't think "more" and "most" comparative forms of English adjectives are recorded as non-lemmas, so the non-lemma figures probably reflect that. Similarly in other languages that use this form of comparative. DonnanZ (talk) 19:08, 14 October 2016 (UTC)

"book rendering failed" when generating PDFEdit

See Wiktionary:Information_desk/2016/October#book_rendering_failed. Our PDF generation feature seems to be broken, with this error: "book rendering failed. There was an error while attempting to render your book". To reproduce the error, visit the dog entry (for example) and choose Print/Export, Download as PDF on the left-hand menu panel. Apparently it works fine on French Wiktionary. Equinox 08:55, 9 October 2016 (UTC)

Seems to have also been a problem on Wikipedia but got fixed. See w:Wikipedia:Village_pump_(technical)/Archive_150#Download as PDF completely broken? —Enosh (talk) 12:21, 9 October 2016 (UTC)

Can we use CSS in place of ---- between language sections?Edit

Would it be possible to use CSS to have the lines between language sections be generated automatically so that we wouldn't have to manually add ----? --WikiTiki89 20:07, 10 October 2016 (UTC)

Would we have to do something like h2 { border-bottom: 1px solid black }? That would also put a line after the last section on the page, something we don't do now. DTLHS (talk) 22:19, 10 October 2016 (UTC)
h2 is just the header, not the whole section. There's currently no HTML element to contain the section itself, though I think they are "working" on that. —CodeCat 22:21, 10 October 2016 (UTC)
I think this would work:
.ns-0 h2:not(:first-of-type) {
	border-top: 1px solid #aaa;
	margin-top: 1.5em;
It adds a grey line above each h2 in the Main mainspace except for the first one on a page. —suzukaze (tc) 22:32, 10 October 2016 (UTC)
Where are the h2 styles defined anyway? Does anyone know? --WikiTiki89 16:04, 11 October 2016 (UTC)
I don't think it matters. Putting styles in MediaWiki:Common.css can override any default MediaWiki styles. —suzukaze (tc) 10:34, 13 October 2016 (UTC)
@Suzukaze-c: It matters because I want to see the code. --WikiTiki89 20:28, 17 October 2016 (UTC)
Right-click any second level header and choose "inspect element". If you are landed on a span element click h2 which should be just above it. On the right you'll see all the styles that affect h2. This is for Chrome but other browsers behave similarly. --Giorgi Eufshi (talk) 06:10, 21 October 2016 (UTC)
  • this gives exactly the same look at least for the vector skin.
    hr { display:none; }
    .ns-0 h2:not(:first-of-type){
        height: 48px;
        line-height: 69px !important;
        margin-top: 3px !important;
        border-top: 1px solid #aaa;
    --Giorgi Eufshi (talk) 12:20, 13 October 2016 (UTC)
If we did this, would we have to remove all of the manual ----'s first? DTLHS (talk) 22:29, 14 October 2016 (UTC)
We could probably hide those with css, too. Chuck Entz (talk) 22:54, 14 October 2016 (UTC)
What we do first or second doesn't really matter, but yes, if we do this, we will get rid of the manual ----s. --WikiTiki89 20:30, 17 October 2016 (UTC)

Edit request: MediaWiki:Common.cssEdit

Please change the

/* Chinese (Han) */

block to the following

/* Chinese (Han) */

/* Hani: generic */
/* Hans: simplified */
/* Hant: traditional */

.Hans {
	font-family: PingFang SC, Heiti SC, DengXian, Microsoft Yahei, SimHei, Source Han Sans CN, Noto Sans CJK SC, SimSun, NSimSun, SimSun-ExtB, Song, sans-serif;
.Hant {
	font-family: PingFang TC, Heiti TC, Microsoft Jhenghei, Source Han Sans TW, Noto Sans CJK TC, PMingLiU, PMingLiU-ExtB, MingLiU, MingLiU-ExtB, Ming, sans-serif;

.Hant {
	font-size: 1.2em;

.Hani, .Hani *,
.Hans, .Hans *,
.Hant, .Hant * {
	font-style: normal;
	font-weight: normal;

big.Hani, strong.Hani, b.Hani, b .Hani,
big.Hans, strong.Hans, b.Hans, b .Hans,
big.Hant, strong.Hant, b.Hant, b .Hant {
	font-size: 137%;

.Hani b,
.Hans b,
.Hant b {
	font-size: 125%;

per discussion at Wiktionary talk:About Chinese#New font for Chinese?. Thanks. Wyang (talk) 10:40, 13 October 2016 (UTC)

(But leave the Korean and Vietnamese sections alone. —suzukaze (tc) 10:44, 13 October 2016 (UTC))
@Atitarev Could you help please? Wyang (talk) 06:55, 14 October 2016 (UTC)
@Wyang I will, as soon as I get to my desktop and have a moment. Sorry for the accidental revert, BTW. Silly Safari on iPhone.--Anatoli T. (обсудить/вклад) 06:58, 14 October 2016 (UTC)
No worries, thanks! Wyang (talk) 06:59, 14 October 2016 (UTC)
@Wyang Done, please check. --Anatoli T. (обсудить/вклад) 07:18, 14 October 2016 (UTC)
Looks good, thanks! Wyang (talk) 07:25, 14 October 2016 (UTC)

OrphicBot and variation appendicesEdit

There's a bug in user:OrphicBot , it doesn't keep track of the existence of the variation appendices. See this diff [5] where at Uru, the Appendix:Variations of "uru" already appears, but OrphicBot adds accented and capitalized variants atop that as well.

I would suppose the fix would be to check for the existence of a variations page, scrape that appendix and see if the variations that OrphicBot is tracking is listed on the appendix page or not, and then add a fixme banner with the missing variations to the top of the appendix page. The bot would then add the appendix page to entry pages that are missing links to the appendix.

-- 04:00, 14 October 2016 (UTC)

Pinging the operator, @IsomorphycΜετάknowledgediscuss/deeds 04:56, 14 October 2016 (UTC)
@Metaknowledge, Currently, the also links consist of computed and user-added variations. If there are eight or fewer computed variations, I add the direct links, whether or not an appendix exists. If there are more than eight, I do not add links, but only the appendix. (Currently, I have not committed anything to appendices yet; writing to the appendices is still a work in progress.) I think this a reasonable policy because appendices often contain data outside of the primary scope of the also templates, such as alternate script variants. The suppression of links and creation of an appendix depend on the size of the computed list, but neither depends on the other, because anyone can add an appendix for any reason independent of list size. Isomorphyc (talk) 10:02, 14 October 2016 (UTC)
How about adding the {{also}} to the variation appendix instead, with the variations that OrphicBot is tracking; while each entry page would get linked to the variation appendix? Anyone cleaning up the appendix page can add entries to the proper locations there, while entry pages show the appendix link instead of the variations that OrphicBot is tracking. (this would not affect non-tracked links in the {{also}} on entry pages) -- 04:36, 15 October 2016 (UTC)
@ This is close to the policy which will be followed for pages with more than eight computed variants, except that since there are only a few hundred appendices, it is really not that hard to put words under appropriate headings directly after performing some de minimis normalisation of the appendices. But about 99.85% of the {{also}} templates do not involve appendices. The primary purpose is to provide easily accessible links in a prominent place. A line has to be drawn someplace for including links whether or not an appendix exists, and eight was the smallest number suggested. The largest was fifteen. Thanks for thinking about this, though. Isomorphyc (talk) 18:13, 16 October 2016 (UTC)
Does/Can OrphicBot also add the variation appendices into the {{also}} on each entry page for which a variation appendix page exists ? -- 08:44, 19 October 2016 (UTC)

Noun Classes in translation tablesEdit

When you enter a genus and a class, you get an error saying you can't have both, but within Germanic languages, speaking of masculine class I vs. feminine class I is quite common. Why the blockage? Korn [kʰũːɘ̃n] (talk) 09:36, 14 October 2016 (UTC)

Classes here are meant to be used for languages that have classes in place of genders, such as the Bantu languages. It is not meant to be a declension class. --WikiTiki89 14:56, 14 October 2016 (UTC)
Although it's such a pain and so unhelpful that I pretty much never add noun classes. Makes me think we really should do away with gender altogether for translations. —Μετάknowledgediscuss/deeds 04:57, 15 October 2016 (UTC)
I don't see how this initial intention is a reason to actively block the usage of both when such usage could be used. Korn [kʰũːɘ̃n] (talk) 10:48, 15 October 2016 (UTC)
Translation tables aren't grammar tables. —CodeCat 21:26, 22 October 2016 (UTC)


Hello. I copy wikipedia template to Azerbaijani Wiktionary. But I have a design problem. Can somebody fix it? --Aabdullayev851 (talk) 18:32, 14 October 2016 (UTC)

What's the problem? --WikiTiki89 18:34, 14 October 2016 (UTC)

Edit request: template:audioEdit

There's a redundant and very obtrusive space between a list marker and the box, and this is visible everywhere. This is one way to fix. This is the third time I have asked this. --Dixtosa (talk) 12:11, 15 October 2016 (UTC)

OK, I fixed it the way you requested. Please let me know if something breaks as a result. Benwing2 (talk) 21:44, 19 October 2016 (UTC)
@Dixtosa Benwing2 (talk) 21:45, 19 October 2016 (UTC)
@Benwing2: I am sorry that was not a perfect fix. Please apply this change too. --Giorgi Eufshi (talk) 06:36, 20 October 2016 (UTC)
@Giorgi Eufshi Done. Benwing2 (talk) 06:39, 20 October 2016 (UTC)

Removing redundant en-noun 'head' parametersEdit

I've been thinking about doing this automatically. Is it worthwhile/desirable?

  • For English noun entries only: if (i) the headword contains at least one space, and (ii) the entry uses the en-noun template with an explicit head parameter, and (iii) the value of that head parameter is identical to the headword except that each space-separated word is enclosed in [[...]]...
  • ...then remove the head parameter. For example, this would change {{en-noun|head=[[puppy]] [[mill]]}} to {{en-noun}}.
  • Rationale: this parameter value is redundant: it no longer makes any difference to the formatting and hyperlinks in the displayed headword, therefore it is just another piece of clutter in the markup. However, it is very commonly present because it used to be required.

Equinox 12:33, 15 October 2016 (UTC)

Why limit this to English nouns? —Aɴɢʀ (talk) 13:32, 15 October 2016 (UTC)
The automatic thing cannot inflect, right? And it is preferable to directly link to lemmas, I think.--Dan Polansky (talk) 13:38, 15 October 2016 (UTC)
Because I'm most familiar with en-noun and not sure what I might break by doing it to other parts of speech... Equinox 14:54, 18 October 2016 (UTC)
I interpreted Angr's question as referring to nouns in other languages - have I got that wrong? DonnanZ (talk) 14:59, 18 October 2016 (UTC)
  • I have removed a few redundant headers, but sometimes headers are still necessary, e.g. in a three-word entry which is actually derived from two parts. I also find headers are necessary for proper nouns such as Den dominikanske republikk. OK, that's not English, but the same can apply in English. DonnanZ (talk) 13:46, 15 October 2016 (UTC)
  • A three-word entry derived from two spaced parts, like ice cream maker, won't be matched by the rules I stated above (unless already mis-entered, in which case my process will neither help nor harm it, but only remove the redundant markup). Equinox 13:50, 15 October 2016 (UTC)
That looks like the right logic. Conversely, I think instances, with rare exceptions, of English lemma noun headwords containing a hyphen ought to have head= and wikilinked components. DCDuring TALK 14:02, 15 October 2016 (UTC)
While it achieves not a lot, yes, I think it's always good practice to remove redundant parameters from templates, as you do see things like {{en-noun|puppy mills|head=[[puppy]] [[mill]]}} which can simply be converted to {{en-noun}}. It's mostly for human readability although making pages slightly smaller seems like a good enough reason also. If you can make a page load 1% faster with no ill effects, why not do it? Renard Migrant (talk) 15:24, 18 October 2016 (UTC)
Okay. Should I start a vote or something? I have never run a "bot" as such although I sometimes create software that performs edits in small batches, which I babysit, rather than leaving overnight. Equinox 00:35, 19 October 2016 (UTC)
@Equinox I created a tracking category: Category:English terms with redundant head parameter. DTLHS (talk) 00:49, 19 October 2016 (UTC)
There are still some redundant headers in Norwegian inflection entries which I remove when I find them, the same is also true in Danish. DonnanZ (talk) 10:28, 19 October 2016 (UTC)

Using lit= in {{t}}Edit

Could someone with access to Module:translations allow it to pass lit= to full_link? Crom daba (talk) 17:14, 15 October 2016 (UTC)

I'll try to look at this when I have a chance. Benwing2 (talk) 21:42, 19 October 2016 (UTC)

Categories for number of syllables in a wordEdit

I noticed @Bcent1234 manually categorizing words by number of syllables. It seems like a worthwhile but bot-like task that could be accomplished much more easily. Is there any way this could be done automatically by {{hyphenation}}, at least for words over one syllable? — Eru·tuon 20:23, 17 October 2016 (UTC)

Whoops, I see that Module:hyphenation has categorize_syllables array, so maybe English just has to be added to that array? — Eru·tuon 20:25, 17 October 2016 (UTC)

It seems there was already a discussion on this: Wiktionary:Beer parlour/2016/February#Proposal: "Category:English trisyllabic words" and similar categories. Since hyphenation is different from syllabification, the categorization cannot be done by the template. Would be neat if it could be done by the IPA template, but syllabification itself is such a thorny issue that perhaps that is impossible too... — Eru·tuon 20:30, 17 October 2016 (UTC)

We've already discussed this a billion times. English hyphenation is not equivalent to the syllabification. --WikiTiki89 14:10, 18 October 2016 (UTC)

@Daniel Carrero wrote some Lua code which looked at the information in the IPA template, but the marking of syllables was not there consistently, some words were mis-classified. There was some discussion, and even though we were manually marking the syllabification in the IPA for wrong cases, it wasn't fast enough, and someone with the ability to disable it chose to remove the code. As I need the syllabification for my class for English as a second language, I'm manually marking it. Bcent1234 (talk) 11:54, 18 October 2016 (UTC)

Okay. It sounds like both the hyphenation template and the IPA transcriptions are unlikely to work. But what if there were a template, like {{syllables|en|6}} or {{syllabification|en|syl|la|bi|fi|ca|tion}}? Would that make things easier? — Eru·tuon 15:58, 19 October 2016 (UTC)
How is that easier than just adding the category? I've already suggested {{cln|en|X-syllable words}}, which uses an existing template, but that is just a minor improvement. --WikiTiki89 17:12, 19 October 2016 (UTC)
@Wikitiki89: Well, {{syllables|en|6}} would be a little shorter to type than [[Category:English 6-syllable words]] or {{cln|en|6-syllable words}}; {{syllabification|en|syl|la|bi|fi|ca|tion}} could maybe both categorize and display some sort of spelled-out syllabification, similar to the hyphenation... — Eru·tuon 17:26, 19 October 2016 (UTC)
I would oppose having a spelled-out syllabification, otherwise we'd do it in the IPA. And when you're copying and pasting, the length doesn't really matter, there is still just one character in [[Category:English 6-syllable words]] that needs to be changed from page to page. --WikiTiki89 17:29, 19 October 2016 (UTC)
@Wikitiki89: Perhaps {{IPA}} should have a parameter that turns on categorization, to be used with transcriptions that actually have all syllable breaks marked. — Eru·tuon 17:34, 19 October 2016 (UTC)
But since we decided that it is detrimental to show syllable breaks in English, that wouldn't solve this problem. --WikiTiki89 17:35, 19 October 2016 (UTC)
@Wikitiki89: Huh. Why would it be detrimental? Is there a discussion you could link to? — Eru·tuon 17:44, 19 October 2016 (UTC)
In case you're unaware, everything in this discussion has already been discussed in a million different places over the past month or two. Check the WT:BP and User talk:Daniel Carrero, and I'm definitely forgetting some other places. --WikiTiki89 17:51, 19 October 2016 (UTC)
Meh. I found a couple of relevant discussions. English syllabification is such a problem, and the IPA really needs a symbol for ambisyllabicity. Maybe there should be a note about the result of these discussions somewhere... — Eru·tuon 18:05, 19 October 2016 (UTC)

It occurred to me that syllables can be counted by searching for syllable nuclei (vowels or syllabic consonants). I'll work on a module that does that. — Eru·tuon 19:13, 19 October 2016 (UTC)

That's a much better idea. That was the path I was trying to get Daniel Carrero to go down, but he seemingly didn't want to. However, there are a few things that would need to be considered, especially involving quasi-syllabic consonants. Does fire have one syllable or two? Does real have one syllable or two? We sort of agreed that these sorts of ambiguous cases should be placed in both categories. See this discussion that I finally found. --WikiTiki89 19:31, 19 October 2016 (UTC)
I saw that discussion at some point when making the first few posts in this thread. All those words with vowels and a liquid should probably have two transcriptions – for GA real, /ɹil/ and /ɹi(.)əl/ or /ɹi(.)l̩/ – and one transcription would cause them to be categorized as having x number of syllables, the other as x + 1 (and so on, if there is more than just one ambiguous sequence in the word). — Eru·tuon 21:52, 19 October 2016 (UTC)
Can this be done for all languages simultaneously or would you have to account for language specific rules? DTLHS (talk) 22:46, 19 October 2016 (UTC)
There will have to be some sort of language-specific rules to determine which vowel sequences are diphthongs. English transcriptions don't currently use non-syllabic diacritics, so I'm going to have to define which vowel sequences are diphthongs and which aren't. For instance, GA lower is transcribed as /ˈloʊɚ/, with a three-vowel sequence, but two of those vowels form a diphthong, while the other forms another syllable. Finnish transcriptions, on the other hand, do seem to use non-syllabic diacritics, so I could just use the presence of that diacritic as an indication that something is a diphthong. (On the other hand, it might be good to have rules defining diphthongs just in case some Finnish transcriptions don't use the non-syllabic diacritic.) — Eru·tuon 23:27, 19 October 2016 (UTC)
(e/c) I was going to say the same thing .... /aɪ/ is a diphthong in English but two vowels in Russian. As for real, I don't think you should count on there being two transcriptions and instead try to have the module automatically categorize into both N and N+1 syllables in ambiguous cases, unless it's unpredictable. Keep in mind that our use of IPA for English isn't super-consistent and there are potentially lots and lots of cases that would need to be fixed up the way you suggest. Benwing2 (talk) 23:31, 19 October 2016 (UTC)
BTW as for syllable divisions, they are helpful in some cases, particularly at juncture boundaries in compound words (e.g. /ˈgeɪtˌweɪ/ is pronounced quite differently from /ˈgeɪˌtweɪ/; OTOH in most of these cases there will be a primary or secondary stress marker at the syllable boundary, making the syllable dot unnecessary) but I think the general agreement is that syllable divisions aren't terribly helpful in English in most cases because of the difficulty of deciding where to place the boundary in common words like color, writer etc. I don't think there's even a generally accepted theory of how to divide English words into syllables, how to determine which consonants are ambisyllabic, or for that matter whether ambisyllabic consonants exist at all. Benwing2 (talk) 23:38, 19 October 2016 (UTC)
When the Toronto Globe and Mail fouled up one of my contributions in 1984 I asked them how they could ever hope that their machine would know that "realm" was always and everywhere monosyllabic. They shrugged me off, but Lo! twenty years later even a vastly improved system managed to divide it. I presented them with their own rea-lm in triumph. They conceded my point -- and duly got it fixed in something like another ten years flat.
David Lloyd-Jones (talk) 12:42, 20 October 2016 (UTC)

Okay, so I have created a set of definitions for English diphthongs in Module:syllables, based on the list of symbols in Appendix:English pronunciation. There's so far one ambiguity: IPA(key): /iə/ is a diphthong in New Zealand and a disyllabic sequence in GA. Thus, the module currently says that IPA(key): /aɪˈdiə/, the transcription of idea in General American, has two syllables rather than three. Other than that, I can't think of any ambiguities. I s'pose this could be solved by adding a dialect parameter to the {{IPA}} template, and then defining which diphthongs exist in each dialect. — Eru·tuon 03:15, 21 October 2016 (UTC)

Not a bad idea, but that would essentially make the {{a}} template useless in the long term. Also to consider: will every call to {{IPA}} refer to at most one dialect? —CodeCat 21:30, 22 October 2016 (UTC)
This isn't exactly an answer, but I am thinking an easier solution would be to simply replace /iə/ with /i.ə/. I did a search in the source code, and there were only 104 results. Wouldn't be too hard to go through them and make replacements when appropriate. Adding dialects to the IPA template seems like it would be too much work to solve one tiny problem. And there are cases where one transcription is given for two dialects (for instance, in how). Currently there are transcriptions that don't have dialect specified, but that should be corrected, because most words will have at the very least one vowel that is transcribed differently across the dialects in Appendix:English pronunciation. — Eru·tuon 22:06, 22 October 2016 (UTC)
This issue is far from unique to English. In the "standard" pronunciation of Finnish, /ua/ is a two-vowel sequence, but in Savonian it's a diphthong. —CodeCat 22:18, 22 October 2016 (UTC)
We now have a working function in Module:syllables. We should probably integrate this into Module:IPA though. Can someone unprotect the module? —CodeCat 23:54, 22 October 2016 (UTC)

Pronunciation for alternate spellings?Edit

What is our policy on how to handle alternate spellings like oute ? Do we put a pronunciation with them from the current spelling [out], do we ask someone to put a spelling on the word using rfap with the argument that it might have been pronounced differently when the alternate spelling was in vogue, or do we just leave it without a pronunciation, thereby inpoverishing wiktionary ? Bcent1234 (talk) 14:52, 18 October 2016 (UTC)

It doesn't impoverish Wiktionary to keep all the information at the main entry. Also, oute probably never had a final schwa sound, the only difference in pronunciation back then might have been the main vowel, which would have applied equally to the spelling out. --WikiTiki89 14:57, 18 October 2016 (UTC)

Template:wikipedia layout considerations -- luafication has broken certain HTML / CSS behaviorEdit

Apparently the {{wikipedia}} template was luafied on 13 October. This now breaks certain kinds of layout. In the past, multiple instances of {{wikipedia}} could all be clustered in a single <div> element for on-page layout and grouping. That is no longer possible. This causes some unfortunate layout artifacts, such as at 野兎, where the {{ja-kanjitab}} template should (and formerly did) appear immediately to the left of the {{wikipedia}} templates as rendered, where the three appeared in the same block, all aligned on the right of the page, roughly like:

-------- -------------
| ja-k | | wikipedia |
| anji | -------------
| tab  | | wikipedia |
-------- -------------

As now observable at 野兎 and numerous other pages, this layout is no longer possible. In the past, one could explicitly wrap the {{wikipedia}} calls in a <div> element to force this, such as:

<div style="float:right;">
{{wikipedia|ENGLISH TITLE}}

However, this no longer works, apparently because the Lua invocation forces a break in the containing div, so it only wraps the first {{wikipedia}} template and not the second.

This leads me to questions:

  1. Why luafy this in the first place? This template doesn't do much (not many moving parts, nothing that requires heavy logic), and it's been stable for a long time.
  2. Can this be reverted without causing serious disruption?
  3. If reversion is undesirable, can the layout at least be fixed, so that multiple instances of {{wikipedia}} can still be wrapped in a single <div> element?


‑‑ Eiríkr Útlendi │Tala við mig 20:33, 18 October 2016 (UTC)

There was one too many closing </div>s, I fixed that now. But I still can't get 野兎 to look the way you want. —CodeCat 20:49, 18 October 2016 (UTC)
@Eirikr: I think in the case of the entry 野兎, the reason why the kanji box does not display to the left of the two Wikipedia boxes is actually because of the image that intervenes between the two. I removed the image and added the <div style="float: right;"></div> around the Wikipedia boxes, and then the kanji box moved up and sat to the left of the Wikipedia boxes rather than underneath them. I think the module generates the exact same Wikipedia boxes as the original template did; it's just your addition of an image that messed things up. — Eru·tuon 00:14, 19 October 2016 (UTC)
Actually, I just put the div around the Wikipedia boxes and the image in 野兎, and now, at least for me, the kanji box sits in the position that you want it to. What do you think; does it look better now? — Eru·tuon 00:18, 19 October 2016 (UTC)
That doesn't look bad to me even with rhs TOC. DCDuring TALK 00:40, 19 October 2016 (UTC)
  • Fabulous! @CodeCat, I suspect it was the extra </div> -- thank you for finding and fixing that.  :)
@Erutuon, exactly what you describe -- the wrapping div trick is what I've used for some time (including the image too, sorry I forgot to mention that before). With CodeCat's fix, the div wrapper now works again.  :)
Cheers all! ‑‑ Eiríkr Útlendi │Tala við mig 01:46, 19 October 2016 (UTC)

Improving the display of Module:grc-pronunciationEdit

Several people have complained about the Ancient Greek IPA template {{grc-IPA}}. By default it displays three transcriptions with right arrows, but it has a "more" button that you click to view more information. This button displays on the far right side of the content area. The HTML content of this template is generated by Module:grc-pronunciation. The <div> that contains the whole transcription thingy does not have width set, so it defaults to width: auto;. This apparently makes it the width of the whole content area. An example follows:




POS header

Now, I came up with what I thought was a solution: setting width: max-content;, white-space: nowrap;, and adding some more <div>s. But for some reason that makes the POS header immediately below the Pronunciation section vanish. See the example to the right (generated by {{grc-IPA/sandbox}} and Module:grc-pronunciation/sandbox). There's a blank space under the pronunciation, where the header POS header should be. The header is in the HTML source code, but it doesn't display.

I did a little tinkering, and it's the width: max-content; that's the culprit. When I remove that CSS property, the POS header reappears. I have no idea why this is the case. Does anyone know what's going on, or have any alternative ways to fix the Ancient Greek IPA box so that the "more" button is not all the way over on the right? — Eru·tuon 16:26, 19 October 2016 (UTC)

Creating Redlink CategoriesEdit

Can anyone explain to me how redlink categories (for example, Category:German redlinks) are created and added to Category:Redlinks by language? I think editors would find it useful. --Lo Ximiendo (talk) 03:51, 20 October 2016 (UTC)

It is controlled by {{redlink category}}. And it's only useful if there's someone who wants to use it. DTLHS (talk) 04:13, 20 October 2016 (UTC)
Apparently, populating redlink categories for all languages causes a huge load on the server and some pages end up with module errors. That's why only some languages have redlink categories activated at the moment. You can add/remove languages by editing that template linked by DTLHS. --Daniel Carrero (talk) 17:50, 21 October 2016 (UTC)
It would be much better accomplished by a dump-parsing bot or toolserver tool. Anything computationally expensive which doesn't need to be real-time probably shouldn't be real time. - TheDaveRoss 17:54, 21 October 2016 (UTC)
I don't mind if people decide to replace that system by dump parsing. I created the current redlink categorization and I don't have a lot of experience in parsing dumps, so the current situation is the best that we have until further notice. One thing that I like about the current system is that, if someone wants to clean up redlink categories, they get smaller in real time and it's clear how many entries are left. Parsed dumps can get outdated soon if not constantly updated, like our indices. We only probably need to list redlink categories for a few languages anyway-- those where people want to fix the redlinks, so the strain is much smaller than it would be if all languages had those categories. @SemperBlotto said that was interested in fixing the Italian entries at some point. --Daniel Carrero (talk) 18:06, 21 October 2016 (UTC)

Lining up ruby.Edit

In an ideal world we need better type for ruby. E.g.:

In the entry for 国籍, we find the synonym 市民権 with the hiragana ruby しみんけん ‎(shiminken), both correct, but the しみん appears over the 市, which is actually only the し. 民 is みん.

Almost nobody is going to be led astray by this, but it would be nice in both senses of the word if the ruby lined up correctly. This is the sort of stuff that the typography folks have been working on tirelessly back to Gutenberg in the West, and who knows who in the East, for centuries, so I won't hold my breath, simply being satisfied that somebody will get around to it in due course... All praise to Donald Knuth.

David Lloyd-Jones (talk) 12:33, 20 October 2016 (UTC)

@David Lloyd-Jones: See diff, which tells the {{ja-r}} template of boundaries to follow when positioning kana. (This must be a manual job at the moment.) —suzukaze (tc) 05:18, 23 October 2016 (UTC)

MediaWiki:Bad image listEdit

What controls this list? Why is File:MalayanSunBear.jpg for example, on it? DTLHS (talk) 16:36, 21 October 2016 (UTC)

It is just a normal page. The bear is there because Connel added it [6]. Equinox 16:42, 21 October 2016 (UTC)
I think it had to do with a vandal who liked to add it to entries. - TheDaveRoss 17:59, 21 October 2016 (UTC)
Is the page actually used for anything, e.g. anti-vandal bots? It hasn't been updated since mid-2009. Equinox 18:01, 21 October 2016 (UTC)
[[File:MalayanSunBear.jpg|100px]] results in "100px" vs. [[File:Malaienbaer2 fcm.jpg|100px]] resulting in  
I think it is built into MW that files listed on that page are prevented from being displayed on other pages. - TheDaveRoss 18:15, 21 October 2016 (UTC)

Setting things to "template editor" protection levelEdit

Now that we have this protection level, we should use it. That means changing the protection settings of a whole lot of stuff, more than would be reasonable to do manually. Does anyone want to do this automatically for stuff like the language data modules? —Μετάknowledgediscuss/deeds 17:27, 21 October 2016 (UTC)

I don't mind making the changes through the API, the trickier part is defining what should be changed in a way which is able to be fed to the bot. If you have some criteria? - TheDaveRoss 17:44, 21 October 2016 (UTC)
Can we just apply it to all currently protected modules and templates? DTLHS (talk) 17:46, 21 October 2016 (UTC)
Yes, that would be the easier solution of all. The question is whether or not there are modules and templates which should not be reduced to that protection level. - TheDaveRoss 17:55, 21 October 2016 (UTC)
I don't think there are any, actually. Protection levels could of course be changed, should there be reason to do so. —Μετάknowledgediscuss/deeds 19:29, 21 October 2016 (UTC)

Outdated code in MediaWiki:Gadget-legacy.jsEdit

The code related to retrieving a random page in a given language is outdated and can't be updated either because the way we get a random page has changed. It used to query hippie's tool on toolserver, now we use Special:RandomInCategory and the lemma categories. --Dixtosa (talk) 21:42, 22 October 2016 (UTC)


I note that {{ux}} (and other templates) require a parameter "inline=1" to force templated content to appear where one would want it. See strazds recent history. Using the "inline" parameter leads to improper display of {{taxlink}}. Can the misbehavior of {{ux}} and/or of {{taxlink}} be corrected or must one use workarounds (eg, removing the taxa to derived terms in the case of [[strazds]] or dropping use of {{ux}} when it doesn't give desired results)? DCDuring TALK 23:27, 22 October 2016 (UTC)

What specifically is the problem with the display? DTLHS (talk) 23:28, 22 October 2016 (UTC)
The desired behavior in the case of [[strazds]] is that the translation of the Lativian usex appear on the same line as the Latvian text and that {{taxlink}} produce its usual display of its taxon. DCDuring TALK 23:36, 22 October 2016 (UTC)
The last usage example didn't have the inline parameter. I still don't see what the difference is in the taxlink display. DTLHS (talk) 23:39, 22 October 2016 (UTC)
I may have made a mistake when converting the page: I changed all instances of "=" to "{{=}}"- if that parameter was inside of another template it would create an error. I'll try to fix this. DTLHS (talk) 23:41, 22 October 2016 (UTC)
(After e/c) These were the behaviors I saw with various combinations of presence of absence of inline=1 and of {{=}}:
  1. dziedātājstrazds‎ ― song thrush (noshow=1)
    song thrush (Turdus philomelos)
    dziedātājstrazds‎ ― song thrush (noshow=1)
I neglected the one combination that produced the correct result, ie, removed {{=}}:
  1. dziedātājstrazds‎ ― song thrush (Turdus philomelos)
If there are a lot of insertions of {{=}}, then it is beyond my capability to reverse them. DCDuring TALK 23:52, 22 October 2016 (UTC)
I removed {{=}} from the two entries that had both {{ux}} and {{taxlink}}, the only misbehavior that I was looking for. DCDuring TALK 00:04, 23 October 2016 (UTC)
{{ru-ux}} seems to prevent named parameters within {{taxlink}} from working, eg, noshow=1, which is supposed to remove the entry from a category. DCDuring TALK 00:08, 23 October 2016 (UTC)
I have analyzed my edits and determined the only problems were on strazds and ģints. DTLHS (talk) 00:09, 23 October 2016 (UTC)

Detecting incorrect use of Template:etyl and Template:derEdit

It seems like there are lots of cases where {{etyl|language|ancestor}} {{m|ancestor|term}} is used instead of {{inh|language|ancestor|term}}. It wouldn't be too hard to correct these using some regex and AWB, but there's no way to select for these cases. I imagine, since ancestor languages are defined in the data modules attached to Module:language, that there's some way to program Module:etymology to put all uses of {{etyl|language|ancestor}} into a category, which could then be swept through using AWB. Or maybe a bot could do it, because who knows how many entries there would be.

I think there was a bot replacing {{etyl}} {{m}} with {{der}}, but that was discontinued, presumably because it doesn't result in different categorization. But more fully implementing {{inh}} would move terms from derived categories to inherited ones.

I suppose there are the problematic cases, where a word was not inherited from its ancestor language, but more of a learned borrowing. That's a problem. I mean, you don't want a bot making an etymology say that French linguiste was inherited from Latin. Man, that's kind of irritating. But it wouldn't prevent an AWB user from doing it, if people could trust them not to mess things up... — Eru·tuon 05:12, 23 October 2016 (UTC)