Wiktionary:Grease pit/2013/August

xan
 seems to have been the magic invocation on the outer containing frame.) –Catsidhe (verba, facta) 03:34, 5 August 2013 (UTC)


 * Looks great! Thank you very much for your help today! --Anatoli (обсудить/вклад) 03:39, 5 August 2013 (UTC)

Positioning transliterations in inflection tables with CSS
At User talk:Vahagn Petrosyan I suggested modifying specifically for use in inflection tables (by creating a new  which may or may not replace  altogether, depending on how much it's needed elsewhere - but that's beside the point right now; maybe a new template isn't needed). The problem is automatic transliterations. We definitely want them, but we don't want to tie the way they display into the template, because different tables may want to display the transliteration differently. The Russian verb inflection tables, for example, put the transliteration on the line below the main word and display it in grey text, and without parentheses. To account for all these different styles I figured we could use CSS to do the positioning. But how can this be done? Is there a way to say, in CSS, that the transliterations in one table should not have parentheses and be displayed below, while the transliterations in another table should have them and be displayed beside? 11:07, 5 August 2013 (UTC)
 * We should probably use


 * to put transliteration in a new line and use  to remove parentheses. --Z 17:23, 5 August 2013 (UTC)
 * Isn't it possible to use CSS to put the parentheses in, rather than remove them? 17:25, 5 August 2013 (UTC)
 * What do you mean by "to put the parentheses in"? If you mean "Isn't it possible to use CSS to add the parentheses", no, not with CSS... --Z 17:32, 5 August 2013 (UTC)


 * You can add brackets with this CSS:


 * But this is probably a bad idea. Parentheses give meaning; they are part of the text, not optional style. And if you are hard-wrapping text in table rows, shouldn’t you be adding table rows instead? Just keep it simple. —Michael Z. 2013-09-08 01:59 z 

Help with suffixes, adding line breaks where it shouldn't
I'm struggling to get working. I made a module function to generate the correct form of the suffix. But the software keeps adding a line break in front of the * that is used for reconstructed terms. So when I type:

test

it comes out as:

test
 * -atjaną

where the two parts have been broken up by a newline, which turns the * into a list bullet. Does anyone know why it's doing this, and how to prevent this from happening? 15:16, 5 August 2013 (UTC)
 * Fixed. --Z 16:59, 5 August 2013 (UTC)
 * No, I fixed it, and you broke it again in another way... See Category:Proto-Germanic words suffixed with *-atjaną. 17:13, 5 August 2013 (UTC)
 * Are you sure? I reverted my edit and  adds line-break now. --Z 17:19, 5 August 2013 (UTC)
 * Yes that still happens, but I found a workaround for it. I made which is able to strip off the newline again. It's not nice but it works... let's hope they fix this bug soon. I reported it but it turns out it was reported 5 years ago  and never fixed. Kind of sad...  17:24, 5 August 2013 (UTC)

Who's Flying this Plane?
When Wiktionary site coding needs to get changed at a deeper level than editors can do, how do editors let someone who can do that, know that it needs to be done?

My deepest probing of the Help pages finds not a trace of "technical administrators" -- let alone the "Wiktionary Web development team".

HanEditor (talk) 09:25, 6 August 2013 (UTC) hanEditor


 * The Wikimedia Foundation people. Maybe you can get some help here. What needs to be done anyway? — Ungoliant (Falai) 09:48, 6 August 2013 (UTC)


 * If you've noticed a bug, you can report it to Bugzilla. You might also find MediaWiki helpful. - -sche (discuss) 17:20, 6 August 2013 (UTC)

Well I'm trying to find someone who can do some content-alteration batch jobs across hundreds or thousands of pages.

Maybe is there an existing bot that can do this, with customized parameters? Or is there some editor or admin who can easily create a custom bot for specific content-replacement tasks?

Frankly I hope I can't do this as a mere mortal editor (even if I had the vaguest clue how to code a bot), as of course this has the potential to replace content in all articles with vandalism.

But part of the point is that this seems like something fairly normal to do -- some minor formatting issue across articles, missing commas, etc. So I'm kind of bemused and frustrated that there isn't some standing official way to do this, and helpful people in the Grease Pit directing me to get it done quickly and painlessly.

HanEditor (talk) 08:39, 7 August 2013 (UTC) hanEditor


 * 'Kay. So. Anyone volunteering to manually enter an asterisk meaning "reconstructed form" in each of a thousand or more Middle Chinese entries? Crickets... crickets...
 * HanEditor (talk) 09:40, 9 August 2013 (UTC)
 * There are several users who operate bots, who might not be monitoring this discussion. You might look at RC changes by bots for one which is operating and making edits similar to what you are interested in, and contact that bot's owner. (Each bot's operator is clearly stated on the bot account's user page.) - Amgine/t&middot;e 14:13, 10 August 2013 (UTC)

Thanks, I've been looking for the Bot People. But I think I'm leaving this basic Wiktionary editing functionality issue now for others more involved in Wiktionary than I am to work out at some point. HanEditor (talk) 08:19, 15 August 2013 (UTC)

Private Use characters
Is there a way to find entries which use characters from the Private Use Area (possibly from a dump)? They should never occur in entries, but I've seen them when looking through Chinese characters. -- Liliana • 12:54, 6 August 2013 (UTC)
 * User:DTLHS/private use DTLHS (talk) 00:27, 7 August 2013 (UTC)

Killer Robots Eating My Alternate Chinese Characters
I'm trying to discuss the alternate forms of a Chinese character, and something in Wiktionary (basic text handling?, bot?) is physically converting the obscure characters to their more common equivalent. That is, I type the obscure character into the edit form. It's there. Then I click Preview, and the actual character has been replaced -- both in the rendered preview, and in the text editing window.

For one of the obscure characters, I managed to (partly) get around this, by using its Unicode number as an HTML special character (&#x-number-semicolon). I now get the obscure character displayed. But... it won't display as a link.

(I'm not sure if that's because it's an HTML character code not text, or because Wiktionary is "referring" the obscure character to the page for the more common character -- which is the current page, meaning no link.)

For a second obscure character, even using the Unicode HTML code doesn't work. The rendered page converts it to the more common character for display (though the Unicode HTML code remains present in the page source).

The two obscure characters are U+FA5E and U+FA5D, and Wiktionary is trying to convert them to U+8279.

The crime scene: http://en.wiktionary.org/wiki/艹

Thanks, HanEditor (talk) 09:54, 7 August 2013 (UTC) hanEditor
 * That's due to Wiktionary using NFC conversion which turns the compatibility characters back into unified characters. You can use HTML entities as a workaround to display these, and you can even link them (observe: & &) but they will always link back to the normalized form - and since you are on the link target already, they will display in bold instead. I guess you could abuse, as in , which will always link to itself due to the addition of a section anchor , but other than that, there's not much you can do. -- Liliana • 11:12, 7 August 2013 (UTC)


 * Thanks Liliana. I'm now seeing that it actually is displaying the U+FA5E character, when the Unicode code is used. (It's so tiny the two crosses blur together.)


 * And I also now see that being able to link the characters is pointless. I had wanted to create stub pages for them, but no one will be able to search for those anyway (they'll get auto-referred to the standard character page).


 * So resolved enough.
 * HanEditor (talk) 09:42, 9 August 2013 (UTC)

Template:sv-adj
Could someone please figure out how to grandfather in stuff like nära and make them work as is? —Μετάknowledge discuss/deeds 17:52, 7 August 2013 (UTC)
 * Fixed I think. --Z 08:30, 8 August 2013 (UTC)

is not linking to the correct circumfixes. For an example, see მესაქონლე. The circumfix is split it into a prefix and a suffix (which don't even seem to exist independently). Can someone please fix this? Ultimateria (talk) 06:09, 9 August 2013 (UTC)

Unicode "Kangxi Radicals" Block Characters Causing Wiktionary Error
The Unicode "Kangxi Radicals" and "Kangxi Radicals Supplement" blocks —


 * http://en.wikipedia.org/wiki/Kangxi_radical#Unicode
 * http://en.wikipedia.org/wiki/Template:Unicode_chart_CJK_Radicals_Supplement

contains duplicate characters from the main "CKJ Unified Ideographs" block.

Currently, trying to search for them in Wiktionary produces an error:


 * http://en.wiktionary.org/w/index.php?search=⺒&title=Special%3ASearch

They should at least be getting referred to the main equivalent character (I forget what Unicode calls these equivalency referrals).

But an issue is that — in the interest of being exceedingly detailed-oriented and exactingly Unicode-correct — perhaps Wiktionary should be using these "Radical" characters themselves in articles when discussing a character-as-radical, in contrast to using the main character when discussing the character-as-character. Unless (like some other Unicode blocks) it's been decided, officially or in general best practices, to deprecate the Unicode Radicals blocks (as they lack many of the variant radical forms needed anyway). All that is a discussion for the Beer Parlour not here, but may inform your opinion of what should be happening with the Unicode Radicals informatically.

Thanks HanEditor (talk) 10:11, 9 August 2013 (UTC) As for the search, that is a known defect. We will supposedly be getting a better search soon, but who knows when that will be. -- Liliana • 11:59, 9 August 2013 (UTC)
 * I don't think they should be used at all. Most Chinese fonts do not contain these characters, so all users will see is boxes, which isn't really helpful. We should probably have redirects from the Kangxi Radicals to the equivalent character from the CJK block though.

help with lua
I was wondering if I could bother someone to help me with Module:ja. In the function kana_to_romaji, it fails to transliterate the character ッ properly when it is the first character, e.g. at 物質. I want to know which entries currently do that, perhaps by the module throwing an error whenever it returns text that contains ッ. I tried to do it myself but my code just threw an error in every case. Ideally the ッ character (or its counterpart っ in hiragana) should just be ignored when it is the first or last character, but I was hoping there was some way I could know about when that happened. Any help would be much appreciated. --Haplology (talk) 15:56, 9 August 2013 (UTC)
 * I looked at the module, but there is no documentation of how it works anywhere, or even any comments in the code to describe the purpose of each part. That makes it very hard for me to understand what's going on, let alone what's going wrong. Someone would need to know what each part is supposed to do, first, before they can figure out where/why it's not doing what it's supposed to. 16:11, 9 August 2013 (UTC)
 * Fixed I think. --Z 21:26, 9 August 2013 (UTC)
 * Thanks! I decided to keep the existing function for the case of when the ッ character came first, and commented out the line that (I think) does that.  Sorry I misspoke before.  When it comes last, it should definitely be dropped and now it does that correctly.  Thanks for the help! --Haplology (talk) 02:53, 10 August 2013 (UTC)
 * Seems like kanjitab is being replaced with kanjireadingstab. I don't, however, agree with the logic of the current code in 物質. The first consonant in geminate sokuon in kango comes from Middle Chinese checked tone syllables, and should not be assigned to the second character. Hence the more preferable analysis is buQ (< butsu) + shitsu > busshitsu. And in the case of 発表, haQ (< hatsu < *patsu) + *pyō (> hyō) > happyō. Wyang (talk) 04:17, 10 August 2013 (UTC)
 * I don't completely understand, but it looks like I tried to do too much with kanjitab by displaying the readings following sound changes. For the time being at least I'll do away with those and only display the readings as they appear on kanji entries.  If anybody agrees, disagrees, or has any feedback on any of it, please let me know, or if anybody knows what it  should do, feel free to edit it.--Haplology (talk) 14:52, 12 August 2013 (UTC)

Use positional parameter instead of alt= for translations?
The convention that has developed over time is to put the alternative display for a link in a positional parameter after the entry name. For example, , the form-of templates and many more work this way. But one exception has always been the translation templates, which instead use the following parameter for the gender, and specify the alternative display form with alt=. I would like to bring these templates in line with the others. This means that what used to be written as (or similar) now becomes, and  becomes. This is not a big change, but a bot will need to update all old uses, and any existing bots and scripts (particularly XTE and the translation adder) will have to be changed as well. In any case, if there is consensus to do it, the change can't be made yet in any case because Kephir is currently away so he can't update his script and I'm not able to do it myself. 17:04, 11 August 2013 (UTC)
 * I think it's a bad idea, because it forces us to put in an extra  pipe for the majority of entries to simplify a minority of entries. Obviously, most editors will not be directly editing the translation tables, but I sometimes do to fix something, and this could be rather annoying. No benefit, minor loss.—Μετάknowledge discuss/deeds 20:49, 11 August 2013 (UTC)
 * I agree that putting an extra pipe is annoying. For I have to count the number of pipes before I put in the gloss in position 3 and I often make mistakes. The minority of entries that use an alternative form should use alt=; I am not talking just about, but also   ,  and form-of templates. --Vahag (talk) 21:03, 11 August 2013 (UTC)
 * I agree with this, having unnamed parameters for more than two optional ones is a bad idea. Moreover, now that we have Module:links, we don't need the alt parameter as much as before. --Z 00:55, 12 August 2013 (UTC)

IPA validator by language
There was talk of an IPA validator module to make sure that only IPA characters are being used in IPA transcriptions. I don't know if that's being used yet, but in any case I think we should also have a module to validate and fix IPA based on a manually created list (similar to sorting, but probably shouldn't be in Module:languages, since only will use it). For example, the character  should never be used in English IPA, and the character   should never be used in a broad transcription for English. These would categorise in an attention category. On the other hand, if someone types  in a broad English transcription, we know they mean , and it should be automatically replaced. Is this feasible and/or a good idea? —Μετάknowledge discuss/deeds 20:55, 11 August 2013 (UTC)
 * I'm leery of assuming we know everything about how something like IPA will be used. After all, you've just used some of the never-to-be used ones right now- in English. For all the times when people get things wrong, there are still times when you don't want to have templates reporting on you (or worse- correcting you) because someone, somewhere decided that no one could ever possibly have a reason to use certain characters in a certain language. I can understand not allowing the wrong phi, or the multiplication symbol instead of x- but these are valid IPA. It's like the way Windows has taken to saying "are you sure?" every single time you run your own code, after warning you that it could contain malware. Chuck Entz (talk) 08:11, 12 August 2013 (UTC)
 * Yes, but notation and pronunciation are separate things, and although the latter is fluid, the former is stable and accepted. Moreover, we'd have to have an override parameter. A lot of languages have people regularly messing stuff up. I will try to run my bot to catch some errors I'm aware of in our Latin entries, but it would be a lot easier to have a module deal with it. —Μετάknowledge discuss/deeds 16:57, 12 August 2013 (UTC)

{t} generating extra space
I'm seeing an extra space after each hvc translation at Haitian Vodoun Culture Language. —Μετάknowledge discuss/deeds 05:17, 12 August 2013 (UTC)

I'm not sure if Lua offers a straightforward way to tell if a table is empty; if so, we can just change this line. If not, then one approach is to initialize genders to nil rather than {}, and then write  in the while-loop that populates it, and change the test to just. —Ruakh TALK 06:05, 12 August 2013 (UTC)
 * The problem is in Module:translations, where it says . {} creates a new table, and equality comparisons of tables are performed by reference (meaning that a given table is equal only to itself, not to other tables containing the same data), so this condition is always met. As a result, a non-breaking space &amp;nbsp;</tt> is always inserted before the gender, even when there is no gender information.
 * I think this fixed it:  12:46, 12 August 2013 (UTC)

, "Category:(language name) reflexive verbs"
I've made some changes, which add verbs to "Category:(language name) reflexive verbs". The parameter "lang=" becomes mandatory. Is there a quick way to add language codes to entries using it? If you hate this change, please revert. --Anatoli (обсудить/вклад) 05:06, 14 August 2013 (UTC)


 * I've edited examples: in Czech (dívat se), Spanish (peinarse) and German (sich vorstellen). French seems to disallow reflexive verb entries. --Anatoli (обсудить/вклад) 05:15, 14 August 2013 (UTC)
 * They get listed under the non-reflexive entry, such as on . Mglovesfun (talk) 09:50, 14 August 2013 (UTC)


 * It's actually, not Yes, German verbs should either follow the French format, then entries should be allowed to have  or have separate entries, which would use  and add to reflexive categories. --Anatoli (обсудить/вклад) 10:10, 14 August 2013 (UTC)
 * Dutch entries follow the French format as well. I think in general it makes more sense to do reflexive verbs this way if the reflexive inflected forms of the verb don't count as distinct words. This is different from, say, Russian, where the reflexive particle fuses onto the verb form and creates a new word. I'm not sure about Catalan; the two do fuse at least somewhat (and the apocope of -r in the infinitive is even undone in -r-se), but are still recognisably separate in spelling. 11:09, 14 August 2013 (UTC)

Template:term
is broken. It returns "Script error" wherever it is used. —Stephen (Talk) 12:40, 15 August 2013 (UTC)
 * At the risk of sounding blasé, it's just CodeCat experimenting with modules that are used on every fucking page of this wiki. Mglovesfun (talk) 13:24, 15 August 2013 (UTC)
 * Experimenting? Really? I was actually fixing an error with, but made some mistakes, which were then corrected. See User talk:ZxxZxxZ. I don't understand why people post about it here when these kinds of problems are usually fixed immediately. A bit of patience and faith helps. 13:27, 15 August 2013 (UTC)
 * We have categories of thousands of entries with script errors that don't seem to be going away. DCDuring TALK 15:18, 15 August 2013 (UTC)
 * Don't trust the categories. The software takes some time to keep categories updated, sometimes even days can go by before the categories contain only the entries they should. I'm getting MewBot to do null edits on the entries in the category though, which forces an update. 15:28, 15 August 2013 (UTC)
 * I was being tongue-in-cheek, it's really easy to screw up these edits and then fix them later. I've done it before to things like . Mglovesfun (talk) 19:44, 15 August 2013 (UTC)
 * Maybe not the best idea. So many people have been complaining about how they are confused by all Lua-related changes lately, that I assume that anything Lua-related is yet another complaint. 21:28, 15 August 2013 (UTC)
 * And I'm sure that many people now assume that anything broken is yet another half-baked Lua-related change. So I guess you're even? ;-)  —Ruakh <i >TALK</i > 04:11, 18 August 2013 (UTC)

popups not working
Some time between the 7th and today, navigation popups have stopped working for me here at Wiktionary. I've checked my preferences and the appropriate box is ticked, and they still work at Wikipedia. I've tried doing hard refresh of various pages, and ?action=purge on a couple but that hasn't helped, and I continue to not see them on any page.

Any ideas? Thryduulf (talk) 12:03, 16 August 2013 (UTC)


 * Does your browser's error console tell you anything useful? —Ruakh <i >TALK</i > 15:12, 16 August 2013 (UTC)


 * Well it says "[01:56:24.479] Blocked loading mixed active content "http://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript" @ https://bits.wikimedia.org/en.wiktionary.org/load.php?debug=false&lang=en-gb&modules=ext.centralNotice.bannerController%7Cext.dismissableSiteNotice%7Cext.uls.displaysettings%2Ci18n%2Cime%2Cinit%2Cinputsettings%2Cinterface%2Clanguagenames%2Clanguagesettings%2Cpreferences%2Cwebfonts%7Cext.uls.webfonts.repository%7Cjquery.client%2Ccookie%2Ci18n%2Cime%2CjStorage%2Cjson%2CmwExtension%2Ctipsy%2Culs%2Cwebfonts%7Cjquery.uls.data%2Cgrid%7Cmediawiki.Uri%2Capi%2Cnotify%2Cuser%2Cutil%7Cmediawiki.api.parse%7Cmediawiki.legacy.ajax%2Cwikibits%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.startup&skin=monobook&version=20130817T005621Z&*:336" and something very similar with css but I don't know what it means or whether it is important. I do use noscript and addblock but both Wikipedia and Wiktionary are whitelisted. Thryduulf (talk) 01:01, 17 August 2013 (UTC)

I have made a change to MediaWiki:Gadget-popups.js that should hopefully fix this, by loading the referenced script and stylesheet over HTTPS if appropriate. &#x5B;diff&#x5D;  Please do a hard-refresh or cache-clearing or whatnot, and let me know whether the Gadget starts working for you. —Ruakh <i >TALK</i > 04:11, 17 August 2013 (UTC)
 * I see. Yeah, that's a new Firefox feature, whereby it forbids an HTTPS web-page from loading scripts or stylesheets over HTTP (since that's a major security hole: if there's an attacker sitting between your browser and the HTTP server — a "man in the middle" — then the attacker can replace the scripts and stylesheets with anything (s)he wants, and thereby access or modify the supposedly-HTTPS page with impunity). &#x5B;relevant blog post&#x5D;
 * Ok that worked, thank you. Thryduulf (talk) 17:16, 18 August 2013 (UTC)

sw-noun problem
is behaving oddly and I'm not quite sure why... probably some stupid mistake. Example of problem is at kiandarua cha mbu, which is displaying both the correct plural (given as 2nd parameter) and incorrect autogenerated plural. —Μετάknowledge discuss/deeds 07:15, 17 August 2013 (UTC)
 * I gave it a shot. Can you check a bunch of Swahili entries to see if it’s working and if I didn’t break anything? — Ungoliant (Falai) 14:02, 17 August 2013 (UTC)
 * Thank you, that did it. Looking at your edit now, it seems obvious. Ah well. —Μετάknowledge discuss/deeds 17:12, 17 August 2013 (UTC)

Template:confix categorization

 * Why doesn't categorize, say, oneironaut into Category:English words prefixed with oneiro-? DCDuring TALK  11:56, 19 August 2013 (UTC)
 * Should be working now. — Ungoliant (Falai) 12:17, 19 August 2013 (UTC)
 * Yes, thanks. DCDuring TALK 12:31, 19 August 2013 (UTC)

Use of &lt;pre&gt;
Is it the use of  on a page that causes a horizontal scroll bar to appear on my browser as on Grease pit/2013/August? Is there an alternative that would not? DCDuring TALK 12:03, 19 August 2013 (UTC)
 * It’s the huge link at, as far as I can tell. — Ungoliant (Falai) 12:20, 19 August 2013 (UTC)
 * Confirmed. I've now wrapped the relevant comment in <tt>&lt;div style="overflow:scroll"&gt;</tt>, so it has its own scrollbars and won't cause the whole page to need them. (This may not be the most elegant solution, but it's the first one that came to mind.) —Ruakh <i >TALK</i > 05:58, 20 August 2013 (UTC)
 * Thanks. I'll try to remember the cause and the fix for the next time. DCDuring TALK 13:02, 20 August 2013 (UTC)

Citation Needed Template
Don't we need a "citation needed" (or "reference needed") template?

But someone deleted this years ago:

̉http://en.wiktionary.org/w/index.php?title=Template:citation_needed&action=edit&redlink=1

HanEditor (talk) 09:53, 20 August 2013 (UTC)


 * I realize this is a Beer Parlour issue first... then back here for doing it technically:
 * * http://en.wiktionary.org/wiki/Wiktionary:Beer_parlour/2013/August#Citation_Needed_Template
 * HanEditor (talk) 10:12, 20 August 2013 (UTC)


 * We have for that. —Angr 14:58, 20 August 2013 (UTC)


 * Thanks... HanEditor (talk) 07:29, 23 August 2013 (UTC)

((en-adj|-)) is broken
is broken. See e.g. Chicano. Equinox ◑ 04:57, 21 August 2013 (UTC)


 * I think it was left over from one of CodeCat's bad edits to Module:en-headword; I null-edited Chicano, which fixed that page. Dunno if there are others affected. (I'm not sure why she's making so many experimental edits to such a widely-transcluded module — nor, for that matter, why the module's documentation says simply "Under construction", as though it weren't already in use on twenty bajillion pages — but regardless, she doesn't seem likely to stop any time soon, so I suggest we simply get used to it. Functional web-sites are overrated anyway.) —Ruakh <i >TALK</i > 05:58, 21 August 2013 (UTC)
 * I'm sorry for not making the scaffolding more clear. The "under construction" part is there because the way the templates/module work isn't yet set in stone. That's partly because the changes I've been making have been to convert all the existing uses of the template. My aim was to make it able to handle more cases that it currently does not, while still being as easy to use as before. I think that's done now, I will update the documentation. 15:48, 21 August 2013 (UTC)
 * Ok, it's done. 16:57, 21 August 2013 (UTC)
 * Surely you could have done that without the intermediate step of breaking everything? The way the templates/module work should have been set in stone (as much as anything on a wiki is) before being turned on. —Ruakh <i >TALK</i > 18:38, 21 August 2013 (UTC)
 * But the new way would have been incompatible with the old version. I spent most of yesterday trying to find any incompatible entries and fixing them in such a way that didn't break them too much in the meantime, but that was very hard and I did slip up once or twice. Please forgive me. 18:48, 21 August 2013 (UTC)
 * Man, you're making it really hard to stay annoyed. :-P  I still don't understand why incompatible changes were necessary, but I appreciate the effort you put into identifying and minimizing the impact. —Ruakh <i >TALK</i > 20:33, 21 August 2013 (UTC)
 * The original templates were actually rather limited and had many strange exceptions in them that made them hard to extend. For example, you could specify that the first comparative should be some word and alternatively with "more" (with ), but not the other way around ( didn't work). It was also somewhat counterintuitive IMO that the second parameter could be either a second comparative, or a superlative, and the first parameter could be either a comparative form or only a stem. You can probably understand that it's hard to make a template that handles all those cases in a nice and intuitive way. So I changed it so that positional parameters give only the comparatives, but as many as you like and they all work identically. You don't need to specify the stem anymore, because the superlative can be generated from the comparative by removing -er. That in turn makes the superlative parameter less often needed, so it was turned into a named parameter. 21:00, 21 August 2013 (UTC)

Special:SpecialPages
The pages that are normally run every 3-4 days haven't been run since 13 August. Where could I find out why or could someone with good irc-foo or bugzilla-foo find out? DCDuring TALK 01:19, 22 August 2013 (UTC)
 * We may get run in the next few several hours. DCDuring TALK 00:47, 24 August 2013 (UTC)

Upcoming bug triage for RTL issues
Among the bugs being discussed in this one hour session are improvements in fonts for Arab and Hebr. More details can be found here. —Μετάknowledge discuss/deeds 23:58, 23 August 2013 (UTC)

Audio bot
Could somebody please check if my bot does not spoil anything while adding audio files? I am not active on en.wiktionary and don't check latest policy changes. Bot contributions: Special:Contributions/DerbethBot. --Derbeth talk 10:07, 24 August 2013 (UTC)

(?), (!)
These are currently in Special:UncategorizedPages because of sorting issues. For (A) I sorted it as a which worked, for these two, I don't know. Whether these are valid is another question, looks a lot like a question mark and an exclamation mark inside brackets to me. Mglovesfun (talk) 18:52, 24 August 2013 (UTC)
 * I fixed the problem, it was in which was ignoring the sort parameter altogether. The real culprit is in Module:utilities though. Certain characters are stripped, but when all characters are stripped you end up with nothing left, which is what happened here I think.  18:57, 24 August 2013 (UTC)
 * Ok, I think it's fixed properly now. The original rules would remove any text between brackets when generating the sort key. I changed the rules so that it's only removed if either some text precedes or follows, so that if the whole term is in brackets, it's not removed. 19:29, 24 August 2013 (UTC)


 * Interesting entries. I think it's useful to note that ! and ? (unlike all other punctuation) can stand alone in brackets like this. As far as SoP goes, can they stand alone outside brackets? Equinox ◑ 23:09, 24 August 2013 (UTC)

cs-decl-noun-auto
Something is wrong with the Czech declension template (example, see ). Each form shows, a hard return, and , but are not linked. —Stephen (Talk) 20:08, 24 August 2013 (UTC)
 * This is probably happening because the template does not have comments around the line breaks in the code. These line breaks are then added to the inflected forms, and displayed in the table.  20:36, 24 August 2013 (UTC)


 * I think it probably comes from . I tried adding to it, but I only made it worse. I had to undo the edit. —Stephen (Talk) 20:57, 24 August 2013 (UTC)


 * does not seem to cause the problem; it is used directly in krkavec and it looks okay. The problem seems to be with, and indeed seem to do with missing . It actually used to work, but is now broken probably as a result of changes in Mediawiki. The problem has already in part been fixed, as is obvious from kuře entry. The fix is due to edits by Alekxzar to Template:cs-decl-noun-auto; more such edits should fix the issues altogether. --Dan Polansky (talk) 21:21, 24 August 2013 (UTC)

Template:fro-decl-adj
I believe Module:fro-utilities, if employed in fro-decl-adj and fro-decl-noun, would mean that explicit parameters wouldn't be needed most of the time; for example in the automatic plural would be  using fro-utilities's plural lookup function. Just I have no idea how to implement it. Mglovesfun (talk) 12:39, 25 August 2013 (UTC)
 * You could make a start by making a Lua module named Module:fro-adjective, and put a single function in it that, given a table (Lua table, which is a data type) of forms, displays those forms. This is the same as what table templates like do, they don't contain any "grammar logic", they just show whatever is given to them. Once you have this function, you can then write one or more functions that provides this table with forms to show. See Module:nl-adjective, Module:nl-verb or Module:ca-verb for examples (in each case, the table-displaying function is down the bottom).  12:45, 25 August 2013 (UTC)

Making WT:NFE more visible, and the sitenotice more useful
Currently there is MediaWiki:Sitenotice, but that just always displays the same and I don't think anyone ever pays attention to it. At the same time, WT:NFE is often missed or ignored because it's not visible or well known enough. I think it would be nice if we could show recent news automatically in the site notice. But I don't know how that can be done or what the best way is. Subpages for each day might work, but then there would need to be some code that checks for the presence of each page, which means #ifexist which is "expensive". An RSS stream would be ideal, but I have no idea how to implement that at all, let alone how to make the site notice use it. So, any ideas? 16:55, 25 August 2013 (UTC)
 * Since it is to be hoped that we have a lot more non-contributing users than the relatively meager number of active contributors, why would we want to burden the numerous users with something of no use to them? DCDuring TALK 17:28, 25 August 2013 (UTC)
 * Is there a way to add it to a user’s watchlist automatically when the account is created? That would help a little. — Ungoliant (Falai) 17:52, 25 August 2013 (UTC)
 * That's a good idea. That shifts the problem to having useful or interesting content as well as taking casual, passive users out of the picture. DCDuring TALK 18:07, 25 August 2013 (UTC)
 * I don't think it's a good idea at all. Putting it in the site notice is much better. If it's such a burden to casual users, we can always hide it for users who are not logged in, but I think you're just exaggerating again as usual. 18:13, 25 August 2013 (UTC)
 * One does not preclude the other. — Ungoliant (Falai) 18:17, 25 August 2013 (UTC)
 * I have never understood how we can have conversations about the user interface without bothering to mention the users we purport to serve, or, more accurately, I suppose, the users that others think we intend to serve: we don't seem to have any such illusions: We know we serve only ourselves, all others are afterthoughts. DCDuring TALK 18:30, 25 August 2013 (UTC)
 * What purpose do you think a page called "News for editors" would have for non-editing users? I can't think of any. So why is it a problem? The Grease Pit has no purpose for non-editors either, does that bother you as well? 18:33, 25 August 2013 (UTC)


 * I oppose making News for editors more visible. If it can disappear from SiteNotice altogether, so much better. --Dan Polansky (talk) 19:56, 25 August 2013 (UTC)
 * Do you think it's visible enough? 20:04, 25 August 2013 (UTC)
 * Apparently its purpose is to broadcast "news" from CodeCat, who has kindly provided 21 of the last 26 edits. I don't see why passive users should have its visibility increased in any way for them.  Interested active contributors can watch the page.  It is hardly a substitute for BP discussion as it is just one-way. DCDuring TALK  20:27, 25 August 2013 (UTC)
 * How is it my fault if nobody else puts news there? 20:35, 25 August 2013 (UTC)
 * Perhaps we could duplicate the news directly in a watchlist notice. I don't think using a general sitenotice for editor news is a good idea. --Yair rand (talk) 00:18, 26 August 2013 (UTC)
 * You do realise that it has been used for that purpose for years, right? I'm just proposing to put something more useful than a link to WT:NFE in there. 00:21, 26 August 2013 (UTC)
 * I do realize that it's been used for that for years. I don't think it's a good idea. I think the sitenotice should be generally kept empty. It takes up quite a bit of space. --Yair rand (talk) 00:27, 26 August 2013 (UTC)


 * There already is a newsfeed (though it's Atom, not RSS): every page's history on a wiki gets one. Equinox ◑ 03:47, 26 August 2013 (UTC)


 * We have a visible but useless sitenotice, and an oft-overlooked page of News for Editors... I agree with CodeCat that it would make sense to incorporate the news into the sitenotice. I also agree with the suggestion of making the sitenotice visible only to logged-in users (or, if possible, even only to autoconfirmed users) so that it doesn't take up any space on the screens of non-editors. - -sche (discuss) 18:56, 27 August 2013 (UTC)

or issues spotted
Please see current Russian translations of "ease nature". Something weird is happening: отправля́ть есте́ственные на́добности. The automatic transliteration currently shows both the displayed and the linked forms and the pipe "|": "otpravljatʹ|otpravljátʹ jestestvennyj|jestéstvennyje nadobnostʹ|nádobnosti", should be "otpravljátʹ jestéstvennyje nádobnosti". I've tried both and. Let me know if I did something wrong. --Anatoli (обсудить/вклад) 01:44, 27 August 2013 (UTC)
 * I think that was caused by changes that Z made to the  function a while ago. He wanted to simplify it, but maybe a bit too much.  01:50, 27 August 2013 (UTC)


 * Thank you. I'll leave it with you unchanged. --Anatoli (обсудить/вклад) 02:01, 27 August 2013 (UTC)


 * Fixed ( works fine though) --Z 07:17, 27 August 2013 (UTC)

MediaWiki parser from Hell
While working on trying to remove all the redundant alt forms from links (per the BP discussion), I realised that it was very hard to do this with just regular expressions. You have to account for all the different orders that parameters can appear in, parameters that are or aren't present, and in the end it just was too complicated to make it work. So I tried to write a more general template parser but even that seemed harder because I'd have to mimic how MediaWiki itself parses things. While looking for more information about that, I came across a nice Python library called MediaWiki parser from Hell. It does pretty much all I ever needed it to do and it's incredibly useful as I found out, so I wanted to share it here. It converts a wiki page's source text into a parse tree, and you can then do searching and replacing with that tree instead of with raw wikitext. For example, if I want to rename a parameter from "first" to "second" from all occurrences of a template called "xx":

It interprets templates and their parameters, section names, links, comments and more, which makes it a very powerful tool for writing bots that manipulate pages in one way or another. I hope it's useful to other editors here. :) 18:15, 27 August 2013 (UTC)

Special:Search timing out
Recently I often get this error in red text while searching: "An error has occurred while searching: HTTP request timed out.". Equinox ◑ 08:55, 28 August 2013 (UTC)
 * I've been getting this too. Mglovesfun (talk) 09:40, 28 August 2013 (UTC)
 * Me, too. Has WMF cut back on our allowance or have we crossed some size threshold? DCDuring TALK 12:15, 28 August 2013 (UTC)


 * Also, I've noticed some general slowdown when editing and displaying pages, sometimes quite severe. Today it was worst around 3 p.m. GMT. Equinox ◑ 20:49, 1 September 2013 (UTC)
 * Do we have anyone who would know how to figure this out? Did we have heavy usage then?  Can we determine whether it was some outage or heavy demand for the wikis that use the servers we use? IRC? DCDuring TALK  21:32, 1 September 2013 (UTC)


 * Perhaps it's not just us. Wikipedia is giving me a similar error quite often: "An error has occurred while searching: Pool queue is full". Equinox ◑ 09:11, 20 September 2013 (UTC)
 * The search problem seems to be an interruption. "Reloading" – probably only quickly – provides the desired search results. Thus for me it's been just a minor inconvenience. DCDuring TALK 12:39, 20 September 2013 (UTC)

Template:en-noun and -y to -ies plurals
Currently, if one types on e.g. witch, the template correctly infers that it should display witches as the plural. Now that we have Lua, can we rewrite the template so that if is supplied on a page that ends in -y (e.g. oystery), it also knows to display oysteries as the plural? - -sche (discuss) 18:18, 28 August 2013 (UTC)
 * I've already been working on this for the past week. But all of my effort so far has gone into tracking the bewildering variety of parameters that the template uses/used (it's surprising how complicated a simple template like this can be made). The Lua code is already done, in Module:en-headword, but I'm waiting for all the categories to settle so that I can convert the parameters to match the module. 18:32, 28 August 2013 (UTC)
 * Also, I know you probably didn't realise, but it helps if you don't add anymore entries with the "old" parameters. I documented the changes so far on 's documentation page. The main changes are:
 * Instead of using  as the second parameter to indicate countable/uncountable, you use   as the first parameter.
 * You don't split up the word into two parts anymore, just give the whole plural as one parameter.
 * The named  parameter is deprecated. The   and   parameters will also be deprecated and converted into positional parameters, but that has to wait until all of the existing cases have been cleared out, so for the next week or so you still need to use them.  18:43, 28 August 2013 (UTC)


 * You may want to update About English. It still calls for "entr|ies" and, until just now (when I changed it), called for omitting "lang=en". - -sche (discuss) 01:43, 31 August 2013 (UTC)
 * lang=en can actually still be omitted for all templates except for and some of the form-of templates. I'm not sure if that's good practice, but it is still valid.  01:45, 31 August 2013 (UTC)
 * Do you mean or ?  actually still works (vide: word: is a bluelink to word) even with no language code specified, unlike . - -sche (discuss) 02:02, 31 August 2013 (UTC)
 * doesn't take a lang= parameter so it's required. For leaving the language out works only because making it not work would break the 20 thousand entries in Category:term cleanup.  is actually equivalent to . But it's deprecated usage, and the replacement  (whose final name is still undecided) works like, it always requires a language. I strongly believe in being explicit about the language as it prevents errors.  02:06, 31 August 2013 (UTC)
 * I'm sure this is all good progress but I wish things wouldn't just be "deprecated" (=broken) overnight. In my IT history something would be "deprecated" for an entire release, giving lots of time to fix things and learn the new method, and only actually removed one or two versions later. Even fidgety Google (with e.g. Google Maps API) gives you a few months. Or there's the OLE-style "set in stone" approach where you just leave the old version intact and create a new one (remember all those number-suffixed classes like Excel.Application9?). People do need time to learn and adjust. Equinox ◑ 18:56, 28 August 2013 (UTC)
 * You seem to have us confused with a professional operation. DCDuring TALK 21:33, 1 September 2013 (UTC)

Error trapping
Are we ever going to get professional or semi-pro, or even amateur, error-trapping and useful error messages? DCDuring TALK 15:52, 30 August 2013 (UTC)
 * What would you suggest we change about the current script error messages? 16:04, 30 August 2013 (UTC)
 * To start with, how about identifying script errors due to incorrect language codes as being due to incorrect language codes? Also nice would be, in general, tagging problems with parameters as being problems with parameters, even nicer would be tagging which parameter.
 * Right now, error messages have no diagnostic value whatsoever: we're just saying "bad! bad!", and contributors have to figure out what they did wrong with no help from us. Not that the pre-Lua ways were any better, but now that we have the capability, we should use it. It's certainly worthwhile to improve things so no one has to enter transliterations or display forms, but it would be a far greater benefit to our contributors to stop scaring them with big red "Script error" messages and start giving them clues about what they did wrong. Chuck Entz (talk) 17:49, 30 August 2013 (UTC)
 * Wouldn't have said it better. Thanks. DCDuring TALK  18:05, 30 August 2013 (UTC)
 * Is there any way to override the red "script error" message? Right now you have to click on it to find out what specifically the error is. DTLHS (talk) 20:29, 30 August 2013 (UTC)
 * I guess we could write our own error module to do custom messages (unless there's an easier way). DTLHS (talk) 20:44, 30 August 2013 (UTC)
 * For a minute I was going to say that if clicking gives something useful, then we don't need an error module. But then I created an error, clicked on  Script error , and found:
 * Lua error in Module:labels at line 37: You must specify at least one label.
 * Backtrace:
 * [C]: in function "error"
 * Module:labels:37: in function "chunk"
 * mw.lua:553: in function "chunk"
 * Not completely useless to me (the first line helped), but to a newbie? And they have to want to click on it.  DCDuring TALK  21:21, 30 August 2013 (UTC)
 * Yes, it's possible to change both the big red message and the text it shows when you click on it. 21:53, 30 August 2013 (UTC)
 * Scribunto's error sucks, the message should be visible without clicking on anything, just like the errors of MediaWiki software (I bet most of even active users don't know there's a message for them if they click on "Script error"). Someone should file a request in . --Z 18:14, 6 September 2013 (UTC)
 * We can change the appearance and the displayed message. How do you think it should look? 18:29, 6 September 2013 (UTC)
 * Ideally it should be something like Script error: The code "whatever" is not a valid language code. and, like the current errors, we should be able to see which lines of the code caused the error by clicking on the error text. But we can't do that, can we? If you call, only the error will be returned nothing else, so you can't add the error message to the returned string, and we can't make the error text clickable like those of Scribunto. --Z 18:43, 6 September 2013 (UTC)
 * We can make it look like that if we want, although we may want to make the text a bit smaller. I'm not sure if I understand the rest of your message, though. Which returned string? 18:46, 6 September 2013 (UTC)
 * I mean we can't change "Script error" to "Script error: ", can we? How? --Z 18:50, 6 September 2013 (UTC)
 * As far as I know we can. We can change a range of messages by editing one of [//en.wiktionary.org/w/index.php?title=Special%3AAllMessages&prefix=scribunto&filter=all&lang=en&limit=50 these messages]. 18:58, 6 September 2013 (UTC)
 * It must be MediaWiki:Scribunto-parser-error. How are you going to put the explanation of error (which is variable) there? We can't do that, unless a placeholder ($1, etc.) is already defined as the error message for this particular message (MediaWiki:Scribunto-parser-error). --Z 19:17, 6 September 2013 (UTC)
 * I changed "Script error" to "Script error $1 $2" in MediaWiki:Scribunto-parser-error to test it and the error messages simply became " Script error $1 $2 ", so we can't do that, but we can request at bugzilla to reserve $1 as the first parameter of  for MediaWiki:Scribunto-parser-error. --Z 19:34, 6 September 2013 (UTC)
 * It would be nice to add something like (click for details) or (details) . I'm one of those active users who never realized that you could click on " Script error " to get an explanation, until it was mentioned here. Chuck Entz (talk) 19:31, 6 September 2013 (UTC)
 * I agree to add " " to MediaWiki:Scribunto-parser-error for now. --Z 19:37, 6 September 2013 (UTC)
 * I would like all our Lua template modules to have a common vetting module copied in as a default. It would be told what positional and keyword parameters were valid, which were mandatory, what they should contain etc - and would produce a sensible error message stating exactly what's wrong. Something else for CodeCat to do! SemperBlotto (talk) 19:26, 6 September 2013 (UTC)
 * And more important than either bright shiny objects or even embarking on larger projects in hopes that they will solve problems that have already surfaced, essentially a form of doubling down on a losing bet. DCDuring TALK 12:43, 20 September 2013 (UTC)

(Also, I 100% totally disagree with you about language codes. In most cases the language code is not absolutely necessary to useful presentation. Something like should really just behave the same as, except that it should add the page to a cleanup category instead of Category:English nouns. You've previously stated that you think the big "Script error" messages will force editors to fix their problems — IIRC you even used the exact word "force" — but you've recently learned how you react when you feel that someone is trying to force you to do something by preventing you from doing what you want, especially when you don't find it very clear what they're trying to force you to do. Clearly my approach was a poor one: I tried to use technical means to solve a non-technical problem. If your reaction is at all typical of other people, then you can't expect to get any better results than I got.) —Ruakh <i >TALK</i > 17:30, 20 September 2013 (UTC)
 * I think an important technical point is being missed here. Scribunto already forces us to distinguish between what you might call "entry points" (Lua functions whose sole argument is a stack frame, and that can therefore be called directly from wikitext) and what you might call "regular functions" (all other Lua functions). So if we want errors to be caught and handled in a specific way, we can still use Lua's <tt>error</tt> mechanism, and just have the "entry points" use <tt>pcall</tt> to grab the error, and then format it however we want. (Personally, I actually think <tt>error</tt> is being overused, no matter how well we format the result — for example, there's no need for an entire headword-line to be replaced with an error message just because there's one small thing wrong with it — but at least this would be an improvement.) —Ruakh <i >TALK</i > 15:02, 20 September 2013 (UTC)
 * I've used error the way you'd use exception handling, more or less. It may not be the best way to handle it, but Scribunto doesn't really have a good error handling mechanism. What does pcall do, though? I haven't heard of it. 15:15, 20 September 2013 (UTC)
 * Your first two sentences are belied by your third. :-)  <tt>error</tt> is like "throw", <tt>pcall</tt> is like "catch". —Ruakh <i >TALK</i > 15:19, 20 September 2013 (UTC)
 * I didn't know that. How does it work exactly? Can it do exception filtering based on the type, like the exception handling in other languages can do? Or is it "all or nothing"? We probably don't want to catch things like bad language codes, because most templates just can't do anything useful without that, beyond showing an error message. 15:51, 20 September 2013 (UTC)
 * It can examine the error, and re-raise if it doesn't know how to handle it. (You lose the original stacktrace, though.) But I think you're misunderstanding what I'm suggesting. I'm not suggesting that we start making a lot of use of <tt>error</tt> and <tt>pcall</tt>; they're really not considered good practice in Lua. I'm just suggesting that, in cases where a template-call is currently made useless by <tt>error</tt>, we should at least use <tt>pcall</tt> to improve the presentation of the error, to improve the user experience a little bit.