Wiktionary:Grease pit/2013/August

xan[edit]

<references> is blotting out the Lojban entry! Is this supposed to happen? Hyarmendacil (talk) 09:33, 1 August 2013 (UTC)[reply]

My fault. Sorry. — Ungoliant ^(Falai) 09:53, 1 August 2013 (UTC)[reply]

Someone with Wiktionary superpowers to do GREP on all Chinese-character entry pages?[edit]

Over in the Beer Parlour we have been discussing a situation where an editor has been systematically adding inappropriate blocks of content -- consisting of his own hypothetical work -- to a large number of Han (Chinese) character entry pages:

The conclusion is that all of these blocks should be removed -- and the right way to do this is with some kind of automated procedure.

These blocks of content appear on many but not all Han character pages, as a subsection of the section "Translingual". They start with a section title "Phonosemantic interpretation" and end with an off-site link. This regularity should make them fairly easy to delete with GREP.

Alternately, perhaps the content management system for Wiktionary is so sophisticated, that it is aware of classes of Wiktionary-wide section titles, and can "turn off" all of these sections based on the section title "Phonosemantic interpretation"? Or something like that?

Here are two examples:

Note for GREP that the off-site URL at the end ("Source: Howell & Morimoto") will be slightly different for each entry -- linking to a different page on that off-site web site. Also note that you cannot depend on what section will come next on the page as a delimiter -- this varies.

Thanks! HanEditor (talk) 06:45, 2 August 2013 (UTC) hanEditor[reply]

I don't know if GREP is even possible, since around here such things tend to be done by bots. Chuck Entz (talk) 22:20, 2 August 2013 (UTC)[reply]

Actually you're on the right track here. Where do I find the kind of people who write bots for Wiktionary?

Thanks HanEditor (talk) 04:02, 3 August 2013 (UTC) hanEditor[reply]

Some hard-working Wiktionarians have manually deleted all of the sections I discuss here, so this specific issue is resolved. But below in "Who's Flying This Plane?" I rehash it in its more general form, as there are a number of other cross-article edits I'm finding a need for. The GREP concept here also generally applies. HanEditor (talk) 10:41, 9 August 2013 (UTC)[reply]

A problem with the translation fixing gadget[edit]

I tried to change it so that it would add {{tø}} to entries instead of {{t-SOP}}. I think that worked, but the gadget is not always putting links [[ ]] around the individual parts of a SOP term. This is a feature that {{t-SOP}} supported; it would automatically link the words itself. But {{tø}} can't do the same, so the end result is wrong. I have tried to understand why the gadget is not always adding links to the words, but as seems usual with our JavaScripts, they're not documented or even commented so I really have no idea what I'm doing and I don't know how to fix it without possibly breaking something else. Is anyone else knowledgeable enough to have a look? —CodeCa t 21:58, 2 August 2013 (UTC)[reply]

Dynamic loading of content?[edit]

A problem with large pages is that they are basically all-or-nothing. The content all has to be downloaded even if a user is only interested in a small part of it. For Wiktionary:List of languages I added section ids so that you can easily look up a language with WT:LL#en (for English). This is just as easy as looking up the language template used to be. However, this approach has obvious drawbacks because of the page size; it takes long to load it all. So I wonder if there is a way to specify what you are looking for, and load only that and nothing else. Many websites implement this through JavaScript, by loading content only when you request it. Can we do this on Wiktionary too? —CodeCa t 22:48, 2 August 2013 (UTC)[reply]

I don’t understand the problem. In Safari/Mac, I can cancel loading that page before it is finished, and my browser renders the first part of the table, and leaves out the sidebar content (which appears at the end of the HTML code). If I was on a slow connection, I could just stop loading and read the beginning of the page.

But if a page is too long, then split it up into separate pages. Or transclude other pages into it, the way we do with the Beer Parlour. —Michael Z. 2013-09-08 01:50 z

