Wiktionary:Grease pit

Definition from Wiktionary, the free dictionary
(Redirected from Wiktionary:Bug reports)
Jump to: navigation, search

Wiktionary > Discussion rooms > Grease pit

Welcome to the Grease pit!

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

The Grease pit is a place to discuss technical issues such as templates, Lua modules, 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".

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


October 2017

Wiktionary:Administrators/List of administrators[edit]

Wouldn't it be possible to automatise this list, and add a self-updating column "Date of last edit"? --Barytonesis (talk) 18:57, 1 October 2017 (UTC)

abstinence of war is not a one-syllable word[edit]

For some reason, abstinence of war has ended up in Category:English 1-syllable words. I'm guessing this error has something to do with Template:IPA. That template hasn't been edited recently, though, so I'm not sure what's going on. MewBot has been making edits related to the category lately, so maybe User:CodeCat will know what the problem is? —Granger (talk · contribs) 18:30, 4 October 2017 (UTC)

{{IPA}} categorizes syllables for each parameter. In this case "ʌv" and "wɔɹ" are single syllables. DTLHS (talk) 18:31, 4 October 2017 (UTC)
Thanks, that makes sense. I see that it's in Category:English 3-syllable words too. Is there a way to remove the entry from those categories? —Granger (talk · contribs) 18:36, 4 October 2017 (UTC)
Remove the pronunciation since it can be found from the individual component words. DTLHS (talk) 18:39, 4 October 2017 (UTC)
I thought we decided that {{IPA}} should not add these categories at all. --WikiTiki89 18:45, 4 October 2017 (UTC)
Who is "we"? I think it works quite well. DTLHS (talk) 18:48, 4 October 2017 (UTC)
"We" is the WT:BP. But it looks like it's been improved since we had that conversation. Was there any discussion to reinstate this functionality? --WikiTiki89 18:53, 4 October 2017 (UTC)
What was agreed in a previous discussion that I found in this search was that the template needs a parameter that turns off syllable counting. Perhaps there is another discussion that I missed. I finally implemented that now. — Eru·tuon 19:58, 4 October 2017 (UTC)
Proxima Centauri apparently has 12 and 13 syllables. Equinox 21:08, 4 October 2017 (UTC)
Yes, it does. DTLHS (talk) 21:16, 4 October 2017 (UTC)
Now fixed, but I'm struggling to hear how it could be pronounced with 7 syllables. DTLHS (talk) 21:20, 4 October 2017 (UTC)
It's because -aʊə- counts as two syllables. Consider whether hour is 1 syllable or 2. —Rua (mew) 21:40, 4 October 2017 (UTC)

How do I turn off the new Recent Changes?[edit]

It would be fine, but on my old computer it's too slow to load all that script. I went to my Preferences, Beta features tab, but it's already unticked there. Saving didn't help. Equinox 18:37, 5 October 2017 (UTC)

I wish it didn't have to load, but was just available as soon as the rest of the page. All these gadgets with their own load delays annoy me. —Rua (mew) 18:48, 5 October 2017 (UTC)
I would like it a lot more if the list automatically updated periodically. DTLHS (talk) 20:27, 5 October 2017 (UTC)
What exactly do we have to do to go back to the old system? SemperBlotto (talk) 20:45, 5 October 2017 (UTC)
@SemperBlotto: you have to go to "Special:Preferences", then to the tab "Recent changes". There's the following tick box: "Hide the improved version of Recent Changes" - Rolls back the 2017 interface redesign and all tools added then and since. --Barytonesis (talk) 20:49, 5 October 2017 (UTC)
Found it. Thanks. SemperBlotto (talk) 20:53, 5 October 2017 (UTC)

new block page[edit]

When an admin blocks a user, we now get a new page with lots of white space that we have to scroll down. It doesn't seem to add any new function and is annoying. Is there any way we can get rid of it? SemperBlotto (talk) 05:43, 6 October 2017 (UTC)

I don't see it. Screenshot? DTLHS (talk) 05:47, 6 October 2017 (UTC)
After several minutes trying to remember how to take a screenshot - it's at
block Capture.PNG
SemperBlotto (talk) 06:01, 6 October 2017 (UTC)
Try adding these rules to your common.css: #blockiptext { display: none; } and .oo-ui-fieldLayout.oo-ui-labelElement, .oo-ui-fieldLayout.oo-ui-fieldLayout-align-inline { margin-top: .01em; } DTLHS (talk) 06:16, 6 October 2017 (UTC)
OK. I didn't have one of those. Created it with ONLY the above code. Seems to be better. It won't be long before I use it for real. Thanks. SemperBlotto (talk) 06:26, 6 October 2017 (UTC)
Gratuitous white space is modern and sexy. The scrolling is worth it. (but seriously why are these redesigns so damn ugly in Monobook) —suzukaze (tc) 06:55, 6 October 2017 (UTC)
It's been put back the way it was - excellent! SemperBlotto (talk) 06:16, 8 October 2017 (UTC)

Batch fix request[edit]

"From Borrowing from". Wyang (talk) 07:43, 6 October 2017 (UTC)

@Wyang: done. —JohnC5 09:00, 6 October 2017 (UTC)
@JohnC5 Thanks! Wyang (talk) 09:11, 6 October 2017 (UTC)

Getting a list of...[edit]

Entries (or language sections) with an unbalanced number of {}, or []? (potentially good cleanup list.) Wyang (talk) 09:12, 6 October 2017 (UTC)

While useful, it might be hard to find out which of them is unmatched on a long page. So I would suggest that the dump also includes an excerpt from the wikicode which highlights exactly which bracket is missing a pair. —Rua (mew) 10:38, 6 October 2017 (UTC)
On Wikipedia, w:User:BracketBot used to do something somewhat similar, but it hasn't been active since July 2016. I believe there used to be a Toolserver page that allowed users to find pages with unpaired brackets and highlighted the brackets in question, but I don't know if anything similar currently exists. —Granger (talk · contribs) 11:28, 6 October 2017 (UTC)
@Wyang User:DTLHS/cleanup/unbalanced brackets. DTLHS (talk) 17:09, 6 October 2017 (UTC)
@DTLHS Thanks! Wyang (talk) 22:43, 6 October 2017 (UTC)

Complex URLs don't work in single-bracket link syntax[edit]

See normalphobia, please advise. Equinox 17:13, 7 October 2017 (UTC)

You gotta escape those damn quotation marks. — Ungoliant (falai) 17:16, 7 October 2017 (UTC)

Link language in template m+[edit]

I noticed that {{m+}} is not linking the language to the Wikipedia article, unlike other similar templates. This is inconsistent. Can someone fix this, please? If no one does, I may try doing it by myself.


  • {{m+|fr|qwerty}} = French qwerty (currently does not link to the Wikipedia article)
  • {{cog|fr|qwerty}} = French qwerty (currently links to the Wikipedia article)

Thanks in advance. --Daniel Carrero (talk) 21:38, 7 October 2017 (UTC)

And we also have {{noncog}}. Some of these should probably be merged. —Rua (mew) 21:47, 7 October 2017 (UTC)
{{m+}} was created in a discussion in July, and @Florian Blaschke requested that the language name be unlinked by default, because in many cases the language is well-known and the link isn't all that useful. I find that sort of convincing, but I recognize that it is somewhat confusing for the behavior of {{cog}} and {{noncog}} to be different from that of {{m+}}.
It is easy to change the default behavior in Module:links/templates, but note that there's currently a parameter that turns Wikipedia links on, so if the behavior of the template changes, current instances of the template should probably have the no-Wikipedia-link parameter added so that their display doesn't change. Or it could be resolved that the language name should always be linked. — Eru·tuon 22:14, 7 October 2017 (UTC)
Arguably, all languages should be linked by default in {{noncog}} and {{m+}} because that's what all other templates do: {{der}}, {{bor}}, {{inh}} and even the deprecated {{etyl}}. We could say this is the status quo. We are free to discuss and change that, of course, but I'd like any changes to be reflected in the other templates as well.
--Daniel Carrero (talk) 22:22, 7 October 2017 (UTC)
All those other templates are used in etymologies though, where people are likely to encounter languages they're not familiar with. Can the same be said for {{m+}}? Also, it is worth considering that years ago, we had a rule to link some languages in translations but not others. We eventually decided to make it consistent and not link any of the languages. Perhaps the same should be done here. —Rua (mew) 22:56, 7 October 2017 (UTC)
I prefer to use {{m+}} in etymologies when the language has already been mentioned. That way, the link appears only at the first mention of the language, but not at subsequent mentions, which would be annoying. —Aɴɢʀ (talk) 15:06, 8 October 2017 (UTC)

New editor -- horrid[edit]

What's with the new editor? This is appearing since last week. Everything is harder to do -- it loads slower, it sometimes grabs the wrong section for editing, lots of things are hidden now, and everything except typing takes more clicks than before.

Anyone know how to disable this monstrosity? ‑‑ Eiríkr Útlendi │Tala við mig 22:17, 7 October 2017 (UTC)

Check your preferences under "beta features". DTLHS (talk) 22:39, 7 October 2017 (UTC)
@DTLHS: THANK YOU. That was driving me batty. Nearly a textbook example of bad user experience. ‑‑ Eiríkr Útlendi │Tala við mig 00:02, 8 October 2017 (UTC)

Category:French words suffixed with -ment[edit]

As there are two different suffixes -ment (verb → noun vs. adjective → adverb), I've split this category in two (I'm not terribly satisfied of the naming, so I'm open to suggestions):

Would it be possible to run a bot that would assign all the entries using the POS header ===Noun=== to the first one, and the ones using ===Adverb=== to the second? --Barytonesis (talk) 17:22, 8 October 2017 (UTC)

Category:German words suffixed with -en and Category:Dutch words suffixed with -en need similar treatment: substance if adjective, denominative if verb. Additionally, Category:German adjectives suffixed with -en needs to be converted to Category:German words suffixed with -en (substance). —Rua (mew) 19:09, 8 October 2017 (UTC)
Category:English words suffixed with -ly > Category:English words suffixed with -ly (adjectival) and Category:English words suffixed with -ly (adverbial). --Barytonesis (talk) 19:54, 13 October 2017 (UTC)
There's also Category:English words prefixed with a-. --Barytonesis (talk) 15:37, 31 October 2017 (UTC)

Pull-down listing of reasons for reversions and undos[edit]

See Wiktionary:Beer_parlour/2017/October#Please.2C_please_reveal_the_cause_of_the_revert_in_the_edit_summary.

This seems to me a desirable change, though it might need BP discussion.

What would have to be done to provide pull-down listings of reasons for reversion or undoing of contributions? As to content the pulldown listing of reasons for entry deletion would be a start. DCDuring (talk) 19:06, 8 October 2017 (UTC)

If you want to leave a reason you can use undo instead of reversion. DTLHS (talk) 19:14, 8 October 2017 (UTC)
The pull-down menu would be useful to facilitate actually providing a reason, without typing, especially for reversion/undoing of contributions by newbies, anons etc. DCDuring (talk) 19:24, 8 October 2017 (UTC)

proscribed viri(i)[edit]

How can we lay-out in virus that both viri and virii are proscribed? Sobreira ►〓 (parlez) 11:51, 11 October 2017 (UTC)

  • Better now? —Aɴɢʀ (talk) 12:08, 11 October 2017 (UTC)
    • Thanks. I tried with the order, not with the numbers. Sobreira ►〓 (parlez) 12:34, 11 October 2017 (UTC)
      • Named parameters can come in any order. —Aɴɢʀ (talk) 17:23, 11 October 2017 (UTC)

catalyses (n) and catalyses (v)[edit]

My doubt: as in analyses, shouldn't catalyses have two etymologies? Would the plural of catalysis have also a different pronounciation from the present of to catalyse. Sobreira ►〓 (parlez) 12:34, 11 October 2017 (UTC)

Yes. DTLHS (talk) 17:27, 11 October 2017 (UTC)
Yes check.svg DoneAɴɢʀ (talk) 17:34, 11 October 2017 (UTC)

The Wiktionary search 'incategory:"English noun plural forms" incategory:"English third-person singular forms" -"Etymology 2"' found 4,791 such entries with no second Etymology. This would be an underestimate of the size of the total problem. DCDuring (talk) 18:47, 11 October 2017 (UTC)

It seems like a low priority unless the noun and verb forms have different pronunciations. DTLHS (talk) 18:56, 11 October 2017 (UTC)
I agree. It's a particularly high priority when one form has an alternative spelling (in this case, catalyzes) that the other form doesn't have. When only the pronunciation is different, the solution at houses is adequate IMO. —Aɴɢʀ (talk) 19:11, 11 October 2017 (UTC)

Pings not working[edit]

Pings for me haven't been showing up at all for about 3-4 days now. Anyone else experiencing the same? Wyang (talk) 20:09, 11 October 2017 (UTC)

Same here (test: @Wyang) DTLHS (talk) 20:18, 11 October 2017 (UTC)
I have no idea. Has anyone pung me lately? —Aɴɢʀ (talk) 20:21, 11 October 2017 (UTC)
Being discussed at w:Wikipedia:Village pump (technical)#Not receiving pings and phab:T177825. -- John of Reading (talk) 20:25, 11 October 2017 (UTC)
Ah, thanks. It's a pity that they downgraded it from high priority. I miss the pingable days; I feel people tend to be more active when they can see others have pung them at various places. Wyang (talk) 07:03, 12 October 2017 (UTC)
It does make it less easy to communicate, especially for those of use who like to use it in talk pages instead of using WT:TR. (BTW, pung lol... the entry for ping only has pinged as a past tense... do people actually use pung?) — justin(r)leung (t...) | c=› } 07:40, 12 October 2017 (UTC)
No, of course not. I said it as a joke. (But pung is only the past participle; the past tense would of course be pang.) It would also be possible to model it on bring and have ping – pought – pought. —Aɴɢʀ (talk) 08:36, 12 October 2017 (UTC)
Haha :D — justin(r)leung (t...) | c=› } 18:55, 12 October 2017 (UTC)
  • @Wikitiki89, as this explains our recent confusion over his pings not going through... but of course, my ping probably won't work. —Μετάknowledgediscuss/deeds 07:08, 12 October 2017 (UTC)
