BRFA for User:ZhBot

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/contribs 17: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}}.
--David Göthberg (talk) 04:10, 9 January 2010 (UTC)
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)

Example, please?—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 02:33, January 29, 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).
--David Göthberg (talk) 11:34, 29 January 2010 (UTC)
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

It has to be {{lang|fr|[[Pâtissier]]}}: Pâtissier

174.3.98.236 (talk) 04:53, 8 February 2010 (UTC)

As far as I see, [[Pâtissier|{{lang|fr|Pâtissier}}]] works. --bender235 (talk) 05:08, 8 February 2010 (UTC)

External font for special characters

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)

Anyone? --bender235 (talk) 05:09, 8 February 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, Arial Unicode MS, sans-serif; /* or some such */
        }
I guess that's something you'd need discuss at the Village pump. — OwenBlacker (Talk) 14:00, 13 February 2010 (UTC)

Change categorization method

{{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]]
}}

Thanks, --The Evil IP address (talk) 21:58, 2 June 2010 (UTC)

  Done Is there not an easier way of doing this, like adding something to the MP itself? HJ Mitchell | Penny for your thoughts? 01:40, 3 June 2010 (UTC)

{{editprotected}}

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)

Reverted. How do I fix it? HJ Mitchell | Penny for your thoughts? 01:51, 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.) Rich Farmbrough, 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.
--David Göthberg (talk) 16:24, 18 September 2011 (UTC)

Names of categories

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)

{{editprotected}}

This template was recently changed by User:Good Olfactory apparently because of decision made at Wikipedia:Categories for discussion/Log/2010 June 3#Category:Articles containing explicitly cited English language text. This change added a hyphen to each category name and now articles that use this template are moved from categories like Category:Articles containing Czech language text to non-existent categories like Category:Articles containing Czech-language text (note the hyphen). I think this change should be reverted until all the 240 subcategories of Category:Articles containing non-English-language text are created. Svick (talk) 23:26, 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. Rich Farmbrough, 01:58, 22 June 2010 (UTC).
I have untranscluded the edit protected template, given that the problem has been reverted.--Commander Keane (talk) 02:57, 22 June 2010 (UTC)
Thanks. Rich Farmbrough, 14:11, 22 June 2010 (UTC).

So what should we do now? Ignore the CfD and delete the new hyphenated category (and its one subcategory Category:Articles containing German-language text that someone created)? Reopen the CfD? Or something else? Svick (talk) 15:52, 22 June 2010 (UTC)

Nevermind, there is a discussion at Wikipedia:Categories for discussion/Speedy. Svick (talk) 15:57, 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)
  • CFD close amended. This is the easy way out. Good Ol’factory (talk) 23:59, 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

I have created {{Cleanup-lang}}, for articles with non-English text, which should use {{Lang}} but do not yet do so. Suggestions for improvements would be welcome. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 21:38, 28 August 2011 (UTC)

Transclusions of 'missing' ISO 639 templates

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 general interest, I've added a toolserver report that shows these transclusions and the pages on which they occur. - TB (talk) 23:46, 7 December 2010 (UTC)

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

  1. "Use ISO 639 language codes" is confusing as it leads to a disambiguation page. Can this be disambiguated, or are all entries relevant?
  2. 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?

--Pgallert (talk) 18:40, 7 October 2011 (UTC)

CSS class per language

  Resolved

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 !

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.

--Nnemo (talk) 12:16, 1 November 2011 (UTC)

  Done I have added categorisation optout, so you can now write {{lang|nl|Leopoldstad|nocat=true}} to disable the categories. Happymelon 14:50, 24 May 2012 (UTC)
Good news ! But I don't find this in the documentation. Can you add it, please ? --Nnemo (talk) 00:16, 25 May 2012 (UTC)
WP:SOFIXIT. The documentation page is not protected. Happymelon 08:12, 25 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)
There you go. If this is not the correct wording or placement, I'll leave it for those directly involved with its implementation to fix. --Redrose64 (talk) 09:34, 26 May 2012 (UTC)
Thanks Redrose! Happymelon 14:37, 26 May 2012 (UTC)

Rendering problem

This wikitext:

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]
Whether {{lang}} should automatically insert the LRM character is a question for wider discussion. HTH. Anomie 12:06, 28 February 2012 (UTC)

Indicating writing script

