This is an archive of past discussions about Template:Lang. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
At Wikipedia:Bots/Requests for approval/ZhBot, it was suggested that I run this bot by you guys. The bot will make some systematic replacements to pages that transclude the {{zh}} template, which uses {{lang}} indirectly. This run should have no effect on {{lang}} itself (either how it displays or how it is used), but if anyone is concerned feel free to check out the BRFA and offer input. Thanks, rʨanaɢtalk/contribs17:35, 13 October 2009 (UTC)
Requested option: no line breaking
In some articles, particularly ones discussing names in an East Asian language (such as the article "Japanese name"), a version of this template that incorporates the functionality of the {{nowrap}} template could be very convenient. Wrapping all foreign characters in {{lang|...}} is already cumbersome enough. --MQDuck (talk) 04:44, 7 January 2010 (UTC)
Yes that seems very useful, and it is easy to code. The hard part is deciding on a good short name for the new template, since if the name is long it isn't as useful. If we can come up with a good name for the new template I can code it for you.
Here's some ideas: {{LANG}}, {{wlang}}, or {{langw}}. I think I slightly prefer {{langw}}.
Since what we're doing is preventing line wrapping, adding only a W is a little bit counter-intuitive. Still, it's not hard to remember and I can't think of anything better. {{langnw}} is somehow less intuitive. {{langw}} sounds good enough to me, though I wouldn't mind if we could get some more suggestions.
(Incidentally, Wikipedia is being very weird for me tonight. Among other things, my signature is broken) (never mind, I got it working, though how it went wrong is quite unknown to me. --MQDuck (talk) 13:05, 10 January 2010 (UTC)
I would suggest calling the template something very clear and desciptive (and not necessarily short). That doesn't stop you creating a short redirect for the template (like {{langw}}) and using that in articles. — Martin (MSGJ · talk) 16:30, 10 January 2010 (UTC)
Documentation should inform how to keep from gobbling up nearby text
The documentation here needs to tell us how to keep this nasty template from gobbling up birth dates or whatever when it is used. The dates or other text can appear fine on the edit page, then when the edited article shows up, this template sometimes eats other text around it. Gene Nygaard (talk) 23:56, 28 January 2010 (UTC)
Gene: I assume you see this problem when using this template with text that goes right to left, such as arabic, right? If so, then this probably is related to the bug that is currently discussed at Wikipedia:Village pump (technical)#Issues with mixing LTR and RTL scripts (will later end up in /archive 70 or 71).
Yes, I think so, or at least mostly on right-to-left--and it is a problem that has been around for years, so I'm surprised it wasn't discussed in the documentation here. Recent example, see this edit where you can see what shows up on the edit scree at the top, and what shows up afterwards by looking at the text below. Gene Nygaard (talk) 16:07, 29 January 2010 (UTC)
Functionality?
Is there a way to include a link with this template in it?
[[Pâtissier|{{lang|fr|Pâtissier}}]] does not work: Pâtissier
Is it possible to add a CSS code like src: url(.../xyz.ttf) format("truetype") to this template? Because some special characters (like the Etruscan version of Odysseus, 𐌄𐌂𐌖𐌈𐌖) need special fonts ("MPH 2B Damase" in this case) that most Wikipedia users don't have and probably don't even know where to get from. --bender235 (talk) 13:34, 10 January 2010 (UTC)
That could more easily be achieved, I think, by editing the core stylesheet to specify something like:
@font-face{font-family:Damase;src:url(.../Damase.ttf)format("truetype");}span[lang=ett],*:lang(ett){font-family:Damase,ArialUnicodeMS,sans-serif;/* or some such */}
{{editprotected}}
In order to avoid the main page being categorized by this template, would you be able to change this template's categorization method (well, I admit the "real" fix to this would be to move it out of the main space, but since that's unlikely to happen, we gotta go with this solution). The code should be changed to the following:
<span lang="{{{1}}}" xml:lang="{{{1}}}">{{{2}}}</span>{{Cat handler
|main=[[Category:Articles containing {{#switch:{{{1|}}}
|ar = Arabic
|es = Spanish
|de = German
|fr = French
|ja = Japanese
|zh = Chinese
|bg = Bulgarian
|cs = Czech
|da = Danish
|nl = Dutch
|et = Estonian
|fi = Finnish
|el = Greek
|hu = Hungarian
|ga = Irish
|grc = Ancient Greek
|la|lat = Latin
|cy = Welsh
|sl = Slovene
|slv = Slovene
|en|eng = explicitly cited English
|#default = {{#ifexist:Category:Articles containing {{ISO 639 name {{{1|}}}}} language text
|{{ISO 639 name {{{1|}}}}}
|non-English
}}
}} language text]]
}}
The current change breaks every template that uses this meta-template, because the category markup is not properly closed (no closing brackets). Please fix immediately. — Gavia immer (talk)01:46, 3 June 2010 (UTC)
Good question. I thought you had just missed the closing brackets, but looking at your edit they are in there; it's just that they don't get passed through for some reason. I'd suggest asking The Evil IP address to debug this and see where it's going wrong. — Gavia immer (talk)01:58, 3 June 2010 (UTC)
Further note: It's probably {{Cat handler}} mangling the markup somehow, but I've looked at that template code and it frightens me. I don't know where the problem is in there. — Gavia immer (talk)02:02, 3 June 2010 (UTC)
Since the categories are hidden, there should be no problem having the main page categorised. (And yes, Cat handler is another template that is going to have many millions of transclusions simply to allow the functionality of saying explicitly "not on this page" - in some cases for templates that can't use that functionality.) RichFarmbrough, 14:10, 22 June 2010 (UTC).
I know we normally should not add messages to archive pages, but since I created the {{cat handler}} template and this error intrigued me I investigated it and found the error. So here goes:
The code that The Evil IP address supplied here on the talkpage is correct and should have worked. It does work in the sandbox. However when HJ Mitchell copied that code to the {{lang}} template he accidentally moved the closing brackets and thus damaged the code.
Here's the correct ending of the code:
| non-English
}}
}} language text]]
}}<noinclude>
And here is the broken version that unfortunately got deployed:
| non-English
}} language text]]
}}
}}<noinclude>
So it was the human factor. (No shame on HJ Mitchell, we all do mistakes like that all the time.)
However, as Rich Farmbrough pointed out using {{cat handler}} is probably overkill in this case. Since {{lang}} only categorises on articles (thus no problem when shown/demonstrated in other namespaces), and {{lang}} uses a hidden category (so no problem when used on the Main Page.) So it seems {{lang}} is okay as it is now.
Whatever was done to the template made it completely broken. There are a bunch of red link categories across the project.—Ryūlóng (竜龙) 03:48, 21 June 2010 (UTC)
I have reverted. Even if we agreed to change all to xxx-language there are some that are thinks like "Sindarian (Tengwar script) language" which while slightly clumsy should certainly not be "Sindarian (Tengwar script)-language". At the CfD discussion I was almost tempted to say "don't worry about this, the cat is hidden, and is a catch-all as much as anything." The hyphen is not important, and it's certainly not worth making the whole system over for. However if consensus disagrees, please drop me a note and I will try to fix it up to put the hyphens in without breaking anything, and move the necessary categories. RichFarmbrough, 01:58, 22 June 2010 (UTC).
I figured this would be a relatively painless transition that would take only a few days to work itself out, but since so many editors seem upset about it, I'll just change the CFD close to say something to the effect, "tried it and it was too complicated; if you want to rename this one, we need a CFD nomination for all of them, not just the English-language one." Good Ol’factory(talk)23:52, 22 June 2010 (UTC)
How about including a transliteration and a gloss?
How about this (to be added right before the noinclude tag): {{#if:{{{3|}}}| <i lang="{{{1}}}-Latn" xml:lang="{{{1}}}-Latn">{{{3}}}</i>}}{{#if:{{{4|}}}| "{{{4}}}"}}? --A. di M. (talk) 11:46, 1 February 2011 (UTC)
Not working for some languages?
It's probably an error on my part, but the template seems not to be working for some languages with ISO 639-2 and 639-3 codes:
{{lang-eng|working}} gives me English: working, but
{{lang-efi|mbakara}} gives me Efik: mbakara instead of Efik: mbakara (639-2)
{{lang-anw|anaang}} gives me {{lang-anw|anaang}} instead of Anaang: anaang (639-3)
{{lang-ibb|ibibio}} gives me Ibibio: ibibio instead of Ibibio: ibibio (639-3)
Is this something I can fix myself, say by editing a list somewhere? Or does it require expert intervention? I only actually need it to work for Efik, the other two are for comparison only. Thank you, Justlettersandnumbers (talk) 12:04, 16 July 2011 (UTC)
There has to be a template for each language. And yes, this is something you could fix yourself, by creating the template {{lang-efi}}. To know how, you could look at the code of {{lang-en}} and copy it while modifying the language-specific bits. And ideally create the documentation subpage too. I have went ahead and done that. User<Svick>.Talk();22:48, 16 July 2011 (UTC)
Well, thank you very much, that is great. I would maybe have been able to do it myself if I had known where to start. Does anyone think that information on how to do this should perhaps be included in the documentation for this template? Anyway, thanks again. Justlettersandnumbers (talk) 00:28, 17 July 2011 (UTC)
Well, this template is different than the {{lang-xx}} templates. {{lang}} is used to show some text in a foreign language. {{lang-xx}} are used to display some text along with the language it is in. User<Svick>.Talk();02:13, 17 July 2011 (UTC)
Cleanup banner for articles with non-English text, lacking appropriate markup
As part of an unlrelated task, I've found quite a few attempts to transclude ISO_639_name templates that don't exist. While many of these will be typos, some may represent language templates that it would be useful to create.
For those using this tool, it should now be a bit more accurate and quite a bit faster. Any problems please let me know. - TB (talk) 20:04, 5 September 2011 (UTC)
2 questions
"Use ISO 639 language codes" is confusing as it leads to a disambiguation page. Can this be disambiguated, or are all entries relevant?
I quite often provide names in, and translations of, Khoekhoegowab (Special:WhatLinksHere/Template:Contains_Khoekhoe_text lists a few, but by no means all, uses). This language, although spoken by half a million people, seems to have no language code (alternative names: Damara, Nama, Damara/Nama). Would it be possible / a good idea to create a {{lang-kh}} or {{lang-khoe}} template?
Might it be possible to to plug in CSS class names into this template, based on the language code being used? Something like class="lang-{{{1}}}", or something similar. This could help users with custom style sheets better control the appearance of text in a specific language while using this template. - Gilgamesh (talk) 13:49, 28 April 2011 (UTC)
Never mind, I found a way. Where XYZ is the language code, the CSS class is to span:lang(XYZ). - Gilgamesh (talk) 00:27, 29 April 2011 (UTC)
CSS class and/or style parameters
I ran into a very similar problem to the above while looking at {{lang-ab}} which wants span class="Unicode", or {{lang-my}} which wants style="font-family:[...list of fonts...]" and even has a child template that makes that happen. Should we add support for such optional parameters here, or is this misguided? --Joy [shallot] (talk) 18:08, 28 March 2012 (UTC)
The Template:Lang breaks links. Solution needed, please !
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Hello,
I have written {{Audio|Nl-Leopoldstad.ogg|''{{lang|nl|Leopoldstad}}''}} → Leopoldstadⓘ in an article, and this gets broken.
Even a simple link like [[Kinshasa|{{lang|nl|Leopoldstad}}]] → Leopoldstad gets broken.
Here in discussion, as well as in the Sandbox, it is fine. But in articles, the Template:Lang breaks the links.
I guess the culprits are the Categories.
For [[Kinshasa|{{lang|nl|Leopoldstad}}]], I know a workaround, albeit not a nice one. But for {{Audio|Nl-Leopoldstad.ogg|''{{lang|nl|Leopoldstad}}''}}, I am going to write {{Audio|1=Nl-Leopoldstad.ogg|2=''<span lang="nl" xml:lang="nl">Leopoldstad</span>''}} → Leopoldstadⓘ. Which is really heavy ! Or I don't language-tag the Dutch text at all — which is is bad for accessibility. Using the Template:Lang would be much nicer. So can you please provide an option, or a brother Template, for not adding the Categories ? Thanks.
Done I have added categorisation optout, so you can now write {{lang|nl|Leopoldstad|nocat=true}} to disable the categories. Happy‑melon14:50, 24 May 2012 (UTC)
I did not made the change in the code. And, after looking at it, I don't master it. So I am not going to write how one is supposed to use it. --Nnemo (talk) 18:37, 25 May 2012 (UTC)
was used to translate into Greek the Hebrew word "Messiah" ({{lang| he| מָשִׁיחַ}}).<ref>''Jesus of history, Christ of faith'' by Thomas Zanzig 2000 ISBN 0884895300 page 314</ref>
renders like this:
was used to translate into Greek the Hebrew word "Messiah" (מָשִׁיחַ).[1]
When rendered, the parentheses are out of place, and the citation link is broken in two. Can someone please sort this out? Thanks. --99of9 (talk) 09:13, 11 December 2011 (UTC)
The problem is that the Unicode bi-directional text algorithm can get confused if you have right-to-left characters followed by numbers or punctuation. This has nothing to do with {{lang}}; see this example without:
was used to translate into Greek the Hebrew word "Messiah" (מָשִׁיחַ).[1]
The solution is to insert {{lrm}} just after the {{lang}} template. That template contains a character that is a "strong" left-to-right character which causes the following "weak" characters to be interpreted as intended:
was used to translate into Greek the Hebrew word "Messiah" (מָשִׁיחַ).[1]
I mean a specific class. No style needs to be defined for the class, it would just allow the user to format any words using this template, similar to the way {{Official website}} has the class "official website". A scenario where this would be useful (and the way I intend to use it) would be for editors to set the class of this template to a different color in their common.css page so that they can see immediately if any foreign-language text on the page is not using this template. Liam987(talk)13:41, 24 May 2012 (UTC)
It might be sufficient to use a CSS rule along the lines of span[lang]{...}. You could also use something like span[lang|="en"]{...} to match only spans being marked as English. Or is it necessary to match this specific template's output rather than any other template or manual language marking? Anomie⚔17:25, 25 May 2012 (UTC)
The following sentence under "Undetermined language" is missing a word or a comma:
"Many times the character/symbol is used in several languages, but when the article refers to the grapheme itself the ISO 639-2 and ISO 639-3 language code und for Undetermined language". Katana (talk) 04:00, 30 July 2012 (UTC)
Sorely missed language support functionality on Wikipedia
Should this template be used in the case of Fraternity and Sorority letters in articles about them or in articles about American Colleges and Universities? On these Articles, if you are lucky, you get ΣΑΕ (all greek), if you aren't, you get ΣAE (one greek and two latin look alikes. (which I try to correct)Naraht (talk) 10:40, 12 September 2012 (UTC)
The MediaWiki software no longer passes the xml:lang attribute, but it is automatically added when the lang attribute is defined. Therefore, xml:lang can be removed as redundant.
You can check this by viewing the source of this page:
It's not even a MediaWiki bug. Links cannot be nested; that is the way that HTML is designed. The template doc states "This template also includes a categorisation link when used by main namespace pages, therefore it should not be included inside a wikilink." which IMHO is not strong enough - it should read "therefore it must not be included inside a wikilink". --Redrose64 (talk) 16:16, 18 March 2013 (UTC)
So the response is that {{lang|...|...}} can't be used inside a wikilink? I was trying to use the template to indicate that there's a word in a foreign language, so spell checkers and bots don't mistake it for an error. - ʈucoxn\talk10:47, 19 March 2013 (UTC)
The word "Krbava" is a proper noun and isn't translatable—it doesn't have it's own Anglicized form. "Polje" is a Croatian word that means karst field but it's also an obscure word used in English, in it's own right. "Polje" is the operative word. Some people refer to the area as "Krbava karst field" but is also known as "Krbava Polje" in English and Croatian. Your solution seems to produce the correct outcome, though, and I suppose it could be used if it's simply impossible to fix this bug. - ʈucoxn\talk09:41, 21 March 2013 (UTC)
I changed "answered" back to "no" because it's evident that the bug was not fixed or a response that it cannot be fixed was not given. Is it possible to modify this template so that the bug described above (and re-explained on 21 March) can be corrected? If it's simply not possible, please state that, and it will have to be an acceptable response. Thanks! - ʈucoxn\talk04:21, 28 March 2013 (UTC)
Not done: There isn't a simple fix for this - it's inherent in the mediawiki software, and would need to be fixed at the software level, if at all. However, there are a couple of ways to work around it, and neither requires editing the template.
Workaround number one: suppress the category in {{lang}}. This makes the link work, but we have to add the category manually.
Code: [[Krbava|Krbava {{lang|hr|Polje|nocat=true}}]][[Category:Articles containing Croatian language text]]
Workaround number two: do everything manually. This gives the same result, but requires the use of html:
Code: [[Krbava|Krbava <span lang="hr">Polje</span>]][[Category:Articles containing Croatian language text]]
Should there be any limit to the use of this template on a page? I've been adding it to all instances of foreign names in Wordless novel; it seems to me that would be necessary for screen reading software, but I can also imagine people complaining about the page being plastered with this template. Curly Turkey (gobble)01:29, 18 March 2013 (UTC)
It would be good to link to a list of the specific languages. As it stands, it mentions a couple of those languages, but which ones are available? Schwede6618:33, 12 April 2013 (UTC)
This template is now screwing up the formatting for languages it does not specifically support, such as Sorbian, at least on my browser: The words are all bold and significantly larger than the surrounding text, making it look rather ridiculous. Has something been changed recently that can be changed back? — kwami (talk) 21:21, 28 April 2013 (UTC)
All the ones at Sorbian languages, for example, except for the one token coded as German. The German looks perfect. Maybe it's specifying some ungainly font because it can't know which characters it needs to support? Could there maybe be a browser test so those of us with functional browsers don't need to suffer for the deficiencies of IE? Casual readers are not going to modify their WP CSS, but it would help me if there were some instruction for how to format 'none of the above' language encodings through the CSS. — kwami (talk) 22:40, 28 April 2013 (UTC)
I had a similar problem and you lead me to investigate it: the issue is with Firefox setting, not with the template. Namely: Tools/Options/Fonts/Advanced -> check that your "Sans serif" font preference for "Western", "Central European", "Cyrillic", "Greek" (and whichever other look mismatched) is the same for all. I had Calibri for one, Lucida for the other, so I fixed it now. No such user (talk) 09:39, 29 April 2013 (UTC)
I'm not sure if it's a Firefox version issue or a Windows/Mac issue, but for me (Mac OS 10.8, Firefox 22.0), the place to make the change is Firefox/Preferences.../Content/Fonts & Colors/Advanced... Then choose from the "Fonts for:" drop-down menu. Peter coxhead (talk) 08:41, 11 July 2013 (UTC)
Problem with "grc-Latn" setting
{{lang|grc-Latn|test text}} (which is quite widely used) renders as test text. The text will be in the font set in your browser as the default for Greek characters. However, this is wrong: the text is the Latin alphabet version of the Greek and should be in the font used for Latin characters, i.e. the normal font for English text. I'm not sure where this should be fixed, but until it is, I don't think this language option should be used. (If it's felt important to mark Latin alphabet transcriptions of Greek in some way, then surely "lat-grc" would be better?) Peter coxhead (talk) 08:52, 11 July 2013 (UTC)
ISO 639 name template
It looks like we could obviate the need for the big ugly switch statement that's currently in the template, add support for a lot more languages, and probably deprecate most of the Lang-xx templates by incorporating Template:ISO 639 name here. Thoughts? Ibadibam (talk) 23:02, 16 August 2013 (UTC)
Silly me. It is in there, as the default. But in that case, why do we have the switch at all? And why do we have Lang-xx when we could easily just create a flag for this template to show/hide the language name? Ibadibam (talk) 23:05, 16 August 2013 (UTC)
Edit request on 7 September 2013
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
{{ISO 639 name}} is used to resolve lang codes to names; the switch has been superfluous for some time. See the section above me and the demo on the testcases pages for proof it's working properly. — Lfdder (talk) 09:13, 8 September 2013 (UTC)
Quite possibly, although I am afraid I wouldn't know where my user style sheet is. A browser function? I am seeing this on all articles with Template:Infobox Scottish island e.g. Skye. Everything is in the same font save for 'Skið' and if you aren't then clearly I must have a setting awry somewhere. BenMacDui15:07, 21 September 2013 (UTC)
It might also be their browser's user style sheet. If it's something in your WP settings, logging out will confirm it; if it's something in your browser settings, viewing the page in another browser will. — Lfdder (talk) 17:36, 21 September 2013 (UTC)
OK - serves me right for having too much tech I don't understand! However, altho' I find it irritating, the main thing is that it's not a general problem that our esteemed readers are experiencing. BenMacDui17:40, 21 September 2013 (UTC)
I normally use Firefox. I logged out and the problem is still there. I launched Safari and, still logged out, the problem has gone. It doesn't reappear when I log in via Safari. So this means its a Firefox setting issue? BenMacDui17:57, 21 September 2013 (UTC)
Go in your Firefox prefs, Content tab, press on 'Advanced' under 'Fonts & Colors', then on the 'Fonts for' dropdown pick 'Other languages' and change the sans-serif font underneath to match Western's. — Lfdder (talk) 18:02, 21 September 2013 (UTC)
Would it be possible to have the option to switch of the automatic italic formatting in lang-xx? It is useful when translating words, but makes the template unusable when translating proper names, which according to MOS:Ety should not normally be italicised. Or perhaps there already is such a possibility and I just haven't found it? Justlettersandnumbers (talk) 15:24, 21 September 2013 (UTC)
OK, good workaround. Any chance we could, sooner or later, also have a fix? This is not an isolated problem: many words and phrases that need the template are also proper names. Justlettersandnumbers (talk) 22:02, 7 October 2013 (UTC)
Where can I see which fonts are used? I haven't been able to see anything but blank spaces for a lot of languages, such as Javanese, Yoruba, and Bavarian, ever since I switched on automatic font downloading to display Burmese (I have Burmese fonts installed, but MS7/FF does not support them). I've now switched it off, but am stuck with blank spaces for this template and a lot of section headings. — kwami (talk) 17:45, 1 May 2014 (UTC)
This template does nothing with fonts. Web fonts are handled by the Universal Language Selector extension. — lfdder18:41, 1 May 2014 (UTC)
Okay, but where can I see which fonts are selected by the ULS? I tried following the addresses listed here, but can't locate them. — kwami (talk) 18:43, 1 May 2014 (UTC)
Thanks, but that's Webfonts. I have those turned off, and am looking for the fonts that are forced by this template for Latin alphabets such as Bavarian and Yoruba. — kwami (talk) 20:57, 1 May 2014 (UTC)
None are. {{lang|yo|èdè Yorùbá}} produces:
<span lang="yo" xml:lang="yo">èdè Yorùbá</span>
and no CSS is associated with lang=yo. Whatever it is that's happening is happening on your end. — lfdder21:52, 1 May 2014 (UTC)
So odd that this started when I activated font downloading, and that it depends on the language specified in param 1. I'll keep looking. — kwami (talk) 01:34, 2 May 2014 (UTC)
I believe the language tag will dictate which font family your browser uses to render the page. It may be that, for your environment, the font families for those languages are set to include fonts that don't actually support the necessary characters. Try looking at other websites and see if you're having the same problem. Ibadibam (talk) 01:44, 2 May 2014 (UTC)
Thanks. We worked it out. I had the sans-serif font for "other languages" set to "sans-serif", and FF evidently doesn't understand what that means. Odd they'd have it as an option. Now, if I can just figure out why some (but not all) supplementary-plane character sets display as numbered boxes, when I have the appropriate fonts, but that has nothing to do with this page. — kwami (talk) 03:41, 2 May 2014 (UTC)
Likely missing something
I've used lang-XX before to indicate language (XX being the language code), however, when I tried to do it for Hmong it couldn't find the template (lang-hmm), how would I properly use the template for this language? — Preceding unsigned comment added by JMJimmy (talk • contribs) 20:50, 10 August 2014 (UTC)
That template has yet to be created; it's not difficult to do so. First off, the language code you've used (hmm) is for Central Mashan Hmong. Are you certain that's what you want to use? There are a number of codes for the various Hmongic languages. Ibadibam (talk) 21:56, 11 August 2014 (UTC)
Done: I've created {{Lang-hmn}}. If you ever need to create more like this, all these templates follow a certain pattern:
{{Language with name|hmn|Miao|''{{{1}}}''|links={{{links|yes}}}}}<noinclude>{{documentation|Template:Lang-x/doc}}</noinclude>
Be aware though that this pattern works only for languages for which the article (or a redirect) is titled X language. For something like Mashan Miao, I think it'd be
{{Language with name|hmm|{{#ifeq:{{{links|}}}|no|Mashan Miao|[[Mashan Miao]]}}|''{{{1}}}''|links=no}}<noinclude>{{documentation|Template:Lang-x/doc}}</noinclude>
Several {{Lang-xx-YY}} templates have been nomintead for deletion. Participants here may be interested in those TfDs, pro or con.
See also:
The nominator raised related issues in a number of other forums (most of these deal with {{lang-xx-YY}} templates in particular, while the one at WT:NOT is more general):
There are many more changes than just adding provision for |style=, which make it far more difficult to compare old with new. Why is it necessary to change the capitalisation of the templates? Why introduce a newline before the {{category handler}}, hidden inside comment markers? Why remove all the newlines within the {{category handler}}? Why was the comment at the bottom, concerning categories, removed? I don't see the necessity for any of these, especially not the newline removal. --Redrose64 (talk) 09:34, 17 September 2014 (UTC)
Taking your queries in order:
It isn't necessary to capitalise or lowercase template names, but I've noticed that the names of templates whose influence and/or effect tends to be relatively small or local – e.g. inline templates – tend to be lowercased, while the names of those whose influence and/or effect may be larger or not so local – e.g. boxes/bars or, as regards influence/reach, templates such as {{Category header}} – tend to be capitalised (sentence-cased);
Newlines between comment markers are one of the ways to present sections/segments/units of code as such...
...as can removing newlines within these sections/segments/units so that their own sections/segments/units remain, in turn, the next most readily identifiable;
Aren't people likely – or, in this case, able – to edit this template also already likely to be aware of how categories, interwikis and templates with /doc pages are organised..? (And, if not, soon would be..?)
The whitespace was clearer before you changed it. If you just want the size parameter added, I have no objections. — Martin (MSGJ · talk) 12:43, 18 September 2014 (UTC)
Yes, please – it's the parameter that'll be used. I am intrigued, though, that you find it easier to see and handle structure within
I've made the change. The main advantage of the first version is that every open brace is accompanied by an indent, so it is easier to ensure that you don't forget to close any braces. I guess it's just personal preference though, and what you've grown used to. I think your other suggestions are more esoteric. If you're writing a template, I don't think anyone would complain about the structure you choose; but I don't think you should be wary of changing templates wholesale over to your preferred structure. — Martin (MSGJ · talk) 08:17, 19 September 2014 (UTC)
Thanks. I'm reminded of a Richard Feynman story (I think) where "seeing" and "counting" things are contrasted (here, size/placing or number of indents), each with their own strengths and shortcomings. Sardanaphalus (talk) 10:44, 19 September 2014 (UTC)
lang in citation titles
In order to prevent a chunk of Arabic (etc.) in a citation title from interfering with the direction of following text, you need to use {{lang}} with the |nocat=true parameter, thus: {{lang|nocat=true|ar|.شبكة}}. As an example:
Please don't use this template in citation templates. The included markup renders in the title field of the COinS metadata:
Markup
Renders as
{{cite book |title=IANA Delegation Report for {{lang|nocat=true|ar|.شبكة}}}}
IANA Delegation Report for .شبكة.
'"`UNIQ--templatestyles-00000043-QINU`"'<cite class="citation book cs1">''IANA Delegation Report for <span title="Arabic-language text"><span lang="ar" dir="rtl">.شبكة</span></span>''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=IANA+Delegation+Report+for+%3Cspan+title%3D%22Arabic-language+text%22%3E%3Cspan+lang%3D%22ar%22+dir%3D%22rtl%22%3E.%D8%B4%D8%A8%D9%83%D8%A9%3C%2Fspan%3E%3C%2Fspan%3E&rfr_id=info%3Asid%2Fen.wikipedia.org%3ATemplate+talk%3ALang%2FArchive+2" class="Z3988"></span>
We are adding a new parameter to the templates:
Markup
Renders as
{{cite book/new |title=IANA Delegation Report for |script-title=ar:.شبكة}}
IANA Delegation Report for .شبكة.
script-title: Title in the original writing system where it is not appropriate to italicize (e.g. Arabic, Chinese, Hebrew, Japanese). Displays after title in upright font and is isolated from the surrounding text-direction settings so that right-to-left scripts render properly. The language may be set by prefixing the value with the ISO 639-1 two-character language code followed by a colon. Unrecognized codes are ignored and will display in the rendered citation. Example: |script-title=ar:العربية.
Because |script-title= is concatenated with the value held in |title= into meta-parameter Title, |title= is not required. Editor Scott's example cite might be written like this:
{{cite web/new|url=http://www.iana.org/reports/c.2.9.2.d/20131021-xn--ngbc5azd|accessdate=3 February 2014|script-title=IANA Delegation Report for شبكة |year=2013}}
Probably not the best way to use |script-title=. I left out the language identifier part of |script-title= because of the mix of English and Arabic.
What |script-title= does is isolate strongly directional text from not so strongly direction text. The English and the Arabic are strongly directional so they can coexist pretty comfortably; the digits are not. So, if the title was "IANA Delegation Report for شبكة 2013", then |script-title= is no help:
In Latin spelling and pronunciation and a few other articles, an epigraphic style (meaning based on the style of lettering used in inscriptions) of Latin text is used. That is, Latin words and graphemes are presented in small caps, with v and i used instead of i, j and u, v, and acute accent and the i longa (U+A7FE) used for long vowels in place of macrons. Epigraphic Latin needs two CSS properties: font-variant: small-caps; and font-family: 'fonts with i longa in them';. In addition, it should have the selector lang="lat".
Applying class=Unicode to epigraphic text is not a solution, because the fonts for that class in MediaWiki:Common.js are Arial Unicode MS and Lucida Sans Unicode, which do not contain the character i longa. See LATIN EPIGRAPHIC LETTER I LONGA (U+A7FE) Font Support on FileFormat.Info and {{Latin-epigr}} for a list of some fonts that do. To allow the character to display properly, we need a separate list of fonts for Latin epigraphic text.
Small caps are currently achieved using the {{smallcaps}}, but this simply adds inline CSS.
The most elegant solution would be to apply the language code and a class to the text — perhaps class="epigraphic" or class="epigr" — and add the properties to text selected by both the language code and the class using an external CSS file, like MediaWiki:Common.js. (A class is required because not all Latin text is in epigraphic style.) The second most elegant solution is to create a template using inline CSS, as I have already done with {{Latin-epigr}}. But using selectors and an external style sheet would reduce the amount of code.
Inclusion of left-to-right mark for right-to-left languages
As discussed here previously, the left-to-right mark (‎) can help browsers determine when to switch back to left-to-right rendering. I've noticed that it's being manually included at the end of RTL templates such as {{lang-ar}} and {{lang-ur}}. This seems to be an easy candidate for automatic inclusion in this template when the rtl argument is specified. Does anyone have any concerns over such an inclusion? — Quoth (talk) 16:38, 20 May 2015 (UTC)
Or we could just bypass this and wrap the content in <bdi>...</bdi>. This isolates text directionality from the outer text so it doesn't matter. — Preceding unsigned comment added by Gadget850 (talk • contribs) 23:38, 20 May 2015 (UTC)
Which means simply replace the <span>...</span> tags with <bdi>...</bdi> tags in {{lang}}. The attributes added to the <span> tag in {{lang}} are supported by <bdi>. The attribute dir= could probably go away. Module:Citation/CS1 wraps titles provided with |script-title= inside <bdi>...</bdi> tags but doesn't set the dir= attribute.
{{lang-ar}} includes ‎ in its output. That character is probably not needed with <bdi>...</bdi>.
I would go with <bdi>...</bdi>, this will permit elimination of ‎ which often cause problems with copypaste. The <bdi>...</bdi> element is inherently dir=auto so if the enclosed text is entirely of a single direction, no explicit dir= attribute should be needed either. --Redrose64 (talk) 07:07, 21 May 2015 (UTC)
<bdi>...</bdi> sounds like the ideal solution. Unfortunately I'm not so sure we should use it at the moment for compatibility reasons. It seems to have been introduced as part of HTML5, and might not be supported by a wide enough variety of browser versions.[2] We should thoroughly test this across browsers and platforms before implementing it.
Though even if that tag doesn't work, we might have better luck with <bdo>...</bdo>,[3] which was introduced in HTML4, and seems to currently have much broader support. I've yet to do any testing of either myself, and am going purely on what's currently written on the MDN, which is by no means up-to-date. — Quoth (talk) 09:41, 21 May 2015 (UTC)
When we were deciding on <bdi>...</bdi> for cs1|2 I remember looking at the compatibility issue. If I remember correctly, the incompatibilities for current browsers were in the less often used attributes. I don't remember where I discovered that and don't have the time now to rediscover it. If I wrote about it, that writing will be in the Help Talk: Citation Style 1 archives.
After some testing in Chrome and IE11 on Windows 8, <bdo>...</bdo> no longer seems applicable for this situation. Its intended use seems to be only to override unicode's bidi algorithm for a stretch of text (forcing LTR to RTL or vice versa), but without the text isolating property that <bdi>...</bdi> has. This means that numbers and other weak characters which follow still become entangled in the preceding text direction. And like Gadget850, I was unable to get <bdi>...</bdi> to have any effect in IE11 (with or without CSS shims and element attributes). Unfortunately the only method I found to work correctly in IE11 was using ‎.
Since that seems to currently be the de facto method anyway, and unless anyone has any other alternatives, I'd like to move ahead with consolidating its use from the individual RTL templates into this one as originally suggested. The benefit at least being that when browser support is finally broad enough to change to a better method, we won't have to update as many places. — Quoth (talk) 15:05, 24 May 2015 (UTC)
Protected edit request on 28 May 2015
This edit request to Template:Lang has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
In the René Lavand article I'd like to markup the sentence
The catchphrase he used to close several of his tricks is "No se puede hacer más lento" (Spanish for "it cannot be done any slower"), referencing the intentional slow pace at which he performs.
which currently uses no language template. Yet neither {{lang}} nor {{lang-es}} are optimal here. With {{lang}} I could easily tag the Spanish phrase but there's no way to attach the translation to the template. The markup would look like
The catchphrase he used to close several of his tricks is "{{lang|es|No se puede hacer más lento}}" (Spanish for "it cannot be done any slower"), referencing the intentional slow pace at which he performs.
which renders as
The catchphrase he used to close several of his tricks is "No se puede hacer más lento" (Spanish for "it cannot be done any slower"), referencing the intentional slow pace at which he performs.
The catchphrase he used to close several of his tricks is {{langx|es|"No se puede hacer más lento"|lit=it cannot be done any slower}}", referencing the intentional slow pace at which he performs.
renders rather awkwardly:
The catchphrase he used to close several of his tricks is Spanish: "No se puede hacer más lento", lit. 'it cannot be done any slower'", referencing the intentional slow pace at which he performs.
and would require a rewording.
Seems to me that a reverse version of {{lang-es}} is needed or {{lang}} needs an additional translation parameters. Ideally editors should be able to do something like
The catchphrase he used to close several of his tricks is "{{lang|es|No se puede hacer más lento|en|trans=it cannot be done any slower|translink=no}}", referencing the intentional slow pace at which he performs.
The purpose of this template is to indicate, via a code, that a span of text belongs to a particular language.
That's very nice, but if you follow the link you get a stub that discusses the issues of classification and coding and lists eight systems of assigning language codes, but gives no clue as to which system to use for Template:Lang. How in Hades is an editor to find the code to use for a language? Please {{Ping}} me to discuss. --Thnidu (talk) 03:42, 15 July 2015 (UTC)
Not a reasonable request, either. User agents that, e.g., pronounced the word properly in a screen reader depending on the language can only do this for one language. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 22:22, 14 February 2016 (UTC)
Sub-types of English
Notably en-AU, en-CA, en-GB, en-IE and en-US. Text tagged with these codes should go into something like:
Good work, Rich Farmbrough. We will actually need this at some point, as we start developing better articles on English and its dialects. They're actually remarkably bad at present. En.Wikipedians have largely neglected articles on our own language in the rush to write them about Pokemon characters and pornstars. The upcoming WikiProject English Language will attempt to address this, and will have use for these parameters, but it is not urgent at present. These options won't have any utility outside comparative-English topics, at least not from this particular template, and it'll have to be documented to discourage stupid WP:OWN use like trying to span the entire article with it. If people want to flag the general English language variety of the article, they can use one of the WP:ENGVAR-tagging templates for this (though these, too, need work; there's a divergent set of them for articles and talk pages, and there was an RfC at WT:MOS last year that concluded to consolidate them, and to stop them from generating HUGE SCREAMING BANNERS IN PEOPLES FACES for no reason; we'll get to it eventually). — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 22:32, 14 February 2016 (UTC)
Display bug in mainspace
This clean semantic markup fails for no apparent reason in mainspace:
[[World view|''{{lang|de|Weltanschauung}}'']]
[[Coverture|''{{lang|fr|Feme Covert}}'']]
It renders as:
[[World view|Weltanschauung]]
[[Coverture|Feme Covert]]
This does not happen outside mainspace, at least not on in the Talk: and Wikipedia: namespaces (the only two I tested); they both render these testcases exactly as intended:
Moving the italics outside does not fix it (they have nothing to do with the issue). Naming the parameters does not help, either. Nor does encoding the template's | characters with {{!}}.
This is a problem with {{lang}} in particular, in a certain namespace (or namespaces).
It is highly desirable for the [[Title|''{{lang|xx|content}}'']] markup to work as-is, for metadata cleanliness, since neither the italicization nor the linking to the English article are really part of the German or French content (in the examples). Doing things like "{{lang|de|''[[World view|Weltanschauung]]''}}" is semantically bletcherous, and thwarts our likely desire to re-use code from the initial linked instance elsewhere in the article, by copy-pasting the ''{{lang|de|Weltanschauung}}'' part without the link code. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 22:16, 14 February 2016 (UTC)
I bet it's because in mainspace the template output is:
In talk space, the category isn't part of the {{lang}} output. The category link within a wikilink confuses MediaWiki. I don't think that this is something that can be fixed in this template.
(edit conflict) Oh! Right. Forgot about the category thing. Hmm. It's actually undesirable that people will de-categorize just to link; that's a kluge. The solution is to add a |link= parameter, so that we'd do: ''{{lang|de|Weltanschauung|link=World view}}'' instead of [[World view|''{{lang|de|Weltanschauung|nocat=y}}'']] (FAIL) or ''{{lang|de|[[World view|Weltanschauung]]}}'' (bletcherous). Have the parameter apply the link around the content, with the cat. outside of it. While I would not get the in-page, copy-pasteable code portability I was initially looking for, this still would be an overall improvement, in multiple ways. Editors are actually quite amenable to using link-formatting templates ({{Cuegloss}} alone is used in over 700 articles; we have a category tree of them at Category:Internal link templates). After some bot-assisted cleanup (look for any instances of the template with nocat that are inside links), we'd have a much more accurate count of the articles in these language categories, too. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 08:33, 15 February 2016 (UTC)
Other-language wikilinks
Is it appropriate to use this template around a wikilink in the English-language wikipedia when the link text is in another language? For example, {{lang|fr|[[Académie française]]}}? Does the answer depend on whether the link contains characters/diacritics not normally seen in English, or if it does but it's nonetheless a phrase used in English (e.g. {{lang|fr|Fin de siècle}}), {{lang|de|Götterdämmerung}}) or whether the title has no special characters but contains words that wouldn't pass an English spell checker (e.g. Arc de Triomphe)? Colonies Chris (talk) 09:49, 26 February 2016 (UTC)
I’m no specialist, but I think the purpose of this template is just to mark the text as being from a certain language, so that computers can use it to apply a proper font, do spell-checking, etc. Concretely: whether a link or not, you can always use this template to indicate a phrase from a different language.Geke (talk) 11:54, 1 April 2016 (UTC)
Help with Arabic text breaking across lines
Resolved
I'm having difficulty getting right-to-left Arabic strings to break correctly at the end of a line. For instance, in my Sandbox there are examples (originally from the Saudi Arabia article) where "آل سعود" breaks incorrectly, with آل on the first line and سعود on the second. (If you can't replicate this in your browser change the size of the browser window to get آل سعود breaking at the end of a line. I've used template lang and lang and lang-ar and they all result in incorrect breaking. The template instructions in the Section "Writing direction" say:
To embed a string of right-to-left text (from languages like Arabic or Hebrew) within the usual left-to-right context, you should add the | parameter...
Shhhnotsoloud, for a short phrase such as that I suggest using {{nobreak}} to prevent the unwanted line break. Longer passages would probably best be formatted as quotes. I don't think the "incorrectness" is in the Arabic or in the lang template – it's a consequence of embedding the Arabic in left-to-right text: in all your examples, آل سعود breaks quite correctly, with the first word on the first line and the second word on the second; however, it looks very wrong because both those words are at the wrong ends of their respective lines. Justlettersandnumbers (talk) 13:38, 27 April 2016 (UTC)
Good tip, thank you Justlettersandnumbers (talk·contribs). And yes, you're right, it's my perception of "correctness" that's the problem. If my eyes are reading left-to-right and I hit arabic, I'll skip to the end of the arabic and start reading right-to-left, and a line break screws that up - "proper line breaking behaviour" is in fact what I see as incorrect Shhhnotsoloud (talk) 19:02, 27 April 2016 (UTC)
Which ISO 639 table to use?
I wanted to use this template to mark a word as Sanskrit, but I’m not sure if I should insert the 2-letter code or the 3-letter code?
The article contains a link to the ISO 639 table, but that redirects to a list of 5 different tables, flabbergasting the uninitiated!
So my plea is: please include an indication which table(s) should/may be used in this template, and maybe update the link accordingly. Thanks! Geke (talk) 11:54, 1 April 2016 (UTC)
I don't think it matters whether you use sa or san, but my browser (Firefox 45.0.1) seems to only recognise sa. --Redrose64 (talk) 21:50, 1 April 2016 (UTC)
I've rewritten the documentation to be a little clearer. When there are two equivalent ISO 639 tags, the shorter one should be used. – Quoth (talk) 12:11, 29 April 2016 (UTC)
Glitch with lang+poem
I just noticed a strange interaction with {{lang}} -- I don't know if it's user error, a known issue, or an unforeseen glitch. I'll leave it to those who know what they're doing to sort out what, if anything, to do about it.
Lines of verse are commonly indented with : (although other methods are also available). So...
<poem>
:Text
Text
:Text
</poem>
...renders as:
Text
Text Text
Applying {{lang}} within <poem>...</poem> breaks down in 2 different ways, depending upon how <poem>...</poem> is applied:
As I mentioned, other methods are available to indent verse, but I thought I'd point this out in case it's a relatively easy fix, or points to other possible problems with the template. Cheers. Phil wink (talk) 15:33, 14 September 2016 (UTC)
The {{lang}} template emits a <span>...</span> element, which in HTML terms, is an inline element, and must not be used to enclose block-type elements. The <poem>...</poem> extension emits a <div>...</div> element, which is block-type; similarly, the colon markup, often used as an indent feature, produces an association list - and lists are always block-type structures. Therefore, neither of these may be placed inside a <span>...</span>, and thus not inside a {{lang}}. Rather than trying to misuse the template, you can apply the lang=fr attribute directly to the <poem>...</poem> structure, as in
<poem lang=fr>
:Texte
Texte
:Texte
</poem>
which renders as
Texte
Texte Texte
If you examine the source of this, you will find that the outermost element is <div class="poem" xml:lang="fr" lang="fr">...</div>, so your problem lies not this template but in the way that it's used. --Redrose64 (talk) 21:31, 14 September 2016 (UTC)
Thanks. The case I'm currently running into is with {{Verse translation}}, which has {{#tag:poem}} built into it, so in the near-term <poem lang=fr> is not an option, unless I want to add that as a parameter -- but also, this value often contains both non-English text and a ref (which typically is in English), so I'm not certain painting the whole value with one language would be appropriate. But, just so I'm sure I understand you: (1) {{lang}} inside <poem>...</poem> is not a problem -- but : inside {{lang}}is a problem. So the most bone-headed fix is just to use another indentor. Right? and (2) Only the initial colon renders badly (at least for me): is it only this initial colon that makes trouble within {{lang}}, or must I avoid them at all line beginnings? Thanks again. Phil wink (talk) 22:22, 14 September 2016 (UTC)
I added a |lang= parameter to {{Verse translation}}. It appears to work correctly: applying the lang="" xml:lang="" attributes only to the foreign-language poem, not to the translation or attribution. Let me know if this is a satisfactory solution. — Eru·tuon22:33, 14 September 2016 (UTC)
I would like that to be the correct fix, but I'm not sure. As I said, it is often the case that within this value (the foreign-language text value) there is also a <ref>...</ref> at the end, which cannot be assumed to be in that same language. Moreover, this would disallow correct tagging for macaronic verse (which I haven't yet formatted, but does exist), and cases like:
{{Verse translation|italicsoff=y|
{{lang|ja|菊の香や}}{{pad|1.9em}} ''{{lang|ja-latn|Kiku no ka ya}}''
{{lang|ja|奈良には古き}} ''{{lang|ja-latn|Nara ni wa furuki}}''
{{lang|ja|仏達}}{{pad|3.8em}} ''{{lang|ja-latn|Hotoketachi}}''
|attr1=Bashō|
In the city of Nara
Fragrance of chrysanthemums;
Buddhas of yore.<ref>For an alternative translation, see De Bary et al. (2001: 368).</ref>}}
...which admittedly may be pushing the template, as it basically fakes 3 columns... but which is a real use case, rendering:
菊の香やKiku no ka ya 奈良には古きNara ni wa furuki 仏達Hotoketachi
In the city of Nara
Fragrance of chrysanthemums;
Buddhas of yore.[2]
—Bashō
References
^Jesus of history, Christ of faith by Thomas Zanzig 2000 ISBN0884895300 page 314
^For an alternative translation, see De Bary et al. (2001: 368).
The first case is a problem. The ref tag should not be wrapped in the HTML tag containing the lang="" xml:lang="" attributes. Perhaps a solution would be to always place the ref for the foreign-language text in the |attr1= parameter, after the name of the work? — Eru·tuon23:54, 14 September 2016 (UTC)
In the second case, you can simply omit the |lang= parameter for Japanese verse that is juxtaposed with its transliteration — or create a parameter that creates a table cell for the transliteration, and has a separate language parameter, maybe |trans-lang=? — Eru·tuon23:56, 14 September 2016 (UTC)
Detecting requests for languages that do not have templates
While looking at the latest Special:WantedTemplates report, I saw that there are a lot of transclusions of ISO 639 templates that do not exist. Specifically, 73 of the top 500 most-transcluded nonexistent templates are ISO 639 templates.
I'm going to play around with the sandbox to see if I can add a maintenance category to list pages calling templates that do not exist. That way, we could be alerted to (a) typos and errors and (b) templates that should exist but do not. – Jonesey95 (talk) 03:30, 29 September 2016 (UTC)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
See above. Please copy the sandbox into the live template to add a tracking category for unknown ISO 639 name templates. I have checked the testcases page and tested the sandbox in a live article. – Jonesey95 (talk) 16:31, 30 September 2016 (UTC)
Resolved
Won't fix