Try to updated yours preferences saving some change and then saving it back. It worked for me. On Special:Preferences#mw-prefsection-echo I changed to mention->email, I received a ping by email, I restored preferences back to "web" and now it is working fine onwiki. Of course, it won't work for pinging others, but for receiving pings to you. --Vriullop (talk) 16:05, 12 October 2017 (UTC)

Spacing issue[edit]

What's going on at bila#Swahili with the Arabic etymon? I'm not seeing a space between the words "Arabic" and بِلَا. —Μετάknowledgediscuss/deeds 19:47, 14 October 2017 (UTC)

I can see a space on my computer: [1]. Wyang (talk) 23:37, 14 October 2017 (UTC)
I can see it, too. — justin(r)leung (t...) | c=› } 00:41, 15 October 2017 (UTC)
What browser? Are you using any extensions or messing with fonts that could cause this? DTLHS (talk) 00:43, 15 October 2017 (UTC)
The problem only occurs on Safari. That's weird, but I guess I won't worry about it then. —Μετάknowledgediscuss/deeds 02:37, 15 October 2017 (UTC)

Adding Xiongnu and Xianbei as etymology-only languages[edit]

Would be handy for Chinese etymologies. How should I go about this, and what code should they have? Wyang (talk) 08:06, 15 October 2017 (UTC)

Module:etymology languages/data. I'm not sure of the exact rules for coming up with a code, but it looks like (closest parent language)-(three letters representing language). DTLHS (talk) 17:37, 15 October 2017 (UTC)
In this case you want to format them like Turduli (q.v.), as und-xnu and und-xbi or whatever three letters make sense to you. (Unless Xianbei is so clearly Mongolic that you'll want to be deriving terms back to Proto-Mongolic, in which case the code should begin with xgn-.) —Μετάknowledgediscuss/deeds 17:52, 15 October 2017 (UTC)
If they're etymology-only languages, they need a parent language (i.e. the language that they're considered a "dialect" of). That can be und, as it is for Turfuli, but in that case Xianbei probably shouldn't be given a code starting with xgn-. —Aɴɢʀ (talk) 19:58, 15 October 2017 (UTC)
Ah, thanks for pointing that out. They'd best be und. —Μετάknowledgediscuss/deeds 21:05, 15 October 2017 (UTC)
Thanks all. I added them under the codes of und-xnu and und-xbi. Wyang (talk) 07:55, 16 October 2017 (UTC)

Looking for small technical tasks+mentors for new contributors - got something in mind?[edit]

Hi everybody! Google Code-in (GCI) will soon take place again - a seven week long contest for 13-17 year old students to contribute to free software projects. Tasks should take an experienced contributed about two-three hours and can be of the categories Code, Documentation/Training, Outreach/Research, Quality Assurance, and User Interface/Design. Do you have an idea for a task and could you imagine mentoring that task? For example, do you have something on mind that needs documentation, research, some gadget or template issues on your "To do" list but you never had the time, and can imagine enjoying mentoring such a task to help a new contributor? If yes, please check out mw:Google Code-in/2017 and become a mentor! Thanks in advance! --AKlapper (WMF) (talk) 19:55, 16 October 2017 (UTC)

About show/hide sections[edit]

Hi you all! (Sorry for my English)

I am an Admin from Turkish Wiktionary and have been working on some extensions lately to improve Turkish Wiktionary in a level which English Wiktionary reached at this point. I updated the Commons.js file few days ago; this was inevitable, because we had to use "the show/hide" feature on translitions template. I managed to translate this feature with the "Visibility" title that shown on sidebar. But as you can see on this page, it doesn't work on mobile pages. We should do an extra change for that? If anyone can help, that would be nice. Thanks! HastaLaVi2 (talk) 08:46, 17 October 2017 (UTC)

@HastaLaVi2 See MediaWiki:Mobile.js. --Vriullop (talk) 12:13, 17 October 2017 (UTC)


In what module is the code that shows transcriptions automatically when writing a non-latin scripted word in {{m}} or {{l}} etc.? We intend to use it at sv.wikt.Jonteemil (talk) 21:00, 17 October 2017 (UTC)

The code that handles these templates is in Module:links, but this module calls on a function in Module:languages to create a transliteration, where it gets forwarded to the language's transliteration module. Different languages have different transliteration modules. —Rua (mew) 21:02, 17 October 2017 (UTC)
See Category:Transliteration modules for a full list of the modules. The Language data modules specify which module is used by which language. — Eru·tuon 21:26, 17 October 2017 (UTC)
@Erutuon Thank you!Jonteemil (talk) 23:20, 17 October 2017 (UTC)

Memory issues[edit]

The page e doesn't check for redlinks and it uses {{t-simple}}. Despite that, it's still running out of memory before it gets to the end. What's the next step to fix this? —Μετάknowledgediscuss/deeds 06:05, 20 October 2017 (UTC)

It barely has any translations so that's not the problem. One possibility is splitting the page into language subpages (this is not currently possible, since many templates rely on the page name). DTLHS (talk) 06:08, 20 October 2017 (UTC)
Commenting out {{R:M&A}} frees up enough memory (~5 MB) to temporarily postpone the problem. It's odd that e failed but a doesn't. e has fewer languages (69) than a (99), transcludes fewer modules (94 vs. 150), and is shorter in terms of bytes. (And it's not at the beginning of the alphabet.) Unfortunately, there's no way to look at the memory usage of each module that is transcluded. I do think removing all the alphabet navigation templates would help. @Rua advocates getting rid of letter entries altogether, which would help even more. — Eru·tuon 09:32, 20 October 2017 (UTC)
I have managed to free up 7% of the Lua memory usage and a more than double as much significant amount of CPU usage i.e. page loading time by on one hand removing {{gloss}}, {{sense}}, {{qualifier}}, {{also}}, which has removed the most memory, and removing clutterings links of words like “and”, “his”, “but” on the other hand, which helped the CPU usage. Note that {{also}} takes 1 MB Lua memory while it is not even needed as on the translingual sections there are always the variants listed; thus I judge that the usage of {{also}} should be removed in letter pages. Palaestrator verborum (loquier) 11:02, 20 October 2017 (UTC)
I suggest removing all the "letter" entries and putting them in an appendix, leaving only the real words. —Rua (mew) 11:44, 20 October 2017 (UTC)
Would we have a clear link to this appendix from the single-letter word entries, e.g. from I? Equinox 14:36, 20 October 2017 (UTC)
Of course. Preferably, the Translingual entry would contain a list of all languages that use the letter, with Appendix links. —Rua (mew) 15:30, 20 October 2017 (UTC)

Strange code points for IPA characters?[edit]

I've noticed a number of edits over the past year or so like this one, where the diff highlights changes to strings that look identical in both the before and after versions.

In that particular edit, I noticed that the change maintained a typo I'd made earlier, where I'd accidentally entered a double-g and didn't notice. So I opened the page in the editor to fix it, and hit Ctrl+F in my browser and entered gg. Chrome found nothing.

Closer inspection revealed that the diff changed out regular ASCII g at U+0067 for the IPA Extensions ɡ at U+0261.

  • What utility is there in making this change? The IPA Extensions glyph appears to be visually identical. However, it is impossible for me to enter using my US 101 keyboard layout.
  • How many other glyphs are there in use in Wiktionary IPA contexts that are visually identical to ASCII characters?
  • What objections does anyone have to using the standard ASCII characters? These are both easier to enter, and easier to search for.

Curious, ‑‑ Eiríkr Útlendi │Tala við mig 15:48, 20 October 2017 (UTC)

Addendum: U+0067 g and U+0261 ɡ are rendered distinctly in Chome when using a monospace font, such as when wrapped in <code> tags above or in the Editor view when configured to use a monospace font. However, when simply displayed on the page in Wiktionary's default font, they look the same to me: g vs. ɡ. ‑‑ Eiríkr Útlendi │Tala við mig 15:51, 20 October 2017 (UTC)
@Eirikr: As you noticed, g and ɡ are not visually identical in all fonts. If you paste them into a word processor like Microsoft Word and view them in Times New Roman, you'll see the difference. U+0261 is a valid letter of the IPA, U+0067 isn't, so we use U+0261 in IPA transcriptions here. It's no different from using Cyrillic А and Greek Α correctly even though they're both visually identical to Latin A. As for other IPA letters that can be mistaken for regular Latin letters, depending on your font, the IPA letter ɑ may look identical to a, the IPA letters ǀ and ǃ may look identical to the punctuation marks | and !, and the IPA letters ɛ, ɸ, and ʋ make look identical to the Greek letters ε, φ, and υ. —Aɴɢʀ (talk) 16:34, 20 October 2017 (UTC)
I understand the basic point. However, IPA characters are hard to input (I can't seem to find U+0261 in the IPA and enPR quick-insert list in the Editor view), and graphically ambiguous. As noted on the WP page for the voiced velar stop /ɡ/, the regular "g" coded by U+0067 is an acceptable alternative that is visually identical in some fonts, and on some systems, U+0261 confusingly appears as something closer to ɣ (gamma).
Which brings me back to my first question: is there utility in using U+0261? I.e., is it useful? Or is this glyph technically correct, at the hazard of introducing more user confusion and processing difficulties? ‑‑ Eiríkr Útlendi │Tala við mig 19:27, 20 October 2017 (UTC)
PS: Please note that I am not arguing that U+0261 is not useful -- I am looking for reasoned input on the pros and cons, with a focus on usefulness versus risks. ‑‑ Eiríkr Útlendi │Tala við mig 19:31, 20 October 2017 (UTC)
U+0261 is in the "IPA and enPR" quick-insert list toward the end of the "Pulmonic consonants" section, after ɧ and before ɫ. The templates {{x2i}} and {{X2IPA}} make inputting easy because they let you type XSAMPA characters (all of which are simple ASCII characters) and get IPA characters output. The pros to using U+0261 in my opinion are (1) it's the correct character and (2) it's the character people will be expecting us to use. U+0067 is an acceptable alternative when it appears as an open-tail g (if you're writing a book in a font where U+0067 is open-tail, no one is going to notice, let alone, complain, if you use U+0067 to indicate a voiced velar stop), but is at best grudgingly accepted by phoneticians (less grudgingly by phonologists) when it appears as a loop-tail g. And if we were to switch over to using U+0067 consistently, I can almost guarantee you we would get complaints from know-it-all newbies and occasional editors saying that we're using the wrong character – and attempts from them to correct the character back to U+0261, but only sporadically in some entries and not others, leading to an inconsistent mess – and we would have to have this whole conversation over and over again. —Aɴɢʀ (talk) 20:01, 20 October 2017 (UTC)
There is an IPA keyboard layout that is pending for merge in xkeyboard-config, i.e. all keyboard layouts of free desktop, @Eirikr. The creator has also posted it on GithubGist so one can use it pre-release. It does also include the ASCII g though because the rest of the first level key points are ASCII-compatible, so you have to press Shift+Caps+g to explicitly write ɡ U+0261 LATIN SMALL LETTER SCRIPT G with that layout selected. If you have not switched to Linux yet, such custom layouts are surely a reason to do. I have not thought about the usage of it here yet, but for me it is a matter of course to use Linux as an editor here, and you might be interested because of the different input methods there, writing Japanese. Palaestrator verborum (loquier) 21:03, 20 October 2017 (UTC)
There's also an option to change to an IPA keyboard (SIL or X-SAMPA) right on the wiki editor (right bottom corner). There are various other keyboards you can install even if you don't use Linux. SIL's IPA Unicode Keyboards are good ones. — justin(r)leung (t...) | c=› } 21:48, 20 October 2017 (UTC)
@Eirikr: It is the same situation as the difference between and : it depends on what fonts you use and who you talk to :) —suzukaze (tc) 21:57, 20 October 2017 (UTC)
Thank you all for your input, and for your suggested workarounds.
  • @Aɴɢʀ, thank you for where to look -- I saw the version of U+0261 with the over-circle, but in scanning the list, I didn't see the other plain one further along. Any insight into how that list is ordered? I'm scratching my head about that.  :) And thanks too for the template pointers, I didn't know those even existed.
  • @Palaestrator verborum, justin(r)leung, I've used Linux in the past, and for a while I was on Mac, but due to work needs, I'm on Win 10 anymore. FWIW, I've found WinCompose (https://github.com/samhocevar/wincompose) an indispensable tool for multi-script support outside of the usual MS keyboard or IME framework. I will have to peruse the config (based on the old XOrg compose files) to see if the IPA extensions are lurking in there somewhere; if not, I'll add them to my setup.
  • @suzukaze, やはり。(^^)
  • @Anyone -- what font would be best for the default EN Wiktionary rendered display to differentiate these glyphs? Or would changing that be enough of a PITA that we shouldn't bother? ‑‑ Eiríkr Útlendi │Tala við mig 23:19, 20 October 2017 (UTC)


I realize it's been deprecated and even nominated for deletion, but Template:def is producing random numbers at the ends of definitions (see here for an example). As long as it's still being used, it should at least work properly. Esszet (talk) 03:16, 21 October 2017 (UTC)

The number is the count of links (I don't know why it's counting the links). DTLHS (talk) 03:20, 21 October 2017 (UTC)
@Erutuon, Rua are the only people to have edited the module recently. —Μετάknowledgediscuss/deeds 03:47, 21 October 2017 (UTC)
Fixed. It was because of the string.gsub function, which returns the text as well as the number of substitutions. — Eru·tuon 03:55, 21 October 2017 (UTC)

Why can't we do one-click rollback for page moves?[edit]

See e.g. vandalism by User:Lopunny (who did it under another name recently too). Equinox 20:37, 21 October 2017 (UTC)

Not just recently: they've been doing it for a long time, all the while leaving clues so we'll know it's the same person. I think they want to be seen as the merry trickster leaving the stodgy old authority figure shaking his fist and sputtering "Curse you, Masked Bandit! Oooh, if I ever get my hands on you...".
Of course, the shows they're imitating have better writers, and the authority figures in them are cartoonish buffoons designed to set up the gags rather than unpaid volunteers who are just trying to help out.
I find the best approach is to block them, quietly clean up the mess and forget about them until their next lame attempt- it's not possible to shut them down completely, and making a big deal out of it just feeds into their mental Wile E. Coyote/Roadrunner narrative. Low-key strategies like abuse filters that slow them down and increase the hassle seem to work better- the Tar Baby vs. Brer Rabbit approach. Chuck Entz (talk) 22:36, 21 October 2017 (UTC)

Cross-references should default to current language[edit]

I'll pick an example of a problem I've seen many times in multiple languages.

The Swedish word kämpa has kamp in the "Related words" subsection. The link text is kamp rather than kamp#Swedish so it goes to the top of the kamp page. I have to scroll down to find the the Swedish word that was meant to be linked.

Is Wiktionary software smart enough to know a link is in a Derived terms or Related terms section and add the current language if it is missing? Alternatively, are there any bots smart enough to fix up all the missing languages in cross-references? (But not in definitions, because those tend to link to English words.) Vox Sciurorum (talk) 00:29, 22 October 2017 (UTC)

If you write {{l|sv|kamp}} instead of [[kamp]] then it will work. It would be nicer to default the simple-style links to the current language as you suggest, but I don't believe it is possible. Equinox 00:37, 22 October 2017 (UTC)
I think @Rua once did a bot run to fix bare links in derived / related terms sections- maybe she would do it again. DTLHS (talk) 00:39, 22 October 2017 (UTC)
@DTLHS: The bot messed up all plainlinked translingual terms that it touched, inasmuch as it made the links orange for those that have the Orange links box checked on the gadgets page. The simplistic logic was apparently that any plainlinked terms ("term") not in the etymology section would be reformatted as {{l|langcode|term}}. DCDuring (talk) 20:29, 27 October 2017 (UTC)
I imagine JavaScript could make links in derived or related terms sections (or synonyms, antonyms) go to the language of the first level-2 header above them. But that would be done in your browser, not the Wiktionary server. — Eru·tuon 01:33, 22 October 2017 (UTC)

Fixed kämpa as Equinox suggested, but there's bound to be loads more like it. DonnanZ (talk) 18:51, 27 October 2017 (UTC)

Bot request: removing DEFAULTSORT from Greek entries[edit]

It seems that Greek-alphabet entries at one point needed to use DEFAULTSORT to ensure that vowels with a tonos (a mark that shows which syllable is stressed) are treated the same as unmarked vowels for the purposes of alphabetical sorting. Apparently this is no longer required. Many Greek entries still have the DEFAULTSORT code included which should be removed: an ideal job for a bot.

A possible algorithm to use:

  • For each Greek-language page (it should be sufficient to trawl through all pages listed in Category:Greek language and all subcategories):
  • Check whether the page includes {{DEFAULTSORT:...}} (ignoring capitalisation). If it does:
  • Work out what the page name would be without diacritical marks. A sample substitution table of characters: (I was initially going for just the tonos, but why not cover everything, eh?)
With mark Without mark With mark Without mark
ά ἀ ἁ ἂ ἃ ἄ ἅ ἆ ἇ ὰ ά ᾀ ᾁ ᾂ ᾃ ᾄ ᾅ ᾆ ᾇ ᾰ ᾱ ᾲ ᾳ ᾴ ᾶ ᾷ α Ά Ἀ Ἁ Ἂ Ἃ Ἄ Ἅ Ἆ Ἇ ᾈ ᾉ ᾊ ᾋ ᾌ ᾍ ᾎ ᾏ Ᾰ Ᾱ Ὰ Ά ᾼ Α
έ ἐ ἑ ἒ ἓ ἔ ἕ ὲ έ ε Έ Ἐ Ἑ Ἒ Ἓ Ἔ Ἕ Ὲ Έ Ε
ή ἠ ἡ ἢ ἣ ἤ ἥ ἦ ἧ ὴ ή ᾐ ᾑ ᾒ ᾓ ᾔ ᾕ ᾖ ᾗ ῂ ῃ ῄ ῆ ῇ η Ή Ἠ Ἡ Ἢ Ἣ Ἤ Ἥ Ἦ Ἧ ᾘ ᾙ ᾚ ᾛ ᾜ ᾝ ᾞ ᾟ Ὴ Ή ῌ Η
ί ϊ ΐ ἰ ἱ ἲ ἳ ἴ ἵ ἶ ἷ ὶ ί ῐ ῑ ῒ ΐ ῖ ῗ ι Ί Ϊ Ἰ Ἱ Ἲ Ἳ Ἴ Ἵ Ἶ Ἷ Ῐ Ῑ Ὶ Ί Ι
ό ὀ ὁ ὂ ὃ ὄ ὅ ὸ ό ο Ό Ὀ Ὁ Ὂ Ὃ Ὄ Ὅ Ὸ Ό Ο
ῤ ῥ ρ Ρ
ύ ϋ ΰ ὐ ὑ ὒ ὓ ὔ ὕ ὖ ὗ ὺ ύ ῠ ῡ ῢ ΰ ῦ ῧ υ Ύ Ϋ Ὑ Ὓ Ὕ Ὗ Ῠ Ῡ Ὺ Ύ Υ
ώ ὠ ὡ ὢ ὣ ὤ ὥ ὦ ὧ ὼ ώ ᾠ ᾡ ᾢ ᾣ ᾤ ᾥ ᾦ ᾧ ῲ ῳ ῴ ῶ ῷ ω Ώ Ὠ Ὡ Ὢ Ὣ Ὤ Ὥ Ὦ Ὧ ᾨ ᾩ ᾪ ᾫ ᾬ ᾭ ᾮ ᾯ Ὼ Ώ ῼ Ω
  • If the contents of the {{DEFAULTSORT:...}} code matches the page name without marks (ignoring capitalisation):
  • Remove the {{DEFAULTSORT:...}} code entirely. If it's the only thing on that line, remove that line entirely.
  • Allow for line breaks: if there is a blank line both before and after the {{DEFAULTSORT:...}} then collapse these down into a single blank line.

I don't know, but it's possible that the same issue affects pages in other scripts. So an alternative might be to extend the mapping table above to cover lots more scripts, and to instead search for all pages containing {{DEFAULTSORT:...}}. Extending the bot for other scripts can be done as a later enhancement.

Thanks! -Stelio (talk) 20:46, 23 October 2017 (UTC)

@Stelio: It should be fine to remove the DEFAULTSORT in all cases, because sortkeys are automatically generated by the makeSortKey function in Module:languages. (If there are any errors in that function or the data that it uses, they can be fixed in the appropriate module, rather than on the page where the error occurs.) However, if there are any bare categories ([[Category:Greek autological terms]]), they will have to be converted to the corresponding category template ({{cln|el|autological terms}}), or the sortkey will be the unmodified root page name. I believe @DTLHS has a category-templatizing script. — Eru·tuon 21:40, 23 October 2017 (UTC)
I do. @Saltmarsh are you OK with this? DTLHS (talk) 21:43, 23 October 2017 (UTC)
I have occasionally/recently added DEFAULTSORT to overcome the problem summed up in the 1st sentence above - if automatic sorting in category's is achieved I see no reason why that line shouldn't be removed from entries. — Saltmarsh. 05:09, 24 October 2017 (UTC)

Thanks @NadandoBot, DTLHS for fulfilling this request. :-) -Stelio (talk) 08:54, 30 October 2017 (UTC)

