Jump to content

Template talk:Lang/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3→Archive 5

lang-ru, lang-ar, ...

There are two templates right now that have similar functionality, lang-ru and lang-ar. (There may be others; these are the only two I know of). In addition to adding the span tag, these templates also prefix the encompassed text with the name of the language and a link to the relevant Wiki article.

I was thinking these two templates could be rewritten in terms a simpler "lang" template, in the form: 

[[{{{2}}} language|{{{2}}}]]: <span lang="{{{1}}}" xml:lang="{{{1}}}">{{{3}}}</span>

This would be used like: 

{{lang|ar|Arabic|لرررررل}}

And produce something like: 

Arabic: لرررررل

But then I found that this similar lang template already exists. Since this template doesn't seem to be used in too many places, would any of its authors mind if I rewrote it to work like the above? Or perhaps this template could be left as-is and a "langWithName" template could be created for the above. What do people think? 

 — J’raxis (T) 18:22:26, 2005-08-03 (UTC)
There's also lang-uk. —Michael Z. 2005-08-3 21:55 Z

In Russian wikipedia, there are a lot of these lang-xx templates (see ru:Википедия:Шаблоны:Языки). They are really handy in that form. As for the current lang template, it should be left as it is — very often foreign words or phrases are inserted many times in the same article, and it would be annoying if they are every time accompanied by (e.g.) German: .... German: .... German: .... — Monedula 05:56, 4 August 2005 (UTC)

Yep, there's a use for both of these types of templates. I'm going to make a new {{langWithName}} template and rewrite the three lang-xx ones in terms of it.
— J’raxis (T) 20:09:47, 2005-08-04 (UTC)

span lang vs. font lang

Can anybody explain or illustrate the difference? Wikipeditor 10:48, 10 January 2006 (UTC)

No real difference at all. But span is preferable, since it does not suggest that it is about fonts. Formerly, Wikipedia did not allow the use of span, so font was used instead. — Monedula 11:11, 10 January 2006 (UTC)
Thank you! I see either tag's main use in helping the browser to choose an appropriate font, as mentioned above. I gather from your reply that there aren't really any situations where font lang is more appropriate than span lang.—Wikipeditor
In fact, the font tag is deprecated in HTML 4.0 and absent in XHTML. — Monedula 06:39, 13 January 2006 (UTC)

What should be tagged?

Question: should we mark transliterations? (I think not) —Michael Z. 2005-01-27 10:17 Z

Why not? IMHO in the general case is more important to tag transliterations than "original" words (words written with a different script are obviously not in English). --surueña 10:38, 10 March 2006 (UTC)
Because it looks bad. Example:
A user chooses in their Firefox options to show "Western" (i.e. English and such languages) text in the font Gentium, Cyrillic text in the font Georgia, and Simplified Chinese text in the font SimSun or SimHei.
Now when this user sees a word in Cyrillic letters (e.g. Југославија), it will appear in Georgia characters if the template:lang is used, and as an irritating mix of Gentium characters (those whose shape also occurs in the Latin alphabet: Ј, о, с, а, ј) and Georgia characters (specifically Cyrillic characters: у, г, л, в, и) if it is not used.
When the same user sees a Hanyu Pinyin romanisation (e.g. Bái Máo Nǚ), it will be displayed in ugly SimSun or SimHei if the template is used to mark it as zh-CN, or in highly legible Gentium if not.
If it weren't for this problem, I agree that it wouldn't make much sense to treat romanised text in a foreign language as Western, e.g. to tag pinyin as English in an article in the Chinese Wikipedia.
Wikipeditor 18:39, 10 March 2006 (UTC)
Screenshot with Firefox 1.5 under Linux
I'm mainly interested in this template for accessibility reasons (using the lang attribute is an important point specified in the Web Content Accessibility Guidelines)[1] because text-to-speech browsers need to know the language of every (the pronunciation of an English word is very different from a French one, for example).
But you are right, if it's looks ugly nobody will use it. Once I tried to use Unicode numerals[2] instead of plain ASCII letters (yes, to allow screen readers pronounce "the second" instead of "/i i/"), but in my browser (Firefox 1.5) it was illegible in boldface:
Ferdinand II -> Ferdinand Ⅱ
Maybe a new template should be created for transliterations? --surueña 20:17, 10 March 2006 (UTC)
On a related note, do you think there is a way to use ISO 15924 to have Simplified or Traditional Chinese appear as such in Wikipedia articles, instead of using ISO 3166-1 alpha-2? It feels so wrong to use country codes sometimes.
Wikipeditor 18:39, 10 March 2006 (UTC)
I've never heard about that before, sorry. Maybe a new template like Template:Polytonic can be created for that. However, from the accessibility POV, it's not very useful to specify the script instead of the language. I mean, it's OK to create accessible templates like Template:Polytonic, because it "specifies the script" (through class="polytonic", i.e. useful to style sheets but this isn't a HTML standarized method to indicate the script) as well as the language. Please, don't create templates that only specify the writing system.
But you are OK, I don't think it's a good solution to tag Traditional Chinese with zh-tw. and Simplified Chinese with zh-cn. --surueña 20:17, 10 March 2006 (UTC)
Yes, it seems the W3C recommends the use of zh-Hant and zh-Hans language codes for Traditional and Simplified Chinese respectively, i.e. the ISO 3166-1 alpha-2 language tag followed by the ISO 15924 script tag, as you suggest.[3] I just modified some templates like Template:Chinese to follow this guidelines. It seems the language tags are richer than I expected, as there is a standard procedure to specify after the language the script, region, variant and even a private tag, see [4] --surueña 10:28, 21 September 2006 (UTC)

I've come to the conclusion that all text in another language should be marked as that language. The HTML lang attribute does not indicate character set or alphabet, merely language—how it's displayed is a browser issue. So I would use the template for, e.g., both Cyrillic and romanized versions of a name in Ukrainian: {{lang |uk|Україна, ''Ukrayina''}}, yielding: [Україна, Ukrayina] Error: {{Lang}}: text has italic markup (help).

Regarding Firefox's mixed-font display, I don't think this should happen if the name is entered correctly. Please note that no Unicode letters occur in both Cyrillic and Latin alphabets. Don't use Latin a in place of Cyrillic а! How does this appear in Firefox?

  • without template: Југославија
  • with lang|mk: Југославија

Won't Firefox just switch to a different font if necessary even when you don't specify it? Safari displays everything on this discussion page correctly in Lucida Grande, without any font shifts, and it doesn't even ask the user choose fonts for different scripts. Why not pick a broad Unicode font like Lucida Grande, Arial Unicode, or Gentium as your default font for everything? —Michael Z. 2006-03-10 23:02 Z

It seems to be a font issue. When I set Firefox to use a serif font and make Gentium the standard serif font for both Western and Cyrillic, the following happens:
  • Regular and bold text: у, г, л, в, и are displayed correctly (in the default font for Cyrillic where the template is used, in the default font for Western where it is not. In this case, Gentium is both.)
  • Italic and italic bold text: у, г, л, в, и are displayed in the default sans font for “other languages”. All other letters are displayed in Gentium.—Wikipeditor