This template's documentation section on Indicating writing script deals with templates of the type {{lang-ru}} rather than {{lang}}. Can we find a better home for it, then link to that? Or replace the examples with some using this template? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:46, 28 February 2012 (UTC)

Yes, zh has suitable varieties. Rich Farmbrough, 15:47, 21 March 2012 (UTC).


Span class

Could we add a span class to this template, so that it (foreign language text) can be formatted by the user?  Liam987  16:47, 5 May 2012 (UTC)

See also #CSS class and/or style parameters. Can we get an agreement of exactly what is needed here, and some use cases? Chris Cunningham (user:thumperward) (talk) 09:45, 9 May 2012 (UTC)
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)

When you've worked out how best to do this, please put the code in the /sandbox and reactivate the request. — Martin (MSGJ · talk) 17:32, 29 May 2012 (UTC)

Small but stumble-provoking grammar

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

Please see my proposal at Template talk:Lang-en#This template could supply sorely missed language support functionality on Wikipedia. __meco (talk) 11:26, 8 September 2012 (UTC)

Fraternity Letters?

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)

Proposal: Protect Chinese from Italics

In Wikipedia:Manual of Style/Text formatting, it is noted that Chinese characters shouldn't be italicized. However in templates such as template:Infobox book, the field of original title (where Chinese is likely to appear) still use Italics. I've made suggestions to change that template, but I wonder if the lang template can protect Chinese from Italics?114.25.189.86 (talk) 03:45, 13 September 2012 (UTC)

  • Refer to MoS China. It appears that the answer may be yes. You could try it. LittleBen (talk) 03:53, 13 September 2012 (UTC)

xml:lang is now redundant

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:

Markup Renders as
<span xml:lang="en">text1</span>

<span lang="en">text2</span>

text1

text2

--— Gadget850 (Ed) talk 19:02, 9 January 2013 (UTC)

  Done Anomie 03:07, 10 January 2013 (UTC)

Edit request on 25 February 2013

Add |zh-cn = simplified Chinese to the template per Wikipedia:Categories_for_discussion/Log/2013_February_10#Chinese_text

Armbrust The Homunculus 21:37, 25 February 2013 (UTC)

  DoneMr. Stradivarius ♪ talk ♪ 09:31, 2 March 2013 (UTC)

Bug-fix / Edit request on 12 March 2013

There seems to be a bug in the template that is not permitting it to correctly parse the following code in main space:

"approaching from the opposite side of the Krbava Polje (Croatian: Polje or karst field)"
Here is the code: "approaching from the opposite side of the [[Krbava|Krbava {{lang|hr|Polje}}]] ({{lang-hr|[[Polje]]}} or [[karst|karst field]])"

This code seems to parse correctly in user space, talk space, and usertalk space.

Thank you very much for your help! - ʈucoxn\talk 01:51, 12 March 2013 (UTC)

So far as I can see this is an unavoidable issue with the use of the category code. If piped text contains a category, it won't be linked. See Template:Lang/testcases#Category problem for a simple test case. Disabling for now as this template can't be edited to fix the problem: it may need to be raised in Bugzilla. Chris Cunningham (user:thumperward) (talk) 13:33, 18 March 2013 (UTC)
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)
The links aren't nested: the parser figures out there's a category link and sticks it at the bottom of the page. It's not an inline link. Chris Cunningham (user:thumperward) (talk) 08:37, 19 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\talk 10:47, 19 March 2013 (UTC)
Maybe I'm missing something, but why not just do {{lang|hr|[[Krbava|Krbava Polje]]}} instead (putting the link in the {{lang}} rather than the {{lang}} in the link)? Chris Cunningham (user:thumperward) (talk) 15:36, 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\talk 09: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\talk 04: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]]

Hopefully one of these methods will work for you, because the template can't be fixed, I'm afraid. — Mr. Stradivarius ♪ talk ♪ 05:47, 28 March 2013 (UTC)

Mr. Stradivarius, thank you very much for explaining some creative work-arounds for this problem! - ʈucoxn\talk 21:58, 1 April 2013 (UTC)

How much is too much?

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)

For proper nouns that don't have a common Anglicised form this shouldn't be used at all. There are very few cases where it is appropriately applied to a person's name. Chris Cunningham (user:thumperward) (talk) 10:53, 19 March 2013 (UTC)