Translation tables are invalid HTML[edit]

Our translation tables are invalid HTML 5 because they have dl (definition list) elements that contain dd (definition) but no dt (associated term being defined). Is this a simple fix? Equinox 12:11, 24 October 2017 (UTC)

This is a problem with Wikicode rather than with our translation tables. Wikicode allows you to use dd without dt, and everyone uses dd to indent their posts, like I did. We could disallow the use of : for indentation, but enforcing it would be like herding cats. —Rua (mew) 14:29, 24 October 2017 (UTC)

Pharyngealized mark[edit]

Whenever I use the pharyngealization mark ˤ in شنطة, I get an erroneous error message saying invalid IPA characters (ˤ), replace ˤ with ˁ when I demostrate a preview of my edit. I don't get it, I'm using the correct symbol, why do I get that notice? The error could be from module:IPA/templates. --Mahmudmasri (talk) 14:13, 25 October 2017 (UTC)

You're not using the correct symbol. U+02C1 (MODIFIER LETTER REVERSED GLOTTAL STOP) is different from U+02E4 (MODIFIER LETTER SMALL REVERSED GLOTTAL STOP). Note that this error will only show up in the preview- you can still save the page. DTLHS (talk) 16:07, 25 October 2017 (UTC)
See Module:IPA/data/symbols for the symbols that are considered valid and the suggestions that are displayed when one uses a symbol that isn't in the list ("suggestions"). As DTLHS says, sometimes the symbols look identical but are actually different codepoints. But it's best to choose one codepoint so that transcriptions are consistent (and you can search for a codepoint and find all the instances of a particular IPA symbol). There was a previous discussion on the reasons for choosing the one we did. — Eru·tuon 18:35, 25 October 2017 (UTC)
It should be noted that we have this character the wrong way around; U+02E4 is apparently the correct IPA symbol. I posted this in the previous discussion you linked, but perhaps too late for anyone to see it: According to Unicode, U+02C1 is a ‘typographical alternate for U+02BF’, i.e. ʿ, whereas U+02E4 canonically decomposes to a superscript U+0295, i.e. ʕ. The official IPA website also has a link labeled ‘IPA and Unicode’ that leads here, where U+02E4 is given as the hex code for ‘pharyngealized’. — Vorziblix (talk · contribs) 21:14, 25 October 2017 (UTC)
  • Regardless of which is correct, shouldn't we have {{IPA}} convert the wrong ones to the right ones automatically instead? Similarly we will always get people (including me, when I forget) putting g in IPA rather than the proper ɡ. But it wouldn't be hard to fix that without bothering the editor. —Μετάknowledgediscuss/deeds 23:04, 25 October 2017 (UTC)
What do you mean "convert automatically"? The template can't change what the user types. And I already periodically fix common IPA character mistakes with my bot. DTLHS (talk) 23:08, 25 October 2017 (UTC)
What might be useful is to distinguish characters that are indubitably wrong for IPA, versus those (such as g and ˤ) that are simply easy to confuse with similar looking characters, and only display the error message for the former. DTLHS (talk) 23:18, 25 October 2017 (UTC)
@Metaknowledge: Module:IPA could display the correct characters, but the wrong ones would still be there in the wikitext.
@DTLHS: I like the idea of restricting the error message to visually distinct characters (like δ and ð), and letting bots handle those that are identical in many fonts. — Eru·tuon 23:37, 25 October 2017 (UTC)
Yes, that's what I was talking about. Who cares what's in the wikitext — now that the search looks at template output, readers would only see the correct characters if we did that (and we could still do bot runs to clean up the wikitext every so often). —Μετάknowledgediscuss/deeds 18:35, 26 October 2017 (UTC)
Of course, what's visually distinct is a matter of fonts, so we have no control over that. —Rua (mew) 18:37, 26 October 2017 (UTC)
Why not two-staged? Some things can be displayed as errors, others give warnings. A classic. And I would like to see a warning for using “g“ from ASCII in IPA sections, as I can easily type in “ɡ” from the IPA extensions. Palaestrator verborum (loquier) 20:32, 26 October 2017 (UTC)

Adding HSK grade to entries[edit]

Just as Kanji entries do, the HSK level of the words' meanings could also be easily added automatically. Apparently, some words do have such a tag (see 不僅). --Backinstadiums (talk) 08:37, 27 October 2017 (UTC)

@Backinstadiums: I think we have been removing these, as the Chinese entries is not just for Mandarin. We've been categorizing the entries with {{zh-cat}}, though. — justin(r)leung (t...) | c=› } 00:25, 30 October 2017 (UTC)
@Justinrleung: Thanks for replying. I do not see what the problem with having them really is. Could you elaborate a bit please? --Backinstadiums (talk) 02:23, 30 October 2017 (UTC)
@Backinstadiums: It might be confused by users that the term is only used in Mandarin when it can also be used in other varieties of Chinese. — justin(r)leung (t...) | c=› } 02:24, 30 October 2017 (UTC)
@Justinrleung: just for that? As many tags do, a link would redirect to the Appendix where the precise info. is developed. Lexicographically, the improvement that having them entails is greater than the unlikely confusion you mention. That same consideration doesn't seem to have been taken into account for the several dialects of Japanese. --Backinstadiums (talk) 02:38, 30 October 2017 (UTC)
@Backinstadiums: For HSK, it is labelled as "X Mandarin", which makes it look like it's only Mandarin. Japanese would not have this problem, since it's not "X Tokyo" or something like that. This is the problem that I see, but I can't recall if it was the original reason for removing these tags @Wyang, Atitarev, Tooironic. — justin(r)leung (t...) | c=› } 02:46, 30 October 2017 (UTC)
@Justinrleung: The official terminology, "HSK" plus number, is unambiguous --Backinstadiums (talk) 02:59, 30 October 2017 (UTC)
@Backinstadiums: OK, but I don't think HSK levels can be assigned to specific definitions. The HSK doesn't publish definitions with the word lists. — justin(r)leung (t...) | c=› } 03:07, 30 October 2017 (UTC)
I support removing the labels from the code and handling these centrally and automatically using data modules. It will be much easier to maintain and update and is resistant to errors. Perhaps {{zh-forms}} is a good carrier (not necessarily displayer) for such information. Maybe the HSK category should be made more obvious, but I can't think of a good place to put it. Directly underneath the language headers and to the right may work, with some JS magic. Wyang (talk) 06:09, 30 October 2017 (UTC)
@Wyang: Right under the "Chinese" header wuold be O.K. --Backinstadiums (talk) 14:33, 30 October 2017 (UTC)
@Wyang: Is it feasible then? Do you know specifically where I have to request it? I will gladly help in whichever I can --Backinstadiums (talk) 14:34, 31 October 2017 (UTC)
@Backinstadiums The above was only my envisagement - I don't know if it's feasible as my JavaScript is poor. You can request it here or on a more specific page, but you need to ping all the Chinese editors for their opinions on this change first. Wyang (talk) 09:27, 1 November 2017 (UTC)
@Wyang: How can I find out who the Chinese editors are? Can I ping them in this very same post? --Backinstadiums (talk) 09:48, 1 November 2017 (UTC)
@Backinstadiums Atitarev, Bumm13, Dine2016, Dokurrat, Hongthay, Jamesjiao, Justinrleung, kc_kennylau, Mar vin kaiser, Suzukaze-c, Tooironic. You can request it on any page. I'd suggest you make sure the proposed format is technically feasible, and that there is someone willing to implement it, though. Wyang (talk) 10:06, 1 November 2017 (UTC)