Strange; Gentium does have an italic font: are you sure you have the italic version installed? And come to think of it, Gentium only has enough Cyrillic letters for Russian and Bulgarian, so it's just not a great choice for an international font if you're going to need other Cyrillic-alphabet languages. Sorry.
I think Arial Unicode has a pretty good range, although it displays a few characters incorrectly (see #Affricates and double articulation). —Michael Z. 2006-03-11 03:47 Z
Screenshot with Firefox 1.5 under Linux
This is how I see it in my machine. They are rendered with different fonts (see the J), maybe too big when the language tag is used. Both look OK to me, don't you think?
--surueña 11:50, 11 March 2006 (UTC)


I propose to use these language templates with every foreing word, i.e. words that currently should be put in italics in Wikipedia (except those commonly used in English, see Wikipedia:Manual of Style#Loan words) but also with foreing proper names (but I'm not completely sure). However, as Wikipeditor has said, they sometimes looks very bad, for example look the following test I made to Akira (film):

Screenshot with Firefox 1.5 under Linux
'''''{{lang|ja|Akira}}''''' ({{langx|ja|アキラ}}) is a ...

Note that the title not only looks ugly, it's not even in italics (and every title should be put in italics, see Wikipedia:Manual of Style (titles)). The Akira at the bottom is rendered right because it doesn't have any lang attribute.

It's very important for accessibility reasons that every foreing word is marked with the proper language, but if it looks like so bad nobody will use it. Maybe we can create another template for romanized words: 

<span lang="{{{1}}}" xml:lang="{{{1}}}" class="romanization">{{{2}}}</span>

and a new standard style for that class that uses the right font (a font with all diacritical marks, needed in words like rōmaji). Maybe a good name for this template could be Template:latn (for latinization), or Template:rom (for romanization). Transliteration is not a good name because it seems that can be used between any two writing systems, as we want to refer only with latinized words. But I'm not very good choosing template names!, please help me out with that :-) See also: Template:IPA, Template:Unicode, Template:polytonic, Template:Nihongo, Template:Zh-all, Template:Ruby, Template:Ivrit, Template:ArB, Template:ArTranslit --surueña 12:41, 11 March 2006 (UTC)

Proper names should not be tagged. That's overkill, and they are not in a foreign language.
A separate template for romanized text would just confuse things. There is no correct font for romanized words; different platforms have different sets of fonts, and choose how to display them differently. Everything on this page looks right in my Safari. You are just making a workaround for the selection of fonts and display settings of your Firefox (or whatever). This is a system and browser configuration problem, and it shouldn't be worked around by injecting custom HTML and styles into Wikipedia. —Michael Z. 2006-03-11 16:25 Z
"Proper names should not be tagged. That's overkill, and they are not in a foreign language."
I'm not sure about that. The pronunciation of a name depends on its language, but maybe in practice the best behavior is to pronounce it like an English speaker, and refer to the phonetic notation if you want the native pronunciation. Maybe an accessibility expert can help with this.
Of course there is not a specific font for romanization characters, I was talking about using a widely available font in the MediaWiki:Common.css. I agree with you that the romanization template is only a hack (as well as Template:polytonic and Template:Unicode), but nowadays browsers have some limitations and those problems should be circumvented. The best option is to use Template:lang for everything, but this is problematic for a high number of users. Also, I've checked the above examples with Firefox 1.5 under Windows and it looks much better, but still not perfect. The rendering with Internet Explorer 6.0 is nearly the same.
So, Michael Z., in your opinion, what's the best policy? Use the lang template only for words in different scripts? For every foreign word (except proper nouns)? This last option in my opinion is problematic, you know. --surueña 17:33, 11 March 2006 (UTC)
Well, we could formulate all sorts of complicated rules: "Antonín Dvořák" should be pronounced as by a Czech, "August Dvorak" as by an American, etc. Should "Paris" be pronounced in French, even though it has its own English pronunciation? Pages of discussion and many revert wars would ensue, and screen readers probably wouldn't support any of the results anyway. A name is a name; it is not text in a foreign language. If a screen reader supports a database of foreign names, it will choose its own pronunciation for them; if it doesn't, then there's no point in our trying to coach it.
Regarding some of those other templates mentioned above:
Template:IPA, Template:Unicode, and Template:polytonic are necessary workarounds for a bug in MSIE/Windows; certain text will not display at all in MSIE/Win without these templates. The fix is performed by a style sheet rule which is hidden from all other browsers, so these templates do not affect display in any other browser (although they do allow you to use your user style sheet to alter the display; e.g. I have IPA displayed in green).
Template:Nihongo breaks accessibility by injecting junk text into the page and then hiding using CSS. This is bad, and it should not be used.
I can't tell what template:ZH-all is, and there is no documentation.
Template:Ruby breaks the validation of both the HTML and CSS of pages, by injecting non-HTML (MSIE-specific) tags into the page, and by incorporating a CSS hack which doesn't survive wikitext rendering. This should not be used.
All of these things display correctly in my browser. If your browser has a bug or problem that mixes up the fonts a bit, 1) please don't add code to the page that changes the display in my web browser to fix the display in yours, 2) editors should not be required to add specialized tags just for this purpose. —Michael Z. 2006-03-11 17:56 Z
Sorry for the delay, but I'm somewhat busy these days… I've been thinking about the Template:lang and the Template:rom, and although a template for romanized words can be a good solution to currently solve the font problems of some browsers, you are right that this can be hard to use by editors (and this is only a short-term solution for the problems found in some Linux distributions AFAIK) and probably will not help voice browsers (probably each transliteration should be tagged with a different template to choose the good pronuntiation, and this could be a real nightmare.
I'm not an expert about accessibility, although I've read some articles in my free time about Web Accessibility, Universal Design and Device Independence, and made some web pages WCAG 1.0-AA compliant. I also have some knowledge about assistive technologies, but I've never used a screen reader or voice brower. Do you know how JAWS and other common assistive techonologies use the lang attribute?
In summary, Template:lang should be used for every non-English words, regardless of the script. But, I'm still not sure about:
* Book and film titles: Amistad (film), El Ingenioso Hidalgo Don Quixote de la Mancha
* Names of places: Palazzo Pitti
* Names of non-English instituions: Real Academia Española
* Words in two or more languages, see Template:lang-ru/uk
Also, I suppose that when talking about the origins of words, nearly all of them must refer to Ancient Greek (Template:polytonic), i.e. it's wrong to tag it merely as Greek ({{lang|el|…}}) because it would refer to modern Greek.
--surueña 09:27, 16 March 2006 (UTC)

Interwiki

please add es:Plantilla:Lang to the interwiki --Yonghokim 21:37, 22 April 2006 (UTC)

Done.—Ëzhiki (ërinacëus amurënsis) • (yo?); 04:37, 23 April 2006 (UTC)

Please add bg:Шаблон:lang. Thanks. --Petar Petrov 10:44, 29 December 2006 (UTC)

Done Metros232 15:14, 30 December 2006 (UTC)

Overspecifying

Keeping in mind the W3C's golden rule, what is the purpose of the following additions?

Slang words are typical examples of terms used only in some regions, for example the Mexican Spanish word chale :

This is not an example like Taiwanese, where the language script is used differently in a different location. It's merely a local word. We're not going to add a language tag to every English regionalism in Wikipedia, nor should we promote the needless practice of labelling regionalisms in foreign words as if they belonged to yet another language.

Changes in script must always be specified (when not inferred from the language), even when the language doesn't change. The following example shows this for text always in English: ... In the sign can be read the word {{lang|en-Brai|⠃⠗⠊⠇⠇⠑}}, which means "braille".

Does this come from any W3C guideline? It seems to me that the language (en) is already specified for the page, and the fact that the script is braille should be inferred by any Unicode-capable web browser. Adding a language tag is superfluous. (Anyway, since this is not a braille encyclopedia, better style would be to write "the word braille, itself written in braille."

I'm going to remove these examples from the page, pending evidence that they represent good practice. —Michael Z. 2006-09-26 01:35 Z

I'm agree with you, both examples weren't very good. In the first, I wanted to put another example to show that the script isn't needed when specifying the variant. And currently, with the example of Taiwan, this isn't very clear. As a side note, in my opinion the example of Taiwan isn't very good neither, don't reflect why that word is a variant only found in that region (and as far as I know, it isn't, it's also used in any Chinese dialect). For that reason I didn't include any word when I write that example, only the language tag needed in a hipotetical case. I'm a native Spanish speaker, and I know when a Spanish word is a regionalism, but not in other languages.
In the other example, I wanted to put a more exotic case: a non-intuitive script, and also that language tags can be needed for English words. Probably it wasn't very well written, but I still think the idea is good. And isn't an academic example, it seems browsers need to specify those changes in script, otherwise the user won't be able to choose the font she wants (but I haven't make the test, maybe I'm wrong with current browsers). Anyway, I'm happy to see you again, comments are always welcome and you know really about this. Best regards --surueña 19:17, 26 September 2006 (UTC)
I understand the desire to be exhaustive with the examples, but don't worry: sooner or later an editor will come here and add a real example which they used. These are both unusual cases, and if the need arises, a solution will come. In the meantime, simpler instructions are always better.
I think Taiwanese script has to be indicated because some of the characters are different, or have different meaning: it's a technical difference that the browser/OS needs to be aware of for correct rendering, and not an indicator to the reader that the content uses local vocabulary—but "Taiwanese language" doesn't really offer much information about this.
Perhaps en-brai should be used for braille text, but I think the Cyrillic and transliterated Russian example is sufficient to illustrate the same point as in the braille example.
Regarding the browser choosing script, I suggest you test with a few different browsers. I find that Safari and Firefox render almost anything correctly as long as the OS has an appropriate font installed, while Internet Explorer is brain-dead about blocks of text from different Unicode ranges, and requires font-specification hacks like template:IPA and template:Unicode to be used in Wikipedia, although even these sometimes fail. —Michael Z. 2006-09-27 01:45 Z
After reading the article about "Taiwanese language" I think the example is even more misleading, because somebody can understand TW is used for dialects, where in fact the correct tag in that case would be zh-min-nan-Hant. Isn't a good idea to use a macrolanguage for explaining this subtag, and maybe it would be better if we don't explain them. Anyway, I think the 99% of editors writing articles with loan words will use only the language code, and less frequently maybe the script code and the rtl writing direction. I think the variant subtag it's very specialised. However, although it's true the variant code isn't an indicatior for the reader, it is an indicator for a spell checker.
I'm interested in which cases template:IPA and template:Unicode sometimes fail. I want to use a similar technique for improving language templates: to add an optional second parameter to language templates written in a non-Latin script to ease adding the trasliteration. For example {{lang-ru|Москва́|''Moskva''}}, where the second parameter is optional for backwards compatibility, will generate the following code:
[[Russian language|Russian]]: <span lang="ru" xml:lang="ru">Москва́</span>, [[Romanization of Russian| translit.]]: <span lang="ru-Latn" xml:lang="ru-Latn" class="Unicode"><i>Moskva</i></span>
--surueña 22:25, 28 September 2006 (UTC)
It can't ever be simple, can it!? I thought the Taiwanese example would be safe because the W3C uses it in their overview page. Oh, well.... This stuff is new anyway, I'm sure more will be published on the subject, or conventions will emerge eventually.
IPA and its friends sometimes fail to render particular characters because different fonts include different characters, and no one seems to be the best. One of the Windows XP default fonts with the widest range of supported characters has a bug and renders double-width combining tie bars incorrectly. You can read the details on the templates' talk pages. Or use Firefox and forget about it forever. (I use a Mac so I never suffer from any of the MSIE font bugs, but ironically I've done much of the implementation of these templates just so we could abandon ugly, confusing SAMPA and just use proper Unicode characters in Wikipedia.)
The extended template with transliteration sounds like a very good idea.  —Michael Z. 2006-09-29 03:42 Z
I'm a bit late to join in, but examples for regional variants could be:
  • Poetry or other texts written in Classical Chinese by Koreans (i.e. most pre-1900 texts from Korea) that could be displayed using Korean variants, for example {{lang|zho-Hant-KR|平}} instead of {{lang|zho-Hant|平}}: printed texts for use in Korea usually use the variant where the small strokes point upwards (/\), whereas in texts printed for use in China, I think the other variant (\/) is more common. One problem is that old prints often don't use the standard variants of today, another is that the use of KR would be an anachronism in many cases. Anyhow, as long as browsers give precedence to language tags over script tags, we must act as if those texts were Korean language: {{lang|ko-Hant|平}} = 平.
  • Swiss texts use ss in words where other standards use ß, but unlike the above Korean example, regional information (i.e.-CH/-FL) is of course unnecessary for such words to be correctly rendered by an application.
I'm sure there are better examples, but I can't think of any right now. Wikipeditor 13:13, 16 October 2006 (UTC)
Better late than never! :-) And any example can help, because this is a difficult topic. Actually, after thinking about this for some days I believe this is probably too much specialised for the Wikipedia (and maybe more appropriate for the Wiktionary?). At least from my POV, we should start tagging only the language, and the script when needed (not an easy task, though), removing from the documentation the part about regional variants or at least stating this is needed rarely.
But I think your examples are interesting. I believed regional variants are only useful to spell checkers, but you showed more uses. Maybe in the future. However, I don't agree with you in the example about Korean poetry: altough a Chinese text is printed with a Korean font the language is still Chinese, so the subtag must be zh instead of ko. We must circunvent browser bugs when we can, but in this case we are tagging the text with a wrong tag and not with a compatible one. Anyway, it will be interesting to known the behavior of current browsers (and other user agents :-) regarding language tags. I still working with the Template:lang-ru test and lang-uk test templates (to busy theses days), I hope to have time to make some tests also with IE. I will keep you informed. --surueña 20:37, 16 October 2006 (UTC)

ISO 639; more exactly

I was trying to use {{lang-gla}} and did not realise for some time we have {{lang-gd}}. I think we should specify more exactly which codes to use to name templates. Namely, should we use ISO 639-1, ISO 639-2 or ISO 639-3? Then perhaps create redirects from other used codes. --Eleassar my talk 13:02, 22 December 2006 (UTC)

"The golden rule when creating language tags is to keep the tag as short as possible",[5] so ISO 639-1 is preferred over ISO 639-2 and ISO 639-3. Also, some browsers only recognize alpha-2 codes. Best regards --surueña 00:27, 25 December 2006 (UTC)
I say use the ISO 639-3 code if it is known (be more precise.) Saving a character is not worth the ambiguity. ISO 639-1 is ambiguous for languages such as Chinese ("zh") as over a dozen spoken Chinese languages, in several written forms, are in official use throughout Asia. (Such as "cmn-Latn" for Mandarin in Pinyin or "yue-Hant" for Cantonese.) Int21h (talk) 01:46, 6 May 2009 (UTC)

Fonts customization through whole wiki

I suggest to add id parameter to span: 

<span id="lang-{{{1}}}" lang="{{{1}}}" xml:lang="{{{1}}}">{{{2}}}</span>

if Your lang is "cop", id will also "lang-cop" and You may include line in MediaWiki:common.css like: 

#lang-cop { font-family: MPH 2B Damase; }

--AlefZet 19:34, 2 April 2007 (UTC)

See current realization of the idea in kk:MediaWiki:common.css, kk:Template:lang, kk:Template:rtl-lang--AlefZet 11:42, 3 April 2007 (UTC)
You will have to use a class for this not an id. Attribute selectors would be even nicer, but they don't work in IE6, while Mozilla and Opera don't need this hack. It idea is a good idea though, I was planing on implementing this in the near future. —Ruud 12:12, 3 April 2007 (UTC)
I think about future use of ids in some javascript tricks--AlefZet 05:09, 27 April 2007 (UTC)

smart selection of css class

In the spirit of the above, note templates like {{Ar}}, {{ArB}}, {{Hebrew}} and {{Ivrit}}. These are created unsystematically by users who feel that Hebrew or Arabic script isn't rendered nicely by default, trying to fix it ad hoc (by explicit imposition of fonts, font size, boldface etc.) {{Ivrit}} uses a "spanHe" css class.

Obviously, our aim should be to have people just use {{lang|ar|...}}, {{lang|he|...}}, etc. and delegate style issues to the css. For this purpose, this template may need some conditional statements that would insert things like class="spanHe" based on the language code.

The problem is that these issues are really a matter of the script used, not of the language proper. Thus, on one hand, not just 'ar' would need to trigger an "Arabic" class, but also fa, ur, ku, ps, tg, ug etc. On the other hand, transliterated Arabic etc. ("ar-Latn") should not trigger them.

As noted above, both {{lang|kk|Қазақ тілі}} and {{lang|kk|قازاق ڌﻳل}} should result in correctly formated Kazakh spans. But these cases are rare, and could be disambiguated by using kk-Cyrl vs. kk-Arab.

Note the existence of the separate {{ISOtranslit}} for ISO compliant romanizations (and {{ArabDIN}} for DIN compliant Arabic transliteration in particular).

I am not sure what would be the best way of addressing this. At the moment, I think it might be introducing a third, optional, script parameter. Instead of {{lang|kk-Cyrl|Қазақ тілі}} and {{lang|kk-Arab|قازاق ڌﻳل}} we would then write {{lang|kk|Қазақ тілі|Cyrl}} and {{lang|kk|قازاق ڌﻳل|Arab}}, and the template do something like 

<span lang="{{{1}}}" xml:lang="{{{1}}}" {{ #if {{{3|}}} | class="Span{{{3}}}" |}}>{{{2}}}</span>

or, if we really want to provide recognition of default script, something like 

<span lang="{{{1}}}" xml:lang="{{{1}}}" {{ #if {{{3|}}} | class="Span{{{3}}}" |
 {{#switch: {{{1}}}
 |fa
 |ur
 |ku
 |ps
 |tg
 |ug
 |ar = class="SpanArab" 
 |yi
 |he = class="SpanHebr"
 }} }}>{{{2}}}</span>

This would need just a small number of css classes, say, SpanLatn (for romanizations), SpanCyrl (for cases like Tajik or Kazakh), SpanHebr (for the desired formatting elements), SpanArab. Others like SpanGrek or SpanTaml would not be needed unless there was some genuine formatting requirement, since proper usage would be {{lang|el|ελληνικά}}, {{lang|ta|தமிழ்}}, not {{lang|el|ελληνικά|Grek}}, {{lang|ta|தமிழ்|Taml}}.

Finally, it is unsatisfactory to use both {{lang|xx-Latn|...}} and {{ISOtranslit|xx|...}} for Romanization. Wouldn't it be cleaner to have a separate template for all romanizations, and restrict xx-Latn to languages that can be written in Latin natively (Kazakh etc.)? An exception is pinyin which has its own ISO 639 code pny (zh-Latn should be equivalent to pny, I suppose?)

thoughts? dab (𒁳) 12:03, 14 April 2007 (UTC)

I think it should even be possible to do {{lang|kk|Cyrl|Қазақ тілі}} and {{lang|kk|Arab|قازاق ڌﻳل}} by testing for the existence of a third parameter. I'm not sure if the matching of a default script to a language should be done by template code or clever use of CSS. The first is more elegant, the second probably causes less strain on the servers (but then again Don't worry about performance.) For transliterations I'd like to see something like {{transl|ar|DIN|al-Ḫuwārizmī}} / {{transl|ar|ALA|al-Khwārizmī}}. —Ruud 12:31, 14 April 2007 (UTC)
I agree entirely. It's important to keep the "script" and "scheme" (ISO, DIN) parameters optional (which is what you are saying, too). My main point is that the sooner we look towards clever standardization the better, to prevent more of the ilk of {{ArB}} or {{Hebrew}} turning up. Such a centralised approach may also somehow account for things like {{IAST}} (and {{PIE}}), but people will want to use these as shortcuts, and we can always use bots to subst: things. dab (𒁳) 14:03, 14 April 2007 (UTC)
I've created {{transl}} along the lines you suggest. So far, it doesn nothing with classes, and I don't know what classes should or should not be included. I suppose we need a clean list first, there being disparate things like "IAST", "SpanHe" and "Arabic Unicode". I am transcluding {{transl}} from {{ArabDIN}} so far. dab (𒁳) 14:35, 14 April 2007 (UTC)

glyph variants: classes or templates?

we need a mechanism to select preferred fonts for cases considered "glyph variants" by Unicode. Most notably, this will apply to CJK, and to Nasta'liq script fonts for Persian, Pashto and Urdu. Less urgently, some rarely supported ({{SMP}}, and perhaps {{mufi}} for ang, non etc.) scripts will need selection of specific fonts.

shall we define these fonts in templates (such as {{Hebrew}}), and select these templates from here ({{lang}}), or will we define css classes (and, can css classes depend on the "lang" parameter, or will we have to explicitly switch "class" here?). Note {{script}}, intended to select a script by ISO 15924 codes, but ISO 15924 is unsatisfactory for the purposes outlined above (it only has "Ital" for Etruscan and Raetic scripts, it only has "Arab" for Naksh and Nastaliq and it has only "Xsux" for all sorts of cuneiform, but it does have e.g. Latf and Latg vs. Latn, and Hant, Hans, Japn vs. Hani) dab (𒁳) 07:43, 16 April 2007 (UTC)

A websearch reveals, the answer to my question are language pseudo-classes. The proper solution would be to introduce these to common.css.

we'll need: 

:lang(he) {
       font-family: SBL Hebrew, Ezra SIL SR, Ezra SIL, Cardo, Chrysanthi Unicode, TITUS Cyberbit Basic, Arial Unicode MS, Narkisim, Times New Roman;
       font-family /**/:inherit;
}
:lang(fa) {
       font-family: Nafees Nastaleeq, Pak Nastaleeq, PDMS_Jauhar;
       font-family /**/:inherit;
}
:lang(ps) {
       font-family: Nafees Nastaleeq, Pak Nastaleeq, PDMS_Jauhar;
       font-family /**/:inherit;
}
:lang(ur) {
       font-family: Nafees Nastaleeq, Pak Nastaleeq, PDMS_Jauhar;
       font-family /**/:inherit;
}
:lang(sux-Xsux) {
       font-family: Akkadian;
       font-family /**/:inherit;
}
:lang(ja) {
       font-family: Code2000, Arial Unicode MS, Bitstream Cyberbit, Bitstream CyberCJK, IPAGothic, IPAPGothic, IPAUIGothic, Kochi Gothic, IPAMincho, IPAPMincho;
       font-family /**/:inherit;
}
:lang(ko) {
       font-family: Adobe Myungjo Std M, Baekmuk Batang, Baekmuk Gulim, Batang, Dotum, DotumChe, Gulim, GulimChe, HYGothic-Extra, HYMyeongJo-Extra, New Gulim, UnBatang, UnDotum, UnYetgul, UWKMJF;
       font-family /**/:inherit;
}
:lang(zh-Hans) {
       font-family: Adobe Song Std L, AR PL ShanHeiSun Uni, AR PL ShanHeiSun Uni MBE, MS Hei, MS Song, SimHei;
       font-family /**/:inherit;
}
:lang(zh-Hant) {
       font-family: Adobe Ming Std L, AR PL New Sung, AR PL ZenKai Uni, AR PL ZenKai Uni MBE, MingLiU, PMingLiU;
       font-family /**/:inherit;
}
:lang(de-Latf) {
       font-family: Gutenberg Textura, Humboldt Fraktur Regular, Alte Schwabacher, Hansa Gotisch;
       font-family /**/:inherit;
}
:lang(ga-Latg) {
       font-family: Corcaigh, Duibhlinn, Ceanannas, CeltScript;
       font-family /**/:inherit;
}
:lang(got-Goth) {
       font-family: Code2001;
       font-family /**/:inherit;
}
:lang(gem-Runr) {
       font-family: FreeMono, Junicode, Code2000;
       font-family /**/:inherit;
}
:lang(ang-Runr) {
       font-family: FreeMono, Junicode, Code2000;
       font-family /**/:inherit;
}
:lang(non-Runr) {
       font-family: FreeMono, Junicode, Code2000;
       font-family /**/:inherit;
}
:lang(ang) {
       font-family:  Alphabetum, Cardo, LeedsUni, Junicode, "TITUS Cyberbit Basic", ALPHA-Demo;
       font-family /**/:inherit;
}
:lang(non) {
       font-family:  Alphabetum, Cardo, LeedsUni, Junicode, "TITUS Cyberbit Basic", ALPHA-Demo;
       font-family /**/:inherit;
}
:lang(goh) {
       font-family:  Alphabetum, Cardo, LeedsUni, Junicode, "TITUS Cyberbit Basic", ALPHA-Demo;
       font-family /**/:inherit;
}
:lang(gmh) {
       font-family:  Alphabetum, Cardo, LeedsUni, Junicode, "TITUS Cyberbit Basic", ALPHA-Demo;
       font-family /**/:inherit;
}
:lang(ett-Ital) {
       font-family:  Cardo, Code2001;
       font-family /**/:inherit;
}
:lang(xrr-Ital) {
       font-family:  Cardo, Code2001;
       font-family /**/:inherit;
}
:lang(gmy-Linb) {
       font-family:  Cardo, Code2001;
       font-family /**/:inherit;
}
:lang(cu-Glag) {
       font-family:  Dilyana;
       font-family /**/:inherit;
}
:lang(mn-Phag) {
       font-family: Code2001;
       font-family /**/:inherit;
}
:lang(so-Osma) {
       font-family: Code2001;
       font-family /**/:inherit;
}
:lang(grc-Cprt) {
       font-family: Code2001;
       font-family /**/:inherit;
}
:lang(grc) {
       font-family: Athena, Gentium, "Palatino Linotype", "Arial Unicode MS", "Lucida Sans Unicode", "Lucida Grande", Code2000;
       font-family /**/:inherit;
}

dab (𒁳) 12:23, 16 April 2007 (UTC)

I've added some pseudo-classes to common.css now. Not the more esoteric, but the important ones, fa, ps, ur, he, ko, jp, grc. dab (𒁳) 10:50, 17 April 2007 (UTC)

Nice idea! But what about browser-side compatibility? Yet another suggestion: what about in 1st place in list the Vista's fonts for complex scripts in appropriate cases?--AlefZet 05:14, 27 April 2007 (UTC)
font-family /**/:inherit; doesn't work in MSIE7--AlefZet 05:36, 27 April 2007 (UTC)
I don't have access to a Windows box. Feel free to fiddle with the font lists to favour whatever fonts are common. dab (𒁳) 09:52, 24 July 2007 (UTC)
These pseudo-classes can not work in any browser - :lang is not supported in MSIE6 anyway, and in all other browsers font-family /**/:inherit resets previous font-family declaration.

--89.164.253.183 (talk) 07:20, 17 March 2009 (UTC)

Devanagari

Hi,

I've created Template:Lang-dev, for use to signify how something is written in Devanagari, but without saying exactly which language. --Soman 12:56, 8 June 2007 (UTC)

Hello, Soman. I'm afraid this template is wrong, because the {{lang}} family of templates is to specify the language, not the script. The dev language code does exists, but it is the code for a language from New Guinea called Domung. I have modified the template:lang-dev accordingly (anyway, it wasn't used in any article or page).
It's not straighforward how to implement what do you want to do. It's possible to create a template to specify the desired font, but the question is if this should be done (see above). Best regards —surueña 20:58, 18 July 2007 (UTC)

To mark a string as Devanagari without specifying a language, use {{script}}: {{script|Deva|देवनागरी}}: देवनागरी. dab (𒁳) 09:49, 24 July 2007 (UTC)

That doesn't quite give the same effect. So do we continue to use: Devanagari: देवनागरी-equivalent? Example, see Ravi Shankar. His name is written the same in hindi as in Marathi (hence Devanagari). How do we sort this out? -- Mayuresh 17:19, 24 September 2007 (UTC)

edit request

{{editprotected}} Here is the new code. 

<includeonly><span lang="{{{1}}}" xml:lang="{{{1}}}">{{{2}}}</span></includeonly><noinclude>
{{pp-template|small=yes}}
{{template doc}}
</noinclude>
From what I can see, this is switching from {{{{FULLPAGENAME}}/doc}} to {{template doc}}: which is good. Although, I'm not sure why you're includeonly'd the template itself. Is there a particular reason for this? Thanks in advance, GracenotesT § 00:13, 1 October 2007 (UTC)
Well, not really, numerous templates do it, probably for aesthetic reason like Infobox Company. Indeed I don't think we really need to see "{{{2}}}" before the documentation. 16@r 07:48, 1 October 2007 (UTC)
Perhaps even more useful than not showing it would be showing the source. It seems like this would be possible with:
<<noinclude><nowiki/></noinclude>span lang="{{{1}}}" xml:lang="{{{1}}}">{{{2}}}</span>
GracenotesT § 17:06, 1 October 2007 (UTC)
I've changed to template doc, but I left the includeonly tags out. --- RockMFR 14:09, 1 October 2007 (UTC)
Ok, that's fine, thank you :) 16@r 17:50, 1 October 2007 (UTC)

Why?

I'm not sure I understand the reason for this template, and other templates such as Template:Lang-fr (et cetera). Why can't the article for that specific language be placed as follows: "French:"? --213.42.21.59 (talk) 13:08, 1 February 2008 (UTC)

Because the text would not be marked as French with the span tags, which allow the search engines to search for text more efficiently.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 16:20, 1 February 2008 (UTC)

Discussion at WT:MOS

I've started a discussion about this template at Wikipedia talk:Manual of Style#Language tags. Your input is more than welcome there. Fram (talk) 06:52, 6 June 2008 (UTC)

Ugly font changes in Firefox

Please see Template talk:Transl#Font for translated words.  --Lambiam 16:22, 9 July 2008 (UTC)

Recent edits broke the front page

{{editprotected}} It appears recent edits broke the Main Page, see Talk:Main Page#Wikipedia languages links. --Voidvector (talk) 19:52, 28 August 2008 (UTC)

The recent edit breaks links in the form of 
[[link|{{Lang|xx|title}}]]
where the extra category information break this linking. (ex: {{Arabic alphabet}}) — Dispenser 01:25, 29 August 2008 (UTC)
Appears to be resolved already. Disabling editprotected request. --MZMcBride (talk) 04:55, 29 August 2008 (UTC)
平平This user favours {{lang}} template.
Nope, it's definitely still a problem; I manually fixed the {{Arabic alphabet}} issue, having not seen that this discussion was going on. Another example would be at User:Yes0song/GUS/User Lang, where the link in the left-hand side won't work because of category links. I don'think these category edits are worth the pain they may be causing across the Wikipedia, so I think we should revert them for now, whilst we discuss the issue. — OwenBlacker (Talk) 07:42, 3 September 2008 (UTC)
I reverted the category feature for now. The primary problem seems to be that many existing usages of this template are in the form:
  • [[Aleph|{{lang|ar|ﺍ}}]]
With the new category feature that ends up being converted to a string with the category link INSIDE the link to Aleph:
  • [[Aleph|ﺍ[[Category:Articles containing Arabic language text]]]]
...which breaks the Aleph link and instead displays, [[Aleph|ﺍ]].
If we want to keep the category feature then I think we would first need to go through all the existing transclusions of this template (more than 500 in the template namespace alone) and put the calls to 'lang' OUTSIDE the links. For example:
  • {{lang|ar|[[Aleph|ﺍ]]}}
That would then convert to [[Aleph|ﺍ]][[Category:Articles containing Arabic language text]] and work fine. --CBD 12:55, 5 September 2008 (UTC)

We can't reliably do that — if a link contains more than one language in its text (an unusual circumstance, but not necessarily one that isn't legitimate), then we can't wrap it like that. The simplest example to see is the somewhat artificial one at {{User:Yes0song/GUS/User Lang}}, transcluded above, but I'm sure there are other examples that are less tenuous. — OwenBlacker (Talk) 11:04, 8 September 2008 (UTC)