To "cancel loading that page before it is finished" doesn't seem like much of a solution. I mean, sure, it's great if the language you want to know about is aaa, but what if the one you want to know about is zlw-slv? And you seem to be implying that the wonderful behavior you love is specific to your browser; do you suggest we ignore the needs of users in other browsers? Likewise, to "transclude other pages into it" seems backward, since all transcluded pages will be rendered and downloaded as a single HTML document. —Ruakh_TALK 04:43, 8 September 2013 (UTC)[reply]

Anyone who wants to spend a few days writing and debugging JavaScript in whatever browsers can’t handle long pages is totally welcome to. I don’t have the skills. Sounds like something you could suggest for the developers on Bugzilla, rather than implementing for just one project.

If pages are transcluded, then they’re also separate HTML documents. Like the monthly pages of our Beer Parlour. While you wait for the developers, you might consider taking 10 minutes to split up a super-long page that would benefit from it. Then the search field and an index page would be two ways to specify what you are looking for, and load only that and nothing else. —Michael Z. 2013-09-08 10:08 z

Abuse Filters 25 and 26[edit]

I tried to write a filter that would catch instances of new users adding external links, but the filters I wrote seem to tag anything and everything, whether it contains a link or not. Can someone more familiar with the language of abuse filters have a look? Blocking external links would stop spambots without preventing colleagues from other wikis from introducing themselves like Filter 21 so controversially did. - -sche (discuss) 02:53, 4 August 2013 (UTC)[reply]

You should have used added_lines, because new_wikitext means all of the text of source code of the page after edit. I made a change to Special:AbuseFilter/26, but used a more accurate variable there. --Z 18:18, 5 August 2013 (UTC)[reply]

I'm not sure if it's your change that did it, but user-page spam has started getting through the filters. Please fix it. Thanks. Chuck Entz (talk) 14:37, 6 August 2013 (UTC)[reply]

If the pick-up in spam started about the 26th of July, it's because that's when I deactivated filter 21 pursuant to this; if it happened more recently, I don't know what caused it. Z's change to Filter 26 should stop the spam, though... thanks Z! The filter also blocks some non-spam edits, like this one where someone formatted a link to Wikipedia like an external link, but it's a lot less sloppy than filter 21 and shouldn't block colleagues from other wikis. - -sche (discuss) 16:47, 6 August 2013 (UTC)[reply]

Wiktionary:Statistics/generated[edit]

This hasn't been updated since May (except to quibble over a comma). Can someone update it? If it'd be too hard to separate form-of defs from non-form-of defs, just a list of how many times each L2 occurs would be nice. - -sche (discuss) 15:34, 4 August 2013 (UTC)[reply]

The comma has now been updated, but not the data, which some would argue is the more important part of the page. - -sche (discuss) 14:51, 5 August 2013 (UTC)[reply]

Data shmata. DCDuring TALK 15:34, 5 August 2013 (UTC)[reply]

[1]. Good enough? — Ungoliant ^(Falai) 18:19, 1 September 2013 (UTC)[reply]

I appreciate getting this information. We still don't have a good way of comparing our English coverage with that of other dictionaries, even print dictionaries. We do not have a count of English entries that consist of more than mere form-of entries. From these statistics we know only that it is fewer than 448,254 (total number of gloss definitions) and more than 293,658 (total entries less total form-of definitions). Even if we throw in the fewer than 10,000 taxonomic name entries we have, we are probably 100K-150K entries behind MWOnline, even though we include more MWEs of dubious idiomaticity. If we were to compare on definitions, the comparison would be even worse, as it is hard to find any good entries for which we have more definitions than they and I often find that they have two or three times the number of definitions for common words. DCDuring TALK 19:36, 1 September 2013 (UTC)[reply]

`{{Han compound}}`[edit]

Why does this have no rs= parameter to pass to {{liushu}}? Currently we have over a thousand characters in Category:Chinese terms needing attention and most of them are characters using this etymology template. -- Liliana • 20:58, 4 August 2013 (UTC)[reply]

Russian noun declension table (width) and verb conjugation (colour of missing forms)[edit]

Two requests/questions:

Could someone please suggest a way to adjust the width of Russian declension tables - {{ru-decl-noun}}. Now, with automatic transliteration, it's probably better to make them wider (the external and internal frame) or automatically adjustable to the width of a form + transliteration. The transliteration appears in a different colour (gray) and in round brackets, so it would be nice if forms and transliteration would appear on the same line (where practical). Example: взаимопонимание. Multipart words should eventually be converted to use {{ru-decl-noun-see}}, no need to worry about superlong words.
Verbs using Module:ru-verb use template, which makes missing forms appear in red, e.g. делать. What should be changed to the module to make them appear in black as with nouns? --Anatoli ^{(обсудить}/^вклад) 01:40, 5 August 2013 (UTC)[reply]

You can put the "inflection-table" CSS class on the table, that will make red links black. —CodeCa t 01:43, 5 August 2013 (UTC)[reply]

Thank you. Could you do it, please? Or suggest what to change in these lines from Module:ru-verb:

...
    return [=[<div class="NavFrame" style="width:49.6em;">
<div class="NavHead" style="text-align:left; background:#e0e0ff;">]=] .. title .. [=[</div>
<div class="NavContent">
{| class="inflection inflection-ru inflection-verb"
...

Where should "inflection-table" class be applied? I haven't found an example. --Anatoli ^{(обсудить}/^вклад) 02:30, 5 August 2013 (UTC)[reply]

...
{| class="inflection inflection-ru inflection-verb inflection-table"
...

should do it. That's how you specify multiple classes. –Catsidhe ^{(verba, facta)} 02:38, 5 August 2013 (UTC)[reply]

Brilliant! Thank you very much.

The noun declension query remains open. --Anatoli ^{(обсудить}/^вклад) 02:44, 5 August 2013 (UTC)[reply]

Well, at the moment, the ru-decl-noun template says

{| style="background:#F9F9F9;text-align:center;width:30em" class="inflection-table"

So it's saying that the width should be 30em. Whatever you put there, it will make the default width. So to double the width (for all tables from this template), make it 60em. Or else remove the "width=..." part entirely, and the table will be as wide as it needs to be, and no more.

It might be worth trying changing it to "min-width=30em", so that smaller tables won't shrink, but they can grow as necessary. In theory; browser CSS compliance depending.

–Catsidhe ^{(verba, facta)} 03:02, 5 August 2013 (UTC)[reply]

I have tried but it didn't work as expected. The table now takes the whole page and there's some internal table, which is still narrow. See [[взаимопонимание]]. --Anatoli ^{(обсудить}/^вклад) 03:11, 5 August 2013 (UTC)[reply]

I just deleted both references to width, and it's as wide as it wants to be. Which is probably wider than it needs to be. Give me a sec, I'll have a tweak. –Catsidhe ^{(verba, facta)} 03:18, 5 August 2013 (UTC)[reply]

Set the table to 45em min-width (which means it should grow as necessary, but not shrink beyond that: that setting can be tweaked, and can probably be set back down to 30em), and set the first column to 10em, from the 33% it was. Which means the width of that column should remain the same as it was, but the other two columns can grow as needed, and won't affect the first. Please check that it looks OK across Russian nouns of varying lengths. –Catsidhe ^{(verba, facta)} 03:23, 5 August 2013 (UTC)[reply]

Thank you but it's not quite right yet. The inner coloured frame stretches alright but the outer frame occupies the whole width of the page (partially white). I don't know if it's possible to make them stretch together. --Anatoli ^{(обсудить}/^вклад) 03:28, 5 August 2013 (UTC)[reply]

Try now. (style="display: inline-block;min-width:45em" seems to have been the magic invocation on the outer containing frame.) –Catsidhe ^{(verba, facta)} 03:34, 5 August 2013 (UTC)[reply]

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

Positioning transliterations in inflection tables with CSS[edit]

At User talk:Vahagn Petrosyan I suggested modifying {{l-self}} specifically for use in inflection tables (by creating a new {{l-table}} which may or may not replace {{l-self}} 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? —CodeCa t 11:07, 5 August 2013 (UTC)[reply]

We should probably use

span.translit {
    display: block;
}

to put transliteration in a new line and use display: none; to remove parentheses. --Z 17:23, 5 August 2013 (UTC)[reply]

Isn't it possible to use CSS to put the parentheses in, rather than remove them? —CodeCa t 17:25, 5 August 2013 (UTC)[reply]

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)[reply]

You can add brackets with this CSS:

span::before { content: " ("; } 
span::after { content: ")"; }

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[edit]

I'm struggling to get {{suffixcat}} 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{{#invoke:compound|make_affix|*atjaną|lang=gem-pro|sc=|suffix=1}}

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? —CodeCa t 15:16, 5 August 2013 (UTC)[reply]

Fixed. --Z 16:59, 5 August 2013 (UTC)[reply]

No, I fixed it, and you broke it again in another way... See Category:Proto-Germanic words suffixed with *-atjaną. —CodeCa t 17:13, 5 August 2013 (UTC)[reply]

Are you sure? I reverted my edit and test{{#invoke:compound|make_affix|*atjaną|lang=gem-pro|suffix=1}} adds line-break now. --Z 17:19, 5 August 2013 (UTC)[reply]

Yes that still happens, but I found a workaround for it. I made {{concat}} 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 [2] and never fixed. Kind of sad... —CodeCa t 17:24, 5 August 2013 (UTC)[reply]

Who's Flying this Plane?[edit]

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[reply]

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)[reply]

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)[reply]

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[reply]

'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)[reply]

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·e 14:13, 10 August 2013 (UTC)[reply]

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)[reply]

Private Use characters[edit]

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)[reply]

User:DTLHS/private use DTLHS (talk) 00:27, 7 August 2013 (UTC)[reply]

Killer Robots Eating My Alternate Chinese Characters[edit]

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[reply]

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 {{l}}, as in {{l|mul|艹}} {{l|mul|艹}}, 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)[reply]

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)[reply]

Template:sv-adj[edit]

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)[reply]