Versions of this template for specific languages

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? Schwede66 18:33, 12 April 2013 (UTC)

Latin

"Latin" is getting formatted as a link to Latin language, which is a redirect to Latin. Curly Turkey (gobble) 04:49, 1 May 2013 (UTC)

Screwing up formatting

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)

That page looks fine to me. Perhaps you could pull out some specific template usages that seem wrong to you? Dragons flight (talk) 21:31, 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)
Ah, thanks. That took care of it! — kwami (talk) 09:46, 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

Import sandbox to get rid of the unnecessary switch. — Lfdder (talk) 00:05, 7 September 2013 (UTC)

Uh...[1] doesn't look right to me... Legoktm (talk) 00:49, 8 September 2013 (UTC)
Which part? — Lfdder (talk) 00:50, 8 September 2013 (UTC)
What happened to all the other languages? I'm probably just missing something... Legoktm (talk) 02:52, 8 September 2013 (UTC)
{{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)
Its not correctly categorising {{lang/sandbox|zh-cn|foo}} which should be placed in Category:Articles containing simplified Chinese-language text. You need to test this in the main article namespace as the {{category handler}} is only categorising that namespace.--User:Salix alba (talk): 10:34, 8 September 2013 (UTC)
zh-cn is invalid. Regardless, it can easily be remedied by creating modifying {{ISO 639 name zh-cn}}. — Lfdder (talk) 10:39, 8 September 2013 (UTC)

Sooooooo? — Lfdder (talk) 12:14, 10 September 2013 (UTC)

  Done. Sorry for the wait. — Mr. Stradivarius ♪ talk ♪ 13:38, 10 September 2013 (UTC)
Thanks. You must be the only person who pays attention to the protected edit queue. — Lfdder (talk) 13:46, 10 September 2013 (UTC)

Lang-non font

Does anyone know why or how Template:Lang-non template produces a different font to Template:Lang-gd? The code looks the same to me. Ben MacDui 12:55, 21 September 2013 (UTC)

The font looks the same to me. Could it be a rule in your user style sheet? — Lfdder (talk) 13:07, 21 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. Ben MacDui 15:07, 21 September 2013 (UTC)
You don't have a user style sheet. If you did, it would be at either Special:MyPage/common.css or Special:MyPage/skin.css. However you do have some user script pages, at Special:MyPage/common.js, Special:MyPage/monobook.js and Special:MyPage/vector.js - something in those might be interfering. --Redrose64 (talk) 17:01, 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. Ben MacDui 17: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? Ben MacDui 17: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)
Hey presto, a magic fix. Many thanks indeed - its been bugging me for weeks. Ben MacDui 20:10, 21 September 2013 (UTC)

Italics

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)

There's no switch in lang-xx, but you can place the text inside inside {{noitalics}}, e.g. {{lang-fr|{{noitalics|french stuff}}}}French: french stuff. — Lfdder (talk) 17:33, 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)
We'd have to modify each and every (Latin script) lang-x template (there's about 200 or 300 of them). — Lfdder (talk) 22:16, 7 October 2013 (UTC)

Which fonts are used?

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. — lfdder 18: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)
mw:Universal_Language_Selector/WebFonts#Table_of_languages_and_default_fontslfdder 19:24, 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. — lfdder 21: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 (talkcontribs) 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)
I guess the wiki page I was looking at was out of date... hmn (the macrolanguage) is what I'd need JMJimmy (talk) 09:40, 12 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>

...but that leaves an irregularity with the documentation template I'm not sure how to resolve. Ibadibam (talk) 20:23, 12 August 2014 (UTC)

Lang-xx-YY TfDs

  FYI
 – Pointer to relevant discussions elsewhere

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

 — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  07:16, 19 August 2014 (UTC)

size parameter

Hello – For the sake of scripts such as Arabic that can be tricky to read at default font-size, I've added a size parameter to the sandbox version here (current as of this message) and some tests to Template:Lang/testcases#Sandbox. Would there be any objection if a request was made to replace the main version with this one? Sardanaphalus (talk) 12:09, 17 August 2014 (UTC)

Protected edit request on 17 September 2014

Per the above, please replace the current code with this version in the sandbox. Sardanaphalus (talk) 00:07, 17 September 2014 (UTC)

  Not done: please establish a consensus for this alteration before using the {{edit protected}} template. --Redrose64 (talk) 06:53, 17 September 2014 (UTC)