I'm hard pressed to imagine a situation where using two languages in one link would be necessary in article space. But if such a situation should ever actually occur, the simple solution would be to split it into two links. --Latebird (talk) 10:04, 10 September 2008 (UTC)
OK I'm fixing up these articles and templates, at some point soon I will reinstate the categorization. Rich Farmbrough, 15:45 7 February 2009 (UTC).

{{editprotected}}

This same problem has broken User:Yes0song/GUS/User Lang again. Given the categories should only be used in the article namespace, can we wrap the categories in an "article namespace only" statement: 

{{#ifeq:{{NAMESPACE}}|{{ns:0}}| current category stuff here }}

please? Whilst that won't fix any similar problems in actual articles, it would be a quick and easy way of making the userbox problem go away… — OwenBlacker (Talk) 11:34, 26 April 2009 (UTC)

 Fixed, hopefully. — Martin (MSGJ · talk) 13:42, 26 April 2009 (UTC)

LANG-DV

DV, which is reserved for Dhivehi, shows up as Mahl language, which redirects to Mahal language. This is not Dhivehi, but a sister language spoken in India. Dhivehi is spoken in the Maldives; does anyone know how to fix this issue? I can't figure out where I'm supposed to go to fix it. ناهد/(Nåhed) speak! 07:27, 29 October 2008 (UTC)

I have edited {{lang-dv}}. Have it fixed the problem? --fryed-peach (talk) 18:37, 4 November 2008 (UTC)

{{rtl-lang}}

The guidelines currently self-contradict over the use of {{rtl-lang}} (for languages read right-to-left). In way place, usage is encouraged, and in a second location the suggest use is struckout, suggesting instead {{rtl-para}}. Could somebody with more of an understand suggest how the two sentences could be reworded, to be in in harmony. —Sladen (talk) 11:08, 27 November 2008 (UTC)

Guidance for using this template with Korean script

I'm a getting a bit lost with all the various ISO codes and such, so I need some assistance with using this template for the Korean language. Primarily this is for implementation in language templates such as {{Infobox Korean name}} and such. As I understand things from reading the documentation:

  • {{lang|ko|...}} should be equivalent to {{lang|ko-Kore|...}}, which can be used for both Hangul and Hanja.
  • Alternatively, {{lang|ko-hang|...}} can be used to specify Hangul, and {{lang|ko-hani|...}} can be used to specify Hanja. Is it desirable to make this distinction, or is the above sufficient?
  • Revised Romanization of Korean and McCune-Reischauer can be specified as either {{lang|ko-Latn|...}} or {{transl|ko|...}}. Again, is this sufficient or would it be desirable to be more specific? And if so, how?

Thanks in advance if anyone can help me out with this. PC78 (talk) 12:01, 22 December 2008 (UTC)

That looks good. I suppose it's good to be as specific as is practical, so ko-Latn would probably be preferable for Romanization. —Michael Z. 2008-12-22 16:28 z

Should there be a parameter to include a link to the language before the text like the style of the lang-xx templates? The form of the template would then be {{lang|xx|text|yes}}. The 3rd parameter would be named "link" or "language link" to make things clearer and it would default to no. The form could then also be {{lang|xx|text|link=yes}}.

Additionally, wouldn't it be better to merge the lang-xx templates into this one? Other than the link to the language, I'm not really sure why we need all these different templates if one template could accomplish the same thing. Once the code is complete, the lang-xx templates could either redirect to here and/or deleted once all occurrences are converted to this "master" template. ~ PaulT+/C 01:10, 31 December 2008 (UTC)

Alternatively {{lang named|fa|some Farsi}} giving two templates rather than dozens. Rich Farmbrough, 22:22 8 February 2009 (UTC).

#ifexist

{{editprotected}} This page uses #ifexist, an expensive parser function call, causing several pages that use it to show up in Category:Pages with too many expensive parser function calls. By moving the #ifexist to the end of the switch it will only get used if needed. 

<span lang="{{{1}}}" xml:lang="{{{1}}}">{{{2}}}</span><includeonly>{{#Switch:{{{1|}}}
|ar=[[Category:Articles containing Arabic language text]]
|es=[[Category:Articles containing Spanish language text]]
|de=[[Category:Articles containing German language text]]
|fr=[[Category:Articles containing French language text]]
|ja=[[Category:Articles containing Japanese language text]]
|zh=[[Category:Articles containing Chinese language text]]
|{{#ifexist:Category:Articles containing {{ISO 639 name {{{1|}}}}} language text|
[[Category:Articles containing {{ISO 639 name {{{1|}}}}} language text]]|
[[Category:Articles containing non-English language text]]
}}}}</includeonly><noinclude>
{{documentation}}<!-- Add cats and interwikis to the /doc subpage, not here! --></noinclude>

--Pascal666 11:09, 22 February 2009 (UTC)

Done. --- RockMFR 22:26, 22 February 2009 (UTC)

Official languages of the European Union

{{editprotected}} Please add the below to the template. These are the official languages of the European Union that are not already included. This will fix List of member states of the European Union in the official languages so that it no longer trips Category:Pages with too many expensive parser function calls. 

|bg=[[Category:Articles containing Bulgarian language text]]
|cs=[[Category:Articles containing Czech language text]]
|da=[[Category:Articles containing Danish language text]]
|nl=[[Category:Articles containing Dutch language text]]
|et=[[Category:Articles containing Estonian language text]]
|fi=[[Category:Articles containing Finnish language text]]
|el=[[Category:Articles containing Greek language text]]
|hu=[[Category:Articles containing Hungarian language text]]
|ga=[[Category:Articles containing Irish language text]]

Thanks! --Pascal666 00:34, 23 February 2009 (UTC)

Ancient Greek

{{editprotected}} Please add the below to the template. This will fix Ancient Greek grammar (tables), List of Greek place names, and List of Greek words with English derivatives so that they no longer trip Category:Pages with too many expensive parser function calls. 

|grc=[[Category:Articles containing non-English language text]]

Thanks! --Pascal666 16:48, 23 February 2009 (UTC)

Latin

{{editprotected}} Please add the below to the template. This will fix List of birds of Angola, List of birds of Bhutan, List of birds of Uganda, and List of birds of Bolivia so that they no longer trip Category:Pages with too many expensive parser function calls. 

|la=[[Category:Articles containing Latin language text]]

Thanks! --Pascal666 16:51, 23 February 2009 (UTC)

 Done Ruslik (talk) 18:29, 23 February 2009 (UTC)

Welsh

{{editprotected}} Please add the below to the template. This will fix Welsh morphology so that it no longer trips Category:Pages with too many expensive parser function calls. This should finally get all of the articles out of there! YAY! 

|cy=[[Category:Articles containing Welsh language text]]

Thanks! --Pascal666 19:16, 23 February 2009 (UTC)

Done. --- RockMFR 19:04, 24 February 2009 (UTC)

Template simplification

There is no need to check whether each category exists. This is adding a lot of expensive parser functions to pages. We know the list of acceptable inputs - they should all have their own categories, and any other value goes into non-English. I agree that this template should handle the exception for English rather than ISO 639 name. The best way might be as follows: 

[[Category:Articles containing {{#switch:{{#iferror:{{ISO 639 name|{{{1|}}}}}|unrecognised}}
 |unrecognised  = non-English
 |English       = explicitly cited English
 |#default      = {{ISO 639 name|{{{1|}}}}}
}} language text]]

or perhaps the following might be tidier. 

[[Category:Articles containing {{#ifeq:{{ISO 639 name|{{{1|}}}}}|English
 |explicitly cited 
}}{{#iferror:{{ISO 639 name|{{{1|}}}}}
 |non-English
}} language text]]

Thoughts? — Martin (MSGJ · talk) 10:35, 3 May 2009 (UTC)

The two questions that still arise:
  1. What is the actual cost of #ifexist: vs calling {{ISO 639 name}}, evaluating the switch and testing for an error?
  2. What is the cost of evaluating the switch vs returning a literal string?

Normally these would be negligible concerns but the number of places this is used make it relevant. Apart from the the single template has a lot to recommend it as well as some minor concerns. Rich Farmbrough, 11:24 3 May 2009 (UTC).

Ok try reloading these two pages;
For me the first one is about 7 times slower. Allowing for some constant overhead the factor is bigger, probably 14-45.
Rich Farmbrough, 12:08 3 May 2009 (UTC).
Yes, the first one is slower for me too. This surprises me because I had heard that ifexist was an expensive function. I'll ask Happy-melon to comment here because he knows more about this kind of thing. — Martin (MSGJ · talk) 19:25, 3 May 2009 (UTC)
First, remember that the time you measure is the total round-trip time from you sending the HTML GET request, to the squids receiving it, it falling through the cache to the Apaches, them revving up the wiki parser, getting any necessary data from a slave database, processing it, and then (most importantly) sending the data back to you (and for your browser to process it and render it on the screen to the extent that you're satisfied that the rendering is 'finished'). The size of the HTML text rendered by the first example is about four times the size of the second, and all that data has to be pushed through your internet connection to reach you. An accurate test would need to produce a final output that is a similar size in both cases.
Regarding the actual computational complexity, turn to the preprocessor limit report that's embedded in the HTML source of each page. for lang-test-one:
<!-- 
NewPP limit report
Preprocessor node count: 253031/1000000
Post-expand include size: 73358/2048000 bytes
Template argument size: 2294/2048000 bytes
Expensive parser function count: 0/500
-->
And for lang-test-many:
<!-- 
NewPP limit report
Preprocessor node count: 2839/1000000
Post-expand include size: 20437/2048000 bytes
Template argument size: 11/2048000 bytes
Expensive parser function count: 161/500
-->
We can see very clearly the difference in processing 'style'. The preprocessor node count is a rough estimate of the computational complexity of the operation, while the post-expand include size is the bytecount of the expanded wikitext before it goes to the parser for convertion into HTML. The template argument size is the bytecount of the wikitext content that came out of template expansions, and the expensive parser function count is the number of database transactions that were made in the course of expanding #ifexist statements: the results of #ifexists are cached, so querying the same page multiple times does not hit the database multiple times, and the parser can also get some values from the Links cache, which caches red/blue links for normal processing. So only 161 of the #ifexist staments actually hit the database in that test.
From these data we can see that the first one is indeed significantly more computationally heavy, almost 100 times so, in fact. But this load falls on the Apache servers; of which Wikimedia has a hundred and seventy nine. This compares to (for the s1 cluster) five database slaves and one database master. Which method is worse for Wikimedia is a much more complicated question.
The acid test, in terms of performance, has to be response time, as you rightly suggest by creating this test. And the very bottom line of each page source gives precisely this information; for lang-test-one I get:
<!-- Served by srv77 in 0.146 secs. -->
And for lang-test-many:
<!-- Served by srv157 in 2.583 secs. -->
Those results speak for themselves: they are the total processing time the Apaches spent from receiving the request to returning the generated content. And it takes considerably longer for the method using #ifexist.
What this really goes to show, of course, is the validity of WP:PERFORMANCE. One method is heavier on the database, the other heavier on the Apaches. One method takes longer to render, the other longer to display. One of these methods can be objectively described as 'performing better' than the other. I know I'm in no position to say with certainty which one it is. Do whatever is easiest and most elegant on-wiki, and let the developers pick up the pieces if anything breaks upstream. Happy‑melon 20:35, 3 May 2009 (UTC)
Happy-melon's explanation of "Expensive parser function count" is not correct. User:Rich Farmbrough/lang-test-many2 has 150 identical #ifexist statements and shows an "Expensive parser function count" of 150. The 161 is the number of #ifexists that actually found an existing page. For whatever reason, a #ifexist that does not find the page it is looking for is not counted as expensive.
Also, when loading the two test pages above, make sure you purge them before you view the page source. When purged first, for lang-test-one I get:
<!-- Served by srv68 in 28.339 secs. -->
And for lang-test-many:
<!-- Served by srv151 in 1.681 secs. -->
--Pascal666 21:45, 3 May 2009 (UTC)
How interesting - you're entirely correct, yet that doesn't fit with what I remember at all. I'm not sure if that's a regression or I'm just remembering wrong; either way, it's very inefficient. Also rather wierd that only #ifexists that find a target get counted, that's probably a bug. Thanks for pointing that out.
Also a good point about purging, although again the results are interesting. Particularly that while a purge on lang-test-one takes between 20 and 35 seconds to render (while lang-test-many takes 2 to 3), doing a null edit, which is what I was doing, and which one would naively expect to be slower still, takes usually less than two seconds.
Essentially Pascal's points merely reinforce the futility of trying to do performance profiling without access to the full server logs. Just do whatever works best on-wiki, for wiki users. Happy‑melon 22:54, 3 May 2009 (UTC)
Agreed. In this case, even though lang-test-many has many expensive parser functions, it still renders for the user much faster than lang-test-one. With pages like List of Greek place names calling {{lang}} over 500 times, most users would probably give up before the page even loaded if we went with the lang-test-one method. --Pascal666 02:50, 4 May 2009 (UTC)
This discussion has been illuminating and turned upside down my understanding of how expensive different parser functions are to run. I still really hate using the individual templates: it's completely inelegant and goes against the grain for me, probably for all template coders. However the differences in the performance cannot be ignored, and List of Greek place names was taking a long time to render. I'm going to keep thinking about how this template can be improved, but for now I've reverted my change to use the single template {{ISO 639 name}} and we are now using the individual templates again. — Martin (MSGJ · talk) 16:22, 4 May 2009 (UTC)

We need to re-evaluate everything that was discussed in this section. The lang-test-many page is not doing what we actually thought it was. My original comments in this section and Happy-melon's concurrence were both in error. The first two lines of lang-test-many read: 

# {{#ifexist:{{ISO 639 name aa}}| aa exists| aa doesn't exist}}
# {{#ifexist:{{ISO 639 name aaq}}| aaq exists| aaq doesn't exist}}

this resolves to: 

# {{#ifexist:Afar| aa exists| aa doesn't exist}}
# {{#ifexist:| aaq exists| aaq doesn't exist}}

That is to say, the first line is checking if a page named "Afar" exists, and the second is checking nothing because {{ISO 639 name aaq}} does not actually exist. This is why the second line is not showing up as an expensive parser function, it is not actually doing anything. I believe this test page should have read either: 

# {{#ifexist:Template:ISO 639 name aa| aa exists| aa doesn't exist}}
# {{#ifexist:Template:ISO 639 name aaq| aaq exists| aaq doesn't exist}}

or 

# {{#ifexist:Category:Articles containing {{ISO 639 name aa}} language text| aa exists| aa doesn't exist}}
# {{#ifexist:Category:Articles containing {{ISO 639 name aaq}} language text| aaq exists| aaq doesn't exist}}

--Pascal666 02:42, 5 May 2009 (UTC)

Hehe, well spotted Pascal. Would be interesting to have the correct results, but I doubt it will come close to the time of lang-test-one. — Martin (MSGJ · talk) 07:18, 5 May 2009 (UTC)

Request to create Template:Lang-ast

I am busy editing pages from Asturias, Spain. When possible, I would like to give the local name in Asturian (and obviously in Spanish).

The template Template:Ast icon does exist but I miss its counterpart: Template:Lang-ast (like for ex. Template:Lang-es)

Would it be possible to create it? Thanks in advance Alberto Fernandez Fernandez (talk) 16:55, 21 May 2009 (UTC)

Done, and well done !… --Budelberger (   ) 17:41, 21 May 2009 (UTC).
Thanks on behalf of all the Spaniards!! Done, well done and already employed ! Alberto Fernandez Fernandez (talk) 18:36, 21 May 2009 (UTC)
You know what ? I'm glad you are happy… Don't you think that a template « lang-es/ast » would be useful ? :

{{langx|es/ast|San Miguel de Lillo|San Miguel de Lliño}}
=
Spanish: San Miguel de Lillo, Asturian: San Miguel de Lliño

And « lang-es+ast » ? :

{{langx|es+ast|same name}}
=
Spanish and Asturian: same name

See for example « Template:lang-grc/la »,

{{langx|grc/la|Greek name|Latin name}}

-- Budelberger (   ) 21:38, 21 May 2009 (UTC).

Language templates are being removed

Language templates are being unilaterally removed by one user. Please see related discussion at template talk:lang-uk. —Michael Z. 22:29, 16 October 2005 (UTC)

Some templates that shoudl probably be merged here

Rich Farmbrough, 22:34, 8 February 2009 (UTC).

Categories

I have searched for pages which would break with the category code and corrected all I can find (see above)). In the event that there are additional problems, please let me know and I will attempt to resolve them. Rich Farmbrough, 07:35, 10 February 2009 (UTC).

Template breaking

Using <font>, <span>, and other tags within {{lang}} seems to break it. See the following examples:

  • Fine:
{{lang|zh|你好}}

你好

  • No problems with <u>:
{{lang|zh|<u>你好</u>}}

你好

  • Problems with <span style>:
{{lang|zh|<span style="color: red">你好</span>}}

[undefined] Error: {{Lang}}: invalid parameter: |<span style= (help)

  • Not specific to zh:
{{lang|en|Hello}}
{{lang|en|<u>Hello</u>}}
{{lang|en|<span style="color: red">Hello</span>}}

Hello

Hello

[undefined] Error: {{Lang}}: invalid parameter: |<span style= (help)

rʨanaɢ talk/contribs 02:24, 9 August 2009 (UTC)

Hm, this seems to be a more general problem.... it seems that templates can't be passed parameters with <font>, <span style>, and other html tags in them. I will leave a message at WP:VP/T. rʨanaɢ talk/contribs 02:31, 9 August 2009 (UTC)

Breaking when linking

It only happens at Article.

Links written with 

*[[:ja:初音ミク|{{lang|ja|初音ミク}}]]
*{{lang|ja|[[:ja:初音ミク|初音ミク]]}}
*[[Hatsune Miku|{{lang|ja|初音ミク}}]]
*{{lang|ja|[[Hatsune Miku|初音ミク]]}}

will get

not

How resolve it? I'm from zh.wikipedia and there are so many links written with 1st and 3rd pattern.RalfX (talk) 06:52, 26 September 2009 (UTC)

This is the expanded output from the template:
*[[:ja:初音ミク|<span lang="ja" xml:lang="ja">初音ミク</span>[[Category:Articles containing Japanese language text]]]]
*<span lang="ja" xml:lang="ja">[[:ja:初音ミク|初音ミク]]</span>[[Category:Articles containing Japanese language text]]
*[[Hatsune Miku|<span lang="ja" xml:lang="ja">初音ミク</span>[[Category:Articles containing Japanese language text]]]]
*<span lang="ja" xml:lang="ja">[[Hatsune Miku|初音ミク]]</span>[[Category:Articles containing Japanese language text]]
The categories are only added in the main namespace, and naturally they totally break the surrounding link. Happy‑melon 09:19, 26 September 2009 (UTC)
Using the syntax such as
*{{lang|ja|[[:ja:初音ミク|初音ミク]]}}
*{{lang|ja|[[Hatsune Miku|初音ミク]]}}
or no category... Thanks. RalfX (talk) 15:41, 26 September 2009 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Lang/Archive_1&oldid=1255223726"