Fixed I think. --Z 08:30, 8 August 2013 (UTC)[reply]

`{{circumfix}}`[edit]

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)[reply]

Unicode "Kangxi Radicals" Block Characters Causing Wiktionary Error[edit]

The Unicode "Kangxi Radicals" and "Kangxi Radicals Supplement" blocks —

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)[reply]

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.
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)[reply]

help with lua[edit]

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)[reply]

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. —CodeCa t 16:11, 9 August 2013 (UTC)[reply]

Fixed I think. --Z 21:26, 9 August 2013 (UTC)[reply]

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)[reply]

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)[reply]

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 {{kanji readings tab}} should do, feel free to edit it.--Haplology (talk) 14:52, 12 August 2013 (UTC)[reply]

Use positional parameter instead of alt= for translations?[edit]

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 {{l}}, {{term}}, 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 {{t|la|homo|m|alt=homō}} (or similar) now becomes {{t|la|homo|homō|m}}, and {{t|nl|mens|n}} becomes {{t|nl|mens||n}}. 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. —CodeCa t 17:04, 11 August 2013 (UTC)[reply]

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)[reply]

I agree that putting an extra pipe is annoying. For {{term}} 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 {{t}}, but also {{t}}, {{l}} and form-of templates. --Vahag (talk) 21:03, 11 August 2013 (UTC)[reply]

I agree with this, having unnamed parameters for more than two optional ones is a bad idea. Moreover, now that we have Module:links#prepare_title, we don't need the alt parameter as much as before. --Z 00:55, 12 August 2013 (UTC)[reply]

IPA validator by language[edit]

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 {{IPA}} will use it). For example, the character q 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 r 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)[reply]

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)[reply]

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)[reply]

{t} generating extra space[edit]

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

The problem is in Module:translations, where it says if genders ~= {} then. {} 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   is always inserted before the gender, even when there is no gender information.
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 genders = genders or {} in the while-loop that populates it, and change the test to just if genders then. —Ruakh_TALK 06:05, 12 August 2013 (UTC)[reply]

I think this fixed it: diff —CodeCa t 12:46, 12 August 2013 (UTC)[reply]