Does no response not count as a "don't mind" consensus? Or is, in fact, the requirement to try to find objection – a WP:BEANS variation – ? Sardanaphalus (talk) 09:05, 17 September 2014 (UTC)
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..?)
Regards, Sardanaphalus (talk) 20:11, 17 September 2014 (UTC)
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
<span>{{
| = [[ {{
  || = 
  | = {{
    |{{}}
    |
    }}
  }} ]]
| = 
}}
than within
<span><!--
-->{{
    | = [[ {{ ||= |={{ |{{}} | }} }} ]]
    | = 
   }}
or, giving the #switch its own structure level, within
<span><!--
-->{{
    | = [[ {{
            || = 
            | = {{ |{{}} | }}
           }} <!--
     -->]]
    | = 
   }}
Regards, Sardanaphalus (talk) 20:00, 18 September 2014 (UTC)
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:

With lang
"IANA Delegation Report for .شبكة". 2013. Retrieved 3 February 2014. {{cite web}}: Invalid |ref=harv (help)
Without lang
"IANA Delegation Report for .شبكة". 2013. Retrieved 3 February 2014. {{cite web}}: Invalid |ref=harv (help)

I've clarified this in the documentation. — Scott talk 11:42, 18 March 2014 (UTC)

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-0000003E-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:العربية.

This should be going live soon. --  Gadget850 talk 12:44, 3 October 2014 (UTC)

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}}
which gives:
IANA Delegation Report for شبكة. 2013. Retrieved 3 February 2014. {{cite web}}: Invalid |script-title=: missing prefix (help)
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:
IANA Delegation Report for شبكة 2013. 2013. Retrieved 3 February 2014. {{cite web}}: Invalid |script-title=: missing prefix (help)
This is a new parameter. There will be a learning curve and surely there will be opportunity to improve its functionality.
Trappist the monk (talk) 13:55, 3 October 2014 (UTC)

Technical issue at another language template

Please see Template talk:Engvar#Use standard language codes; could use some extra brains on that. {{Engvar}} didn't even have a talk page until just now, so virtually no one is watching it.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  06:52, 7 November 2014 (UTC)

Epigraphic style of Latin

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.

Is this proposal possible, or should I settle with a template using inline CSS? — Eru·tuon 21:11, 13 December 2014 (UTC)

Inclusion of left-to-right mark for right-to-left languages

As discussed here previously, the left-to-right mark (&lrm;) 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)

|rtl= does not seem to be documented. -- Gadget850 talk 22:07, 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 (talkcontribs) 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 &lrm; in its output. That character is probably not needed with <bdi>...</bdi>.
Trappist the monk (talk) 00:00, 21 May 2015 (UTC)
Now in sandbox. -- Gadget850 talk 01:00, 21 May 2015 (UTC)
I would go with <bdi>...</bdi>, this will permit elimination of &lrm; 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)
A quick test shows that IE11 does not support <bdi>...</bdi> but does support <bdo>...</bdo>. -- Gadget850 talk 11:18, 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.
Trappist the monk (talk) 11:53, 21 May 2015 (UTC)
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 &lrm;.
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

Please replace the current code with this revision in the sandbox per the above discussion. An example of what this fixes has been added to the test cases page. — Quoth (talk) 08:49, 28 May 2015 (UTC)

  DoneMr. Stradivarius ♪ talk ♪ 10:27, 28 May 2015 (UTC)

Cleanup

-- Gadget850 talk 15:43, 28 May 2015 (UTC)

foreign quote followed by translation

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.

And {{lang-es}} markup

