Wealth Maker: Wiktionary - Recent changes [en]: Wiktionary:Grease pit/2013/February

Wiktionary - Recent changes [en]

Track the most recent changes to the wiki in this feed. // via fulltextrssfeed.com

Wiktionary:Grease pit/2013/February

Feb 27th 2013, 20:34

Revision as of 11:11, 27 February 2013 (edit) Mglovesfun (Talk \| contribs)		Latest revision as of 20:34, 27 February 2013 (edit) (undo) Jamesjiao (Talk \| contribs)
Line 725:		Line 725:

	:: 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 <tt>frame:getParent().args</tt> or one that requires <tt>frame.args</tt>. (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?) —[[User: Ruakh \|Ruakh]]<sub ><small ><i >[[User talk: Ruakh \|TALK]]</i ></small ></sub > 07:32, 26 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 <tt>frame:getParent().args</tt> or one that requires <tt>frame.args</tt>. (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?) —[[User: Ruakh \|Ruakh]]<sub ><small ><i >[[User talk: Ruakh \|TALK]]</i ></small ></sub > 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: [http://en.wiktionary.org/w/index.php?title=Module:zh-hanzi-box&oldid=19615621 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. [[User:Jamesjiao\|Jamesjiao]] → <sup><small>[[User talk:Jamesjiao\|T]] ◊ [[Special:Contributions/Jamesjiao\|C]]</small></sup> 20:34, 27 February 2013 (UTC)

	== Meta templates ==		== Meta templates ==

Latest revision as of 20:34, 27 February 2013

[edit] Font oddities in JA entries

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:

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

{{#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? —CodeCa t 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 [lang=ja]. 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[lang="ja"], .Latn[lang="ko"], .Latn[lang="zh"] {      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:

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[lang=ja],  .Latn[lang=ko],  .Latn[lang=zh] { 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[lang=(anything?)] so that it doesn't need to be overridden separately for every single language? —CodeCa t 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". —CodeCa t 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. —CodeCa t 15:54, 2 February 2013 (UTC)

But [lang=something] 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 [lang|="en"] 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 */     [lang|="ja"], /* 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. */     [lang|="ja-Latn"], /* 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 [lang="ja"]. —CodeCa t 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,[1] so testing is required. But because, apparently, :lang() is more specific than [lang], we might get more consistent results using the former, and adding the latter as another level of fallback for IE7. By the way, [lang|="ja"] 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 }.)^[2] —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".^[3] —Ruakh_TALK 09:13, 9 February 2013 (UTC)

[edit] Japanese headword-line templates

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}}: Grease pit/2013/February (い-i declension, hiragana いたい, romaji itai);

{{ja-counter}}: Grease pit/2013/February (じかん, jikan);

{{ja-diacritical mark|}}: Grease pit/2013/February;

{{ja-kanji}}: Grease pit/2013/February (grade 3 "Kyōiku" kanji);

~~{{ja-kanji reading}}~~ [to be deleted]: Grease pit/2013/February (romaji jō);

{{ja-noun|r}}: Grease pit/2013/February (hiragana ぜん);

{{ja-phrase|kk}}: Grease pit/2013/February(hiragana よいおとしをおむかえください, romaji yoi otoshi o omukae kudasai);

{{ja-pos|r|prefix}}: Grease pit/2013/February (hiragana ぜん);

{{ja-punctuation mark}}: Grease pit/2013/February;

{{ja-verb|h}}: Grease pit/2013/February (godan conjugation, romaji inu);

{{ja-verb form|h}}: Grease pit/2013/February (romaji mita);

{{ja-verb-suru|k}}: Grease pit/2013/February + する (irregular conjugation, hiragana あんしんする, romaji anshin suru)Grease pit/2013/Februaryする Grease pit/2013/February suru;

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! —CodeCa t 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. —CodeCa t 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."[4] 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? —CodeCa t 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. —CodeCa t 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. —CodeCa t 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:

Editors should get used to using language codes, including lang=en
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). —CodeCa t 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}}. —CodeCa t 21:33, 9 February 2013 (UTC)

[edit] lang and xml:lang attributes in templates

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."[5] 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. —CodeCa t 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

[edit] Can't save large page

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.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 [No Error] 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|?—CodeCa t 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. —An gr 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? —CodeCa t 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. —CodeCa t 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}}. —An gr 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? —CodeCa t 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. —An gr 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! —CodeCa t 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. —An gr 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)

[edit] German adjectives with multiple comparatives and superlatives

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? —CodeCa t 21:28, 6 February 2013 (UTC)

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

[edit] Edittools and FF on Win 7

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?

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) 20:02, 18 February 2013‎ (UTC).

I've added a nolabel argument to {{X-SAMPA}}. nolabel=[anything] 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

[edit] Edit Filter for HTML links?

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)

[edit] Import new ISO codes

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)

[edit] Bug on 𨳒, hopefully just me

𨳒

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)

[edit] HTML for headwords

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:

What code is in the inflection lines?: It looks like most of them have a  or  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  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. —CodeCa t 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.[6]

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. —CodeCa t 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!). —CodeCa t 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? —CodeCa t 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}}. —CodeCa t 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. —CodeCa t 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: ? 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. —An gr 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... —CodeCa t 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 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). —CodeCa t 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 is a better option than . —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:

dl (description list) incorporated into our page markup. This would be a bigger project.
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 – headword

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

^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))

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 [[prisoner]] is all sneaky, linking to [[gefangen]] rather than to [[Gefangener]], 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)

[edit] Labs project

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)

[edit] Scribunto extension roll out planned for February 18

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! —CodeCa t 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 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}}). —CodeCa t 15:45, 15 February 2013 (UTC)

[edit] Converting our template infrastructure to Scribunto

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? —CodeCa t 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. —CodeCa t 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. —CodeCa t 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, [[7]]

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. —CodeCa t 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... —CodeCa t 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... —CodeCa t 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. —CodeCa t 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) 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. —CodeCa t 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. —CodeCa t 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 [8]: "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 CodeCa t 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. —CodeCa t 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. —CodeCa t 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. —CodeCa t 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. —CodeCa t 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)

[edit] An idea/proposal for future Lua-fied templates

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. —CodeCa t 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. —CodeCa t 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? —CodeCa t 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)

[edit] mass-adding Spanish entries

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)

[edit] Languages with multiple names

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 [[: Category:Albanian Sign Language language]], 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}}. —CodeCa t 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)

[edit] Replace Template:unicode with a single font declaration for MSIE 6

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

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?
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[9] 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.[10] —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

[edit] Scribunto (Lua) has been installed

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! —CodeCa t 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. —CodeCa t 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. —CodeCa t 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? —An gr 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)

[edit] Categorising modules?

Can this be done? —CodeCa t 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. [11] --Njardarlogar (talk) 23:25, 19 February 2013 (UTC)

That is better than nothing then. I suppose we should just categorise the talk pages instead. —CodeCa t 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. —An gr 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? —CodeCa t 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? —CodeCa t 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". —An gr 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. —CodeCa t 15:32, 20 February 2013 (UTC)

[edit] Allowing templates to be previewed without script errors

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? —CodeCa t 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)

[edit] Meta templates

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:

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

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")? —CodeCa t 18:29, 23 February 2013 (UTC)

[edit] Module requests

Is there any better way than this to request modules for those who don't know Lua? I was thinking of {{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 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)

You are receiving this email because you subscribed to this feed at blogtrottr.com.

If you no longer wish to receive these emails, you can unsubscribe from this feed, or manage all your subscriptions

Wealth Maker

Wednesday, February 27, 2013

Wiktionary - Recent changes [en]: Wiktionary:Grease pit/2013/February