Wiktionary:Grease pit/2013/February

I just noticed that some JA headword templates display Latin text strangely. Example:

The ===Counter=== and ===Prefix=== POSes use {{ja-pos}}; the ===Noun=== POS uses {{ja-noun}}. The key difference between the code in these two templates is the following:

• {{ja-pos}}:

{{#switch:{{{1}}}|r='''{{PAGENAME}}'''|...

• {{ja-noun}}:

{{#switch:{{{1}}}|r={{Latn|{{PAGENAME}}|lang=ja|face=head}}|...

Double-checking this, we find:

• {{Latn|Example text}} produces:

Example text

• {{Latn|lang=ja|Example text}} produces:

Example text

So using {{Latn}} with lang=ja produces weird and kinda ugly results. Anyone know why? -- Eiríkr Útlendi │ Tala við mig 19:21, 1 February 2013 (UTC)

FWIW, I realized I was mistakenly adding the above content to the Zen page; I wound up adding it to the zen page instead. -- Eiríkr Útlendi │ Tala við mig 19:26, 1 February 2013 (UTC)

Browsers are smart enough to apply a Japanese font to text whose language is set to Japanese. This is, in this case, a bit unfortunate. -- Liliana • 19:35, 1 February 2013 (UTC)

It seems that browsers are being so smart they are making it hard for us to give correct markup to our content. Kind of not what they should be doing. Is there a way to tell them not to do that? —CodeCat 19:37, 1 February 2013 (UTC)

(After edit conflict) Yerg. That's more than a bit unfortunate. I have yet to see the Japanese font that renders Latin text in any visually appealing way. Is there any way we can tweak the template code or CSS to avoid this bit of eyeball ouchiness? -- Eiríkr Útlendi │ Tala við mig 19:38, 1 February 2013 (UTC)

You can do it like I did in my CSS, set a selector for . This will however break IE6. -- Liliana • 21:02, 1 February 2013 (UTC)

• Thanks, Liliana. Could we apply that site-wide? Changing this just in my personal setup is all very well, but that wouldn't address the way that this makes JA entries look ugly and inconsistent for everyone else. -- Eiríkr Útlendi │ Tala við mig 21:14, 1 February 2013 (UTC)

There, see if you like what I did. -- Liliana • 22:32, 1 February 2013 (UTC)

• Hmm, no appreciable difference really, not even after clearing my browser cache. As I learn more about FF and Firebug, I do note that the Latin text marked as Japanese gets this bit in the final rendered CSS:

.Latn, .Latn, .Latn {
    font-family: inherit;
}

The Latin text not marked as Japanese doesn't have this bit. I suspect it's the font-family: inherit; setting that's leading the browser astray. Could that be removed? There's really no useful reason that I can think of to have Latin-spelled Japanese text inheriting anything font-wise. (And possibly ditto for KO and ZH... though I thought we weren't using the ZH lang code anymore anyway?) -- Eiríkr Útlendi │ Tala við mig 22:59, 1 February 2013 (UTC)

Re: "There's really no useful reason that I can think of to have Latin-spelled Japanese text inheriting anything font-wise": Clearly you have some sort of mistaken understanding of what inherit means. You should look it up. But anyway, the CSS that you're objecting to is actually the CSS that Liliana just added to MediaWiki:Common.css in a failed attempt to fix the issue. It's obviously not the cause of the issue, since you complained about the issue before she added it. —Ruakh_TALK 03:21, 2 February 2013 (UTC)

I'm confused, because this bit of CSS does work excellently for me. -- Liliana • 08:35, 2 February 2013 (UTC)

• Ruakh, I'm sorry I seem to have offended you. Using the limited tools available to me (or at least that I know how to use), the inherit bit was the only difference I could see between the two on the CSS level, so I assumed that must have been what was causing the difference.
• Liliana, all, I have since found that Firefox handles languages and scripts differently than MS Word, in ways where I think MS Word actually (shockingly?) does a better job.

In particular, MS Word allows you to specify fonts separately for Latin text and Asian text, and MS Word seems to handle language specifications differently for Latin script vs. Asian text. Given the following sample sentence:

これはsampleです。

In Word, you can manually mark the whole sentence as Japanese, but Word will treat the Latin-script word sample as not Japanese, marking this internally instead using the default Latin-script language. In terms of MS Word styles, you can specify fonts for all scripts, for Latin scripts, and for Asian scripts.

In Firefox (at least as of v. 18.0.1), when a string is marked as a language, script appears to be irrelevant. Firefox has no way in its options of specifying separate fonts by script, and I mistakenly assumed that setting Western fonts as the default for Japanese would result in mojibake. Testing to ferret out this particular issue shows that I was wrong, and I can set Arial as the default sans-serif font without screwing up Japanese non-Latin text. On my machine, this results in text marked as lang="ja-Latn" appearing in the same font as English text.

Firefox's default Japanese fonts are different from the default Western fonts. This probably accounts for the different results we have seen -- some of us have undoubtedly changed our configurations, while others haven't.

• While this issue is fixable, by just changing the browser's font settings for the different languages, it's also very technical and fiddly (the user has to change the font settings for each language). If it's possible, I would certainly be a fan of finding a way to get the browsers to use fonts we specify for Latin-based text, either by language, or regardless of language. -- Eiríkr Útlendi │ Tala við mig 19:56, 4 February 2013 (UTC)

• Re: "Ruakh, I'm sorry I seem to have offended you": I'm sorry. You didn't offend me. I'm sorry that my comment gave the impression that I was annoyed; I admit that it was an accurate impression (your comment came amid a surge of ill-informed GP and BP comments), but my annoyance was not justified, or at least, not justifiably directed at you, and I didn't intend to let it show. —Ruakh_TALK 02:59, 5 February 2013 (UTC)

Not working for me either. Mglovesfun (talk) 23:29, 1 February 2013 (UTC)

Those CSS rules are applied in MediaWiki:Common.css, but I don't think that's causing the problem.

/* This is needed to overcome the "smartness" of certain web browsers */
 
.Latn,
.Latn,
.Latn { font-family:inherit; }

The discrepancy between the two seems to be because of a bug in {{Latn}}. The first “Example text” above has empty lang attributes, which indicate “unknown language.” The html looks like this:

<span class="Latn" lang xml:lang>Example text</span>

 —Michael Z. 2013-02-02 00:57 z

Re: last paragraph: that is simply not true. It's because of an intentional behavior of {{Latn}}, which does not generate the broken HTML that you impute to it. (In fact, it's actually impossible for any wikitext to generate that broken HTML; the software won't allow it.) —Ruakh_TALK 03:21, 2 February 2013 (UTC)

Hm, I can’t double-check at the moment, but maybe they are just empty, like lang="", which is equivalent. That was what I saw in Safari’s DOM inspector earlier today. What HTML is it generating in that fragment?

Anyway, it’s time to change the way we style lang-tagged text. Instead of applying classes, these templates should only apply lang attributes, with the addition of script subtags for non-default values. So lang="ja" for Japanese and lang="ja-Latn" for transliterated Japanese. Then the style sheet should use the :lang("ja") pseudo-class to style the former where necessary, so it can override browser default, and :lang("ja-Latn") { font: inherit; } to reset transliterations back to the default font. —Michael Z. 2013-02-02 04:52 z

I suggested that same thing some time ago, but it kind of died because of a certain 12 year old browser. Also concerning the CSS solution given above: would it be possible to specify just .Latn so that it doesn't need to be overridden separately for every single language? —CodeCat 11:30, 2 February 2013 (UTC)

We don't want it for everything, because some Latin-script languages have special fonts. -- Liliana • 15:15, 2 February 2013 (UTC)

But the way CSS works, you can override more general settings with more specific ones. So we could say "Use this for all languages that have Latn" and then "But, for this language in particular, use this instead". —CodeCat 15:19, 2 February 2013 (UTC)

No, it's always the last definition that overrides any previous ones. And that is a problem, because for Japanese the inherit needs to come last, but for other languages, it needs to come first. -- Liliana • 15:30, 2 February 2013 (UTC)

But it depends on how specific the definition is. CSS defines a measure for how specific a selector is, and the ordering is only important if two selectors are equally specific. —CodeCat 15:54, 2 February 2013 (UTC)

But is always more specific than classes, and that is the problem. -- Liliana • 19:17, 2 February 2013 (UTC)

It is applied differently. If our body element has lang="en" then the a selector applies to the body only, but a :lang(en) selector applies to the body and all of its child elements that inherit the language. —Michael Z. 2013-02-10 16:03 z

So the exact problem is the font rendering of the Latin-alphabet text, “Zen” in the example, right?

In the Safari 6.0.2 Web Inspector I change lang="ja" to lang="ja-Latn" on that element, and the problem goes away. So in a fully language–script-compliant browser, we can fix this by adding detailed language–script tagging. Let’s put the energy into improving the standards support of our code for the long term.

In Firefox 18.0.1, I do the same and but the problem persists. So this is a missing feature in Firefox’s rendering of languages. I suggest filing a Firefox bug report in Bugzilla.

Does this affect other browsers? If it’s a common problem, we can probably work around it with some fancy CSS. —Michael Z. 2013-02-02 17:40 z

Opera behaves like Firefox; specifying ja-Latn does nothing. -- Liliana • 19:06, 2 February 2013 (UTC)

We may as work on a solution based on standards that will continue to work, and work for other possible situations than the ones we have used so far, and fall back for browsers with varying standards support.

We currently have this:

   /* Japanese Template:Jpan (Template:Hira, Template:Kana) */
   .Jpan, .Hira, .Kana {
       font-family: Hiragino Kaku Gothic Pro, MS PGothic, Arial Unicode MS, Code2000, sans-serif;
       font-size: 110%;
       font-style: normal;
       }

Let’s use this sort of arrangement for all non–Latin-script languages:

   /* #### Japanese Template:Jpan (Template:Hira, Template:Kana) #### */

   .Jpan, .Hira, .Kana, /* fallback for MSIE 6 */
   , /* fallback for MSIE 7 */
   :lang(ja) {
       font-family: Hiragino Kaku Gothic Pro, MS PGothic, Arial Unicode MS, Code2000, sans-serif;
       font-size: 110%;
       font-style: normal;
       }

   /* override for transliterations and other Latin-script text. For Firefox, Opera, and other 
       browsers whose default stylesheet doesn't support language-script subtags. */
   , /* fallback for MSIE 7 */
   :lang(ja-Latn) { 
       font-family: inherit;
       font-size: inherit;
       font-style: inherit;
       }

This requires the -Latn subtag to be added to transliterations in templates. Needs testing. The second :lang declaration should override the first. The inherit keyword will force normal inheritance of the parent element’s style, instead of applying the font properties from the preceding CSS declaration.

The classes in our templates and the first declaration can be removed in the future when we no longer support MSIE 6 & 7. The third declaration can be removed when other browsers support the script subtags in their default CSS (Safari already does). Maybe we can remove some stuff earlier, since this is “progressive enhancement,” and not something that’s absolutely necessary to read Wiktionary in an old browser that gives inferior rendering anyway. —Michael Z. 2013-02-08 20:43 z

I definitely agree with this. The top two definitions can probably be merged, though? Also, does IE7 support attribute selectors? A more compatible alternative to :lang("ja") could be . —CodeCat 20:59, 8 February 2013 (UTC)

Top two definitions can be merged, but I’d like to see the options clearly commented. IE7 does support plain attribute selectors, with bugs, so testing is required. But because, apparently, :lang() is more specific than , we might get more consistent results using the former, and adding the latter as another level of fallback for IE7. By the way, would match both ja and ja-Latn. —Michael Z. 2013-02-08 22:38 z

Updated the code sample, above. —Michael Z. 2013-02-08 22:57 z

I think the top few rule sets should be unmerged, because according to the CSS spec, if the browser doesn't understand part of a selector, it should discard the entire rule set. (The spec gives the example of h3, h4 & h5 {color: red }: since & is not allowed in selectors, the whole rule set is discarded, and — in particular — is not to be treated as h3 {color: red }.) —Ruakh_TALK 09:13, 9 February 2013 (UTC)

That code is valid CSS 2 according to the validator, so theoretically it should work as-is in browsers supporting that level, even if they don’t support every selector. But, needs testing. —Michael Z. 2013-02-09 18:15 z

That CSS will fail if Japanese text is inside any non-English text. Maybe font-family: sans-serif is better than font-family: inherit.

Also, I remembered that inherit is not supported by MSIE 6 or MSIE 7. —Michael Z. 2013-02-11 00:38 z

You know, looking at it now, what I wrote there is the solution to a different related problem. A more basic problem is that {{ja-pos}} doesn’t apply lang="ja", so its output isn’t consistent with that of {{ja-noun}}. I suppose there are other Japanese P.O.S. templates too. They should all put out the same HTML for the same bits before we start messing around with the site’s CSS. —Michael Z. 2013-02-08 20:59 z

Are romaji entries, like zen#Japanese, considered part of Japanese script (Jpan)? If kanji, katakana, hiragana, and romaji are mixed, then they should all appear in the same font – matching continuous text in the same language is more important than matching Wiktionary’s default font. Perhaps we should tag Japanese romaji entries (ja-Jpan or ja-Latn) differently from our transliterations from kanji and kana (ja-Latn-hepburn). —Michael Z. 2013-02-08 22:57 z

Romaji is not considered part of Jpan / Japanese script, since the latter is an "alias for Han + Hiragana + Katakana". —Ruakh_TALK 09:13, 9 February 2013 (UTC)

I took each template from Category:Japanese headword-line templates and duplicated its content from a random entry. Here are the results:

{{ja-adj|kk|decl=i|hira=いたい|rom=itai}}

February(いたい) • (itai) -i (adverbial February(いたく) (itaku))

<span class="Jpan JA" lang="ja">

{{ja-counter|index=しかん'|kana=じかん|romaji=jikan}}

Template:ja-counter

<span class="Jpan JA" lang="ja">

{{ja-diacritical mark|}}

Template:ja-diacritical mark

<b><span class="Jpan JA" lang="ja">

{{ja-kanji|grade=3|rs=宀03}}

<font lang="ja" style="font-size:125%">

{{ja-kanji reading|hidx=しょう'|rom=jō}}

Template:ja-kanji reading

<span class="Jpan JA" lang="ja">

{{ja-noun|r|hira=ぜん}}

February(ぜん) • (zen) 

<b class="Latn" lang="ja">

{{ja-phrase|kk|hira=よいおとしをおむかえください|rom=yoi otoshi o omukae kudasai}}

February(よいおとしをおむかえください) • (yoi otoshi o omukae kudasai) 

<span class="Jpan JA" lang="ja">

{{ja-pos|r|prefix|hira=ぜん}}

February(ぜん) • (zen-) 

<b>

{{ja-punctuation mark}}

Template:ja-punctuation mark

<b><span class="Jpan JA" lang="ja">

{{ja-verb|h|rom=inu|type=1}}

(removed)

<span class="Jpan JA" lang="ja">

{{ja-verb form|h|rom=mita}}

(removed)

<span class="Jpan JA" lang="ja">

{{ja-verb-suru|k|hira=あんしん|rom=anshin}}

February(あんしん)する • (anshin suru) suru (stem February(あんしん)し (anshin shi), past February(あんしん)した (anshin shita))

<span class="Jpan JA" lang="ja">

The HTML generated by these should probably be consistent before we get focussed on adjusting the CSS to make any one of them display a certain way. —Michael Z. 2013-02-09 23:45 z

Ew... a font tag... MediaWiki actually lets that pass through unchanged? That must be a bug! —CodeCat 00:05, 10 February 2013 (UTC)

What does the "JA" class actually do here? It seems rather redundant to having the lang= attribute, and I don't see anything about that class in common.css. —CodeCat 23:59, 10 February 2013 (UTC)

Hm, might that be from before we discovered script codes? Stuff like that tended to get left in for a long time because the style sheet was cached AOL’s proxy servers for weeks or months, or something. —Michael Z. 2013-02-11 00:34 z

Indeed. Before script templates existed we had {{JAchar}}, {{RUchar}}, {{ARchar}}, etc. Even though that is long ago, remains are still everywhere. -- Liliana • 11:30, 11 February 2013 (UTC)

• I note that {{ja-adj}} categorizes even when not in principal namespace. DCDuring TALK 11:28, 11 February 2013 (UTC)

As an aside, {{ja-kanji reading}} should not be used. Thank you for reminding me that this exists. The pages that use this all need to be restructured to put the relevant information under the proper POS headers, and use {{ja-def}} to point to the proper lemma forms. Once orphaned, {{ja-kanji reading}} should be deleted. (Should I add {{ja-kanji reading}} to WT:RFDO now, or only after orphaning it?) Now to add to my To-Do list... -- Eiríkr Útlendi │ Tala við mig 19:02, 11 February 2013 (UTC)

RFDO now, while it’s on our minds (and remind me to vote to delete). Then when it’s time to delete it, you don’t have to mess around with permission. —Michael Z. 2013-02-12 02:35 z

Thanks Michael, now listed at WT:RFDO#Template:ja-kanji_reading. -- Eiríkr Útlendi │ Tala við mig 06:43, 12 February 2013 (UTC)

Breaking off a thread from #Font oddities in JA entries, above.

{{Latn|Example text}}

Produces the following

Example text

The HTML is:

<span class="Latn" lang="" xml:lang="">Example text</span>

Producing an empty lang attribute is incorrect. “Setting the attribute to the empty string indicates that the primary language is unknown.” The template should omit the lang and xml:lang attributes if no language is given, thus inheriting the primary language from the parent element.

Unless I am missing something, is it possible to omit lang attributes if nothing is given? —Michael Z. 2013-02-02 17:53 z

It's possible, but in what cases would that be useful? —CodeCat 17:59, 2 February 2013 (UTC)

Obviously it's possible; that, in fact, was the old behavior, until I changed it to use the current behavior. And (unsurprisingly) I think we should keep the current behavior. If someone fails to tag their Latin-script Japanese with lang=ja, that makes it "unknown language", not "English". No? —Ruakh_TALK 18:57, 2 February 2013 (UTC)

Maybe. But the expected behaviour is that un–lang-tagged elements in an English-language web page are English. Why are we to assume that an error is more likely than the behaviour expected by the standard? —Michael Z. 2013-02-03 00:34 z

"Elements"? "Assume"? "Error"? "Expected"? You are presupposing a different universe from the one that I believe myself to reside in, so I don't think I can even begin to answer your question about it. :-/   —Ruakh_TALK 02:54, 3 February 2013 (UTC)

I have a special CSS assigned to language tags: User:CodeCat/common.css. But I noticed that text that is tagged with lang="" doesn't show the coloured background. That means that CSS selectors, at least, treat lang="" as if it inherits the language. —CodeCat 19:25, 2 February 2013 (UTC)

I disagree with that assessment. In my browser (Firefox 18.0.1 on Windows 7), an explicit lang="" does indeed trigger a *:not(:lang(en)) selector. It's possible that your browser is behaving correctly and mine is behaving wrongly — I haven't checked the specs — but we certainly can't assume a priori that your browser's behavior is a reliable guide to what "CSS selectors" do. —Ruakh_TALK 20:02, 2 February 2013 (UTC)

Opera does the same as Firefox here. So it seems that CodeCat's browser is at fault. -- Liliana • 21:27, 2 February 2013 (UTC)

I'm using Firefox 16.01. —CodeCat 21:47, 2 February 2013 (UTC)

I have copied your CSS to my vector.css, and I see the pink background behind “Example text,” above, in Safari 6.0.2/Mac, Chrome 24/Mac, Opera 12/Mac, but not in Firefox 18.0.2/Mac. —Michael Z. 2013-02-08 22:18 z

Okay, is this template only used within other templates? Then the solution would be to ensure that it is called with a language parameter whenever possible, right? Sorry for the confusion. —Michael Z. 2013-02-09 19:04 z

It is almost only used within other templates, but not in a way that really helps. I mean, whether an entry contains {{Latn|foo}} or {{term|foo}}, either way it's just as much effort to change it to identify the language. —Ruakh_TALK 19:34, 9 February 2013 (UTC)

Okay. And {{term}} is customarily used without lang=en, although I see that since October the docs state that it should always include the language code. I guess the nature of the problem is:

1. Editors should get used to using language codes, including lang=en
2. Super-templates should always pass on language codes, including lang=en, to their sub-templates

Tracking down lapses in no. 2 would be difficult, at least for me. Any idea if most of the high-usage templates are doing this correctly?

I guess having redundant lang="en" HTML attributes in the page is not significantly harmful. Is it practical for bottom-level templates to omit the lang tag in the case of en? —Michael Z. 2013-02-09 20:52 z

While it would probably take a while to make it work, I think it would be beneficial to make {{term}} and {{l}} work the same way with regard to language codes. That would mean converting the lang= parameter of {{term}} into the first positional parameter. Such behaviour would also make it more obvious that a code is needed, because you can't use the template without either writing the code or skipping a parameter (i.e. you have to be conscious of the presence and meaning of the first parameter). —CodeCat 21:00, 9 February 2013 (UTC)

I just don't see how that could be done. It seems like a fundamentally incompatible change. You say "it would probably take a while", but it would actually have to be done everywhere simultaneously. No? —Ruakh_TALK 21:17, 9 February 2013 (UTC)

We could have two versions of the template in use at the same time, like we're doing with {{list helper}}. —CodeCat 21:33, 9 February 2013 (UTC)

Our web pages are now HTML5, making the xml:lang attribute obsolete. According to the spec, “The attribute in no namespace with no prefix and with the literal local name "xml:lang" has no effect on language processing.” Wiktionary’s doctype is HTML5, and the root html tag has no xml:lang tag:

<!DOCTYPE html>
<html lang="en" dir="ltr" class="client-nojs">

Although they’re harmless, let’s start removing the xml:lang attributes from templates as we go. Any problems with this? —Michael Z. 2013-02-02 17:59 z

I agree, if it makes no difference. —CodeCat 18:07, 2 February 2013 (UTC)

It's kind of academic, because some component of the software adds xml:lang= wherever we put lang=, anyway. But yeah, I agree that we should stop adding xml:lang= ourselves. —Ruakh_TALK 19:02, 2 February 2013 (UTC)

Vote for Bug 44609 - Stop adding xml:lang attributes to HTML5 pages. —Michael Z. 2013-02-03 00:48 z

I am unable to save edits containing all of the text on the page Wiktionary:Frequency lists/Norwegian Bokmål wordlist as, apparently, it is too big. I get a timeout error:

Request: POST http://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?title=Wiktionary:Frequency_lists/Norwegian_wordlist&action=submit, from <IP> via amssq46.esams.wikimedia.org (squid/2.7.STABLE9) to 91.198.174.49 (91.198.174.49) Error: ERR_READ_TIMEOUT, errno at Sun, 03 Feb 2013 14:12:10 GMT

This leaves me unable to undo this accidental edit; wich was accepted as the new page size wasn't particularly big. --Njardarlogar (talk) 14:14, 3 February 2013 (UTC)

Damn, I can't undo it either. Mglovesfun (talk) 14:57, 3 February 2013 (UTC)

Does it help if you replace all instances of {{l|nb| with {{l|nb|?—CodeCat 14:58, 3 February 2013 (UTC)

 Done -- Liliana • 15:08, 3 February 2013 (UTC)

What I was originally trying to do, was to change the intro + changing {{l|no| to {{l|nb|; and that's still impossible. Any change to that page except from reducing its size substantially seems to be impossible. --Njardarlogar (talk) 15:16, 3 February 2013 (UTC)

The solution is clear: we need to split it into subpages which transclude there. Especially because (unlike the Grease Pit, which does the same thing), the pages shouldn't be edited too often anyway. —Μετάknowledge^{discuss/deeds} 16:48, 3 February 2013 (UTC)

I've noticed this phenomenon before: that editing some large pages (like Wiktionary:Frequency lists/Norwegian Bokmål wordlist, and a) is impossible, but editing others (such as Wiktionary:Requests for deletion/Others, which is five times as large) is still possible. What causes this? Is it the fact that the Norwegian page and a use many more templates than our RFD/RFDO and RFV pages? Is it even true that they use many more templates than RFD/RFDO and RFV? Anyway, splitting the page seems like the thing to do. - -sche (discuss) 19:24, 3 February 2013 (UTC)

I always get a timeout error when I try to save an edit to Appendix:Swadesh lists for Slavic languages, but my edits get saved anyway. It's not even all that big, but it does use {{l}} a whole lot. The timeout happens even when I only have one section open rather than the whole page. —Angr 19:50, 3 February 2013 (UTC)

LOL, I just noticed the same thing happened to me when creating the subpages - so if some admin could delete Wiktionary:Frequency lists/Norwegian Bokmål wordlist/1-2000 and Wiktionary:Frequency lists/Norwegian Bokmål wordlist/1-1500, that would be nice.

The subpages definitely work as an temporary solution at least, so that's good. --Njardarlogar (talk) 20:09, 3 February 2013 (UTC)

Has anyone tried using {{l/nb}} instead? —CodeCat 20:41, 3 February 2013 (UTC)

It looks like it did the trick. Trying to convert {{l/nb}} into {{l|nb}} I get the error, while other edits work fine. --Njardarlogar (talk) 11:35, 4 February 2013 (UTC)

I think this is good evidence that the simplified linking templates really do improve speed, then. —CodeCat 14:08, 4 February 2013 (UTC)

I've changed most of the Serbo-Croatian links at Appendix:Swadesh lists for Slavic languages to using {{l/sh/Latn}} and {{l/sh/Cyrl}}, but it's still as hard to edit as ever. Maybe that's just because I haven't finished switching them all over yet, and all the other languages still use plain old {{l}}. —Angr 14:53, 4 February 2013 (UTC)

I've changed over a few more but it's still slow. I'm not sure how to create templates for the Cyrillic languages though. Should they include transliteration or not? —CodeCat 15:04, 4 February 2013 (UTC)

Probably not, not for the purposes we seem to be using these language-specific l-templates for. I'm impressed you're able to edit the whole Appendix page in one go. I can't even open the whole page. I can only open one section at a time, edit it, and then when I press "Save page" I have to wait a couple minutes for the green "Wikimedia servers are down" page, hit the back button, save the changes a second time, wait for the "Wikimedia servers are down" page a second time, and then go to the page history to confirm that the edits have been saved. —Angr 15:21, 4 February 2013 (UTC)

I've replaced all of them now, but there are still a few Serbo-Croatian links that need fixing. I do notice a big speedup now! —CodeCat 16:25, 4 February 2013 (UTC)

À propos de bottes, someone mentioned on WP today that the absolute maximum article size is 2 MB. - -sche (discuss) 06:11, 6 February 2013 (UTC)

And apparently that's after expansion with templates. DCDuring TALK 12:39, 6 February 2013 (UTC)

Are the page sizes that we see the page sizes that matter, ie, the after-expansion size?

Well, Appendix:Swadesh lists for Slavic languages is 3000 bytes larger now than it was a month ago, but it responds much faster than it did then. —Angr 13:30, 6 February 2013 (UTC)

Speed has been our biggest concern in principal namespace, but I'd hate to see us bump against other limits. I wonder to what extent templates contribute to the speed problem on pages like RfV. DCDuring TALK 14:20, 6 February 2013 (UTC)

Currently this links to Category:constructed languages, but it should link to Category:Constructed languages. The problem is, if I capitalise it, it breaks the category tree structure and something like Category:English terms derived from Lojban gets sorted into Category:English terms derived from Constructed languages. How can I solve this? —Μετάknowledge^{discuss/deeds} 23:09, 3 February 2013 (UTC)

 Fixed; see Template:famt?diff=19467745. —Ruakh_TALK 01:08, 4 February 2013 (UTC)

Thank you. I still don't understand the infrastructure of the category tree... —Μετάknowledge^{discuss/deeds} 05:16, 4 February 2013 (UTC)

Currently, when a German adjective has two comparative/superlative forms (like "rot" does), the headword lines and declension sections are just repeated. The later is probably for the best (but is it really necessary to repeat the ====Declension==== header twice?), but for the headword line, could we expand {{de-adj}} to accept multiple comparative and superlative forms? - -sche (discuss) 00:05, 6 February 2013 (UTC)

Maybe it makes more sense to just use {{head|de|adjective}} for such cases?
As for the Declension section — rather than repeating the header verbatim, you could write e.g. “Declension with röter and rötesten:” and “Declension with roter and rotesten:” (not as headers, just as normal text). The section would probably also benefit from some prefatory text explaining that two sets of comparatives and superlatives exist, perhaps with an explanation of any semantic/regional/context/register/frequency differences, or a statement that there aren't any, or whatnot.
—Ruakh_TALK 06:09, 6 February 2013 (UTC)

I've added two new parameters to {{de-adj}}, comp2= and sup2=. I hope that helps? —CodeCat 21:28, 6 February 2013 (UTC)

Thanks! - -sche (discuss) 21:06, 9 February 2013 (UTC)

Edittools have been extremely helpful, and I am deeply grateful for everyone involved in their creation. I have made my own edittools page to group together the features and hard-to-enter characters that I use most. Prior to my hiatus from last summer through last month, things worked pretty well.

Then late January I noticed that edittools sometimes wouldn't load properly. When that happens, all I see is this:

Not even the default MediaWiki edittools load up properly. If I change the dropdown selection, then the newly selected item does appear, but my own edittools items are nowhere to be found.

I noticed that this does not happen in Chrome, and this does not happen in FF on WinXP or Mac. It only seems to happen in FF on Win 7.

As an additional oddity, if I hit an Edit link, or click the Preview button when already in the editor view, and then immediately change tabs, edittools will load correctly so long as I let the page finish loading before changing back to that tab. But if I enter the editor view on a page, or reload a page already in the editor view, and stay on that tab while it loads, my own edittools will remain missing, or disappear if previously correctly loaded.

I do have NoScript installed, but I have it installed on Win XP and Mac as well, and I've configured NoScript to allow all Wiktionary / Wikipedia / Mediawiki domains.

Does anyone have the foggiest idea what's happening? Aside from Microsoft being crap software, I mean? -- Eiríkr Útlendi │ Tala við mig 21:16, 6 February 2013 (UTC)

I coded my edit-tools magic to run after a one-second delay (using window.setTimeout; see the very last section at User:Ruakh/common.js). I no longer remember why I did that, but you might want to try it and see if it helps. —Ruakh_TALK 02:41, 7 February 2013 (UTC)

• Thanks Ruakh, I'll give that a shot tomorrow. It's sleepy bobos time now. -- Eiríkr Útlendi │ Tala við mig 06:22, 7 February 2013 (UTC)

The code in these should be made compatible with that in their respective parent templates. Does anyone know their internals well enough to do that?

• Template:IPAchar ← Template:IPA
• Template:enPRchar ← Template:enPR
• Template:SAMPAchar ← Template:X-SAMPA

The last should probably be moved to Template:X-SAMPAchar, no? —Michael Z. 2013-02-09 20:33 z

I have eliminated as many of these as possible, but there is a significant number of legitimate uses of these labels. Instead of trying to keep the -char templates in sync with the main templates, the main ones should have an option added to display them without the label.

Is someone able to add a label=no argument to {{IPA}}, {{enPR}}, and {{X-SAMPA}}? —Michael Z. 2013-02-17 02:07 z

Actually, a positive nolabel=yes argument is probably better.

Does anyone have any objections or suggestions about changing {{IPAchar}} to {{IPA|. . .|nolabel=yes}}, etc?

— This unsigned comment was added by Mzajac (talk • contribs) at 20:02, 18 February 2013 (UTC).

I’ve added a nolabel argument to {{X-SAMPA}}. nolabel= will hide the “X-SAMPA:” label, so this template can replace {{X-SAMPAchar}}. Trying it out on the following entries: phenomenon, yogurt, chorizo, -andry, Template:U:Latin stop+liquid poetic stress alteration (transcluded in pharetra, idololatres, lucubro). —Michael Z. 2013-02-22 21:51 z

Why? If you're so worried about their falling out of synch, I think it makes more sense to have {{X-SAMPA}} just use {{X-SAMPAchar}} (etc.). Arguments like nolabel=yes are confusing, unwieldy, contradictory, and hard to remember. —Ruakh_TALK 05:53, 23 February 2013 (UTC)

good idea. I will try that. —Michael Z. 2013-02-23 18:27 z

I have updated {{X-SAMPA}} and {{X-SAMPAchar}}. They seem to work. If there’re no problems, I will update the others likewise. —Michael Z. 2013-02-24 17:28 z

Updated {{enPR}} and {{enPRchar}}. Holler if anything looks weird. —Michael Z. 2013-03-01 03:08 z

Updated {{IPA}} and {{IPAchar}}.

Now all of the Xchar templates take multiple arguments, and contain the code to render the characters for the X templates. —Michael Z. 2013-03-05 01:19 z

The information desk has been plagued lately by automated spam, to which an edit filter has been suggested. One feature of this particular spammer is the use of <a href="" It occurred to me, though, that there doesn't seem to be any legitimate reason for anyone to enter an HTML link of this sort at all, since it's exactly equivalent to square brackets in wikicode (except for a few attributes). Would it be possible and/or desirable to create an edit filter for the string "<a href="? Or is there a way to distinguish functioning html links from those quoted in discussion, as in this comment? Chuck Entz (talk) 00:25, 10 February 2013 (UTC)

I wish we would also put a block on people adding "NOT A WORD" to entries. That is quite common. Equinox ◑ 15:23, 10 February 2013 (UTC)

Or a block on "poop" with more than two o's... Chuck Entz (talk) 15:40, 10 February 2013 (UTC)

See WT:Beer_parlour/2013/January#ISO_639-3_changes. It would be good if someone could bot-import the "entirely new code elements" the ISO approved here. Remember that the contents of each added code Template:foo should be the language name followed by <noinclude>{{langt}}. Also, it would be useful if for every added code foo, Template:foo/script could be created with None as its content. And it would be really neat if a list of the added codes could be compiled so that they could all be added to (transcluded by and thus protected by) WT:Index to templates/languages/protection. - -sche (discuss) 04:19, 10 February 2013 (UTC)

As long as they don't overwrite those that have been added already by hand. As usual, some are probably redundant to ones we already have- or have already deleted- and some may even be for languages that don't really exist, but we can sort all of that out later. Chuck Entz (talk) 04:58, 10 February 2013 (UTC)

I've set my bot on the task. There are 81 new codes (not counting the three marked as rejected). You may find a list of the new codes here. DTLHS (talk) 06:33, 10 February 2013 (UTC)

Fantastic! Thank you! - -sche (discuss) 06:47, 10 February 2013 (UTC)

It is really great! Thank you! -- Andrew Krizhanovsky (talk) 07:48, 13 February 2013 (UTC)

As you can see, all the text wrapped in {{Hani}} comes out as blank (which explains why I reverted my own edits to {{vi-adj}}; I think they were in fact correct but it's Hani that's performing weirdly). Hopfully it's just me, or is it a change to MediaWiki:Common.css? {{Hani}} has not been changed. See Commons:File:Vietnamese entry showing Hani bug.jpg. Mglovesfun (talk) 15:12, 10 February 2013 (UTC)

All text? Even this text? -- Liliana • 20:23, 10 February 2013 (UTC)

I see text on 𨳒 (though it's only boxes, not actual characters...grr), and I see Liliana's text. - -sche (discuss) 21:37, 10 February 2013 (UTC)

Hmm no I can see Latin in wrapped up in Hani. I've just checked; Firefox and Internet Explorer display the text perfectly, but not Chrome. I've been using Chrome for months as I started having problems with Firefox all of a sudden, and IE's just plain shit. Mglovesfun (talk) 21:57, 10 February 2013 (UTC)

Doesn't seem to be an issue with Chrome. I think it's a font problem. -- Liliana • 22:29, 10 February 2013 (UTC)

What sort of font problem? I've just made this change to User:Mglovesfun/vector.css after installing the PMingLiU font which I didn't have before. Still not working. If I've made a mistake in that edit, can someone correct it please? Mglovesfun (talk) 23:28, 10 February 2013 (UTC)

Aaaaand it's working again. WTF? Mglovesfun (talk) 11:07, 11 February 2013 (UTC)

Now it's gone again, sigh. Mglovesfun (talk) 11:11, 11 February 2013 (UTC)

PMingLiU doesn't work well for ext-b characters. Leave it out. -- Liliana • 11:20, 11 February 2013 (UTC)

OK, some entries are displaying normally, some such as 𨳒 are not. Hence the confusion. Mglovesfun (talk) 11:47, 11 February 2013 (UTC)

• @Mglovesfun, do you get different results if you (re)load a tab and let it finish loading while that tab is in the background? -- Eiríkr Útlendi │ Tala við mig 18:55, 11 February 2013 (UTC)

Our Headword-line templates produce a bizarre range of HTML. We can’t use CSS to style them consistently.

For an idea of the range code that our templates produce, please see:

• User:Mzajac/English inflection-line templates
• #Japanese headword-line templates, above

What code is in the inflection lines?

It looks like most of them have a <b> or <span> element, or both. Many have lang and script codes and classes, like class="Latn" lang="en". Some have class="infl-inline", which applies display: inline in MediaWiki:Common.css – I only see this uselessly applied to spans, which are inline elements. There’s also a class="None" in {{head}}, which looks like a mistake.

What code should be in an inflection line?

Why not use a <dfn> element? This could be styled in bold roman font, making a <b> element redundant, or styled otherwise for some languages. Perhaps it could use a <dfn class="headword"> or something, as a target for styles and scripts.

 —Michael Z. 2013-02-11 00:25 z

I would agree to using <dfn> if we can be sure that there are no strange surprises with its support in browsers. A CSS class seems like a good alternative too. There is a lot of variation among language-specific templates too. Many just bold the headword with ''', presumably with the assumption that presentation/appearance is all that counts. A number of templates use a script template with face=head, which is handled specially by many script templates. This is what I've been using myself, and I've converted some templates to that when they didn't use it already. —CodeCat 00:30, 11 February 2013 (UTC)

Dfn has been around forever. Some or all browsers render it italicized, so it needs a font-style: normal.

So how exactly does the face argument work, and where would I find the docs for it? —Michael Z. 2013-02-11 05:59 z

I think it bolds the term. See Template:Latn for example. -- Liliana • 11:19, 11 February 2013 (UTC)

Not always. {{Hebr}} and {{Goth}} make the text bigger, and {{Hani}} completely ignores the parameter. I think that is partly why we have script templates; to account for such differences. I think CSS is a better way to do that than templates, though. —CodeCat 14:56, 11 February 2013 (UTC)

I think I understand. What is the intended difference between bold and head in script templates? General boldface and boldface for a headword? If so, then we could plug dfn right into these, assuming they are used as intended. Is that a fair assumption, given the lack of documentation? —Michael Z. 2013-02-11 15:17 z

Yes, but we're currently inconsistent about inflected forms in the headword line: in some headword-line templates they have face=head, in others they have face=bold. —Ruakh_TALK 04:29, 12 February 2013 (UTC)

With some trial and error those could probably be found, though. We could temporarily add some code to the script templates that categorise the page whenever face=bold and the first parameter is equal to the page name (which will catch the majority of headwords!). —CodeCat 14:27, 12 February 2013 (UTC)

Er, sorry, you seem to have misunderstood both the purpose of my comment (I was simply answering Mzajac's factual question with a factual answer) and its content (I wasn't saying that headwords sometimes have face=bold, I was saying that inflected forms sometimes have face=head). —Ruakh_TALK 14:55, 12 February 2013 (UTC)

I think so, yes. We could probably replace face=head with the <dfn> element, with the appropriate changes in the CSS. I think an even better idea would be to abandon script templates altogether, and allow the CSS to do it instead. Are there any cases where that would lead to problems? —CodeCat 15:32, 11 February 2013 (UTC)

You’re right, much simpler to just put <dfn lang="xx"> in the headword-line template and forget about it. A .headword class would only be neede if we ever used <dfn> in another part of the page, which, as far as I know, is not in the foreseeable future. Maybe try this out in a language just a few headword-line templates? —Michael Z. 2013-02-11 16:44 z

Would non-Latin scripts need a class like class="Jpan" to set the script? Or will the lang="ja" attribute be enough, so that the CSS automatically chooses the right script for a language? The former will be much easier for us to do currently, but I do think the latter is better as an ultimate goal, because it lets us get rid of things like {{Xyzy}} and {{ru/script}}. —CodeCat 17:01, 11 February 2013 (UTC)

We only need a class to fix MSIE 6’s broken multilingual text rendering.

For our text tweaking in other browsers, we can start using the lang attribute instead of a class. We still need to provide a script code explicitly if we decide to style multi-script languages, like Sanskrit, Serbo-Croatian, etc., and for special cases like transliterations and IPA. But I hope we can change over to standardized language subtags (lang="sh-Cyrl") instead of classes. —Michael Z. 2013-02-12 03:26 z

I've added the dfn element to {{nl-noun}}, {{ru-noun}} and {{en-noun}}, and added a style for it to the global common.css. It seems to look just fine to me. —CodeCat 17:17, 11 February 2013 (UTC)

Nice to see things moving forward. —Michael Z. 2013-02-12 03:26 z

Any idea why the headword-line template has stuff like this in it: <span class="form-of diminutive-form-of lang-nl gender-n">? I guess some of those are for the PREFS gadgets, but lang-nl is definitely redundant. —Michael Z. 2013-02-12 03:55 z

See WT:ACCEL. —Ruakh_TALK 04:29, 12 February 2013 (UTC)

Some WT:ACCEL pre-loads automatically bold the headword by means of brute-force '''...''' too; cf. my recent creation of longyis. —Angr 15:08, 11 February 2013 (UTC)

Yes, I've been trying to oust that practice for a while now, but I think a few editors (DCDuring if I'm not mistaken) aren't having it... —CodeCat 15:32, 11 February 2013 (UTC)

I never had any objection except for ACCEL of English inflected forms where any extra templates seem silly. I suppose that I still think there is a lot to be said for not killing off standard wikitext, especially for English, unless we are planning on moving this show to another host, especially one better suited for a dictionary. DCDuring TALK 15:49, 11 February 2013 (UTC)

By standardizing the input method for editors, and by controlling the output of HTML and CSS, we make this better suited for a dictionary. Also incidentally make it more portable, if we are ever to entertain such insanely interesting ideas. —Michael Z. 2013-02-11 16:33 z

• One IMHO-compelling reason not to use a <dfn> element is that it violates the HTML 5 spec, since our headword-lines are <p> elements that do not contain a definition of the headword. (I don't necessarily hold that we need always conform to the specs when there's a reason to deviate from them, but when there isn't, it's rather bizarre to use such an uncommon, semantically-specific element in a way that violates its semantics.) —Ruakh_TALK 04:24, 12 February 2013 (UTC)
  • Do you think that is an important enough reason to use span-tags with a class instead? Or is there a better alternative? From Wiktionary's point of view it wouldn't matter that much (except that using a class would mean browsers have to support multiple classes per element). —CodeCat 14:25, 12 February 2013 (UTC)

• Yes, I think that's a compelling reason not to use <dfn>. Though, for a few reasons, I think that <b> is a better option than <span>. —Ruakh_TALK 14:55, 12 February 2013 (UTC)

Crud, I had not seen that bit about the definition in HTML5. The requirement is a “must,” so let’s not violate it. Some options:

1. dl (description list) incorporated into our page markup. This would be a bigger project.
2. strong, indicating the content’s importance. It can continue to be styled as bold, or not, by our current mechanisms, where this is convenient.
   • CSS – strong.headword { font-weight: normal; }
   • HTML – <strong lang="en" class="headword"><b>headword</b></strong>

Once established, we can centralize the face= business in the stylesheet, instead of distributed in 1,000 templates.

strong.headword { font-weight: bold; }

strong.headword:lang(ja) { font-weight: normal; font-size: 1.1em; }

strong.headword:lang(ja-Latn) { font-weight: bold; }

strong.headword:lang(cu) { font-weight: normal; letter-spacing: 0.2em; }

 —Michael Z. 2013-02-12 17:06 z

I’ve changed <dfn> to <strong class="headword" in {{nl-noun}}, {{ru-noun}}, {{en-noun}}, and added a placeholder to MediaWiki:Common.css. —Michael Z. 2013-02-21 02:28 z

I updated some more ru- templates, all but one that uses {{head}}. —Michael Z. 2013-03-01 03:35 z

^New user script. When searching for a word that we don't have an entry for, but do have as translation(s) of other entries, it adds a line or lines to the search page saying "(word) is a (language) translation of (word) (gloss)". It can be enabled using WT:PREFS (at the bottom, "Show translations-listings of words without entries on the search page.") or by adding importScript("User:Yair rand/FindTrans.js") to your common.js.

(We seem to have quite a lot of entry-less words that are listed as translations in numerous places. Kind of odd...) --Yair rand (talk) 11:44, 11 February 2013 (UTC)

Cool! (PS: When will TL be ready for anonymous consumption?) —Μετάknowledge^{discuss/deeds} 17:59, 11 February 2013 (UTC)

(Re TL: Not until bugzilla:27488 is fixed. Maybe if we bug the devs about it enough it will happen sooner... :) --Yair rand (talk) 18:19, 11 February 2013 (UTC))

(Update re TL: The devs have said that it doesn't make sense for them to invest time on Bug 27488 in the current version of Gadgets since Gadgets 2.0 is going to replace it. The development on Gadgets 2.0 is halted "until after the current fiscal year ends, in mid-2013." There's now been a separate bug opened specifically for TL deployment.) --Yair rand (talk) 22:05, 28 February 2013 (UTC))

This should also be enabled for everybody, unless there's a bug I've missed. Do we need a vote or can we just gain consensus for this? (Any improvement of our shoddy search feature is a step in the right direction, IMO.) —Μετάknowledge^{discuss/deeds} 01:52, 13 February 2013 (UTC)

We probably don't need a full vote for this. --Yair rand (talk) 12:08, 14 February 2013 (UTC)

Considering that nobody else s commenting, it's hard to achieve consensus. Unless, of course, we count as consensus. I must say, I really appreciate your scripts; the key is ensuring that a majority instead of a minority of users can utilise them. —Μετάknowledge^{discuss/deeds} 01:27, 15 February 2013 (UTC)

I just searched for Gefangener, which we don't have an entry for but do list as a translation of prisoner, and didn't notice anything new on the search page. Am I misunderstanding which circumstance the script adds a line to the search page under, or is my computer/browser just slow? (I tried searching after adding importScript("User:Yair rand/FindTrans.js") to my common.js, and again after removing it and enabling the PREF. I'm using Firefox 18 on Windows XP. Eh, it may just be that my browser cache didn't clear.) - -sche (discuss) 02:30, 15 February 2013 (UTC)

Your understanding and computer and browser are all presumably fine, but when you search for "Gefangener", the script consults the equivalent of Special:WhatLinksHere/Gefangener, and since ] is all sneaky, linking to ] rather than to ], this approach doesn't find it. —Ruakh_TALK 06:06, 15 February 2013 (UTC)

Well??? Consensus or no? —Μετάknowledge^{discuss/deeds} 05:51, 27 February 2013 (UTC)

I'm gonna give it a go. Mglovesfun (talk) 11:11, 27 February 2013 (UTC)

If it isn't buggy then I see little harm (only slowness) and a good deal of benefit, so support. (That said, I haven't tried it much and don't know whether it isn't buggy.) I would prefer italics rather than quotation marks around the word and its translation (as throughout the site; currently, they have quotation marks, as does the gloss, which should).​—msh210℠ (talk) 23:10, 28 February 2013 (UTC)

Re italics:  Done. --Yair rand (talk) 23:53, 28 February 2013 (UTC)

• Since there wasn't very much response in this thread to whether we should enable the script by default, I've started a discussion in the BP: Wiktionary:Beer parlour/2013/March#Enabling User:Yair rand/FindTrans.js by default. --Yair rand (talk) 05:05, 4 March 2013 (UTC)

Hi,

As some of you know, the Toolserver is set to move to the Wikimedia Labs (it may take some time though), and it may be an opportunity to gather the tools developed individually by various users for their respective language, and organize them in a global project where it would be easier to share those tools.

I don't mean that we should all use the same tools (although that would be ideal) but to organize our tools so that they can be worked on and maintained more efficiently. As an example, here on en.wikt there is a tool to gives random pages in a given language (NB: I developed something similar for fr.wikt), but in August the account of User:Hippietrail expired on the toolserver and the tool was broken for some time. On the labs the tools are not individualized, so that if someone quites, the tool can still work and be maintained as long as some people remain.

I thought at first that I would only create a project for fr.wikt, as we already have a lot of dedicated tools (e.g. anagrams or pronunciations search in fr.wikt), but it may be better to have all languages chapters in the same project, even if in the end the various languages may work independently. That way it will be easier to work on common projects (instead of having one project for every language chapter).

Therefore, I propose to create a common wiktionary project on the Wikimedia Labs where we would migrate our tools (scripts, webservices...). Are any of you interested? Dakdada (talk) 12:27, 12 February 2013 (UTC)

Here is the project proposal. Dakdada (talk) 12:43, 12 February 2013 (UTC)

The project is now known as "wiktionary-tools", with its first instance "wiktionary-dev". If you are interested, create an account on the labs and I will add you to it. Dakdada (talk) 19:06, 12 February 2013 (UTC)

This is all very vague. What specific tools are being developed? Who is developing them? DTLHS (talk) 19:15, 12 February 2013 (UTC)

Many tools which are dedicated to the Wiktionaries are already existing: the crosswords search engine of Darkdadaah, my formating bot or KassadBot... Regrouping them would allow to share and avoid to redevelop them on each project from zero. JackPotte (talk) 19:28, 12 February 2013 (UTC)

To give other examples of tools, apart from the random pages example above: some advanced search tools for fr.wikt (search by pronunciation, graphy, anagrams). I also have scripts to compare Wiktionary words contents (User:Darkdadaah/Diff), or to find unknown words in any Mediawiki dump, or a tool to help create plates. There are also tools to look for new words in news sites (I think there was one on en.wikt too).

There may be other tools developed by individuals in their respective language, so the idea is to gather all these tools in one place where they can be known, shared and maintained. Dakdada (talk) 22:05, 12 February 2013 (UTC)

Wikimedia Foundation has been working on improving performance and adding features to template pages within MediaWiki. As a result of this WMF developed a new Scribunto extension for MediaWiki which enables Lua scripting language for templates. The developers are confident about the extension's maturity and it was decided that Scribunto is going to be deployed to this wiki in the first batch. The deployment will begin on February 18 and will simply add a feature. Please be so kind and spread the word about the deployment on your wiki. If you are interested in converting current templates to Lua, please see more information and submit your feedback to Lua page on Meta. Regards, Kozuch (talk) 18:10, 13 February 2013 (UTC)

Great news! I wonder how much Lua I can learn in five days :-) — Ungoliant ^(Falai) 18:44, 13 February 2013 (UTC)

So, string manipulation at last? (no idea if I've employed the modules the way they are supposed to be). That will make many of the inflection templates a lot more powerful, finally. And easier to use. (rot = root, finn = find, lengd = length, ord = word, for anyone looking at the string and function names) --Njardarlogar (talk) 20:14, 13 February 2013 (UTC)

It will also mean that we don't need as many different templates, because the inflection can be inferred from the ending in many cases. A language like Esperanto would only need one inflection template for all parts of speech! —CodeCat 20:29, 13 February 2013 (UTC)

I'm excited to see a simplification of inflection-table templates, but also an idiot who's never used Lua before. Could somebody demonstrate with a simple example so I can slowly learn how to convert my favorite templates into modules? Also, will we build transliterator templates? —Μετάknowledge^{discuss/deeds} 00:21, 14 February 2013 (UTC)

I've rewritten Njardarlogar's example above to put the entire headword-line template into Scribunto; see test2wiki:Kasta, test2wiki:Template:Nn-verb-1, test2wiki:Module:Njardarlogar/Nn-verb-1. —Ruakh_TALK 06:08, 14 February 2013 (UTC)

Is there any great advantage to putting all of the template into the module? It's harder to maintain the overview in the script code, if nothing else.

There is now a simple way to force a newline. Don't think that was possible, or at least not easy before? (e.g. when substituting parser functions; not counting <br /> which does not work well with subst) Whitespace is also simple now. --Njardarlogar (talk) 09:33, 14 February 2013 (UTC)

Re: "Is there any great advantage to putting all of the template into the module?": Good question. I think there's a disadvantage to treating Scribunto simply as a poor man's StringFunctions, and making the exact same module call six times one right after the other; especially since {{#invoke:Njardarlogar/rot|finn|{{PAGENAME}}}} is not very transparent. (And note, by the way, that I improved the template in a way that — had we tried to do it by just modifying test2wiki:Template:Nn-verb-1 — would have resulted in many more occurrences of {{#invoke:Njardarlogar/rot|finn|{{PAGENAME}}}}. Specifically, I changed the links to point specifically to the Norwegian Nynorsk section of the page, and I added an "attention" category when the verb didn't end with 'a' or 'e'.) But if we want to avoid overusing Scribunto for things that templates can accomplish just fine, then the same goal(s) could have been achieved by having test2wiki:Template:Nn-verb-1 be something like {{ Nn-verb-1/helper | root = {{ #invoke: Njardarlogar/Nn-verb-1 | get_verb_root }} }}. —Ruakh_TALK 16:03, 14 February 2013 (UTC)

I've created Babel templates for Lua so you can show your level of understanding of Lua on Wiktionary: {{User Lua-0}} through {{User Lua-4}} (it has a capital L so that it doesn't conflict with the spoken language {{lua}}). —CodeCat 15:45, 15 February 2013 (UTC)

Scribunto is nice, but our templates are closely intertwined, and Scribunto can't use templates itself. This means that we have to build our Scribunto modules from the ground up, starting from the most basic templates that do not use any other templates. I think our language code templates are a good way to start, since they're so widely used. I have written a small example at User:CodeCat/Module:lang which hopefully gets across the general idea. Because we can't use prefixed names like proto: or etyl: in Lua, I've decided to put languages, reconstructed languages and families all together, but to differentiate them with an extra property called "type". Alternatively, we can decide to have a separate module for families, but {{derivcatboiler}} treats languages and families almost the same, so it would benefit from unifying them. I'd like to know if this general idea is ok, though? —CodeCat 20:26, 13 February 2013 (UTC)

Lua can't use templates? Are you sure about that? Was this a recent change? --Yair rand (talk) 21:04, 13 February 2013 (UTC)

I think it was part of the design of Scribunto. Scribunto does have a few functions that let you evaluate templates and other wikitext, but the documentation explicitly mentions that this is very slow and should be avoided if at all possible. So if we use that, it should be only as a stopgap measure and not permanently. —CodeCat 21:06, 13 February 2013 (UTC)

All I can think is, "baby, meet bathwater." I presume there was a solid technical reason for designing Scribunto this way, but it does seem like a tremendous waste of effort to have to jettison all existing template infrastructure. -- Eiríkr Útlendi │ Tala við mig 22:37, 13 February 2013 (UTC)

Converting the language templates isn't a big problem. A script could fairly easily make an inventory of all our code templates, and generate matching Lua code. What I am asking is more whether we can find a good way to code the language data in Lua. Once we settle on a standard coding practice, I can make a script to convert the templates, and we can then gradually begin converting all of our templates to use them, and deleting the language templates themselves as they become orphaned. —CodeCat 22:45, 13 February 2013 (UTC)

Re: "we can't use prefixed names like proto: or etyl: in Lua": I disagree. In fact, Lua makes it even easier to do so.
Re: "Scribunto does have a few functions that let you evaluate templates and other wikitext": You're mixing up several different things. Scribunto modules output wikitext; we don't (and can't) call any special functions to evaluate wikitext, because that's just an automatic part of the processing of Scribunto's output. There's a special function for calling out to a template, and a broader special function for calling out to the preprocessor (for templates, yes, but also for magic words and parser functions and so on). Both of these special functions return wikitext. And I don't see anything in the documentation that even implies, let alone "explicitly mentions", that either of these "is very slow and should be avoided if at all possible". That's a very strong claim, and I think it requires a supporting link — but I doubt there is one, because it's wrong, at least in the general case. Tim Starling's draft roadmap for Scribunto, written just two and a half months ago, describes mw.getCurrentFrame():preprocess('{{PAGENAME}}') as "simple and efficient".
I think we need to be very careful in making these sorts of statements; whatever practices we promote now are likely to become very pervasive. Any hunches that we erroneously promote to facthood are likely to haunt our Scribunto module designs for years (especially efficiency-related hunches, since as you know, those can be really hard to test).
—Ruakh_TALK 06:30, 14 February 2013 (UTC)

Sources: mw:Extension:Scribunto/Parser interface design#Parent frame access, ]

And just because we can use these prefixes doesn't mean we should. But I am not getting into this argument with you again because it never gets us anywhere and will just serve to divert the topic. —CodeCat 14:30, 14 February 2013 (UTC)

Re: sources: Thanks for the links. The first one does not support your claim, and the second one is to a statement that was added by Uncle G (talk • contribs), who obviously doesn't know as much about the subject as Tim Starling. Furthermore, although he writes "Avoid frame:preprocess() like the plague", from context it seems that he's really only thinking about templates, and hasn't considered other uses.
Re: your whole second paragraph: WTF?? First you claimed that we can't use prefixes; now it turns out that you know that we can, and you simply don't want to — and don't want to discuss it — so you hoped that you could get away with bypassing the argument by just lying and claiming that we have to do it your way. (Right? I want to assume good faith here, but this really seems to be what you're saying. Please correct me if I'm wrong.) Similarly, to a lesser extent, with having Scribunto call templates: first you claimed that Scribunto "can't" do it, and now it becomes clear that you knew that we could, and simply thought we shouldn't. It's valid to say so when you think we shouldn't do something, but you absolutely should not pretend that something can't be done when you know perfectly well that it can.
—Ruakh_TALK 15:27, 14 February 2013 (UTC)

You never said how it could be done, so I assumed you intended to use string parsing to pick out the "proto:" in each string. Which I think would be completely counterproductive and therefore should not be done. So it's not possible for practical purposes. But I've kind of given up trying to reason with you on this subject, because I don't feel that you are being reasonable. I will wait for others to give their views, I already knew yours before I started this discussion... —CodeCat 16:40, 14 February 2013 (UTC)

I don't know why you feel I'm being unreasonable. As far as I can tell, it's simply because I disagree with you . . . so since turnabout is fairplay, I hereby deem you to be unreasonable. :-P   But seriously . . . we can both regard each other as unreasonable, if we want, but we still need to be honest with each other, and with everyone else. Don't say that we "can't" do something in Lua when what you mean is that you'd rather we didn't — especially when, as in this case, you already know that others disagree with that preference. —Ruakh_TALK 04:15, 15 February 2013 (UTC)

CodeCat and others, please bear in mind that being bold is small step from being rash; and that it can be hard to undo steps once taken. This is a big change for the project, and no non-negligible part of it should be done unilaterally.​—msh210℠ (talk) 19:01, 15 February 2013 (UTC)

That's kind of why I created this topic. To discuss, you know... —CodeCat 19:04, 15 February 2013 (UTC)

Unfortunately as it is Lua is still unusable, as there is still no Unicode support at all. (See bugzilla:39646) -- Liliana • 10:42, 14 February 2013 (UTC)

Wow, that's bad. It appears, though, that as long as you don't try to interact with the unicode symbols themselves, it works fine. Compare Æøåêr with Æøåê. In both these cases, the last letter is removed, and that screws up when the last letter needs unicode; it seems. --Njardarlogar (talk) 12:40, 14 February 2013 (UTC)

It doesn't explicitly support Unicode, but that's not a problem because it uses UTF-8. That just means that you need to be aware that certain characters have a length of more than 1, and you shouldn't cut them in half. So it's far from unusuable. —CodeCat 14:31, 14 February 2013 (UTC)

Anyway, when are we going to get it? I wrote versions of the Italian conjugation templates back in September last year (on the test wiki), and have subsequently forgotten everything about it. SemperBlotto (talk) 15:32, 14 February 2013 (UTC)

Look to the section above this one. --Njardarlogar (talk) 15:42, 14 February 2013 (UTC)

Is it rash to suggest that we continue to use templates for templating, and only dive into procedural code when complex logic is necessary? A template is far more accessible and understandable, much easier to relate directly to the output code, even for a programmer. There’s no reason to bury basic wikitext or HTML, or a simple category declaration, in a remote procedure call. —Michael Z. 2013-02-14 16:51 z

I totally agree. Only complex templates with lots of "if" statements and the like should be converted. There would be no savings on converting a simple template such as {{it-adv}} that has no logic in it. SemperBlotto (talk) 16:57, 14 February 2013 (UTC)

Indeed, let's not reinvent the wheel. Mglovesfun (talk) 17:34, 14 February 2013 (UTC)

Is Lua good for handling the complexity of {{context}}? Wouldn't it be good at handling anything where we might have zero, one, or multiple simultaneous values for a parameter, eg, in taxonomic names where different authorities give a different direct hypernyms (at the same level) to a given taxon or in {{term}} where there may be multiple glosses useful to display in an etymology? — This unsigned comment was added by DCDuring (talk • contribs) at 18:29, 14 February 2013 (UTC).

Yes, absolutely. I think {{context}} should be among the very first templates we convert, once we get the language templates sorted out. (Or heck, even before we get the language templates sorted out. The only thing it needs the language-templates for is getting the language name, and we can always just have Template:context pass that into the Scribunto module for now.) —Ruakh_TALK 06:00, 15 February 2013 (UTC)

Weren't we supposed to replace it with {{label}}? -- Liliana • 15:56, 15 February 2013 (UTC)

• I've been altering instances I run into of things like {{slang}} or {{physics}} into {{context|slang}} or {{context|physics}} on the theory that this removes some of the recursion. -- Eiríkr Útlendi │ Tala við mig 01:21, 16 February 2013 (UTC)

• And I've been doing the opposite (only when editing anyway and only for some context tags) because someone told me that with the extra {{context}} it's more labor-intensive (by the server).  :-) ​—msh210℠ (talk) 04:34, 17 February 2013 (UTC)

Ok, so... to get back to the topic this was originally started for... Is the example I gave at User:CodeCat/Module:lang ok? We can always leave out the reconstructed languages and the "type" part for the time being, until we settle on how to do that. I think having something we can agree on, even if it's not complete, is better than having to wait because we are trying to solve the whole problem in one go. —CodeCat 22:02, 17 February 2013 (UTC)

Would it be faster than just having Lua use the existing language templates? If not, we should continue to use the current ones. --Yair rand (talk) 22:25, 17 February 2013 (UTC)

Yes it would definitely be faster. Using the existing language templates means having to do one page lookup, then parsing, for every code, script or family that is looked up. Lua is presumably precompiled, so the module would have to be loaded once and then it can be used lots of times within a script with nearly no additional cost. —CodeCat 22:42, 17 February 2013 (UTC)

I'm not sure of the details, but I don't think your last sentence can be completely true, given that (according to mw:Extension:Scribunto#Lua environment, “Each {{#invoke:}} call runs in a separate environment. Variables defined in one {{#invoke:}} will not be available from another. This restriction was necessary to maintain flexibility in the wikitext parser implementation”, which means that modules can't be cached in a pre-evaluated form. Furthermore, although there does seem to exist a Lua compiler, I believe (based on a quick look through the source code) that we use the interpreter instead; and I'm not sure whether or not we even store the Lua module in a pre-parsed form. —Ruakh_TALK 02:18, 18 February 2013 (UTC)

But there is also a remark at : "Similarly, avoid things like using w:Template:ISO 639 name aze to store what is effectively an entry in a database. Reading it would be a nested parser call with concomitant database queries, all to map a string onto another string. Put a simple straightforward data table in your module, like the ones in Module:Language]." That seems like a de facto endorsement of just this thing. I would like some more information on this myself, but I do think that if our old template-style implementation is faster, then that isn't a reason for us not to use Lua to do it; it's a reason for them to fix Scribunto so that this is no longer an issue. And besides, there is no way for us to know whether this really does work better until we try it out. So why don't we try it out? The old language templates won't disappear overnight, the two can exist side by side while we compare them. —CodeCat 02:32, 18 February 2013 (UTC)

Yes, but remember, that passage was written by someone with no special inside knowledge. (This is the same guy who showed up last September 4th and told us breathlessly that Scribunto was going to be enabled here "in a day or so".^link) He may be right, of course — I really have no idea — but some of his pronouncements warrant a grain of salt. (And we may want to direct some questions to developers who are in a better position to answer them accurately. Questions like, "How do we know whether a given template should be Luacized?" Oh, and hey, I now see that you've already started taking steps in that direction.^link Thanks. :-)   ) —Ruakh_TALK 03:34, 18 February 2013 (UTC)

I've taken a few steps further. :) I joined the #wikimedia-tech IRC channel, and asked about it. Tim Starling was available so he answered some questions and also provided some useful insights that might be useful to us more generally. There is a log of the conversation here. The main points are: 1. A module is parsed and compiled once per page, regardless of how many invocations there are on that page. 2. the approach with a large module that is imported hundreds of times is not a problem speed-wise, so it will still be faster (he gives some statistics). From that I gather that 3. There is no speed-detriment whatsoever for converting all templates to Lua. —CodeCat 03:48, 18 February 2013 (UTC)

Awesome, thank you! I think it'll be a while before I've fully digested all of that, but it sounds good.   Re: "There is no speed-detriment whatsoever for converting all templates to Lua": Well, that's certainly not completely true. Consider a template like {{en}}, which evaluates to English. Changing it to {{#invoke:…}} would definitely have an adverse performance impact, because it would mean that already the preprocessor is doing more work (in addition to Scribunto having to do work). But yeah, it sounds like any statement of the form "We shouldn't Luacize ____ because it's faster in template-space" is probably a micro-optimization at best. (Of course, statements of the form "We should Luacize ____ because it'll be faster that way" are also likely to be micro-optimizations.) —Ruakh_TALK 04:18, 18 February 2013 (UTC)

That's true, but consider that code templates like {{en}} are not used directly in pages, they are only transcluded from within templates. That means that if we convert it, we already have the invocation overhead from the parent template, but the extra overhead from looking up the code becomes much lower by comparison because it is internal within Lua. The impact you mention would only really be an issue if we ever had a need to look up codes directly from within a page, but that almost never happens. —CodeCat 04:28, 18 February 2013 (UTC)

Yes, absolutely. I just chose {{en}} as my example because it was the first template-that-doesn't-do-anything-interesting that came to mind. —Ruakh_TALK 04:46, 18 February 2013 (UTC)

As a rule of thumb I'd say that any templates that don't contain parser functions are probably not worth converting. I don't know if it's also true of parameters. But we don't have many templates that are that simple, even declension tables still often contain a parser function or two. —CodeCat 04:53, 18 February 2013 (UTC)

If I have around 5 templates like this one, would it be an idea to put them all into the same module (an expanded version of what Ruakh did here) and then simply pass on to this module which inflection is being used? (and either still have 5 templates, each passing on the inflection class directly; or have just 1 template that receives the inflection class as an argument from the individual entry in the main space). It would be much easier to maintain just one page.

I suppose another way of asking the question is: would 5 extra if conditions slow down the template to such an extent that that it should be avoided as a matter of principle? --Njardarlogar (talk) 09:44, 18 February 2013 (UTC)

A module can contain many functions, and there is no reason why different templates couldn't call different functions within the same module. So, for example, {{nn-verb-1}} might invoke Module:nn verb with one function, and {{nn-verb-2}} would invoke that same module with another function. You could also do it by passing a parameter, but that depends on whether there is a big difference. There wouldn't be that much of a point in passing a parameter to, say, a function that is supposed to handle both {{nl-conj-wk}} and {{nl-conj-st}}, because they are too different for that to be practical. I do personally think that it would be a good idea to combine both {{nn-verb}} (the headword-line template) and {{nn-verb-1}} (inflection table) into a single module. Headword-line templates often generate inflected forms, so it would be more practical if they appeared in the same module as the inflection table so that they could share common functions more easily. I would like to follow a general rule that modules are split by part of speech, so that a single module handles, say, all verbs in a language (both their headword lines and inflection tables). For parts of speech that don't require much coding (like prepositions) and for the code that is not specific to any part of speech, there could be a "common" module, like Module:nn or Module:nn common. —CodeCat 14:57, 18 February 2013 (UTC)

I did 10 test runs for the page oppleve before and after introducing the module (the 4th class became redunant with the module; so that particular template change introduced Lua). The relevant module, Module:nn-verb, is quite massive (the non-Lua template not so much; yet the post-Lua results had an average of 0.714s, while the pre-Lua results had an average of 0.941; so even (unnecessarily) massive modules can be significantly faster than traditional templates.

Though, how much slower the addition of support for additional verb classes makes the module I have yet to test. --Njardarlogar (talk) 19:01, 19 February 2013 (UTC)

Did 5 and 10 runs on vøla comparing the slimmer verion of Module:nn-verb to the fatter version of it. The 5s were for checking the Lua time only; in which case both versions ended up with an average of 0.004s. The 10s compared the rendering of the entire page, and the slim version had an average of 0.743s and the fat one 0.745s. So if these methods of measurement are reliable, then apparently you need to add a lot of code (or small but particularly demanding pieces) to Lua before it slows notably. --Njardarlogar (talk) 19:26, 19 February 2013 (UTC)

Could someone remove this page from Category:Japanese い-i adjectives? I suppose {{ja-adj}} is the problem but I can't see what the problem is, nor how to fix it. Mglovesfun (talk) 16:42, 14 February 2013 (UTC)

 Done. I was actually working on it just as you posted here. :-)   —Ruakh_TALK 16:45, 14 February 2013 (UTC)

Some people have already mentioned automatic transliteration using Lua. That is probably something we want to do. But there is also something similar that we should consider... automatic removal of diacritics. Many of our templates currently have two distinct parameters, one for the main headword and another for the headword with diacritics. For example {{l|la|amo|amō}}. Lua could automatically remove the diacritics, based on rules that are set for each language, so such templates would no longer need the extra parameter. {{l|la|amō}} alone would be enough. —CodeCat 02:59, 17 February 2013 (UTC)

I'd like that. Add to that list stripping diacritics from {{t}} & Co., which make make most uses of alt= unnecessary. Also, languages in which IPA can be reliably written based on spelling or transliteration (Spanish, Ido, Mandarin, etc) could be "transliterated" into IPA. I'd love to help once there are examples for me to copy. —Μετάknowledge^{discuss/deeds} 03:22, 17 February 2013 (UTC)

We could do this for all templates, as long as we keep some kind of central module with the information necessary for all languages, which all templates that want to create links can then use. Perhaps something like Module:Links which would include the Lua backends of templates like {{term}}, {{l}} and {{t}}, and which could also be imported by language-specific modules. —CodeCat 03:44, 17 February 2013 (UTC)

I'm not sure doing it with t would be helpful. WT:EDIT already automatically strips diacritics for the user when adding a translation. --Yair rand (talk) 12:26, 17 February 2013 (UTC)

There is no reason when you look at it that way, but on the other hand it wouldn't be detrimental either. And for the sake of consistency, why not? —CodeCat 14:49, 17 February 2013 (UTC)

@Yair: That wasn't always the case, and editors sometimes have trouble using the script and edit directly. The problem isn't too acute, but there are examples out there, and I'd like to see it solved. —Μετάknowledge^{discuss/deeds} 15:59, 17 February 2013 (UTC)

A few years ago, User:TheCheatBot mass-created loads of English entries of verb and noun forms. How would one create a similar thing for Spanish? I'm talking about nouns and adjectives in Spanish, as there's thousands of missing forms there, and the bot would only have to read the templates and add the forms, saving a human user lots of time. Is this possible? Or is ACCEL the quickest way to do this? --She Isnt Me (talk) 19:47, 17 February 2013 (UTC)

It's hard to give you advice without knowing your level of programming expertise. Many bots use the pywikipediabot framework to upload pages. DTLHS (talk) 22:43, 17 February 2013 (UTC)

Please please please! I've been adding them manually, and it's almost not worth the effort. —Μετάknowledge^{discuss/deeds} 01:22, 18 February 2013 (UTC)

Wiktionary:Languages#List_of_languages_with_multiple_names is out-of-date, and IMO it doesn't make sense to try to maintain it by hand, anyway. If we want a list of languages with multiple names, could someone write a bot to maintain it (on a subpage which WT:LANG would transclude, à la WT:STATS)? The bot could either check WT:LANGLIST each time it is updated, or go directly to the source WT:LANGLIST gets its info from, and add to the "multiple names" list all languages with Template:foo/names subpages containing more than one name. (To tell if a subpage contained more than one name, the bot could check if it contained a comma.) But: do we even want a list of languages with multiple names? Is it useful to anyone, or just clutter? - -sche (discuss) 06:12, 18 February 2013 (UTC)

If it was on RFDO, I think I'd vote delete. —Μετάknowledge^{discuss/deeds} 16:08, 18 February 2013 (UTC)

My impression is that most languages could have multiple names, if you count things like hyphenation or qualifiers such as "Modern" or "Standard". Is our system of naming conceptually rigorous enough for the difference between having alternative names and not having them to have any real meaning? If someone is just looking for the language that a given alternative name belongs to, it would be better to just go to WT:LANGLIST and do a text search. This page is really just WT:LANGLIST with the single-name entries removed. Chuck Entz (talk) 18:05, 18 February 2013 (UTC)

This is showing up as completely blank to me, is it anything to do with class="NavContent"? Mglovesfun (talk) 19:21, 18 February 2013 (UTC)

If I remember correctly, NavContent must be inside NavFrame. Take another look. — Ungoliant ^(Falai) 20:26, 18 February 2013 (UTC)

Looks good, thanks! I've made the same change to {{fro-indefinite-article}}, per Chuck Entz's comment below. —Ruakh_TALK 21:36, 18 February 2013 (UTC)

Also, I've edited MediaWiki:Common.css to avert this in future.^link I mean, class="NavContent" should never appear outside class="NavFrame" anyway, but when it does, it might as well not totally break. —Ruakh_TALK 21:40, 18 February 2013 (UTC)

(edit conflict) Template:fro-indefinite-article has the same problem. Comparing those two with the other members of Category:Old French declension-table templates might be helpful. To my untrained eye, it looks like class="NavContent" might not be the problem, per se, because other templates have it (in combination with other code not in these two) and work fine. Chuck Entz (talk) 20:29, 18 February 2013 (UTC)

...currently thinks that its associated language category should be ], whereas {{ase}} correctly understands that its language category is Category:American Sign Language. What needs to be done to make {{sqk}} drop the extra "language"? - -sche (discuss) 20:14, 18 February 2013 (UTC)

I think that bit is done by {{languageshift}}. —CodeCat 20:19, 18 February 2013 (UTC)

Yep. I just added it. — Ungoliant ^(Falai) 20:21, 18 February 2013 (UTC)

Thanks, both of you! - -sche (discuss) 20:47, 18 February 2013 (UTC)

{{unicode}} has about a zillion transclusions. Its function is to work around MSIE 6’s inability to display Unicode text. It applies class="Unicode" to a span of text. In the style sheet MediaWiki:Common.css, the class is used to apply a long font-family stack in MSIE 6 only.

   /* Template:unicode */
   .Unicode {
       font-family: TITUS Cyberbit Basic, Code2000, Doulos SIL, Chrysanthi Unicode, Bitstream Cyberbit, 
           Bitstream CyberBase, Bitstream Vera, Thryomanes, Gentium, GentiumAlt, Visual Geez Unicode, 
           Lucida Grande, Tahoma, Arial Unicode MS, Microsoft Sans Serif, Lucida Sans Unicode, sans-serif;
       font-family /**/:inherit;
       text-decoration: none;
       }

Questions:

1. text-decoration: none; is being applied in all browsers. I believe this was simply copied from {{IPA}}, where it helps the readability of IPA in a link. Is there a need for {{unicode}} to do this? Examples?
2. The face attribute has been added to this template, so it adds HTML into pages. Why? Can we transfer this function to templates that aren’t merely there to fix MSIE 6 bugs?

We could simply apply a good unicode font-family declaration, for MSIE 6 only, to the root <body> element. Then we could completely remove {{unicode}}. Maybe {{Latinx}} too, which is almost a subset of the fonts in {{unicode}}. —Michael Z. 2013-02-18 22:03 z

Re: why it supports face=: that's because it's a script template. See e.g. {{proto:ine-pro/script}}. Re: adding it to the <body> element: I dunno, that seems pretty extreme. Wouldn't it look kind of terrible? —Ruakh_TALK 22:19, 18 February 2013 (UTC)

MSIE 6 is only supported on Windows XP, and has been replaced on newer MS OSes. The default Win XP fonts in our .unicode font stack are Tahoma, Microsoft Sans Serif, and Lucida Sans Unicode, in that order. So of the 1% using MSIE 6, probably 99.9% will be seeing the page in Tahoma. I haven’t even looked at MSIE 6 and Windows XP in years, but from memory, any font looks like pants in it, so its users are probably not setting high standards. But in any case, I think a page in Tahoma would look better than an Arial+Tahoma patchwork. —Michael Z. 2013-02-19 15:58 z

In case you’re not aware, the font-family /**/:inherit; line resets that font spec, for every browser except MSIE 6. —Michael Z. 2013-02-19 16:59 z

I feel we should avoid hacks as they will break in future browser versions when the underlying bugs get fixed. Equinox ◑ 17:04, 19 February 2013 (UTC)

It’s not exactly a “hack,” but this is the very point. It takes advantage of a bug in MSIE 6 to serve that browser CSS which works around an unrelated MSIE 6 bug. MSIE 7+ fixes both of these problems. This is 100% valid CSS, and will continue to be harmless in all future browsers.

I brought this techniques to Wikipedia and Wiktionary because editors wanted to use a real hack: imposing a font choice on all browsers as a solution for broken text display in only one. MSIE 6, which is practically incapable of displaying international text properly, is now a tiny minority, and I can barely wait for it to drop below the radar so we can remove most of these font-choice hacks.

The real problem is that we’ve become accustomed to doing this, and have stitched together a whole network of hacks around it. More than 85 (!) font stacks are being served up for all browsers, where they are probably quite unnecessary. The basis for this practice will be gone in the near future. I want to get started on unravelling this tangled mess. —Michael Z. 2013-02-20 18:44 z

Scribunto has been installed, judging from Special:Version. However, a recommendation at meta:Lua says that it's preferable if we don't start converting templates just yet, because the deployment might still fail and that would leave us with templates that don't work. I don't know if it's safe to create new Scribunto modules, because if they end up having to remove the extension temporarily, it could take the Module: namespace and all of its contents with it.

We don't really have any established practices yet when it comes to Lua, so the first few months will probably be a bit awkward while we try to find out what practices work best for us and what does not. One suggestion I made a bit above is to group modules for a given language by part of speech, and put functions for both headword lines (like {{es-verb}}) and inflection tables (like {{es-conj-ar}}) together in the same module. Headword-line templates often also display inflected forms, so it makes sense to put them into the same module so that they can share common operations when necessary. I also proposed having a "general" module for each language, which we could name after the language, like Module:en for English. This module would contain shared code and also things that are too small in scale to dedicate a whole module to (like {{en-interj}} which is completely trivial). Many languages might not even need more than this one module. We don't currently have a naming scheme for modules, but I suggest using lowercase like we already do with templates. I'm not sure if we should also copy the practice of separating words and codes with hyphens (-)... we could also use spaces, or maybe choose to separate the language code from the remainder with a hyphen or some other character, and separate the rest with spaces. This is a whole new start so we have an opportunity to think about it and try to get it right the first time. :)

I am currently working on collecting all of the data in our language code templates, and I will then try to convert it into Lua. Me and Ruakh have written some information about using Scribunto and Lua at Wiktionary:Scribunto. There is also a page Wiktionary:Scribunto/Converting templates for tips and notes that might be useful when migrating from templates to Lua, and to help "translate" concepts that you may be familiar with. I hope it helps. There are also new Babel templates that you can use to show how well you are able to write Lua code on Wiktionary. You can add them with Lua-0 (don't understand it at all) to Lua-4 (understand all the details easily).

Happy coding! —CodeCat 00:05, 19 February 2013 (UTC)

Just a note about something I realised. When making and testing templates, we could use a page that was a subpage of our own user page as a sandbox. Scribunto does not allow that, it has to be in the Module: namespace, although subpages still work as usual. So I propose that everyone can use a module (and its subpages) that has the same name as their user page, for testing purposes. For example, for me that would be Module:User:CodeCat and subpages. The extra User: would be needed to avoid clashes, in case we have someone whose name just happens to be the same as a module we already have. —CodeCat 02:35, 19 February 2013 (UTC)

Regarding naming, I suggest that we use unabbreviated names for modules, and create redirects for abbreviated versions of the name. It’s frustrating to go through four or five preview cycles and then start searching Wiktionary to determine whether I should type en-interjection, en-interject, en-interj, en-inter, or en-int. —Michael Z. 2013-02-19 15:35 z

I think I agree. With templates, abbreviated names make some sense because we often have to type them in entries. But modules are never invoked directly from entries (at least I don't think they should) so that isn't a problem. —CodeCat 15:39, 19 February 2013 (UTC)

• Should we have the script that adds the "Documentation" tab to templates also work on modules? --Yair rand (talk) 17:03, 20 February 2013 (UTC)
  • Actually, there is a slight problem with documentation subpages. It is sometimes necessary to create a subpage named "doc" for the language whose code is "doc", and that will lead to a conflict. —CodeCat 17:07, 20 February 2013 (UTC)
    • Why not use /docu as the subpage name for documentation? —Angr 17:52, 20 February 2013 (UTC)
    • {{doc}} does not currently exist (you deleted it), and I've suggested formally merging it with its southern co-dialect, {{kmc}}. That would free up /doc pages, though we could always decide to use /docu anyway. - -sche (discuss) 18:00, 20 February 2013 (UTC)

• I'd like to strongly recommend that Scribunto module codes and abbreviations be ^^{at least} four letters to avoid any possible overlap and confusion with lang codes. /docu is unambiguously not a lang code, and would be preferable to just /doc, even if we don't actually have a {{doc}} language. -- Eiríkr Útlendi │ Tala við mig 18:50, 20 February 2013 (UTC)
  • Of course, Docu could be a script code. :-)   Anyway, what's wrong with documentation? —Ruakh_TALK 05:04, 21 February 2013 (UTC)
    • Ah, yes, I should have been clearer -- I've amended my comment above.  :) -- Eiríkr Útlendi │ Tala við mig 17:47, 21 February 2013 (UTC)

Is there any reason why the module code is in such a tiny font? Can we fix this? DTLHS (talk) 21:28, 20 February 2013 (UTC)

•  Fixed. Note that you will probably need to visit http://bits.wikimedia.org/en.wiktionary.org/load.php?debug=false&lang=en&modules=site&only=styles&skin=vector&* and perform a hard-refresh there if you want to get the fix anytime soon. —Ruakh_TALK 05:04, 21 February 2013 (UTC)

Can this be done? —CodeCat 20:48, 19 February 2013 (UTC)

• I can't see how it could be. Another thing you can't do is redirect them (or move them and leave a redirect). I haven't tried adding an {{rfd}} template to one, but I imagine that wouldn't work either. SemperBlotto (talk) 20:55, 19 February 2013 (UTC)

You can categorize the discussion pages, right? DTLHS (talk) 23:15, 19 February 2013 (UTC)

Yeap. --Njardarlogar (talk) 23:25, 19 February 2013 (UTC)

That is better than nothing then. I suppose we should just categorise the talk pages instead. —CodeCat 23:56, 19 February 2013 (UTC)

And if someone wants to nominate one for deletion, the talk page is the place to put the tag, too. —Angr 08:19, 20 February 2013 (UTC)

Where should we categorise them? Would it be best to just categorise them in the current categories we have for templates? —CodeCat 12:31, 20 February 2013 (UTC)

Isn't it better to categorize them as modules and not as templates? Mglovesfun (talk) 12:37, 20 February 2013 (UTC)

It might not be, if we have enough of them, but for now, I think we should put them in Category:Modules just to make it easier to keep track of how many we have, what kinds, etc. —Μετάknowledge^{discuss/deeds} 14:45, 20 February 2013 (UTC)

My reasoning is that modules generally work in tandem with templates, so it is useful if they can be found in the same category. If we want to categorise modules into their own category, why not put them in both when applicable? —CodeCat 15:01, 20 February 2013 (UTC)

For the time being, they should go in the same categories as the templates, but Category:xxx Templates would then become, strictly speaking, a misnomer, since modules aren't templates. We need to come up with a term that covers both modules and templates, in the same way that "term" covers both words and phrases. Chuck Entz (talk) 15:17, 20 February 2013 (UTC)

I propose "tempules" for that. Sounds better than "modplates". —Angr 18:16, 20 February 2013 (UTC)

If the idea is that all modules would go in Category:Modules, then that category would just be redundant to Special:PrefixIndex/Module:, no? —Ruakh_TALK 15:10, 20 February 2013 (UTC)

We also have Category:Templates, so presumably Category:Modules would follow the same path. —CodeCat 15:32, 20 February 2013 (UTC)

When a template uses a Scribunto module, and the template has required (non-optional) parameters, then the template page will display a script error (like {{nl-conj-wk}}) even though it works ok when it's transcluded. Is there a way to prevent that from happening, without making the parameters optional? —CodeCat 21:41, 20 February 2013 (UTC)

Here's one way: Module:nl-verb?diff=19612164. —Ruakh_TALK 04:56, 21 February 2013 (UTC)

See, as examples, {{it-noun}} and {{it-adj}}. The module tests for the presence of required parameters and issues an error message if absent. SemperBlotto (talk) 08:07, 23 February 2013 (UTC)

Sorry, but you've misunderstood CodeCat's question. {{nl-conj-wk}} does the same thing; the point is that it shouldn't do that on the template-page itself. You circumvented that by simply using <includeonly>, but CodeCat sought a better solution. —Ruakh_TALK 16:56, 23 February 2013 (UTC)

The way I go about this is to pass the parameters in directly from the calling template. This means that instead of using frame.getParent().args, you use frame.args. In the module, when handling the parameters, instead of raising an error on a missing required parameter, you simply convert it to an empty string and make a check against it in the code. Take a look at Module:zh-hanzi-box and Template:zh-hanzi-box. This is still just a workaround. Someone higher up needs to find a solution to the script error. Jamesjiao → ^{T ◊ C} 21:49, 25 February 2013 (UTC)

Your first two sentences are not really true, or at least, not really relevant. The decision whether or not to raise an error when parameters are missing is completely orthogonal to the decision whether to pass in arguments in a way that requires frame:getParent().args or one that requires frame.args. (Looking at the history of Module:zh-hanzi-box, I get the impression that you originally realized this, but then were somehow led to believe you'd been mistaken. Suffice it to say, you were correct to begin with, and were later led astray. Maybe you forgot to take into account the job queue?) —Ruakh_TALK 07:32, 26 February 2013 (UTC)

Hi Ruakh. I think you might have overestimated my understanding of this. What job queue are you speaking of? At one point in my code history, I had exactly what it looks like now in the init function: edit. However when I checked the namesake template, it actually showed the same script error, only without my customized error message. I only base my changes on what I observe. There might be a delay between a change in the module and when its associated template realizes that a change has taken place. I don't know. I don't have access to the backend, so this is all I can tell you. Jamesjiao → ^{T ◊ C} 20:34, 27 February 2013 (UTC)

Re: "There might be a delay between a change in the module and when its associated template realizes that a change has taken place": Essentially yes. When you edit a template or module, the pages that transclude that template or module are not instantly regenerated. Instead, they're added to a list called the "job queue", and the software will subsequently go through the job queue and regenerate those pages. (This has always been the case when you edit a template; the Scribunto extension just makes use of the same feature for modules.)
If you want to force a page to be regenerated immediately, you can make a "null edit" (click "Edit", then click "Save page" without actually changing anything). If you don't care to do that, but you want to see what it'll look like once it is regenerated, you can click "Edit" and then "Show preview".
—Ruakh_TALK 05:17, 28 February 2013 (UTC)

That makes sense. Thanks! Jamesjiao → ^{T ◊ C} 20:46, 2 March 2013 (UTC)

I’m trying to clean up the delightful variety of HTML generated by the #Japanese headword-line templates. I’m looking at the following headword-line templates:

• Template:meta-diacritical mark
• Template:meta-punctuation mark
• Template:meta-combining form (with script)
• Template:meta-phrase (with transliteration)

Why do these templates require a script code? Is there any reason not to just turn them into a custom call to {{head}}? —Michael Z. 2013-02-21 00:40 z

{{look}} While these are all very small templates, they do have a few features that many editors are likely not aware of (like the optional period, or the title text). That means that if we decide that each template should "roll its own" form of gender-and-number display, those features will probably be forgotten. So I think it would be nice to convert them into Lua. How should that be done? My initial thought is to have a single function that accepts a table of genders, and loops over each of them, converting it to a proper string, then concatenates them all together. However, we would need something to be able to distinguish, say, m and f gender (which is two genders so it needs "and") from m p gender (which is only one gender so does not need "and")? —CodeCat 18:29, 23 February 2013 (UTC)

Bumping this because this is kind of a blocking issue for me, I can't convert {{nl-noun}} without having some kind of answer for this... —CodeCat 16:51, 4 March 2013 (UTC)

Those who have done the most to develop and design them would be the most relevant people to ask. Personally, I have little knowledge of the intricacies of these templates. --Njardarlogar (talk) 17:51, 4 March 2013 (UTC)

While we’re at it, can we simplify and clean up the code? For example:

<span class="number s" title="singular number"><i>sg<span class="gender-period">.</span></i></span>

1. Instead of <span><i>, let’s use a semantic <abbr> tag, with abbr.gender, abbr.number { font-style: italic; } in the style sheet
   • The title attributes should expand abbreviations, not define them: <abbr title="singular">sg</abbr> as it would be read out loud, not “singular number.”
2. Drop <span class="gender-period">.</span>, and use CSS abbr.gender:after { content: '.'; } to add a period. (Not supported in MSIE ≤7, but registered editors don’t use outdated browsers, right?).
   • Or maybe just agree on one style or the other and drop this needless user preference altogether.
3. Instead of a bevy of independent classes (.gender .m .f .n .c .c1 .c1a .c2 .c2a .c3 .c3a .c4 .c4a .c5 .c6 .c7 .8 .c9 .c10 .c11 .c12 .c13 .c14 .c15 .c16 .c17 .number .s .p), use compound classes like .gender-m and .number-s. The style sheet can use a full list for older browsers, but customizations can use modern selectors: abbr { }.
4. Missing classes: dual in {{dual}}, invariant in {{inv}}
5. Serial comma preference? What percentage of Wiktionary readers use that?

 —Michael Z. 2013-03-04 18:38 z

I like plenty of commas in my cereal.

More seriously, I do prefer the serial comma, as I find it makes for quicker visual parsing of comma-separated lists when the last two distinct items are separated by a comma, rather than just the "and". -- Eiríkr Útlendi │ Tala við mig 20:32, 4 March 2013 (UTC)

I happen to have the same preference, so let’s propose a new writing-style guideline in the BP.

But the question for here is whether there needs to be a user preference for this. I don’t think we need parser code to help a machine copy-edit some tiny subset of our writing on the fly. This is far less helpful than just deciding how to write and then writing it. —Michael Z. 2013-03-05 00:17 z

We don't actually need to include the gender period as part of the code. As far as I know, CSS supports a property that lets you insert extra content after an element, so we could use that. I don't see what purpose that long list of classes has either. We can probably do away with it and just have a single "gender" class. While we are at it, we might as well introduce combined names for gender and number, like "fp" or "md". That way, we can avoid the ambiguity that something like {{m|f|p}} has. Is it masculine singular and feminine plural? Masculine plural and feminine plural? Masculine singular, feminine singular and plural for all genders? This distinction is significant because Dutch and German, for example, have no gender in the plural, so for them "plural" is technically a fourth gender and contrasts with the three singular genders. —CodeCat 22:33, 4 March 2013 (UTC)

Re: first two sentences: Yes, that's what Mzajac (talk • contribs) was referring to in his point #2. —Ruakh_TALK 06:36, 5 March 2013 (UTC)

I do think we want a Lua function like CodeCat describes (that takes a sequence and returns an HTML string), but I think we probably also want some functions that can be applied directly to args tables, if we can find a good way to do that. (Unfortunately, our templates are not terribly consistent in the names of their gender arguments, but they're not totally arbitrary. We can probably cover the vast majority of affected templates with just two or three such helper functions.)
As for Mzajac's point . . . while I might well support some changes to the HTML that these templates output, I don't think that there's much benefit to making those changes simultaneously with the Lua migration. (Or, put another way — I think it's fine for CodeCat, or someone else, to migrate the current behavior, without waiting for the community to make decisions about changes to the behavior.)
—Ruakh_TALK 06:36, 5 March 2013 (UTC)

I don't know if operating directly on the args table is really that good an idea. Different languages have different genders after all, and presumably each language will want to check the gender parameter separately to see if it's valid. A general template can't do that, not without extra checking code that isn't really required. Furthermore, like you said, different templates have different parameters for the gender. Many templates have copied {{head}}'s approach of using a named g= parameter, but all the language-specific templates I've worked on use the first numbered parameter instead. {{t}} and its relatives use the third numbered parameter. And then there's the issue of specifying multiple genders, which may also differ. Some templates combine them so that you specify mf as the gender, others use separate m|g2=f parameters, and {{t}} uses the fourth numbered parameter to specify the second gender. We can, of course, decide that all templates should use the same set of parameters for the gender, but I doubt that is workable, and it will never work for {{t}}. So it is probably better to abstract away from specific parameters, and allow the function to take a table containing only the genders. —CodeCat 14:39, 5 March 2013 (UTC)

ABBR elements: I have executed my suggestion no. 1, putting a span or abbr element with the appropriate class into each template (some were missing classes). The italic style is controlled in MediaWiki:Common.css, under/* Gender and number templates */. The Vector skin gives abbr elements a cursor: help, which I have not overridden.

The relevant classes are .gender, .number, and .noun-class. I agree that all of the more-specific ones can be removed, unless someone points out a use for them.

.gender-period: I have done a tiny amount of testing, and the period code can be completely replaced with the following code in your Special:MyPage/common.css:

/* add a period after abbreviated genders and numbers */
abbr.gender:after, abbr.number:after { content: '.'; }

I will post this to the BP, and remove the extraneous code. —Michael Z. 2013-03-05 22:30 z

Why do gender and number have distinct classes? Is there a use case where anyone would want them to look differently? —CodeCat 22:47, 5 March 2013 (UTC)

As far as I’m concerned, these are all just inflection labels, in terms of our writing and typography (of course they are distinct grammatical categories). {{inv}} indicates an absence of both gender and number inflections, rather than being either one or the other, right? —Michael Z. 2013-03-05 22:56 z

Invariant or invariable means that a word doesn't inflect, but that really belongs in its inflection information and not in the gender. The purpose of gender and number templates is to show agreement class, which invariable words can certainly have. A masculine noun that does not inflect, in a language where nouns normally do inflect, is still masculine, and so any adjectives that are used with it take masculine agreement. —CodeCat 23:07, 5 March 2013 (UTC)

I think I get it. But any or all of number, gender, and inv labels could appear in a headword line to indicate the grammatical features of a term, yes? But I guess inv would not appear in a mention using {{term}}, where number and gender templates indicate which inflection is mentioned. —Michael Z. 2013-03-06 01:05 z

Yes, the {{inv}} label is more like "1st declension" or "3rd conjugation". We don't normally put inflection labels right after the headword, usually they go in the parentheses that follow it, or in the inflection section. —CodeCat 01:09, 6 March 2013 (UTC)

I've created Module:gender and number, which contains two functions that allow you to format gender specifications in a consistent way. A gender specification is a string containing hyphen-separated list of gender specification codes, such as "f" for feminine, "n-d" for neuter dual, "m-an-p" for masculine animate plural. There is also a function that accepts a list of such strings, and concatenates them with "and" currently (that could probably be improved). The reason I made the gender specifications that way is so that there is a single and unambiguous way for specifying a combination, which is useful when creating, for example, a list of possible genders a language could have ({"m", "f", "n", "p"} for Dutch and German, {"m", "f", "n", "m-p", "f-p", "n-p"} for Latin, and {"m-an", "m-in", "f", "n", "m-d", "f-d", "n-d", "m-p", "f-p", "n-p"} for Slovene). This, in turn, could be built into templates like {{t}} and {{head}} in the future, so that they automatically check the provided gender to see if it's valid for the given language. However, this is different from how we currently use these codes, so any old uses will have to be updated first. —CodeCat 02:43, 6 March 2013 (UTC)

That looks good. You can use single quotation marks in the HTML, to obviate the slashes for readability of the code. Shouldn’t the opposite of anim be inanim? Can you add some documentation in comments or elsewhere, so one can understand the module without help? —Michael Z. 2013-03-06 15:46 z

I've converted {{nl-noun}} to use this module, and it looks like it works nicely. —CodeCat 20:45, 6 March 2013 (UTC)

Awesome. —Michael Z. 2013-03-06 21:10 z

Am I correct that this is one module that specifies the form and HTML of gender labels, usable in any template or module, potentially for any language? So once adopted, we can change a thing like <abbr class="gender"..> in only one place for all of Wiktionary? That is a breakthrough. —Michael Z. 2013-03-06 21:26 z

Yes... but that is not really a breakthrough because that was already possible with {{m}} and such. All I did was create a Lua equivalent of those templates, and added something extra while I was at it so that they could be used more easily. —CodeCat 21:47, 6 March 2013 (UTC)

So, should one start introducing this module to other modules? --Njardarlogar (talk) 19:37, 7 March 2013 (UTC)

Yes, but be careful. This module isn't quite compatible with the old templates (for the reason I mentioned above), so you should be sure to check first to see if any entries need to be changed. The main thing to watch out for is when "s" or "p" are used alongside a gender code: "m|p" should be changed into "m-p" and so on. —CodeCat 20:14, 7 March 2013 (UTC)

Is there any better way than this to request modules for those who don't know Lua? I was thinking of Module:fr-noun to supersede the current Template:fr-noun. Mglovesfun (talk) 16:50, 26 February 2013 (UTC)

• This seems to be the place for "technical requests". Do you want all the French noun templates to be converted (that would be sensible). Do you want all those stupid noun categories retained (I would ditch them)? SemperBlotto (talk) 18:08, 26 February 2013 (UTC)

I think the idea is that {{fr-noun-unc}} and {{fr-noun-inv}} would be rendered obsolete by a new scribunto version of fr-noun. The additional categories are I suppose valid until they fail WT:RFDO and should therefore be retained. Mglovesfun (talk) 18:42, 26 February 2013 (UTC)

I can help with that if you like, Semper. Jamesjiao → ^{T ◊ C} 20:47, 2 March 2013 (UTC)

I noticed today, having visited Talk:Main Page as an anon user, that the "anonymous feedback" links in the left margin ("definition is too complicated", etc.) are shown on that talk page, when they are obviously not relevant in that context (not all of them, anyway — in fact, on that page I'd say only "Could not find the word I want" and "If you have time, leave us a note" are relevant). The links even appear on "Special:" pages. Is there a way of customizing which feedback links are shown are what kinds of pages? - dcljr (talk) 01:28, 27 February 2013 (UTC)

Wiktionary "English main page" has in the last week or so (as of Feb 27 2013) started frequently crashing my browser!

http://en.wiktionary.orghttps://dictious.com/en/Wiktionary:Main_Page

Mac OSX 10.7.5, Safari 6.0.2.

It does not happen with JavaScript disabled. It may be a JavaScript bug itself, or secondarily from something that JavaScript is configuring (CSS layout), or downloading (see Firefox font download error below).

In some quick testing, I haven't gotten the crashing on the main Wiktionary.org page, nor on the French main page, nor on interior English definition pages.

Mac Firefox 16.0.2 does not crash on the English main page, but does show this error in the error console regarding a downloaded font:

Timestamp: 2/27/13 3:32:45 PM Error: downloadable font: table 'GSUB': OpenType layout data discarded (font-family: "Padauk" style:normal weight:normal stretch:normal src index:1) source: http://bits.wikimedia.org/static-1.21wmf10/extensions/WebFonts/fonts/Mymr/Padauk-Regular.woff?version=2.8&20111213 Source Code: @font-face { font-family: "Padauk"; font-style: normal; src: local("Padauk"), url("//bits.wikimedia.org/static-1.21wmf10/extensions/WebFonts/fonts/Mymr/Padauk-Regular.woff?version=2.8&20111213") format("woff"), url("//bits.wikimedia.org/static-1.21wmf10/extensions/WebFonts/fonts/Mymr/Padauk-Regular.ttf?version=2.8&20111213") format("truetype"); }

Does the Meta-Wiki main page also cause your browser to crash? --Yair rand (talk) 20:41, 27 February 2013 (UTC)

Thanks for the quick response. Not in the 5 tests I just did.

Note with the English main page that you should clear your browser before testing, as once it has loaded one time successfully, it may then not crash on future visits (with cached resources).

Also in recent versions of Mac Safari the "Reset Safari" command may not be clearing the cache properly. Manually delete the file ~/Library/Caches/com.apple.Safari/Cache.db to be sure, then restart Safari.

The Main Page:

• 1.65 MB of fonts, although my computer renders all the text on that page without any of these loaded.
• 180 kB of JavaScript
• 69 kB of HTML
• 27 kB of CSS

Remind me not to use this website on mobile. —Michael Z. 2013-02-27 21:18 z

They run like this on every WebFonts-using wiki, which is probably going to be all of them soon. On the main page, they're loaded specifically for the interwikis. The mobile site doesn't load fonts yet. --Yair rand (talk) 21:35, 27 February 2013 (UTC)

Mobile Main Page:

• 15 kB of HTML
• 272 kB of JavaScript
• 43 kB of CSS

Weird. Nice light page, with significantly more JS and CSS than the main page.

Only two of the languages on the mobile home page are lacking fonts on my mobile. I hope we don’t start adding large font files to it.

I generally don’t use mobile sites on my mobile. Wiktionary’s “mobile” link is almost invisible, and the mobile home page inexplicably lacks the basic content of our real home page. How can we tell how many mobile visitors actually use it? —Michael Z. 2013-02-27 22:34 z

OK so is someone looking into this and do you have Mac Safari to test? If you examine the error message above you'll see that the particular downloaded font ("Padauk") being used has defective OpenType layout data . There might also be some JS code being used that breaks in Safari. Note that my computer has tons of RAM and Safari normally doesn't crash just because of a lot of JS or with downloaded fonts -- there's sometime specifically defective about this page. Please respond whether you need me to check back on this discussion to do follow-up testing of your bug fix.

— This unsigned comment was added by 98.180.15.239 (talk).

I have the same Mac OS 10.75 and Safari 6.02, and the main page is not crashing me, neither with cache emptied nor on subsequent loads and reloads (I don’t have that much ram and lots of tabs are open). The web inspector shows .woff fonts downloaded for the page, but not .ttf. It doesn’t indicate any errors. —Michael Z. 2013-03-02 20:43 z

I downloaded the .ttf file mentioned in the error message. Font Book’s validation reports no problems. —Michael Z. 2013-03-02 20:47 z

Thanks Michael. Maybe the font's coding itself is not the issue. The crashing is still happening for me, intermittently but fairly often. With intermittent and hard-to-reproduce bugs like this, a good possibility is JS dependency issues with downloaded assets. That is, a script is running assuming some other script or asset has already been downloaded fully, but the downloading varies with real-world server/connection timing.

Try these steps with OSX Lion 10.7.5 / Safari 6.0.2.

1. Manually delete the file ~/Library/Caches/com.apple.Safari/Cache.db (that is in your user Library, hidden in Lion, ask if you're not sure how to get to it).

2. Run Reset Safari... with all options checked.

3. Close Safari

4. Open Safari and go to bbc.com and browse around for a while. Open a new tab and go to http://en.wiktionary.orghttps://dictious.com/en/Wiktionary:Main_Page

5. Repeat all steps 10 times, see if you get the crash.

Is there a sandbox/staging area where you can post the page with various assets not linked (starting with the downloaded fonts)? Or maybe just comment out the downloaded fonts on the live page, as I don't think they're being used there currently. I will check back in a few days from 8 Mar 2013. Thanks.

Original commenter here 16 March 2013. I'm out of time to follow up on the issue. It is still happening for me intermittently but consistently -- and probably for other Mac Safari users. Thanks to anyone who is able to troubleshoot it from the info above. If you just remove whatever is technologically different about the crashing English Main Page vs the non-crashing French Main Page that, one would think, would do the trick.

I can't reproduce your problem at all. —Μετάknowledge^{discuss/deeds} 15:53, 16 March 2013 (UTC)

I will gladly go through the suggested debugging procedure, when I have the time to create a dummy user account. I am not about to reset my main browser in my main user account. —Michael Z. 2013-03-16 17:06 z

Out of curiosity I had a browse of the Scribunto modules. Now I’m worried by:

• Large HTML templates hard-coded in Lua
• Presentational attributes that are gone from HTML5 (align, bgcolor, color, cellpadding, etc.), instead of CSS styles
• Inline style attributes, instead of styles in the central style sheet MediaWiki:Common.css
• Font sizes specified in points!
• HTML elements that were deprecated in HTML 4 and gone from HTML5, like tt and font!

Are we using Scribunto for better efficiency? It looks like an efficient way to mass-produce bad, redundant HTML while ignoring our style sheet. Also an efficient way to lock and hide templates away from non-programmers.

Can we do our templating with templates, and use scripting for logic and data processing? Can we set some basic standards for HTML and CSS? Maybe we need a few checkpoints and an auditing process for scripts. —Michael Z. 2013-02-27 20:43 z

Are you willing to draft something up? I, for one, wasn't even aware that we had a central style sheet. Jamesjiao → ^{T ◊ C} 22:42, 27 February 2013 (UTC)

I don’t know anything about Lua modules, but I would hope that a template could still be a template, and calls to scripts could fill in the blanks. If that is slow, then perhaps a single module call can update the values of the script arguments, to be returned by the template. If HTML must be embedded in Lua code, then it should be kept separate from the logic, for easy editing. Placeholders in the HTML, or even separate include files might be helpful. Is there a templating framework for Lua?

I will write up some suggestions regarding HTML and CSS. Maybe consolidating 150 templates into 30 modules is an opportunity to tame some of our wild code. —Michael Z. 2013-02-28 02:18 z

I've always supported separating the templates that display inflection tables from those that generate the forms. I have followed this principle when making Module:nl-verb as well. —CodeCat 02:21, 28 February 2013 (UTC)

Can you show where this module is used? —Michael Z. 2013-02-28 03:05 z

Does "what links here" not work? —CodeCat 04:03, 28 February 2013 (UTC)

Yes – I must have only tried that on a couple of modules with no links. —Michael Z. 2013-02-28 04:33 z

I like the way you have placed the HTML at the end of the function, so it is fairly easy to edit. I have a few suggestions on the HTML and CSS for this, which I have mocked up in this web page. View source. The function could deliver just generic table structure with one or two classes. No more presentational markup repeated in every line. The CSS could all be in MediaWiki:Common.css, hooked in by the classes. If we can agree on a single set of styles, then we could update the appearance of all inflection tables by changing a few lines of CSS, once.

We could do even better if wikitext allowed col, colgroup, tbody, thead, and tfoot elements. Vote for bug 986 and bug 4740. —Michael Z. 2013-02-28 06:57 z

I would certainly agree with having a common style for all inflection tables, as long as it's not dull and grey. But before you do that, you may want to look at the rather wide variety of tables we currently have. See {{ca-conj-table}}, {{gem-conj-table}} (which was grey and not broken until an IP changed it), {{sl-conj-table}}, {{sl-decl-adj-table}}. —CodeCat 15:00, 28 February 2013 (UTC)

I believe that a table design less interesting than its contents would best serve the readers, if not the editors (e.g., ковбаса#Declension). Anyway, if we can agree on a common style, then the sky would be the limit as far as customization goes, along with standardization and ongoing, across-the-board improvement. What’s the best place to gather a wide variety of table designs on one page to evaluate? —Michael Z. 2013-02-28 15:18 z

Re: "Can we do our templating with templates  ?": That's a clever turn of phrase, but templates aren't a great language for templating, either. All else being equal, I think it's better for wikitext to be in templates than in Lua modules, but that's not always realistic. —Ruakh_wTALK 05:22, 28 February 2013 (UTC)

Understood. —Michael Z. 2013-02-28 14:33 z

I don't know anything at all about "our CSS". Where is it documented? If the original poster wants to show us exactly what he means in concrete terms, could I suggest that he creates a Module:fr-conj that all the French conjugation templates could use. SemperBlotto (talk) 08:09, 28 February 2013 (UTC)

It is self-documented in MediaWiki:Common.css, to the extent that it is. You are correct that I should give that some attention.

I won’t be able to build that module, but I’m glad to help your code have the best possible HTML and CSS. —Michael Z. 2013-02-28 14:33 z

In that case, if I decide to have a go at fr-conj, I will do what I did for it-conj - i.e. keep the conjugation table structure identical to the old template format. SemperBlotto (talk) 15:36, 28 February 2013 (UTC)

• I'm not sure to what extent folks are thinking about standardizing "the appearance of all inflection tables", but that comment does lead me to chime in and note that each language uses a different format, partly due to linguistic differences and partly due to different aesthetics. And actually, I quite appreciate that each language's tables have different colors and layouts -- I find it helpful actually when looking at a large page like ], as the color-coding helps me stay mindful as to what particular language I'm looking at. Just another 2p.  :) -- Eiríkr Útlendi │ Tala við mig 15:30, 28 February 2013 (UTC)

• Indeed. And I put a lot of effort into coloring {{he-conj}} in a way that (I hope) makes its structure readily apparent. I'd hate to see that sacrificed on the altar of uniformity, even if the uniformity has benefits as well. —Ruakh_TALK 15:46, 28 February 2013 (UTC)

All of this increases incidental uptake load on the reader, to a degree that is self-defeating. The “different aesthetics” aren’t – they are fundamentally different schemes, some of which represent heading–subheading–content structure, others assigning colour to different grammatical categories, and I don’t see a single legend to explain any of it. We have potentially hundreds (thousands?) of languages, and tables that vary so widely in appearance that it’s work for the reader just to figure out whether these are all inflection tables.

Apparently blue means “person subheading or indicative heading,” plum means “table-level heading or personal infinitive heading,” and beige means “non-person heading and person heading or imperative heading or inflection main heading.” Pink means “some words but not others.” That neither helps identify a language nor makes structure readily apparent; it only makes the reader try her best to ignore it. But it could do those things with a bit of coordination.

Ruakh, if you’ve worked hard on your design, wouldn’t you want to see it applied widely enough that readers could take advantage of its qualities? Wouldn’t you want to see it refined by the community? Wouldn’t you like to have a standard set of classes so that reusing it needn’t be a herculean task of craftsmanship?

If an open set of colours each represents one of an open set of qualities, then colour mean nothing. As lexicographers, can we not appreciate that convention, not chaos, creates meaning? —Michael Z. 2013-02-28 16:41 z

I don't think the colours themselves mean anything. Rather, it's the fields that have the same colour that are meant to be logically grouped together. Humans are good at visual tasks generally, so using a visual means of grouping and distinguishing is very helpful. It's one of the reasons why I think French Wiktionary looks better than English. They make far better use of styling and pictographic information than we do, making the page look more visually appealing and easier for the eye to parse. I would definitely support following their lead. —CodeCat 16:46, 28 February 2013 (UTC)

If the colours have no meaning, then a monochrome palette might make it look so. But three different greens are associated with subjunctive headings on poder, so it is clear that green indicates subjunctives, which is fine. I see this consistently in several tables on the page, but then infinitives are purple or beige and I wonder what that means. But then pink is tagging words, not grouping headings – it must mean something else. . . . So after pondering poder, all of these colours are now distracting decoration, with tantalizingly opaque meaning. Better if it was all greys. —Michael Z. 2013-02-28 17:02 z

I’ve started a survey of inflection tables at Wiktionary talk:Inflection-table templates#Standardizing inflection tables. Please add more tables with diverse styles and features. —Michael Z. 2013-02-28 18:06 z

• I think a survey is definitely in order. However, I think the first step would be to simply locate *all* inflection tables that you want to include in this effort, and list them all somewhere on a single page. And simply having ====Conjugation / Inflection / what have you heading==== and then the table would probably suffice -- including a bulleted list that describes everything that we can see simply by looking seems like a waste of time, effort, and page space.  :)

One important thing to note is that languages have very different features. Your comments above here seem to suggest that subjunctive should always be green, and by extension, it would seem to follow that any language that doesn't have a subjunctive mood shouldn't have green in the table. I think that's flawed reasoning.

Instead, it appears that the conjugation templates either 1) were created out of whole cloth, such as Navajo's {{nv-verbtable}}, (as at neiłtsoos) or Japanese's {{ja-go-ru}} (作る), or 2) were created based on a similar table already in use for some other language, such as the Catalan, Galician, and Spanish conjugation templates at ], which probably share their design lineage with Latin as well. Portuguese might be part of this too, but the layout and colors are different enough that I wonder.

German, meanwhile, uses green not for the subjunctive, but rather for the perfect and pluperfect composed verb forms (c.f. gehen), whereas Dutch doesn't use green at all (c.f. gaan). Nor does Swedish (dansa), Romanian (dansa), or Finnish (tanssia).

Then again, Hungarian uses green as the background for its entire conjugation table (táncol).

• I could perhaps get behind an argument that each language *family* should have unified, or at least very similar, conjugation tables. But I *really* don't think it makes sense to try to unify conjugation table styles for all languages, regardless of family or features.
• I would also support the inclusion as needed in each conjugation table template, of some kind of clearly labeled legend, possibly collapsible, or at least a clearly labeled link to a legend, that would explain what the colors are used for. Most of the conjugation tables at ] are relatively clear and don't really need any explanation, but that irregular use of pink in the Catalan conjugation table is confusing without any indication of what it's supposed to signify.
• I would also wholeheartedly oppose any move to make inflection tables monochrome. Color is both a useful tool for distinguishing and grouping, and an attractive accent on a page. Single-color, single-shade tables such as the Finnish one at tanssia are frankly hard to look at, and all-gray tables such as the Japanese one at 作る are both hard to look at and mildly depressing. The all-green Hungarian table at táncol at least uses different gradations, which helps improve visual clarity and reduce mental fatigue, but multi-color tables like at possum are even easier to visually parse.

Michael, you commented that "all of this increases incidental uptake load on the reader, to a degree that is self-defeating", and that "if an open set of colours each represents one of an open set of qualities, then colour mean nothing". The meaning of colors in (most of) the conjugation tables is, like terms in language itself, clear from the context. Most of the color use I've seen so far is primarily for visual grouping, with the labels in the table supplying the meaning. Which color means which group depends on the language and the table. So long as each language uses colors consistently within its own tables, I really do not have any problem with different languages using colors differently. Even more so, I actually prefer it when different language families use color differently, as we currently have things, as this makes it easier to tell immediately that I'm looking at something different. -- Eiríkr Útlendi │ Tala við mig 19:14, 28 February 2013 (UTC)

Thanks for the thoughtful reply.

By all means, add simple links to the survey page, and I encourage you to add comments when appropriate. No need for detailed lists, but the ones I created should give some idea of the range of diverse design elements we are putting in these, with some configurations superior to others.

I’m not suggesting that green should or shouldn’t be used for anything at this time. It’s just part of a false pattern in the few tables I’ve looked at. Organizing the design and production of these templates should either establish patterns or eliminate anti-patterns.

A table is an arrangement of information – only add what supports that. If the intent is to group rows or columns, then use two contrasting tones or colours, like alternating green plus yellow, not six. Multiple colours imply multiple meanings: green, yellow, pink, and beige become a map that wants a legend, even when it isn’t representing anything. Let’s make tables of information that stand alone, omitting non-content devices like legends. The tables you point out are visually oppressive because the overuse of colour or tone has reduced text contrast, and emphasizes the table’s form over the information in it. Obviously many tables need a more complex treatment, but look how clear and bright a table can be when 99% of the designy crap is absent: ковбаса#Declension.

I am opposed to introducing anything for the sole purpose of being “an attractive accent.”

If we want to use colour or another design element to help orient the reader on a long page, then let’s incorporate that into the page design. Sure, inflection tables could be unified with such a scheme, but they don’t contribute to it on their own, because many long pages don’t have them, and even then they don’t show the colour in their default collapsed state. If languages need visual differentiators, then let’s start by making a language-family map and incorporating those colours into language pages and headings, not by picking them randomly and hiding them in collapsed declension tables. That is trying to find a problem for an unneeded solution. —Michael Z. 2013-02-28 20:28 z

Pardon my saying so, but I actually don't think ковбаса#Declension is "clear and bright". The whole table is organized into three columns — "case", "singular", and "plural" — that are wildly heterogeneous. (Why is the upper-left corner marked "case" rather than "number"?) The names of the cases are a different color (yes, gray is a color), which made me think they were links, until I hovered and found that they weren't. And I find that the table is insufficiently set off from the text above it; if it's not going to have a border, then I think it should be centered or indented or heavily padded or something. (These are all minor points, of course. If my goal were to learn the declension of that word, or to find a specific form, I'm sure I'd find the table to be adequate. But the same is true of the tables you're complaining about, so if the goal of your complaints is to push more templates in the direction of ковбаса#Declension, then I don't think we'll ever see eye-to-eye on that. Besides, let's face it, Ukrainian declension templates are an easy case. It would take some effort to create a Ukrainian declension template that's not adequate. The same is not true of, say, a Portuguese conjugation template. If you managed a "clear and bright" version of the latter, and if it were still adequate, then we'd actually have something to discuss.) —Ruakh_TALK 04:31, 1 March 2013 (UTC)

The “case” header is above the column of cases. —Michael Z. 2013-03-01 05:44 z

. . . which is what I said. I guess you didn't understand my comment. Rather than try to re-explain, I've decided instead to "show, don't tell": see ковбаса?oldid=19648391#Ukrainian. —Ruakh_TALK 06:36, 1 March 2013 (UTC)

I see your point. But in terms of the copy, for a reader who’s not too familiar with the nomenclature, that layout makes it look like “number” is a peer of “nominative” and “genitive” (which, I guess, is a ninety-degree twist on the problem with my version). I think “number” should just be dropped, because sing. and pl. are self-explanatory. Perhaps the case names should be links or have tooltips for the unfamiliar.

In terms of the design, I had horizontal rules to help identify the table as a block in the entry. The vertical rules I consider unnecessary, as the left-aligned text already provides strong vertical lines, and the whitespace on the right identifies the right boundary of the table. Here’s a quick sketch of another version: . — This unsigned comment was added by Mzajac (talk • contribs) at 15:49, 1 March 2013 (UTC).

@Michael: Please don't take this too harshly, but when you said "That is trying to find a problem for an unneeded solution" I immediately thought that your statement best described your interest in micromanaging templates. I don't mind most schemes; a few (I'm looking at you, Upper Sorbian and Basque!) are too amateurish to my eye, and Armenian sometimes looks a bit dull, but I don't really care in the end. That said, with its redlinks, layout, and lack of border, the Ukrainian template seems to me to be one of the most aesthetically displeasing inflection-templates we have, at least to my eyes. But if the community voices a strong interest one way or the other... —Μετάknowledge^{discuss/deeds} 05:01, 1 March 2013 (UTC)

I think a list of inflections needs a multicoloured background about as much as a book of poetry does, or a chessboard. But, whatever.

The point here is to pick our favourite table style, or our 10 favourites, so we can get working on some code. I hope that one simple, stable HTML can make use of several sets of styles in the style sheet to render whatever styles we want. It will be much easier to refine or swap the styles Wiktionary-wide. —Michael Z. 2013-03-01 15:48 z

I disagree. Looking at your Ukrainian example, I see an undifferentiated stack of text that makes it hard to tell the row and column headers from the categories. Color is useful for leading the eye and making groupings apparent. It can be garish or ugly if misused, but it's generally very helpful. Standardizing involves a lot of discussion/argument/haggling/compromise that doesn't seem to me to be worth the trouble. Chuck Entz (talk) 18:24, 1 March 2013 (UTC)

Ahem; allow me to elucidate:

For this discussion, I don’t care about the colours. Let’s pick our favourite table styles. I’ll standardize the HTML code, so the smallest set of templates can produce their structure. I’ll make a style sheet that will render the standardized HTML in your favourite style, garish though it may be.

Everyone’s all hot on Lua, but we have totally under-utilized the powerful and ubiquitous CSS technology. We hand-edit 100,000 lines of HTML attributes into 1,000 templates, when with a little planning the changes can be made in a dozen lines of a single style sheet. If we’re rewriting templates in scripts, this is a great time to make the code efficient. —Michael Z. 2013-03-01 19:20 z

I agree with the comments by Metaknowledge and Chuck Entz. - -sche (discuss) 00:11, 5 March 2013 (UTC)

How do I get any votes for my vote? Who do I bribe? --Njardarlogar (talk) 16:32, 28 February 2013 (UTC)

BribesConsulting fees for all can be forwarded to me for further distribution. Please send me your e-mail address so I can send bank-wire instructions. DCDuring TALK 21:17, 8 March 2013 (UTC)

Are the bribes only for support votes, or for any vote at all? —Angr 23:16, 8 March 2013 (UTC)

More $$$ for support votes than opposing votes. Now I need someone to close it. --Njardarlogar (talk) 09:58, 9 March 2013 (UTC)