`{{reflexive of}}`, "Category:(language name) reflexive verbs"[edit]

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)[reply]

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)[reply]

They get listed under the non-reflexive entry, such as {{reflexive|se présenter}} on présenter. Mglovesfun (talk) 09:50, 14 August 2013 (UTC)[reply]

It's actually {{context|reflexive|lang=fr}}, not {{reflexive|se présenter}} Yes, German verbs should either follow the French format, then entries should be allowed to have {{context|reflexive|vorstellen|lang=de}} or have separate entries, which would use {{reflexive of}} and add to reflexive categories. --Anatoli ^{(обсудить}/^вклад) 10:10, 14 August 2013 (UTC)[reply]

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. —CodeCa t 11:09, 14 August 2013 (UTC)[reply]

Template:term[edit]

{{term}} is broken. It returns "Script error" wherever it is used. —Stephen ^(Talk) 12:40, 15 August 2013 (UTC)[reply]

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)[reply]

Experimenting? Really? I was actually fixing an error with {{suffix}}, but made some mistakes, which were then corrected. See User talk:ZxxZxxZ#Appendix:Proto-Slavic/bogynji. 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. —CodeCa t 13:27, 15 August 2013 (UTC)[reply]

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)[reply]

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. —CodeCa t 15:28, 15 August 2013 (UTC)[reply]

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 {{fr-noun}}. Mglovesfun (talk) 19:44, 15 August 2013 (UTC)[reply]

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. —CodeCa t 21:28, 15 August 2013 (UTC)[reply]

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_TALK 04:11, 18 August 2013 (UTC)[reply]

popups not working[edit]

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)[reply]

Does your browser's error console tell you anything useful? —Ruakh_TALK 15:12, 16 August 2013 (UTC)[reply]

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)[reply]

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). [relevant blog post]
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. [diff] Please do a hard-refresh or cache-clearing or whatnot, and let me know whether the Gadget starts working for you.
—Ruakh_TALK 04:11, 17 August 2013 (UTC)[reply]

Ok that worked, thank you. Thryduulf (talk) 17:16, 18 August 2013 (UTC)[reply]

sw-noun problem[edit]

{{sw-noun}} 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)[reply]

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)[reply]

Thank you, that did it. Looking at your edit now, it seems obvious. Ah well. —Μετάknowledge^{discuss/deeds} 17:12, 17 August 2013 (UTC)[reply]

Template:confix categorization[edit]

Why doesn't {{confix}} categorize, say, oneironaut into Category:English words prefixed with oneiro-? DCDuring TALK 11:56, 19 August 2013 (UTC)[reply]

Should be working now. — Ungoliant ^(Falai) 12:17, 19 August 2013 (UTC)[reply]

Yes, thanks. DCDuring TALK 12:31, 19 August 2013 (UTC)[reply]

Use of <pre>[edit]

Is it the use of <pre> on a page that causes a horizontal scroll bar to appear on my browser as on Wiktionary:Grease pit/2013/August? Is there an alternative that would not? DCDuring TALK 12:03, 19 August 2013 (UTC)[reply]

It’s the huge link at #popups not working, as far as I can tell. — Ungoliant ^(Falai) 12:20, 19 August 2013 (UTC)[reply]

Confirmed. I've now wrapped the relevant comment in <div style="overflow:scroll">, 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_TALK 05:58, 20 August 2013 (UTC)[reply]

Thanks. I'll try to remember the cause and the fix for the next time. DCDuring TALK 13:02, 20 August 2013 (UTC)[reply]

Citation Needed Template[edit]

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)[reply]

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)[reply]

We have {{unreferenced}} for that. —An gr 14:58, 20 August 2013 (UTC)[reply]

Thanks... HanEditor (talk) 07:29, 23 August 2013 (UTC)[reply]

((en-adj|-)) is broken[edit]

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

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_TALK 05:58, 21 August 2013 (UTC)[reply]

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. —CodeCa t 15:48, 21 August 2013 (UTC)[reply]