Template:term has been successfully deprecated[edit]

Good news, everyone! Thanks chiefly to Daniel Carrero (though of course many people helped!) {{term}} is no longer used at all in the main, Appendix, or Reconstruction namespaces, or on instruction pages in the Wiktionary namespace. It's only used on talk pages and in archives of old discussions in Wiktionary namespace. I've added it to CAT:Successfully deprecated templates and marked it with class="deprecated" so uses of it appear green. @Rua: could you (or anyone else who's good at editing modules) edit Module:term cleanup so it no longer sorts usages according to script? That seems unnecessary now; sorting according to namespace is probably sufficient, and even that might not really be necessary. —Aɴɢʀ (talk) 16:35, 27 October 2017 (UTC)

I think we could just delete the module altogether? —Rua (mew) 16:50, 27 October 2017 (UTC)
Fine with me if there are no objections from anyone else. —Aɴɢʀ (talk) 18:12, 27 October 2017 (UTC)
Neat! Now I'm going to start removing {{term}} from other namespaces. Project page: User:Daniel Carrero/term cleanup.
Please don't delete the module until I'm done (assuming the module categorizes pages in subcategories of Cat:term cleanup). --Daniel Carrero (talk) 00:55, 28 October 2017 (UTC)
@Daniel Carrero: Unfortunately, I've discovered there are still around 6 dozen mainspace entries in Special:WhatLinksHere/Template:term. For some reason they're not being categorized in CAT:term cleanup or any of its subentries. They're all fairly recent creations and they all use |lang=; perhaps that's the reason. —Aɴɢʀ (talk) 01:34, 28 October 2017 (UTC)
I believe the reason you said is correct. Fortunately, it seems easy to change all instances of {{term|foo|lang=zz}} into {{m|zz|foo}} by bot. I believe Rua did this once. Can someone use a bot to do that again, perhaps for all namespaces, not just the main namespace? (again, just the instances of {{term}} that already have the language code) --Daniel Carrero (talk) 01:57, 28 October 2017 (UTC)
Why can't you just fix the tracking code. DTLHS (talk) 01:59, 28 October 2017 (UTC)
Because {{term}} is deprecated as per Wiktionary:Votes/2015-11/term → m; context → label; usex → ux and related discussions. --Daniel Carrero (talk) 02:19, 28 October 2017 (UTC)
I dealt with the remaining mainspace uses of {{term}} with AWB. — Eru·tuon 03:35, 28 October 2017 (UTC)
Thank you. --Daniel Carrero (talk) 04:24, 28 October 2017 (UTC)

I would like it if any mainspace pages using {{term}} were categorized into CAT:Pages using deprecated templates, but if I simply <includeonly> the category name into the page, it will categorize all pages transcluding {{term}}. How do I restrict it so only mainspace pages (or better yet, mainspace, Appendix: and Reconstruction:) are categorized, while talk pages and the like aren't? —Aɴɢʀ (talk) 16:37, 30 October 2017 (UTC)

Use {{categorize}}. —Rua (mew) 16:51, 30 October 2017 (UTC)
@Rua: Can I use und as the language code if the person who added {{term}} hasn't specified a language using |lang=? —Aɴɢʀ (talk) 18:36, 30 October 2017 (UTC)
Oh right, that annoying issue. You can also use {{#switch:{{NAMESPACE}}||Appendix|Reconstruction=[[Category:something]]}}Rua (mew) 18:54, 30 October 2017 (UTC)
What I did was {{categorize|{{{lang|und}}}|Pages using deprecated templates}} and when I tested it in preview mode it seemed to work okay. Come to think of it, simply {{categorize|und|Pages using deprecated templates}} ought to work too, since there's no language-specific categorization going on anyway. —Aɴɢʀ (talk) 19:00, 30 October 2017 (UTC)
@Rua: I must have done something wrong, because CAT:Pages using deprecated templates is now all full of talk pages. —Aɴɢʀ (talk) 21:57, 30 October 2017 (UTC)
I've tried again using #switch: as you recommended and that seems to work. I suppose it'll take a few hours for the category to empty again. —Aɴɢʀ (talk) 22:09, 30 October 2017 (UTC)
I wonder why it went wrong. It's not supposed to do that. —Rua (mew) 22:16, 30 October 2017 (UTC)
It's because Talk is in the list of namespaces in which Module:utilities adds categories. See Module:utilities/data. Perhaps there's some template that uses Module:utilities to add categories in the Talk namespace, and hence it's in the list. For many, that's not the case. For instance, etymology templates use the module to add categories, but should only add categories in entry namespaces. — Eru·tuon 23:54, 30 October 2017 (UTC)
It looks like it was added by User:Daniel Carrero in diff. That should be undone as it defeats the point. —Rua (mew) 11:58, 31 October 2017 (UTC)

{{t-needed}} and Hebrew[edit]

{{t-needed}} doesn't work with Hebrew in the translation adder because it replaces "-" with "־", resulting in {{t־needed}}. --Anatoli T. (обсудить/вклад) 10:05, 29 October 2017 (UTC)

@JohnC5, Dixtosa, Giorgi Eufshi, who have edited MediaWiki:Gadget-TranslationAdder.js recently. In the mean time, you can use {{trreq}}, which produces the same result but avoids the error for Hebrew. —Μετάknowledgediscuss/deeds 18:53, 30 October 2017 (UTC)


Is there a way to get a notification everytime an edit is done to a main space entry? As when someone posts something on my talk page I mean. --2A02:2788:A4:F44:F0B0:D1E7:E066:EEF4 16:30, 31 October 2017 (UTC)

Logged in users have the preference option "Email me when a page or a file on my watchlist is changed." DTLHS (talk) 17:07, 31 October 2017 (UTC)
Oh, thanks. I can make sure nobody's encroaching on my turf then. --2A02:2788:A4:F44:F0B0:D1E7:E066:EEF4 17:10, 31 October 2017 (UTC)
@DTLHS: there's no way to get emailed for specific pages only though? --2A02:2788:A4:F44:F0B0:D1E7:E066:EEF4 17:12, 31 October 2017 (UTC)
What do you mean by specific? You can specify any page in your watchlist. DTLHS (talk) 17:13, 31 October 2017 (UTC)
@DTLHS: I mean, will I get emailed everytime any page on my watchlist is edited, or can I choose among my watchlist the ones I want email notifications about? IOW, once I enable the email notifications, do I have to remove a page from my watchlist if I don't want to get emailed about that specific entry? --2A02:2788:A4:F44:F0B0:D1E7:E066:EEF4 17:19, 31 October 2017 (UTC)
The former. You could set up an email filter, or create a separate account with a watchlist of only the pages you want notifications about. DTLHS (talk) 17:21, 31 October 2017 (UTC)

November 2017

Why spell out the name of the month in templates?[edit]

I note that {{rft}} has a required parameter "m" with compels the name of the month to be spelled out. Why not permit the number of the month and a three-letter abbreviation? Too hard?

I further note that this template (and other request templates?) seem to be used less since 2016 when the number of required parameters increased. That means that someone looking at the entry would not be aware of the discussion. DCDuring (talk) 12:24, 1 November 2017 (UTC)

Using numbers is potentially better for localisation too. (Heh, I doubt this template will have to support the Hijri calendar or what not, but who knows?) Equinox 19:18, 1 November 2017 (UTC)


I'd like to get rid of the extremely annoying full stop that is currently added automatically by {{back-form}}, and of the {{{nodot}}} parameter which it entails. There are currently fewer than a thousand transclusions; would it be possible to clean them up afterwards? Or could someone add me to the AWB list and I'll try and take care of it myself? --Barytonesis (talk) 14:19, 1 November 2017 (UTC)

nodot=yes has always seemed silly to me. I would rather type a single . where I need it than have to explicitly say that I don't want one by typing an entire parameter. Equinox 14:35, 1 November 2017 (UTC)
@Equinox: exactly. --Barytonesis (talk) 15:47, 1 November 2017 (UTC)
+1 —suzukaze (tc) 16:04, 3 November 2017 (UTC)
Go for it. I can help with cleanup. – Jberkel (talk) 19:23, 6 November 2017 (UTC)
Well, if we're gonna do this manually, we might as well remove the default text altogether (as we're currently doing for {{bor}}, per Wiktionary:Votes/2017-06/borrowing, borrowed). What do you think? --Barytonesis (talk) 20:47, 6 November 2017 (UTC)
I think they're very different cases. The default text should be kept on {{back-formation}}. But the period should be removed from {{deftempboiler}} as well and all templates made from it. —Aɴɢʀ (talk) 21:08, 6 November 2017 (UTC)
[2]... Well, I'd better get to work! --Barytonesis (talk) 09:33, 7 November 2017 (UTC)
Form-of templates wrap their contents in a span with a special class. Are we ok with the dot itself being outside the span? —Rua (mew) 17:03, 7 November 2017 (UTC)

Save Changes versus Publish Changes[edit]

When editing a page, the button to save your work says "Publish changes". The text immediately above this says, "By clicking the “Save Page” button...". These should be consistent by changing the latter Special Message to match the former. -Stelio (talk) 15:24, 1 November 2017 (UTC)

It was changed to "Publish changes" fairly recently. Obviously someone forgot to change the wording above it. DonnanZ (talk) 16:23, 1 November 2017 (UTC)
Super; thank you very much! :-) -Stelio (talk) 16:52, 1 November 2017 (UTC)

Interestingly, this hasn't worked (or at least, not for me). I know that "wikimedia-copyrightwarning" is the correct Special Message by applying the "uselang=qqx" trick to display the underlying field names for messages. Forcing hard refreshes in my browser doesn't change what I see. I tried purging the message page as well, but to no avail. -Stelio (talk) 10:32, 6 November 2017 (UTC)

Idea for an abuse filter[edit]

If there is a sequence of the form {{...}} on a single line, and a user's edit inserts a line break somewhere in the central ... portion (which might be anything), that's almost always vandalism. Heuristic: this kind of vandalism tends to be rather "small" (i.e. page size doesn't change much, maybe a few chars of gibberish added). This could be expressed with a regex, if anyone can be bothered. See e.g. [3]. Equinox 20:16, 1 November 2017 (UTC)

Yes, these can go undetected. I think I have found one or two cases before by checking my watchlist. DonnanZ (talk) 00:46, 2 November 2017 (UTC)
Is this really usually vandalism? I insert line breaks into template calls all the time. Sometimes {{der3}} will have a great long list of derived terms all written together as a block, and I'll add line breaks to make the individual entries easier to read. For the edit linked to above, I'd say what's noticeable is the deletion of the closing }}, not the insertion of a line break. —Aɴɢʀ (talk) 12:50, 2 November 2017 (UTC)

Ideas for a more advanced WT:ACCEL[edit]

@Dixtosa At the moment, the WT:ACCEL script makes use of the preload function to specify text that should be placed in the edit window as soon as the edit page is loaded. This allows you to quickly check and save the page without having to put in all the contents. Obviously it's a very useful tool, but it has drawbacks. A major drawback is that it only works if the page doesn't exist yet. If the page already exists (the link is blue/yellow) then nothing happens, and you have to put the contents in manually. That's not really ideal. A bot can do better, since it can parse the wikitext and figure out where to insert a new language section (for example diff).

This restriction is somewhat strange, though. A bot is just parsing code with a programming language, and WT:ACCEL is implemented in JavaScript, a programming language that is also capable of parsing code. There's nothing in principle that would disallow JavaScript from modifying wikicode, if it received the old wikicode (WT:EDIT does this in order to edit the translations). Of course, when you view an entry with blue/yellow links, the wikicode of all those other pages is not on the current page. There are ways to retrieve the wikicode of a page but this takes time (it's essentially another page request), and doing this for every single blue/yellow link is obviously not going to be feasible. On the other hand, the wiki software helpfully loads the page contents when you click the edit button, so if a script were to be made to automatically modify the wikicode in the edit window, that should work just fine. Essentially, this is what the preload facility that we currently use already does, except we'd be rolling our own custom version that does more.

Currently, it is the page containing the red/green link that generates the new contents, and this new contents is then appended as a new parameter onto the existing link URL. When you click the link to create the new page, the preload facility picks up on this URL parameter, and puts the text into the edit window. In practice, this means that every time a page is loaded, the ACCEL script goes through all the links, generates the new entry code, and modifies the URL, each time for every link. If our new version of ACCEL is going to run on the edit page instead, it makes a lot more sense to generate the page contents at that point, and not on the page containing the link. The linking page will load faster then, since it's not going to be busy generating content and modifying links each time someone views the page. The information will still need to be passed on via the URL in some way, but that could be done without any JS at all in theory. —Rua (mew) 15:59, 3 November 2017 (UTC)

I've created a partial version of the new script at User:Rua/Gadget-AcceleratedFormCreation.js. It differs from the original script in the following points:

At the moment, the script doesn't actually produce any new results. It still doesn't work for links to already-existing pages. When you click on a blue link, it takes you to that page, it doesn't take you to an edit window. It would probably be undesirable to turn such view-existing-page links into edit-existing-page links. Perhaps the script can be made to interface with the OrangeLinks gadget, so that it takes you to an edit page if the link is orange, but not when it's blue. I'm not sure how that would be done, though.

Because the new entry content is created only on editing the page, and only for that one page, we can do more time-consuming or resource-intensive things than we could otherwise. An interesting idea would be to convert the creation rules into a module, and have the script invoke the module. The module would then return the new text of the page, which the script would then place in the edit window, ready to be saved. This would allow much easier editing of creation rules and the addition of new ones, because people on Wiktionary are generally better with Lua than they are with JS, and you don't need to be an admin to edit modules. —Rua (mew) 19:55, 3 November 2017 (UTC)

I am glad you are looking into improving this great tool, and I think you have some good ideas for enhancements. One obvious problem for modifying existing pages is that, in order for the link to know if the target needs to be modified, it has to actually load the entire page. For a page with dozens of such links you could be loading dozens of pages with each page load, which can slow down the user as well as create quite a lot of overhead for the WMF servers. That doesn't mean that it shouldn't be done, it just complicates the issue. Have you thought about any way to avoid or minimize the amount of data loaded? The second step of actually inserting the text isn't as bad, since the API provides section editing which will limit the size of the creation URL considerably even on a large page. - TheDaveRoss 20:01, 3 November 2017 (UTC)
@TheDaveRoss I mentioned the OrangeLinks gadget, which turns links orange (more like yellow to me) when the language section in the fragment # of the URL is not present on the page. I don't know how it's implemented or if it's very inefficient, but at the very least if we already have that gadget, we have the information we need. An possible alternative approach is to not modify the links themselves, but to add an extra little link to the right of them, which takes you to the edit page but with a new entry added to the existing wikicode already. People would probably find that ugly, though. —Rua (mew) 20:14, 3 November 2017 (UTC)
Yet another possibility might be to modify links to existing pages so that they include the acceleration information, but to take the user to view the page as they'd expect to be. The script will then run on that page, see if there is already a language section for that language, and if not, it will display a large friendly message suggesting that the user click a certain link to add the new entry. It adds an extra step to the process - you have to first view the page before you get the edit link - but at least it's a lot easier than having to manually type all the code. —Rua (mew) 20:18, 3 November 2017 (UTC)

The new script is now at least capable of inserting new language sections in existing pages, if you give it acceleration parameters on an existing page. However, because of the above issue, no such links are actually generated yet. —Rua (mew) 22:31, 3 November 2017 (UTC)

I have it working! Now, the script will pick up on accelerated orange links, and modify them into edit links. Then, on the edit page, the new section is correctly inserted among the existing sections. —Rua (mew) 00:22, 4 November 2017 (UTC)

@Rua: I made a form-sorting function in Lua here. It's quite fast, and it's pretty simple to generate the maps used for the sorting. What do you think? — Eru·tuon 22:15, 12 November 2017 (UTC)

I can't really figure out what it does. Sorting cases is not usually needed. What matters is sorting singular before plural. But really, the system should be as agnostic as possible, so it should be limited to something like "this column goes before that column". The makers of the table would include HTML code in the right places to ensure this. The difficulty I'm having is how to actually make such code work. It's really a JavaScript/DOM/JQuery problem. —Rua (mew) 22:25, 12 November 2017 (UTC)
@Rua: So, if you have a case–number pair, each case has a number that indicates its rank in relation to other cases (nominative 1, genitive 2, ...). Same for numbers (singular 1, plural 2). Each morphological category has a number that indicates its rank in relation to other morphological categories (number 1, case 2). These numbers are used to create a base 36 number (string). (The base could be lower at this point, since there aren't anywhere near 36 cases, numbers, or morphological categories in the examples I chose.) The ranking of the morphological categories determines the order of the digits. For nominative singular, the number is 11, for genitive singular 12; nominative plural 21, genitive plural 22. The digit for number comes before the digit for case, so that singular always appears before plural. These numbers can then be sorted using the less-than operator. These ranks are generated from arrays listing the cases and numbers, and the morphological categories, in the order in which they should appear.
I dunno, using the HTML seems so complicated to me. I like a sorting method where the sorting is very explicit so you can tell what the result should be. — Eru·tuon 22:50, 12 November 2017 (UTC)
But what happens when a form isn't in your list, or when it's not easily sortable relative to other forms, such as a comparative form or a participle? —Rua (mew) 22:58, 12 November 2017 (UTC)
Either create ad-hoc categories for them so that they can be assigned rankings, or just have the sorting function leave them in their original positions. I guess I need to find some new examples to adapt the function to. — Eru·tuon 23:32, 12 November 2017 (UTC)
Is it really necessary to make things this complicated, though? What I'd much prefer is for the relative ranking of forms to be indicated as part of the table wikicode. That way, the script can stay agnostic about what the forms actually are, and it doesn't need editing whenever someone comes up with a new kind of form. —Rua (mew) 23:42, 12 November 2017 (UTC)
What do you mean? A new data- attribute that specifies the form's relative position? Or something else? — Eru·tuon 00:00, 13 November 2017 (UTC)
Actually a column number is what I had in mind. —Rua (mew) 00:04, 13 November 2017 (UTC)
I didn't know that was a thing. Oh, do you mean grabbing the nth cell in each row? Or is there some other way? — Eru·tuon 01:51, 13 November 2017 (UTC)
Right now, the script iterates through all accelerated links in a page, in the order that they are present in the HTML, and stores them in that order. My idea was that, if the script encounters a link for which a column number is set, then rather than directly storing the link, it stores it in an array (successively numbered table in Lua terms), indexed by the specified column number. So all entries with column 1 get put together, and all entries with column 2, and so on. Of course the entries in this array must eventually be stored like the rest, so there must be something that says at some point "ok, we're done with these columns, let's store them". One such trigger is obvious: when a link is encountered that's not in the same table. This would occur when the iteration moves on to another inflection table; of course it should be considered separately from the first. A second trigger is when the iteration encounters a link in the same table that lacks a column number. Both of these triggers "reset" the columnisation and cause everything that's currently in the column arrays to be stored. The storing itself is of course done in the order of columns: column 1 first, then column 2, etc. One final trigger is when the iteration reaches the end and there's no more links. —Rua (mew) 12:05, 13 November 2017 (UTC)
I've added column numbers to Module:se-adjectives (down the bottom), to illustrate. Reading from top to bottom, row by row, you first encounter the attributive form. It has no column number, so it's stored in sequence as usual. Then you encounter the nominative singular, which is stored in the array at index 1. Then the nominative plural, stored at index 2. This alternating pattern continues until the essive form. The essive has no column number, which triggers the emptying out of all the links currently in the column array. All entries in column 1 are stored, then all entries in column 2. Then the iteration continues in HTML order, so the essive is stored. The final order will be: attr, nom_s, acc_s, gen_s, ill_s, loc_s, com_s, nom_p, acc_p, gen_p, ill_p, loc_p, com_p, ess. —Rua (mew) 12:20, 13 November 2017 (UTC)
I've added them to Module:se-verbs as well, to illustrate a more elaborate example. Here, there's 6 columns. The first section contains columns 1 to 3, then the second section contains 4 to 6. The second section can't be labelled 1 to 3 because there is nothing in between the two sections that would trigger reset/storage. So additional column numbers are used. —Rua (mew) 12:48, 13 November 2017 (UTC)
I've updated the script with the method I proposed above, and it works. In Northern Sami adjective inflection tables, the comitative singular comes before the locative plural in the generated URL, and therefore also in the generated entry. —Rua (mew) 16:41, 13 November 2017 (UTC)
@Rua: That does sound like it will work. I was curious how it would work when the ordered list of items is oriented differently (say in Latin verb tables, horizontally, vs. Latin noun tables, vertically), but it's clear to me how those cases will work out now. The noun table will have the column number attributes and the verb table will not (at least, for the finite forms). I think "column" could end up being a misnomer, if the items with a certain column number aren't actually in columns, but I don't have any examples. I still like the idea of clearly writing out the order rather than having it hidden in the HTML, but if it works, it works. — Eru·tuon 07:36, 17 November 2017 (UTC)

Found a fatal bug with the automatic Arabic transcriptions.[edit]

  1. If, in Arabic, the preposition لِ (li) is used in front of anything determined by ال (al-), the ا/ٱ () of the article disappears by rule of Arabic orthography.
  2. If, in Arabic, the determiner ال (al-) meets an alveolar, an assimilation occurs whereby the ل disappears in pronunciation but not in writing and the meeting alveolar is geminated, which is indicated in orthography by a shadda ـّ (--) over the character representing the geminated consonant.
  3. Now if لِ (li) is followed by ال (al-) and this by an alveolar, the templates on Wiktionary do not return a transcription.
    1. For an example, see the Qurʾān 3:14 quotation in قَنْطَرَ (qanṭara). The word لِلنَّاسِ is affected. In the page I have written the second lām ل with a sukun ـْ (-), but this is an orthographic error, as in the case of the determiner meeting an alveolar no sukun may be placed, and also the resulting transcription is wrong *“lilnnāsi” instead of “linnāsi”. If you go there and remove the sukun by a hit on backspace, you will see in the preview that the transcription is gone.
    2. I repeat the example here: لِلنَّاسِ versus لِلْنَّاسِ (lilnnāsi)
  4. It seems to me that a fix is possible, because pursuant to the High Arabic phonotactics there is no other case that in vocalized text there is an orthographic word beginning with لِ (li), diacritic-free ل (l) and a geminated alveolar (or any other consonant).
  5. Note that the displayings here of ـّ (--) and ـْ (-) are glitchy too. Palaestrator verborum (loquier) 23:07, 3 November 2017 (UTC)

@Palaestrator verborum: By "vocalized text", do you mean the Qur'an? what do you mean by High Arabic? --Backinstadiums (talk) 23:45, 3 November 2017 (UTC)

@Backinstadiums: I’d think that you have figured out this day already that there is a literary Arabic language which we conceptualize as the proper Arabic which has minute rules about allowed syllables and an unmistakeable system of orthographically representing its sounds, as is exemplified by the Qurʾān and as distinguishes it from Arabic dialects which all have different rules. Why do you only post questions instead of learning the grammar thoroughly? It should not take you more than two months, yet you only post questions since the creation of your account in November 2016 instead of making entries as you should be able to do if you can read Arabic. Palaestrator verborum (loquier) 00:15, 4 November 2017 (UTC)
@Palaestrator verborum: My grammar is still basic, since I've focused on vocabulary, yet I admit I don't like the material taken predominantly from Wehr's and Lane's. Furthermore, I have to learn how to edit properly, perhaps some JS, etc. I still do not understand what you mean by "there is no other case that in vocalized text..."--Backinstadiums (talk) 00:43, 4 November 2017 (UTC)
@Backinstadiums: It is my argument why it should be possible for the programmers here to fix it (or in @Atitarev’s words: why “this case is supposed to work”). Regarding your learning endeavors, I can only advise against such an approach. The concrete shapes of the words heavily depend on the grammar, synchronically and diachronically, and it pays out well to learn at the beginning the grammar from beginning to end as it is the shortest part of the language from which only you will understand idioms and the relations between words in the instances in which they are used. Really, I first read the whole grammar if I want to know a language and pick up not even thirty words in this act (that reading sometimes needs only two days!), then I am armed to read all kinds of texts, faster and faster. There is no such thing as immersion – you do not have the time or opportunities or necessities babies have for the language to pour in upon them. Palaestrator verborum (loquier) 01:18, 4 November 2017 (UTC)
@Palaestrator verborum: This is a digression from the topic but everyone's abilities and interests are different. I'd prefer beginners take their time learning rather than creating in bulk erroneous entries. The Arabic grammar is very difficult too and you can't get a good exposure to it without understanding some words, being able to read and in order to read an unvocalised Arabic text and without transliteration, you need to know those words and grammar, common patterns. The matter is further complicated by the fact that, simply put, nobody speaks the written language and nobody writes the spoken dialects. Complex grammar such as Russian can be learned by reading texts without using aids such as transliteration or vocalisation and listening to it. It is so much harder to get this exposure in Arabic. --Anatoli T. (обсудить/вклад) 01:30, 4 November 2017 (UTC)
Of course one shall only create entries when one has the necessary degree of sureness about them – but obviously exactly to exclude errors in the entry creation one should know the whole grammar, while on the other hand nobody needs to know the whole vocabulary of a language; the pursuit of completing it is what drives us here to create entries: The memorial enhancement brought forth by adding entries as well as the inner altercation with the words and the language wherewith you describe. Is there an off-topic demarcator template? Should be made. Palaestrator verborum (loquier) 01:49, 4 November 2017 (UTC)
Topics just get split but the general discussion we had, had nothing to do with the purpose of the Grease pit. --Anatoli T. (обсудить/вклад) 01:56, 4 November 2017 (UTC)

@Palaestrator verborum: There is no reason for لِلنَّاسِ to fail, since we have an identical working example: بِالتَّأْكِيد (bi-t-taʾkīd). It works well without explicitly providing hamzatu l-waṣl ٱ. You can see this and similar in Module:ar-translit/testcases. Please add another test case and any other glitches. --Anatoli T. (обсудить/вклад) 00:29, 4 November 2017 (UTC)

Oops, I just noticed that your case doesn't have an alif. Not sure, if this case is supposed to work now. --Anatoli T. (обсудить/вклад) 00:32, 4 November 2017 (UTC)
Hmm, my comments were simply wiped out by User:Backinstadiums. I am sure it wasn't intentional. --Anatoli T. (обсудить/вклад) 00:49, 4 November 2017 (UTC)
I added some examples to the testcases. — Eru·tuon 01:34, 4 November 2017 (UTC)
@Erutuon: Swell, but the entry لِلَّبَنِ‏ (li-l-labani) contained by the testcases looks imaginary to me. There is no such thing as full graphical elision of the determiner, as far as I know, so we have ‎لِللَّبَنِ‎. Example found on the web: ‎“هل تعلمي أن لللبن الرائب فوائد أخرى عديدة أكثر من مجرد تهدئة القولون أو علاج عسر الهضم”‎. That is “li-l-labani”, the entry here is “li-labani” without any article (else how would you know if it is determined or not?). Also that is obviously a SOP, so, well, why not delete it? Palaestrator verborum (loquier) 02:39, 4 November 2017 (UTC)
@Palaestrator verborum: Well, I thought a series of three lams was shortened to two. I could be mistaken. There would be ambiguity, but language is often ambiguous. As for the entry, @Stephen G. Brown probably had a reason for creating it. Propose deletion if you want. — Eru·tuon 02:51, 4 November 2017 (UTC)
The reasons then and now may be different. The notion that everything spelled without spaces is a word, even for languages that do use spaces between words is not always true. --Anatoli T. (обсудить/вклад) 02:56, 4 November 2017 (UTC)
My copy of Arabic: an Essential Grammar (p. 57) says that three lams are indeed simplified to two, so لِـ (li-) + اللُّغَةُ (al-luḡatu) is لِلُّغَةِ (lilluḡati), a homograph of لِلُغَةِ (liluḡati) when written without diacritics. But apparently, from the example you give, this rule is not always followed. — Eru·tuon 03:47, 4 November 2017 (UTC)
Back to the topic, the new cases لِللَّبَنِ‏ or لِلتَّأْكِيذ‏ are weak. What we have is "lām + nothing + sun letter + šadda + vowel" in the middle of a word. The module expects to have a vowel point where it sees nothing. It works for definite articles at the beginning of words or after prepositions but dropping the alif makes it very ambiguous. It should continue failing, IMO and a manual transliteration needs to be provided, unless a stronger case is provided to show that only an abbreviated definite article can happen in this position and not another lām in an incompletely vocalised word. --Anatoli T. (обсудить/вклад) 03:24, 4 November 2017 (UTC)
Yuck, Wolfdietrisch Fischer writes in § 22 of his Grammatik des klassischen Arabisch:
“In einigen feststehenden Verbindungen wird alif al-waṣl nicht geschrieben.:
a) bei der Verbindung der Partikel la- und der Präp. li- mit dem Artikel: لِلرَّجُلِ lir-raguli (statt لالرجل‎), لَلْمَجْدُ lal-maǧdu (statt لالمجد). Beginnt in solchen Fällen das folgende Nomen mit ل, wird das ل des Artikels nicht geschrieben: لِلَّيْلَةِ lil-laylati (statt لالليلة‎), لِلّٰهِ lil-lāhi ‘für Gott’ (statt لالله).”
According to this it is classical to drop the ل – honestly that seems weird to me according to current standards and I have to ask some native speakers about the current stringency. But for the module it means that that case has to be handled, as Classical Arabic is also Arabic in Wiktionary – the current evidence points to both cases being in need of handling. Note the transcriptions given by Fischer. Palaestrator verborum (loquier) 03:48, 4 November 2017 (UTC)
The search for للله takes significantly more to scroll down than the search for لله. Note لله and the discussion page, Anatoli. / I did not see btw a need for a text direction fix. The bidi implementations are awful, they apparently even differ across browsers. / Whatever, I am becoming silly and need to sleep. Palaestrator verborum (loquier) 03:59, 4 November 2017 (UTC)
@Palaestrator verborum: I'm not sure why you said "yuck". I am not arguing and I wasn't arguing the correctness of the case as a reading rule (for humans) but for the module, we need to make sure there are no other cases, where unpointed lām is not part of an abbreviated ال to avoid mistransliterations. --Anatoli T. (обсудить/вклад) 10:05, 4 November 2017 (UTC)
@Atitarev: I’m sorry for your feeling offended. I have not referred to anything you said but said yuck about the whole topic and this uncertainty (the indentitation level was supposed to relate to my own message just before it). As it seems that if that rule of § 22a applies, there is no way for the module to recognize the article. So it will always be a bit wrong only by not adding a hyphen. But understanding now what you have said, I think if diacritic-less lām is not part of an abbreviated ال (al-), it is just incomplete transcription and the editor is liable for providing such a transcription; whereas it is of highest importance that the module does not fail with nil if a completely and correctly vocalized Arabic text is provided (it is too regrettable if it fails for just this). And yet also we do not know cases “where unpointed lām is not part of an abbreviated ال (al-)”.
@Heydari, do you know any such cases? And if we are on it, how do you esteem spellings like “لِللَّبَنِ‏”. A matter of taste? Wrong, but pleasant? Horrifying? Justly prefered these days? Palaestrator verborum (loquier) 14:00, 4 November 2017 (UTC)
@Palaestrator verborum: No problem, keep up the good work in Arabic! --Anatoli T. (обсудить/вклад) 23:12, 4 November 2017 (UTC)

@Palaestrator verborum Does prefixing لِـ change the nature of the velarized /ɫ/ of لله? Otherwise the pronunciation should show ɫ --Backinstadiums (talk) 10:54, 4 November 2017 (UTC)

@Backinstadiums Good question, but I am the wrong man asked, I hardly ever hear Arabic speech. Palaestrator verborum (loquier) 14:00, 4 November 2017 (UTC)
@Backinstadiums: Yes. You can see an example of that in Module:ar-pronunciation/testcases. [edit: To be clear, I think it happens after the vowel /i/, long or short, so there are many more possible examples. At least, that's what the module assumes.] — Eru·tuon 19:11, 4 November 2017 (UTC)
@Erutuon, Palaestrator verborum: According to this forum, it's right --Backinstadiums (talk) 21:03, 4 November 2017 (UTC)
Confirming. I replied to you in Talk:لله. --Anatoli T. (обсудить/вклад) 23:12, 4 November 2017 (UTC)


Hello. How I can use Quotations function in other wiki projects? Which extensions, templates or gadgets required? --Drabdullayev17 (talk) 09:00, 4 November 2017 (UTC)

@Drabdullayev17: Are you referring to the JavaScript code that allows quotations to be shown and hidden? I did a search and it seems to be located in MediaWiki:Common.js (search for "Hidden Quotes" and "Visibility toggling"), but other people such as @Dixtosa or @Rua might know more about it. — Eru·tuon 21:30, 4 November 2017 (UTC)
Thanks @Erutuon:, I did it but it didn't solve my problem. --Drabdullayev17 (talk) 06:16, 5 November 2017 (UTC)
@Drabdullayev17: I was simply showing you the code. I can't promise this will work, but you could try copying it to the User:Drabdullayev17/common.js file on the wiki where you want to use it. — Eru·tuon 09:58, 5 November 2017 (UTC)

template:fr-noun and other headline templates[edit]

It's not terribly important, but would it be possible to add automatic parsing of words like attentat-suicide, trait d'union and à l'instar de? Currently, one has to use the parameter {{{head}}} and write manually "[[attentat]]-[[suicide]], [[trait]] [[d']][[union]] and [[à]] [[l']][[instar]] [[de]]". --Barytonesis (talk) 10:59, 4 November 2017 (UTC)

I'd rather not, because automatic parsing like that isn't language-specific as far as I know, which means there would have to be a break at a hyphen and apostrophe in all languages. And I don't want English won't parsed as [[won']][[t]] or Irish t-athair as [[t-]][[athair]]. —Aɴɢʀ (talk) 13:43, 5 November 2017 (UTC)
@Angr: Would it be technically feasible to make it apply only to French? --Barytonesis (talk) 10:49, 6 November 2017 (UTC)
I don't know. —Aɴɢʀ (talk) 11:13, 6 November 2017 (UTC)

languages offered for a certain entry[edit]

I am concerned about the languages offered for a certain entry in the English version of wiktionary. That is, for https://en.wiktionary.org/wiki/a, there're 99 languages with the term "a" in their lexicon, all of them explained in the English language (for example, for french, https://en.wiktionary.org/wiki/a#Etymology_3_12 the third etymology reads "third-person singular present indicative of avoir".

Yet, you could choose the French interface to see the same info., https://fr.wiktionary.org/wiki/a#Forme_de_verbe.

Now , I want to limit the languages which show the term that's been searched, not those of the interface offered on the lelft of the page. --Backinstadiums (talk) 12:48, 6 November 2017 (UTC)

Arabic translit fails on fully vocalised texts[edit]

I can't figure out why it fails here:

هٰذَا ٱلرُّوبُوت اَلَّذِي يَتَكَلَّمُ ٱلْعَرَبِيَّة‏
hāḏā r-rūbūt allaḏī yatakallamu l-ʿarabiyya
This is a robot, which can speak Arabic

but not here هٰذَا ٱلرُّوبُوت اَلَّذِي يَتَكَلَّمُ ٱلْعَرَبِيَّة (hāḏā r-rūbūt allaḏī yatakallamu l-ʿarabiyya)? It requires a manual transliteration, since "robot" is pronounced in a non-standard anglicised way "rōbōt", not "rūbūt" but something's going wrong with one of the modules. It works with {{m}} but not with {{ux}}. @Erutuon, Palaestrator verborum. --Anatoli T. (обсудить/вклад) 12:53, 6 November 2017 (UTC)

@Atitarev: It's because of a right-to-left mark at the end of parameter 2 in {{ux}} above that is not present in {{m}}. I can see it because I have the wikitext syntax highlighting beta feature enabled. That makes the has_diacritics function think that the text isn't properly vocalized. Perhaps the module should ignore right-to-left and left-to-right marks so that bizarre stuff like this doesn't happen. — Eru·tuon 19:32, 6 November 2017 (UTC)
Okay, now Module:ar-translit ignores these marks when determining if text can be transliterated, but tracks them in ar-translit/lrm or rlm. — Eru·tuon 19:58, 6 November 2017 (UTC)
@Erutuon: Thank you for fixing this! Now, there's a new problem. It seems that using {{ux}}, it thinks that there is a final sukūn, although I haven't even entered a full stop to avoid this, so the final word with an unpointed tāʾ marbūṭa is transliterated as "ʿarabiyyat‏" but should be "ʿarabiyya". --Anatoli T. (обсудить/вклад) 13:02, 7 November 2017 (UTC)
@Atitarev: Okay, that's fixed too. It was because of the final right-to-left mark (again), which made the module think the tāʾ marbūṭa wasn't final. — Eru·tuon 18:51, 7 November 2017 (UTC)
@Erutuon: Thanks for the efforts! Do you think you can make it work with the punctuation as well?
هٰذَا ٱلرُّوبُوت اَلَّذِي يَتَكَلَّمُ ٱلْعَرَبِيَّة‏.‏
hāḏā r-rūbūt allaḏī yatakallamu l-ʿarabiyya.
This is a robot, which can speak Arabic.
--Anatoli T. (обсудить/вклад) 05:18, 8 November 2017 (UTC)
@Atitarev: Done! Hopefully it's okay to do it with all punctuation; I can't think of any counterexamples at the moment. — Eru·tuon 05:28, 8 November 2017 (UTC)

Links in category lists[edit]

Is it somehow possible to make the links in category lists go to the correct language? (without too much effort). Very annoying to have to click through to the right entry sometimes. – Jberkel (talk) 19:26, 6 November 2017 (UTC)

Yes, this is already implemented for most categories. What category are you referring to? DTLHS (talk) 19:26, 6 November 2017 (UTC)
What do I have to do to enable it? For example, I recently created Category:Italian nouns with multiple plurals. – Jberkel (talk) 10:06, 7 November 2017 (UTC)
Does {{catfix}} do what you want? I put it on the category you mentioned. —Aɴɢʀ (talk) 10:34, 7 November 2017 (UTC)
Yes, thank you! – Jberkel (talk) 11:03, 7 November 2017 (UTC)

Abuse filter 73 help[edit]

Trying to forbid references as a level two header in the main namespace. article_namespace == 0 & new_wikitext rlike "\n==\s*References\s*==\s*\n" seems not to work at all- what should the regex be? DTLHS (talk) 21:40, 6 November 2017 (UTC)

Looks like it is working to me, perhaps you tweaked it since you asked. You might want to add the inverse for old_wikitext if you don't want to flag entries which already have References as an L2. - TheDaveRoss 15:23, 7 November 2017 (UTC)
@DTLHS you may wish to consider added_lines_pst as that is the most accurate for new additions, otherwise you are testing the entire rendering of the updated page. If doing that I would suggest that you ignore the new lines and focus on the target text so a regex something like ={2}\s{,3}references{,3}={2} (note this is untested), it also shortens the length of your wildcard searches, and either make it [rR] or irlike just in case they don't follow your case pattern. — billinghurst sDrewth 02:57, 8 November 2017 (UTC)

Template alerts for {{bor}}[edit]

The {{inherited}} template helpfully generates an alarm if an editor tries to enter a source language that is not an ancestor of the target language. I wonder if we could do something similar with {{borrowed}}? I believe most users agree that {{bor}} is only supposed to be used for the last derivation in a chain, so e.g. Hungarian láma is not supposed to be marked as a borrowing either from Quechua (the animal) or Tibetan (the title). We in fact do not expect to see any direct borrowings between Hungarian and Quechua, or Hungarian and Tibetan. There are going to be at least hundreds of other pairings like this, where language A very well might have words derived from language B, but they're all going to be mediated by some other language.

For a rough first approximation, would it be possible to:

  1. divide languages as having one or more specific regions;
  2. generate errors for borrowings between non-adjacent regions. (We should clearly not limit things to just one region, since their boundaries are going to be fluid.)

A region in this sense is not merely the native region of a language, but the region where it has speakers at all. "Global" languages like English could be assigned to every or almost every region, so they would almost never trigger errors. (Maybe for regions like "ancient Middle East", but I doubt anyone is going to go in good faith marking e.g. Akkadian words as borrowings from English anyway.)

By "generating an error" I do not necessarily mean an explicit template error — a maintenance category "nonsensical borrowings" or "suspicious borrowings" might be sufficient. --Tropylium (talk) 12:03, 7 November 2017 (UTC)

This sounds like an enormous amount of effort to set up and maintain compared to quite a modest benefit. I wouldn't even say it's a mistake to say that Hungarian láma is borrowed from Quechua and Tibetan: it is borrowed from those languages, just not directly. —Aɴɢʀ (talk) 13:53, 7 November 2017 (UTC)
I agree that we should only use borrowing for the final step in an etymology, but enforcing that is not going to happen until we can put an entire etymology into one template invocation. DTLHS (talk) 02:48, 8 November 2017 (UTC)
@DTLHS Your dumps can help, though. —Rua (mew) 12:08, 9 November 2017 (UTC)
If you are doubtful, just alter them to {{der}}. Like all the proto stuff in many entries, they are often not directly inherited or borrowed and some editors get carried away with the use of {{inh}}. DonnanZ (talk) 12:42, 10 November 2017 (UTC)

In page anchors?[edit]

What is the process for linking to a specific part of a definition on a page. As sub-headings are not unique, about the only place to which I can link uniquely is the language sub-heading, and for a page with multiple meanings/uses, I would like to be more specific in my linking. Thanks. — billinghurst sDrewth 02:46, 8 November 2017 (UTC)

@billinghurst: Use the |id= parameter in linking templates. This links to an HTML id created by {{senseid}}. For instance, {{m|en|-er|id=agent}}-er. Also works in {{affix}} and related templates, only the parameter needs a number to specify which component the id applies to: {{affix|en|teach|-er|id2=agent}}teach +‎ -er. — Eru·tuon 04:06, 8 November 2017 (UTC)
@Erutuon I am only an occasional editor of Wikt:, and definitely don't know the ins and outs, so there is a little (big?) gap in what you are explaining and where my knowledge lies. Nothing at category:Linking templates or category:Internal link templates assists. Are these innate to current labels, or do they need to be explicitly added when one wants to make them an anchor? I had wanted to link to one of the definitions within may#English and I don't see those templates overtly used. Thanks. — billinghurst sDrewth 04:47, 8 November 2017 (UTC)
@billinghurst: If {{senseid|language code|id code}} is not in the definition line that you want to link to, you must add it. Once the senseid template is there, it can be linked to by putting the id code into the linking template. For the {{l}} template, that looks like {{l|language code|page name|id=id code}}. For instance, in the -er entry, one of the definition lines is # {{senseid|en|agent}} {{lb|en|added to verbs}} A [[person]] or [[thing]] that ... ., and the template code {{l|en|-er|id=agent}} creates a link to that definition line. Does that help? — Eru·tuon 05:07, 8 November 2017 (UTC)
Yes, thanks. It would be useful to put it into some guidance page here for other intrepid wikimedians who wander by. — billinghurst sDrewth 07:12, 8 November 2017 (UTC)
What about anchors to subsections? For example, how would I link to Etymology 2 of Irish bán? {{l|ga|bán|id=Etymology 2}} doesn't work, and I don't suppose it would be kosher to write ==={{senseid|ga|grassland}}Etymology 2===. Sometimes I want to link to the whole Etymology section and not just a single sense line. —Aɴɢʀ (talk) 12:42, 8 November 2017 (UTC)
Well, [[bán#Etymology 2]] links to the first Etymology 2 header on the page, which happens to be the Hungarian one at the moment. [[bán#Etymology 2 2]] (I recently discovered this) links to the second Etymology 2 header. Currently that's the Irish one. Either of those links will end up going to a different section if another Etymology 2 header is added above them. There's no way for the linking template to figure out which Etymology 2 header is in which language section, except by getting the page content and doing a search, which would be costly. Maybe you could use {{senseid}} in the etymology section (which I don't particularly like the idea of, but maybe it should be allowed), or {{anchor}} (in which case you have to do something like {{l|ga|bán#anchor name|bán}}). — Eru·tuon 05:23, 9 November 2017 (UTC)
No wait, {{l|ga|bán#anchor name|bán}} doesn't work; it links to [[bán#anchor name#Irish]]. Hmph. — Eru·tuon 05:24, 9 November 2017 (UTC)
So, [[bán#Etymology 2 2]] works as a bare link, but there's no way to get {{l|ga|...}} to link to it, because {{l|ga|...}} will always add #Irish to the URL? That's frustrating. —Aɴɢʀ (talk) 11:30, 9 November 2017 (UTC)
@Angr: I'll take a look at the module and see if that can be fixed. # can only be used for anchors in wikilinks, and the module shouldn't add another anchor after an existing one. — Eru·tuon 17:22, 9 November 2017 (UTC)
Okay, it's fixed. — Eru·tuon 17:54, 9 November 2017 (UTC)
What does it do now instead? —Rua (mew) 19:08, 9 November 2017 (UTC)
Now, {{l|ga|bán#Etymology 2 2|bán}} links to [[bán#Etymology 2 2]], as I think a naive user would expect it to. (So it has the same result as {{l|ga|[[bán#Etymology 2 2|bán]]}}.) — Eru·tuon 19:17, 9 November 2017 (UTC)
But what if that section isn't actually in the English section? —Rua (mew) 19:27, 9 November 2017 (UTC)
Oops, it isn't. (Wrong language code. Changed it from en to ga.) Well, that would be unfortunate. The module probably can't check it, because it would be extravagant in processing time and memory to load and search the page for every link that has a manually inserted fragment. Similarly, the module can't check whether a sense id is present in the language section. The fragment could be removed if it isn't a sense id or language name, but that would be confusing for users and it would add to processing time and memory, as the module would have to check if the putative language name in the anchor was valid. (It would sometimes have to check twice: for {{l|en|-er#English-agent|er}}, whether English-agent was a language code, and then whether English was a language code.) Checking the validity of fragments and sense ids might be easier for a bot. — Eru·tuon 19:42, 9 November 2017 (UTC)
The problem actually runs deeper than that. When someone links to an English section, we know which specific section they intended to link to. With "Etymology 2", there's no such guarantee, since it just picks the first section with that name. It could be in the wrong language section, or it could be in the right language section but not actually be the Etymology section that the linker intended to link to (because someone rearranged the entry). This is why I generally remove anchors from links. They are really unreliable and there's no guarantee that the section they link to is the intended one. Only senseids can solve this problem, since they assign a specific identifier that will never change regardless of how much the entry is changed. —Rua (mew) 19:51, 9 November 2017 (UTC)
I agree that generic anchors are unreliable, but there's still the possibility that someone will change or remove a sense id, making the links that use it fail to work anymore. (I've changed ids before, though I do make sure to update the links that use them.) So it would be good if they were being checked regularly. — Eru·tuon 00:53, 13 November 2017 (UTC)

@billinghurst: I would be willing to write something on how to use sense ids. I just don't know where to put it exactly. — Eru·tuon 05:26, 9 November 2017 (UTC)

The documentation for {{l}} would be a good place. There's also some at {{senseid}} itself. —Rua (mew) 12:07, 9 November 2017 (UTC)

Let me throw this out there -- we've spoken from time to time about more radical restructurings. One that would seem to make a great deal of sense (even if it would be a huge PITA to migrate existing content), would be to move language content to language-specific subpages. So [[bán]] would show all words in all languages that have this graphical representation, while the content specific to Irish would live at [[bán/ga]], and the content specific to Hungarian would live at [[bán/hu]], etc. That would make it possible to link to specific headers in specific languages. This is also quite similar to how the Grease Pit itself is now organized (among other discussion pages), where the main page at [[Wiktionary:Grease_pit]] shows the combined content, while the actual threads live on sub-pages like [[Wiktionary:Grease pit/2017/November]].

Alternatively, we could rework how HTML id values are generated, so rather than id="Etymology_2_2", which, for our purposes, is pretty close to bloody useless, we would instead get useful id values, like id="ga-Etymology_2" or something similar.

Hopefully fodder for productive discussion. ‑‑ Eiríkr Útlendi │Tala við mig 03:59, 12 November 2017 (UTC)

@Eirikr: I imagine that adding ids like id="ga-Etymology_2" could be done with JavaScript. But to do it without JavaScript would require templates. — Eru·tuon 08:23, 17 November 2017 (UTC)
@Erutuon: That's an interesting approach. My initial thought was to see if there's anything in the server setup related to anchor auto-generation that we could reconfigure. id="Etymology_2_2" is clearly not in a format that we're intentionally generating. I'm curious if there's any way of getting the server-side setup to do the work for us, without requiring any change to the wikicode on each page. If not, then JavaScript or templates would presumably be the way to go. ‑‑ Eiríkr Útlendi │Tala við mig 17:18, 17 November 2017 (UTC)
@Eirikr: It would be neater if it were implemented server-side. There would be less mess in the wikitext. It would probably require help from MediaWiki folks, who might or might not want to implement this. To put language codes into ids in headers, the server would have to be updated with the latest language codes and canonical names from our language data modules so that it could convert canonical names in headers to codes. Or it would have to just put the canonical name or whatever else is found in the previous level-2 header in the id (that is, id="Irish-Etymology_2", or id="Irish_Gaelic-Etymology_2" if someone decided to use an alternative name of the language). I don't know that much about how the server software works, though. I would mention, many other wiktionaries use templates in headers, and French Wiktionary seems to use the templates to insert custom ids into headers. — Eru·tuon 10:45, 18 November 2017 (UTC)

Straw poll -- would you be open to the idea of using templates in page headers as a means of improving in-page-anchor functionality?[edit]

As mentioned by Erutuon above, the French Wiktionary apparently makes extensive use of templates in page headers as one means of improving in-page-anchor functionality.

Would you (whoever is reading this) be open to the idea of doing something similar here?

  • Symbol support vote.svg Support ‑‑ Eiríkr Útlendi │Tala við mig 19:23, 20 November 2017 (UTC)
  • Symbol oppose vote.svg Oppose. It doesn't actually solve the problem, like I mentioned in my earlier post. There is no guarantee that the section named "Etymology 2", even if it's in the right language, is the section that the linker intended to link to. There is nothing about it that reveals which etymology section it is. {{senseid}}, specifically because they contain actual meaningful text most of the time, do not suffer from this problem. If we started naming etymology sections rather than numbering them (at least for anchoring purposes), it would be better. However, it would make a lot more sense to link to the part-of-speech section rather than the etymology; when do you actually want to link specifically to an etymology? —Rua (mew) 19:31, 20 November 2017 (UTC)
    @Rua -- Templates in headings could provide more useful and semantically stable link IDs than just numbers, such as the naming possibility you mention. Numbering alone is possibly one of the worst approaches, as pages grow and change and numberings become unstable. Re: linking to POS sections, perhaps I should have been more explicit -- I'm thinking about all headings, not just etymology headings. ‑‑ Eiríkr Útlendi │Tala við mig 19:46, 20 November 2017 (UTC)

Useful graphic on loading sequence[edit]

This graphic looked like it might be helpful at some stage in diagnosing and minimizing the occasionally recurring problems we have with the show-hide JS. DCDuring (talk) 13:18, 8 November 2017 (UTC)

Automation of 'See also' links?[edit]

I've stumbled across a few pages that are lacking {{also}} links at the top of the page recently, e.g. OWO/owo and Szilágyi/Szilagyi.

Was there ever a bot that created these links automatically? Is it possible to write a module which would automatically keep the see-also links up to date? Pengo (talk) 12:41, 9 November 2017 (UTC)

There was a bot, but it wasn't very reliable, and it hasn't run in a long time. —Aɴɢʀ (talk) 14:28, 9 November 2017 (UTC)
I have had to add a number of words including the letter "ø" to {{also}} links, they seem to be missed for some reason. DonnanZ (talk) 14:38, 9 November 2017 (UTC)

"References is forbidden as a level 2 header" in inappropriate namespace[edit]

My bot just tried to edit Wiktionary:Etymology and got booted out by this edit filter. Of course, the filter should only apply to namespaces that contain entries, mainspace and Reconstruction. Can the filter be fixed to that effect? Moreover, the filter shouldn't be triggered for edits that others made. My bot didn't add the References section, so the filter shouldn't be flagging unrelated edits as bad. —Rua (mew) 23:10, 10 November 2017 (UTC)

It's abuse filter 73- I couldn't get it to work right and I've disabled it for now. DTLHS (talk) 01:20, 12 November 2017 (UTC)

Prevent deletion of the main page[edit]

This is evidently something that can be done, so I presume we should. This suggested it to me. @Angr, since you're an admin at en.wiki, can you confirm that the main page can't be deleted there? —Μετάknowledgediscuss/deeds 01:17, 12 November 2017 (UTC)

I don't know. I've never tried. —Aɴɢʀ (talk) 15:16, 12 November 2017 (UTC)
Before you try it, make sure to read Wikipedia:Don't delete the main page. ;-) -Stelio (talk) 21:19, 12 November 2017 (UTC)
@Angr, what I meant was, can you access the page to delete it? —Μετάknowledgediscuss/deeds 21:39, 12 November 2017 (UTC)
I can confirm that the "Delete" and "Move" options that every other main-namespace article has do not appear on the Main Page at English Wikipedia. —Aɴɢʀ (talk) 21:46, 12 November 2017 (UTC)
What if you go to delete some random page, but then change the URL so that the target page is "Main page"? —Rua (mew) 19:14, 13 November 2017 (UTC)
@Metaknowledge, Rua: You get a Permission error saying, "You do not have permission to delete this page, for the following reason: You cannot delete or move the main page." —Aɴɢʀ (talk) 10:08, 17 November 2017 (UTC)

Min Nan POJ entries ended up in HSK categories[edit]

Something puts Min Nan POJ entries into Mandarin HSK entries, e.g. an-chēng#Chinese. @Wyang, Justinrleung. --Anatoli T. (обсудить/вклад) 02:46, 12 November 2017 (UTC)

That thing has been annihilated. Wyang (talk) 02:52, 12 November 2017 (UTC)
Great, thanks! --Anatoli T. (обсудить/вклад) 02:54, 12 November 2017 (UTC)

Request for kana as ruby on kana-containing base text for uses of {{furigana}}, {{ja-r}} & {{ja-usex}}[edit]

Some authors use ruby on base text that contains kana, for example ベーゼキッス or 魔法使いぼく, which {{furigana}} & {{ja-usex}} can't handle yet. It's trickier to automatically render romaji for {{ja-r}} & {{ja-usex}} in these cases, but they also have parameters for manually doing that, so they should offer more options.

By the way, what wrong this: バカじゃないの。 (ぜん) () () (じょ) (みっ) (しつ) () (てん) () () (れん) (ぞく) (さつ) (じん) () (けん)?わざわざ (ことわ)らなくても、 (ふく) ()たまま () ()には (はい) () (じょ)なんていないわよ。だいたい、 () (てん) () () (みっ) (しつ)になった (だん) (かい) (だい) () (けん)だわ。

Baka ja nai no. Zenra bijo misshitsu rotenburo renzoku satsujin jiken? Wazawaza kotowaranakute mo, fuku kita mama furo ni wa hairu bijo nante inai wa yo. Daitai, rotenburo ga misshitsu ni natta dankai de daijiken da wa.
Now that’s just absurd. A series of murder cases of beautiful naked women inside locked-room outdoor baths? I mean, it’s not like there’s such thing as beautiful women taking a bath with clothes on. And an outdoor bath can’t be in a locked room to begin with.

.I tried breaking it down into small parts (バカじゃないの。 (ぜん) () () (じょ) (みっ) (しつ) () (てん) () () (れん) (ぞく) (さつ) (じん) () (けん)?わざわざ (ことわ)らなくても、 (ふく) ()たまま () ()には (はい) () (じょ)なんていないわよ。

Baka ja nai no. Zenra bijo misshitsu rotenburo renzoku satsujin jiken? Wazawaza kotowaranakute mo, fuku kita mama furo ni wa hairu bijo nante inai wa yo.
Now that’s just absurd. A series of murder cases of beautiful naked women inside locked-room outdoor baths? I mean, it’s not like there’s such thing as beautiful women taking a bath with clothes on. And an outdoor bath can’t be in a locked room to begin with.

だいたい、 () (てん) () () (みっ) (しつ)になった (だん) (かい) (だい) () (けん)だわ。

Daitai, rotenburo ga misshitsu ni natta dankai de daijiken da wa.
(please add an English translation of this example)

) and found nothing wrong with the matching of kana. ばかFumikotalk 06:09, 12 November 2017 (UTC)

I made a small change to the function and it appears to fix this problem. I believe the problem is due to repeated characters or sequences of characters, in this case triple apostrophes used for bolding. However, there are likely to be other effects of this edit... — Eru·tuon 06:57, 12 November 2017 (UTC)
Now there's something wrong with ラー (よく) (しん) (りゅう)
no Yokushinryū
Ra the Winged God Dragon
. Can you check it again? ばかFumikotalk 10:58, 12 November 2017 (UTC)
Okay, that is now fixed. — Eru·tuon 18:57, 12 November 2017 (UTC)

ISO codes in tab languages[edit]

The languages in the tabs (PREFERENCES > GADGETS – Enable tabbed languages) take a lot of space, so I'd like to change them for their ISO codes. --Backinstadiums (talk) 17:58, 12 November 2017 (UTC)

Oppose showing language codes in any user-facing place, and especially in such an important place as L2 language headers (which the tabs replace). —Rua (mew) 18:02, 12 November 2017 (UTC)
@Rua: I'd like it as an option in the user's preferences, just as the tabs are optional --Backinstadiums (talk) 18:11, 12 November 2017 (UTC)
I'd be opposed even to letting people opt in to this setup. Even experienced users will sooner or later be baffled and frustrated by the fact that the language codes aren't listed in alphabetical order, since we alphabetize by full name, not by code. —Aɴɢʀ (talk) 13:20, 13 November 2017 (UTC)
@Angr: Customizable order of languages should be optional as well --Backinstadiums (talk) 19:12, 13 November 2017 (UTC)


Is there a way to make the wizard that appears on Creating Category:... pages paste {{autocat}} directly into the editing box upon clicking it (if possible also saving the page and maybe giving me a back massage), I've wasted countless man-seconds on typing this in. Crom daba (talk) 16:29, 13 November 2017 (UTC)

If you're willing to wait a bit, you don't have to create those categories at all. DTLHS runs a bot script that creates them. —Μετάknowledgediscuss/deeds 19:23, 13 November 2017 (UTC)
I'm not, red links provoke me. Crom daba (talk) 19:28, 13 November 2017 (UTC)
P.S. This is off topics, but does anyone know what's wrong with this (I've just added Proto-Yukaghir, but poscatboiler can't see it apparently).
Proto-Yukaghir is "qfa-yuk-pro" not "xgn-mgr", and, you need to also edit Module:languages/canonical names if you add a new language in order for {{auto cat}} to function. DTLHS (talk) 19:39, 13 November 2017 (UTC)

Module:IPA sorting wrong[edit]

For Northern Sami, a sort key is set to sort á immediately after a. But in Category:Northern Sami terms with IPA pronunciation, á is sorted at the very end. Can this be fixed? —Rua (mew) 21:02, 14 November 2017 (UTC)

Done. — Eru·tuon 21:44, 14 November 2017 (UTC)
@Erutuon: Thanks! Can you also arrange it so that {{IPA}} accepts |sort= for manual sorting? —Aɴɢʀ (talk) 21:49, 14 November 2017 (UTC)
@Angr: I guess that feature should be available. Done! — Eru·tuon 22:08, 14 November 2017 (UTC)

Behaviour of {{topic cat}} at "Category:en:New York City"[edit]

I've just noticed that at "Category:en:New York City", {{topic cat}} is generating the following statement: "English terms related to new York City" (with new instead of New). There are some instructions at {{topic cat}} on using the special keyword "default with capital" to alter the default behaviour of the template, but I can't figure out how to do it. Could someone help? — SGconlaw (talk) 10:21, 17 November 2017 (UTC)

It seems to read OK now, so someone must have quietly changed the module. DonnanZ (talk) 17:06, 19 November 2017 (UTC)

Two collapsing displays under the same definition?[edit]

I am having troubling picturing a user interface suitable for infrequent users that would allow for a collapsing display under a definition of a synonyms line and a collapsing display of citations. Are we forced to have a single collapsing display that included both? DCDuring (talk) 13:49, 17 November 2017 (UTC)

Ouput of template:label[edit]

Hello, in the page bump into, we can see for the first two definitions: (literally intransitive) and (literally transitive), without any comma between the two labels. Is there any reason to that? — Automatik (talk) 01:48, 19 November 2017 (UTC)

"Literally, intransitive" would be as ambiguous as "literally intransitive". Perhaps for that reason {{lb|en|intransitive|literally}} produces (intransitive, literally). I think that literally should not appear together with any other label because it can be read ambiguously with many other label words. DCDuring (talk) 11:16, 19 November 2017 (UTC)

what if I wanted to[edit]

As someone with a "C-like" background (can struggle through C and C++; regularly use C#, JS, PHP; am low-level enough to have an idea about assembler), what is a good entry point to all this Lua fun that we have here? Equinox 04:26, 19 November 2017 (UTC)

Does this help? DTLHS (talk) 04:30, 19 November 2017 (UTC)
Excellent, thank you. For future idiots, where should I have found the link? Equinox 04:43, 19 November 2017 (UTC)
I have no idea. DTLHS (talk) 04:48, 19 November 2017 (UTC)
It's linked in the edit notice for module pages, with the link text "Scribunto": MediaWiki:Editnotice-828. — Eru·tuon 04:49, 19 November 2017 (UTC)
It might be a good idea to link this kind of thing from this (WT:GP) page. If I knew Lua (which I don't! yet) I would like the techy page to have a clear pointer to "this is how we do Lua around here". Anyway, thanks! Equinox 04:52, 19 November 2017 (UTC)
I hadn't thought about it before, but I guess I agree. It should probably link to WT:LUA, which can serve as a hub. It has the link given above as well as others. — Eru·tuon 08:15, 19 November 2017 (UTC)

Improving links to pages with many languages[edit]

I hope I am not asking for too much, but is it possible for links to be improved to pages such as ti, which has entries in no less than 47 languages, so you land on exactly the right language. For example, the link from tiande to Norwegian Nynorsk ti. DonnanZ (talk) 12:57, 20 November 2017 (UTC)

It already does bring you to the right section, because the link is using {{l}}. Why don't you try again? —Μετάknowledgediscuss/deeds 15:35, 20 November 2017 (UTC)
Behaviour is erratic, sometimes in the right place, sometimes ends up two or three languages below. Could it be a browser problem? DonnanZ (talk) 15:52, 20 November 2017 (UTC)
The link to [[ti#Norwegian Nynorsk]] worked perfectly for me this time in Chrome 62.0.3202.94 (64-bit), Firefox 56.0.2 (64-bit), and Edge 40.15063.674.0. DCDuring (talk) 16:12, 20 November 2017 (UTC)
FWIW, I've noticed similar behavior on up-to-date Chrome, where the view of the page shifts as the JavaScript loads and different portions of the page expand or contract. @DonnanZ, when you click through a language-specific link using {{l}} or {{m}}, do you see this behavior too? ‑‑ Eiríkr Útlendi │Tala við mig 19:15, 20 November 2017 (UTC)
I think I will have to put it down to my browser. I'm still using IE (with Windows 10 which may be an anachronism), as I can't be bothered moving my links stored in Favourites to another browser. Sometimes I notice it lands on Nynorsk for a split second, then jumps downwards. With pages with just two or three languages there's usually no problem. DonnanZ (talk) 19:28, 20 November 2017 (UTC)
I've had that problem with Chrome (and it can't really be helped), but with Firefox now I can go to the address bar and click enter, and it'll zoom me to the correct section. (On Chrome, that reloads the page.) — Eru·tuon 21:40, 20 November 2017 (UTC)
For the JavaScripters: What would happen if a script runs very last and manually resets the anchoring to the correct position? —Rua (mew) 19:39, 20 November 2017 (UTC)


Translation tables on my browser (Chrome. see: reorganize) have developed a horizontal scroll bar - is this a temporary glitch, or what? — Saltmarsh. 16:35, 20 November 2017 (UTC)

  • No such scroll bar on my Chrome. SemperBlotto (talk) 16:41, 20 November 2017 (UTC)
  • @SemperBlotto: Thanks - "Preferences/Enable targeted translations" makes it come and go. It also appears with all the "pull-down" inflection tables which I have looked at. — Saltmarsh. 18:58, 20 November 2017 (UTC)

Text appearing oddly big at nála[edit]

The link to the lemma in Northern Sami nála is looking really big for some reason. Does anyone know why? —Rua (mew) 21:58, 20 November 2017 (UTC)

According to my Firefox "inspect" window, it's because of the style rule Tibt .use-with-mention .mention, .form-of-definition-link .mention { font-size: 160%; } in MediaWiki:Common.css. I don't know why that's being applied here, because I doubt there are really any <Tibt> tags anywhere, but changing Tibt to .Tibt should fix the problem. — Eru·tuon 22:16, 20 November 2017 (UTC)
Oh, duh, the second selector .form-of-definition-link .mention is what's applying. That should be prefixed by .Tibt too. — Eru·tuon 22:17, 20 November 2017 (UTC)
I came across this with {{alternative form of}}. DonnanZ (talk) 22:23, 20 November 2017 (UTC)
Still happening, see undervassbåt. DonnanZ (talk) 23:07, 20 November 2017 (UTC)
@Wyang: I think this edit caused the problem. The selectors should perhaps be changed to .Tibt .use-with-mention .mention, .Tibt .form-of-definition-link .mention to get the rule to do what you intend. — Eru·tuon 23:09, 20 November 2017 (UTC)
Thanks! Wyang (talk) 23:17, 20 November 2017 (UTC)
I reverted the problematic change until it's fixed. —Rua (mew) 23:09, 20 November 2017 (UTC)
More easily fixed than reverted. 😂 Wyang (talk) 23:17, 20 November 2017 (UTC)

Esperanto headword[edit]

I am going to convert all these using templates to {{eo-head}}:

  • eo-noun, eo-verb, eo-adj
  • head|eo|noun form, head|eo|verb form, head|eo|adjective form

since Esperanto rules are fixed and they can be autodetected in Module:eo-headword. --Octahedron80 (talk) 00:18, 21 November 2017 (UTC)


It is found in MediaWiki:Common.css and Module:scripts/data as an alias for Korean (I think?), but it is actually used (i.e. can it be removed)? (I removed two manual uses here and here. Unless my search query for Special:Search is bad, those were the only manual uses in the dictionary.) —suzukaze (tc) 07:20, 21 November 2017 (UTC)

Well, it's not used by any languages (i.e., not found in any language data modules) according to Module:data consistency check. — Eru·tuon 07:46, 21 November 2017 (UTC)


Lua error: not enough memory. --Barytonesis (talk) 13:05, 21 November 2017 (UTC)

@Barytonesis: Current solution is to move the largest Translations section to a /translations subpage. — Eru·tuon 22:00, 21 November 2017 (UTC)