The catchphrase he used to close several of his tricks is {{lang-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.

which would render as exactly as the current text. How would you handle this case? Jason Quinn (talk) 11:22, 19 June 2015 (UTC)

Which codes here?

  Resolved

The doc begins

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)

@Thnidu: Under Template:Lang#Syntax and usage it says
{{lang |ISO 639 language code |text}}
The ISO 639 code is usually a two- or three-letter abbreviation, in lowercase, of the language's name.
So I altered the link to match the one used here. --Redrose64 (talk) 10:35, 15 July 2015 (UTC)
@Redrose64: Thank you! --Thnidu (talk) 14:49, 15 July 2015 (UTC)

Balinese unsupported yet?

  Resolved

It seems there is no Balinese language ID for the Lang- template yet. Hippo99 (talk) 09:14, 27 October 2015 (UTC)

Why do you say that? The ISO 639-2 code is "ban", and this template is independent of language code. --Redrose64 (talk) 09:24, 27 October 2015 (UTC)
I believe he was talking about the lang-x templates. I've now created {{lang-ban}}. — Quoth (talk) 09:47, 28 October 2015 (UTC)

Multiple language codes

 
  Won't fix
 – Not possible.

Is it legal to input more than a single language code? I have some text which can be either Spanish or Portuguese: Hospital de Clínicas. Thanks. fgnievinski (talk) 02:43, 23 January 2016 (UTC)

No. --Redrose64 (talk) 12:08, 23 January 2016 (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:

which should be subcategories of Category:Articles containing explicitly cited English-language text.

The code I have in the sandbox should achieve this.

Moreover any types which don't have a category will be categorised into Category:Articles containing explicitly cited variant English-language text. This means uses of en- codes which don't have a category - or even an ISO 639 template - will not be categorised as non-English text.

I also added a "|" sign after {{{2 for cosmetic purposes.

I also switched from {{Category handler}} to {{Main other}} for efficiency. This means discarding the "nocat" variable, which I don't see as a loss.

Comments?

All the best: Rich Farmbrough, 19:22, 15 November 2015 (UTC).

No thanks. It would add far too much cruft. --Redrose64 (talk) 10:35, 17 November 2015 (UTC)
  • 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 {{!}}.

You can do:

  • [[Variable|{{var|X}}]]

and it will properly render as:

including in mainspace.

It's not the presence of parameters (named or unnamed) causing the problem. Using:

  • [[Variable|{{var|X|2=junk_data}}]]

will still produce output of

in mainspace.

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:
[[World view|''<span lang="de" >Weltanschauung</span>[[Category:Articles containing German-language text]]'']]
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.
Trappist the monk (talk) 22:36, 14 February 2016 (UTC)
  • ''[[World view|{{lang|de|Weltanschauung}}]]''
  • ''[[Coverture|{{lang|fr|Feme Covert}}]]''

Renders as:

This is reasonable I think. All the best: Rich Farmbrough, 22:44, 14 February 2016 (UTC).

Not true. In mainspace those render as
  • [[World view|Weltanschauung]]
  • [[Coverture|Feme Covert]]
Trappist the monk (talk) 22:56, 14 February 2016 (UTC)

(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...

but I don't understand what that means. Thanks for any help Shhhnotsoloud (talk) 10:44, 27 April 2016 (UTC)

It's a typo, should say "add the |rtl=yes parameter". --Redrose64 (talk) 11:34, 27 April 2016 (UTC)
Thank you Redrose64 (talk · contribs), and for your additions to my Sandbox. Using that parameter doesn't work either! Shhhnotsoloud (talk) 12:32, 27 April 2016 (UTC)
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:

<poem>
{{lang|fr|:Texte
Texte
:Texte}}
</poem>

...renders as:

[undefined] Error: {{Lang}}: no text (help)

And

{{#tag:poem|
{{lang|fr|:Texte
Texte
:Texte}} }}

..renders as:

:Texte Texte :Texte

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·tuon 22: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:

References

  1. ^ Jesus of history, Christ of faith by Thomas Zanzig 2000 ISBN 0884895300 page 314
  2. ^ For an alternative translation, see De Bary et al. (2001: 368).
I just suspect that painting the entire value with 1 language will be too restrictive for some legitimate uses. Thoughts? Phil wink (talk) 23:02, 14 September 2016 (UTC)
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·tuon 23: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·tuon 23: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)

I think I have edited the sandbox correctly to add this error category. It applies only if the language template does not exist, and it applies only in article space. See This version of Reconquista, which was calling {{lang|sp}} instead of {{lang|es}} for Spanish-language words. Using the sandbox version of the template adds Category:Articles containing unknown ISO 639 language template to the category list. If this category is created, I intend it to be a hidden category. – Jonesey95 (talk) 03:48, 29 September 2016 (UTC)

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)

And it's done. Jo-Jo Eumerus (talk, contributions) 09:01, 2 October 2016 (UTC)
Thanks, Jo-Jo Eumerus. – Jonesey95 (talk) 13:28, 2 October 2016 (UTC)