Ok, it's done. —CodeCa t 16:57, 21 August 2013 (UTC)[reply]

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_TALK 18:38, 21 August 2013 (UTC)[reply]

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. —CodeCa t 18:48, 21 August 2013 (UTC)[reply]

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_TALK 20:33, 21 August 2013 (UTC)[reply]

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 {{en-adj|er|more}}), but not the other way around ({{en-adj|more|er}} 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. —CodeCa t 21:00, 21 August 2013 (UTC)[reply]

Special:SpecialPages#Maintenance reports[edit]

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)[reply]

We may get run in the next ~~few~~several hours. DCDuring TALK 00:47, 24 August 2013 (UTC)[reply]

Upcoming bug triage for RTL issues[edit]

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)[reply]

Audio bot[edit]

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)[reply]

(?), (!)[edit]

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)[reply]

I fixed the problem, it was in {{mul-punctuation mark}} 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. —CodeCa t 18:57, 24 August 2013 (UTC)[reply]

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. —CodeCa t 19:29, 24 August 2013 (UTC)[reply]

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)[reply]

cs-decl-noun-auto[edit]

Something is wrong with the Czech declension template {{cs-decl-noun-auto}} (example, see krok). Each form shows [[, a hard return, and ]], but are not linked. —Stephen ^(Talk) 20:08, 24 August 2013 (UTC)[reply]

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. —CodeCa t 20:36, 24 August 2013 (UTC)[reply]

I think it probably comes from {{cs-decl-noun}}. 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)[reply]

{{cs-decl-noun}} does not seem to cause the problem; it is used directly in krkavec and it looks okay. The problem seems to be with {{cs-decl-noun-auto}}, 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)[reply]

Template:fro-decl-adj[edit]

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 tiois the automatic plural would be tiois using fro-utilities's plural lookup function. Just I have no idea how to implement it. Mglovesfun (talk) 12:39, 25 August 2013 (UTC)[reply]

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 {{la-decl-noun-table}} 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). —CodeCa t 12:45, 25 August 2013 (UTC)[reply]

Making WT:NFE more visible, and the sitenotice more useful[edit]

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? —CodeCa t 16:55, 25 August 2013 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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. —CodeCa t 18:13, 25 August 2013 (UTC)[reply]

One does not preclude the other. — Ungoliant ^(Falai) 18:17, 25 August 2013 (UTC)[reply]

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)[reply]

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? —CodeCa t 18:33, 25 August 2013 (UTC)[reply]

I oppose making Wiktionary:News for editors more visible. If it can disappear from SiteNotice altogether, so much better. --Dan Polansky (talk) 19:56, 25 August 2013 (UTC)[reply]
- Do you think it's visible enough? —CodeCa t 20:04, 25 August 2013 (UTC)[reply]

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)[reply]

How is it my fault if nobody else puts news there? —CodeCa t 20:35, 25 August 2013 (UTC)[reply]

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)[reply]

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. —CodeCa t 00:21, 26 August 2013 (UTC)[reply]

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)[reply]

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

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)[reply]

`{{tø}}` or `{{t}}` issues spotted[edit]

Please see current Russian translations of "ease nature". Something weird is happening: отправля́ть есте́ственные на́добности impf (otpravljátʹ jestéstvennyje nádobnosti). 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 {{t}} and {{tø}}. Let me know if I did something wrong. --Anatoli ^{(обсудить}/^вклад) 01:44, 27 August 2013 (UTC)[reply]

I think that was caused by changes that Z made to the remove_links function a while ago. He wanted to simplify it, but maybe a bit too much. —CodeCa t 01:50, 27 August 2013 (UTC)[reply]

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

Fixed (remove_links works fine though) --Z 07:17, 27 August 2013 (UTC)[reply]

MediaWiki parser from Hell[edit]

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":

page_tree = mwparserfromhell.parse(page_wikitext)
for template in page_tree.filter_templates():
    if template.name == "xx" and template.has("first"):
        template.add("second", template.get("first").value, before = "first")
        template.remove("first")

page_wikitext = unicode(page_tree)

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. :) —CodeCa t 18:15, 27 August 2013 (UTC)[reply]

Special:Search timing out[edit]

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)[reply]

I've been getting this too. Mglovesfun (talk) 09:40, 28 August 2013 (UTC)[reply]

Me, too. Has WMF cut back on our allowance or have we crossed some size threshold? DCDuring TALK 12:15, 28 August 2013 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Template:en-noun and -y to -ies plurals[edit]

Currently, if one types {{en-noun|es}} 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 {{en-noun|ies}} 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)[reply]

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. —CodeCa t 18:32, 28 August 2013 (UTC)[reply]

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 {{en-noun}}'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 pl= parameter is deprecated. The pl2= and pl3= 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. —CodeCa t 18:43, 28 August 2013 (UTC)[reply]

You may want to update Wiktionary:About English#Nouns. 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)[reply]

lang=en can actually still be omitted for all templates except for {{term}} and some of the form-of templates. I'm not sure if that's good practice, but it is still valid. —CodeCa t 01:45, 31 August 2013 (UTC)[reply]

Do you mean {{term}} or {{l}}? {{term}} actually still works (vide: (deprecated template usage) word is a bluelink to word) even with no language code specified, unlike {{l}}. - -sche (discuss) 02:02, 31 August 2013 (UTC)[reply]

{{l}} doesn't take a lang= parameter so it's required. For {{term}} leaving the language out works only because making it not work would break the 20 thousand entries in Category:term cleanup. {{term|word}} is actually equivalent to {{term|word|lang=und}}. But it's deprecated usage, and the replacement {{term/t}} (whose final name is still undecided) works like {{l}}, it always requires a language. I strongly believe in being explicit about the language as it prevents errors. —CodeCa t 02:06, 31 August 2013 (UTC)[reply]

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)[reply]

You seem to have us confused with a professional operation. DCDuring TALK 21:33, 1 September 2013 (UTC)[reply]

Error trapping[edit]

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)[reply]

What would you suggest we change about the current script error messages? —CodeCa t 16:04, 30 August 2013 (UTC)[reply]

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)[reply]

Wouldn't have said it better. Thanks. DCDuring TALK 18:05, 30 August 2013 (UTC)[reply]

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)[reply]

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)[reply]

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 <red>Script error</red>, 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)[reply]

Yes, it's possible to change both the big red message and the text it shows when you click on it. —CodeCa t 21:53, 30 August 2013 (UTC)[reply]

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 bugzilla:. --Z 18:14, 6 September 2013 (UTC)[reply]

We can change the appearance and the displayed message. How do you think it should look? —CodeCa t 18:29, 6 September 2013 (UTC)[reply]

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 error(), 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)[reply]

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? —CodeCa t 18:46, 6 September 2013 (UTC)[reply]

I mean we can't change "Script error" to "Script error: <explanation of the error>", can we? How? --Z 18:50, 6 September 2013 (UTC)[reply]

As far as I know we can. We can change a range of messages by editing one of these messages. —CodeCa t 18:58, 6 September 2013 (UTC)[reply]

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)[reply]

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 error() for MediaWiki:Scribunto-parser-error. --Z 19:34, 6 September 2013 (UTC)[reply]

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)[reply]

I agree to add "<small>(click for details)</small>" to MediaWiki:Scribunto-parser-error for now. --Z 19:37, 6 September 2013 (UTC)[reply]

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)[reply]

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)[reply]

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 error mechanism, and just have the "entry points" use pcall to grab the error, and then format it however we want. (Personally, I actually think error 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_TALK 15:02, 20 September 2013 (UTC)[reply]

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. —CodeCa t 15:15, 20 September 2013 (UTC)[reply]

Your first two sentences are belied by your third. :-) error is like "throw", pcall is like "catch". —Ruakh_TALK 15:19, 20 September 2013 (UTC)[reply]

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. —CodeCa t 15:51, 20 September 2013 (UTC)[reply]

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 error and pcall; 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 error, we should at least use pcall to improve the presentation of the error, to improve the user experience a little bit.
(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 {{head|garbage|noun}} should really just behave the same as {{head|en|noun}}, 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_TALK 17:30, 20 September 2013 (UTC)[reply]