Template talk:Lang/Archive 11

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.

Sometimes I come across an article about an obscure language that has a big maintenance template at the top requesting that non-English text in the article be put into {{lang}}. Now, is this really necessary? I know that in principle it's good to have rigorous semantic markup, but I'm struggling to see the practical benefits here. Template:Lang#Rationale lists a number of reasons why adding the template is a good idea, but they mostly seem to presuppose we're talking about a language with well-developed computing resources. Are there any screen readers for the Tape language of Vanuatu (which is spoken by 15 people)? Are there spell-checkers for the Tsez language (spoken in a few villages and never written)? Will readers of Karu language have any genuine difficulty figuring out that the unpronounceable strings in italics quoted here and there are in fact words in Karu?

And how does that weigh against the costs of using the template? Implementing it takes editorial labour, while having it there clutters the wiki source, and adds hurdles in the way of those using the Visual editor. What benefits are there to counterbalance those costs? – Uanfala (talk) 21:11, 31 March 2021 (UTC)

@Uanfala: I've added tags on those articles because they show up on reports of those with the most possibly misspelled words. Language-tagging non-English words for obscure languages makes it feasible to spell-check and grammar-check the English text in those articles. It also lets bots know which language to spell-check those words against, so they can be corrected or added to English Wiktionary. Presumably eventually Wiktionary will have pronunciations for all such words, and smart screen readers should be able to use that data to render them correctly into audio. -- Beland (talk) 00:07, 1 April 2021 (UTC)

I have originally posted this a while ago in Wikipedia talk:WikiProject Languages:

It is nice that language tags assists spellcheckers in their semi-automatized cleanup task, but: who assists us in manually adding these tags for the benefit of an automatized process? Whenever I see this {{cleanup lang}}-tag added, I feel I'd rather check the spelling manually once in a while rather than to bloat the code, which makes the pages harder to edit. –Austronesier (talk) 12:52, 1 April 2021 (UTC)

Well, if there were a tool that allowed me to simply highlight a string and then convert it into lang-tagged text with one click (with the tagged language set only once until changed)... –Austronesier (talk) 12:59, 1 April 2021 (UTC)

Not quite one click (you have to manually type the language code) but you might modify one or more of your CharInsert menus by adding this to User:Austronesier/common.js (or whatever skin it is that you use):

// Add custom CharInsert entries
window.charinsertCustom = {
 "Wiki markup": ' Lang: {\{lang||+}}  {\{lang-|+}}  {\{transl||+}}',
};

This example modifies the Wiki markup CharInsert menu.

If that is not sufficient, perhaps someone at WP:User scripts/Requests can write something for you. If they do, mention it here.

—Trappist the monk (talk) 14:03, 1 April 2021 (UTC)

Hello everybody, I have a question. I know that a registred user can receive alerts whenever a particular page is modified, even template pages like this, just by adding that page to his/her watchlist. Talking about templates, is it also possible to receive alerts whevever a particular template, included inside a page, is modified? To make an example, if I want to be notified when the template "Lang-el" included in any page is edited what shall I do? Is this possible or, to do such a thing, must a user add to his/her watchlist every page which includes that template? Contojorges (talk) 20:15, 5 April 2021 (UTC)

You have to watchlist every page that you want to monitor. If you are careful, there are ways to manually add a list of pages (copied from a category page, for example) to your Watchlist. – Jonesey95 (talk) 00:40, 6 April 2021 (UTC)

AFAICT Contojorges is asking for a way to monitor only changes to transclusions of a template, not all changes to pages with the template. Nardog (talk) 01:06, 6 April 2021 (UTC)

Correct, that's what I was asking. Contojorges (talk) 07:56, 6 April 2021 (UTC)

I don't believe it's possible to track edits to instances of a template. But there's one, much more limited thing that you can do – get alerted if the template is added to an article it hasn't been on before. If you watchlist Category:Articles containing Greek-language text (which is mostly populated by Template:lang-el), and if you have unselected "Hide categorization of pages" from your preferences, then you'll see it in your watchlist as articles get added or removed from the category. – Uanfala (talk) 12:42, 6 April 2021 (UTC)

That's good, I'll try following your instructions to begin with, thanks. In the meantime I'm waiting anyway for further comments either to confirm that there's no way to be notified when a template "Lang" is modified inside a page or to know that's possible in some way. Contojorges (talk) 19:26, 6 April 2021 (UTC)

The categories for Nepal Bhasa were accepted for speedy renaming to Newar, see CFDS (permalink).

Category:Articles containing Classical Newar-language text was apparently incorrect so I moved this again to Category:Articles containing Classical Newari-language text per Classical Newari.

I tried to update Module:Lang/data accordingly, but this has not gone smoothly, and Category:Articles containing Nepal Bhasa-language text is currently populated again – perhaps temporarily. Category:Articles containing Newar-language text also shows an error message – ah, it's gone now. @Trappist the monk: or others, please check again. – Fayenatic London 14:18, 1 May 2021 (UTC)

I reverted your first edit because you disregarded the note at Line 159. As part of my revert, I added new at line 146 so that Module:Lang uses the en.wiki article name instead of 'Nepal Bhasa' (from ~/data) or 'Newari' (from Module:Language/data/iana languages). I did not add a new line for nwc because 'Classical Newari' is the preferred name in Module:Language/data/iana languages and because that name matches the en.wiki article title.

These changes did nothing because those lines had been commented-out and again you disregarded the note at line 160. So I reverted.

Again, disregarding line 160, you made this edit and this edit which also do nothing because those lines were commented out.

And then you uncommented lines 202 and 204. Those changes broke the change that I made with my first revert because Module:Lang used 'Newari' to create Category:Articles containing Newari-language text. With this edit, you recommented line 204 to get the correct category name.

The module was doing that after my first revert of your edits so I am going to revert you again to restore lines 202 and 204 to their proper state.

—Trappist the monk (talk) 14:47, 1 May 2021 (UTC)

@Trappist the monk: Thanks very much for your help. I confirm that it is all working properly now.

A few things were coinciding there to confuse me, chief of which is the current long delay in propagating changes to templates. (I have just forced the rest of the category updates using null edits, but these were not sufficient to update Classical Newari or remove the error message from the category page at that time, presumably due to the chain of nested templates/modules.) Your edit summary on your first revert did not mention that you had also added a line, so at that point I thought I still needed to make a fix. You referred me to the comments but I misread that as pertaining to what was at the end of the lines in the table, rather than looking for explanatory comments at the head of the table.

The starting point of the difficulty, however, is that I could not find documentation explaining what to update where in order to update the categories generated by {{lang-new}} or the ISO parameters in {{Infobox language}}. It would be helpful if explanations could be added or made easier to find.

As for the category link from the infobox on Classical Newari, I am still not sure I understand – did it eventually resolve itself without any action being needed on templates or data pages, because it found the matching language name already listed at Module:Language/data/iana languages ? – Fayenatic London 10:14, 3 May 2021 (UTC)

In Himni_i_Flamurit#Lyrics_and_translation I tried to use {{lang|sq-fonipa}} for the IPA version of the anthem, but the template does not recognize the variant fonipa for Albanian: [rɛθ̟ fla.mu.ɾit tə pəɾ.baʃ.ku.aɾ]

I also tried to tag it as just {{lang|sq}}:

It seems that <poem>, lang and | interact uglyly. --Error (talk) 20:45, 9 May 2021 (UTC)

There are templates specifically designed for IPA, shouldn't you be using one of them?

The <poem>...</poem> tag-wrapped text goes inside {{lang}}; not the other way round:

{{lang|sq|<poem>[rɛθ̟ fla.mu.ɾit tə pəɾ.baʃ.ku.aɾ]
[mɛ ɲə də.ʃiɾ ɛ ɲə c͡çə.ɫim |]
[tə ɟ͡ʝiθ̟ a.tij du.kɛ u bɛ.tu.aɾ]
[tə li.ð̟im bɛ.sən pəɾ ʃpə.tim ‖]
𝄆 [pɾɛj luf.tɛ vɛt͡ʃ a.i laɾ.gɔ.hɛt]
[c͡çə əʃ.tə lin.duɾ tɾa.ð̟ə.tɔɾ |]
[kuʃ əʃ.tə bu.rə nuk fɾik.sɔ.hɛt |]
[pɔɾ vdɛs | pɔɾ vdɛs si ɲə dəʃ.mɔɾ ‖] 𝄇{{efn|name=repeat}}

[nə dɔ.ɾə aɾ.mət dɔ ti mbaj.mə |]
[tə mbɾɔj.mə at.ð̟ɛ.un nə t͡ʃdɔ kənd |]</poem>}}

—Trappist the monk (talk) 13:31, 10 May 2021 (UTC)

{{IPA|sq|<poem>[rɛθ̟ fla.mu.ɾit tə pəɾ.baʃ.ku.aɾ]
[mɛ ɲə də.ʃiɾ ɛ ɲə c͡çə.ɫim |]
[tə ɟ͡ʝiθ̟ a.tij du.kɛ u bɛ.tu.aɾ]
[tə li.ð̟im bɛ.sən pəɾ ʃpə.tim ‖]
𝄆 [pɾɛj luf.tɛ vɛt͡ʃ a.i laɾ.gɔ.hɛt]
[c͡çə əʃ.tə lin.duɾ tɾa.ð̟ə.tɔɾ |]
[kuʃ əʃ.tə bu.rə nuk fɾik.sɔ.hɛt |]
[pɔɾ vdɛs | pɔɾ vdɛs si ɲə dəʃ.mɔɾ ‖] 𝄇{{efn|name=repeat}}

[nə dɔ.ɾə aɾ.mət dɔ ti mbaj.mə |]
[tə mbɾɔj.mə at.ð̟ɛ.un nə t͡ʃdɔ kənd |]</poem>
| }}

doesn't work after efn

[

[rɛθ̟ fla.mu.ɾit tə pəɾ.baʃ.ku.aɾ]
[mɛ ɲə də.ʃiɾ ɛ ɲə c͡çə.ɫim |]
[tə ɟ͡ʝiθ̟ a.tij du.kɛ u bɛ.tu.aɾ]
[tə li.ð̟im bɛ.sən pəɾ ʃpə.tim ‖]
𝄆 [pɾɛj luf.tɛ vɛt͡ʃ a.i laɾ.gɔ.hɛt]
[c͡çə əʃ.tə lin.duɾ tɾa.ð̟ə.tɔɾ |]
[kuʃ əʃ.tə bu.rə nuk fɾik.sɔ.hɛt |]
[pɔɾ vdɛs | pɔɾ vdɛs si ɲə dəʃ.mɔɾ ‖] 𝄇[a]

[nə dɔ.ɾə aɾ.mət dɔ ti mbaj.mə |]
[tə mbɾɔj.mə at.ð̟ɛ.un nə t͡ʃdɔ kənd |]

]

--Error (talk) 14:55, 10 May 2021 (UTC)

{{lang|sq-fonipa|[rɛθ̟ fla.mu.ɾit tə pəɾ.baʃ.ku.aɾ]}} → [rɛθ̟ fla.mu.ɾit tə pəɾ.baʃ.ku.aɾ]

—Trappist the monk (talk) 17:34, 11 May 2021 (UTC)

Sometimes I come across this template and the amount of bold text is pretty jarring. Thoughts on making it less cluttering?

Current:

This article or section should specify the language of its non-English content, using {{lang}} or {{transl}} (or {{IPA}} or similar for phoenetic transcriptions), with an appropriate ISO 639 code. See why. (March 2021)

Proposed:

This article or section should specify the language of its non-English content, using {{lang}} or {{transl}} (or {{IPA}} or similar for phonetic transcriptions), with an appropriate ISO 639 code. See why. (March 2021)

Right now it has more bold than the needs references template, which in my opinion is more important to most readers. Also not sure why phonetic is spelled "phoenetic."

Cheers, Fredlesaltique (talk) 04:28, 13 May 2021 (UTC)

The talk page you are looking for is Template talk:Cleanup lang. That template is where the above text appears. – Jonesey95 (talk) 05:00, 13 May 2021 (UTC)

@Jonesey95: Thanks! Fredlesaltique (talk) 05:20, 13 May 2021 (UTC)

I was trying to tag text in Murcian Spanish with {{lang|es-u-sd-esmc}} like [la casa] Error: {{Lang}}: unrecognized language tag: es-u-sd-esmc (help) but it fails. Since the Murcia Region and the Murcia (province) are coterminous, I tried {{lang|es-u-sd-esmu}}: [la casa] Error: {{Lang}}: unrecognized language tag: es-u-sd-esmu (help), but it also fails. Does Lang not support the -u-sd extension of IETF language tags? --Error (talk) 22:43, 22 May 2021 (UTC)

This template does not work reliably for references formatted with the {{cite}} templates. I've noticed the problem when an URL is provided and the cite template is embedded in a footnote. For example,^[1]

(That displays just fine here, but not in article space.)

— kwami (talk) 08:37, 29 May 2021 (UTC)

At the top of the template documentation page is a notice box with this image:

Using any of {{lang}} or {{lang-??}} templates inside of cs1|2 templates corrupts the citation's metadata. When your example is rendered on this page, the cs1|2 title metadata looks like this:

&rft.atitle=PMEG%3A+%3Ci+lang%3D%22eo%22+title%3D%22Esperanto-language+text%22%3ESpecialaj+elparolaj+reguloj%3C%2Fi%3E

the metadata for a rendering at Esperanto phonology (or any other mainspace article) looks like this:

&rft.atitle=PMEG%3A+%3Ci+lang%3D%22eo%22+title%3D%22Esperanto-language+text%22%3ESpecialaj+elparolaj+reguloj%3C%2Fi%3ECategory%3AArticles+containing+Esperanto-language+text

The category in the mainspace renderings of the cs1|2 title is part of the error message emitted when |title= is linked to more than one target, in this case:

http://bertilow.com/pmeg/skribo_elparolo/elparolo/specialaj_reguloj.html – from |url=

and

Category:Articles containing Esperanto-language text – from {{lang|eo|Specialaj elparolaj reguloj}}

{{lang}} and {{lang-??}} may be used in parameters that are not included in the cs1|2 metadata; see Template:Cite web § COinS. Because the cited source is written in Esperanto, your example template might better be written:

{{cite web |url=http://bertilow.com/pmeg/skribo_elparolo/elparolo/specialaj_reguloj.html#i-c9j |title=PMEG: Specialaj elparolaj reguloj |at=Section Duoblaj literoj |website=Bertilow |language=eo}}

"PMEG: Specialaj elparolaj reguloj". Bertilow (in Esperanto). Section: Duoblaj literoj.

—Trappist the monk (talk) 12:08, 29 May 2021 (UTC)

Thanks. Will that enable screen readers to read them properly, which seems to be the point of this template? — kwami (talk) 18:47, 29 May 2021 (UTC)

No. |language= only tells readers the language or languages of the source; see template documentation.

—Trappist the monk (talk) 22:02, 29 May 2021 (UTC)

Was there recently a change to -Latn display, or am I misremembering? I noticed this at Kaguya in this revision ([1]; notice the words "Kaguya-hime"), and at Chonmage in the current revision ([2], visible for both ja-Latn throughout and zh-Latn in the See also). I think that the transl template is the more semantically correct one and its the one that I normally use, but I just wanted to make sure about that, since this Latinized display caught my eye as being incorrect. Pinging User:Ineffablebookkeeper, who I often see adding such tags, and who added the tags in the Chonmage case. — Goszei (talk) 04:37, 7 June 2021 (UTC)

@Goszei: - from what I recall, -Latn displays text as a different font for *some* users in some browsers, whereas transl tends not to.

FWIW, both give the same language information to the page, but one (transl) fetches a more appropriate display font, as it knows to display romanised text, not, say, MS Gothic because it (in the case of -Latn) thinks it's dealing with kanji or something. -- Ineffablebookkeeper (talk) 08:41, 7 June 2021 (UTC)

There was a bug which has now been repaired.

—Trappist the monk (talk) 12:34, 7 June 2021 (UTC)

The Romanized text appears too small on my Pale Moon (browser). --Error (talk) 00:46, 16 April 2021 (UTC)

I suspect that the problem that you are experiencing is with your browser. This is the html output from the {{lang}} template listed under Wylie in your table:

1. {{lang|bo-Latn|Gzhis-ka-rtse}} → <span title="Standard Tibetan-language text"><i lang="bo-Latn">Gzhis-ka-rtse</i></span> → Gzhis-ka-rtse

Simplifying that to its barest essentials:

2. <i lang="bo-Latn">Gzhis-ka-rtse</i> → Gzhis-ka-rtse

For the sake of argument, changing <i>...</i> to <span>...</span>:

3. <span lang="bo-Latn">Gzhis-ka-rtse</span> → Gzhis-ka-rtse

You should not see any font size differences in the final rendering in each of those three cases.

What happens if you change bo-Latn to, for example, el-Latn? or to ru-Latn

4. <i lang="el-Latn">Gzhis-ka-rtse</i> → Gzhis-ka-rtse

5. <i lang="ru-Latn">Gzhis-ka-rtse</i> → Gzhis-ka-rtse

These should look the same as number 2 above.

There is some discussion about css styling at Template:Lang § Applying styles that may be helpful.

—Trappist the monk (talk) 14:30, 16 April 2021 (UTC)

I read the examples with Firefox without logging in and they all look normal. Reading your examples with Pale Moon shows 1, 2 an 3 smaller than the previous text and 4 and 5 in a normal size. So it is either a problem with the browser or my customization. I will look more into it and use the styles if I cannot solve it otherwise.

Thanks.

--Error (talk) 22:54, 16 April 2021 (UTC)

Playing with the inspector in both browsers, I see that, when the font is rendered too-small, it is rendered in typeface Microsoft Himalaya. When it is normal-size text, it is in Arial.

--Error (talk) 23:30, 16 April 2021 (UTC)

@Error:, Trappist the monk - could this be solved by using {{transl}} over {{lang}}? Transliterated text tends to display properly in the transl template, though the language information sent to the browser is the same. -- Ineffablebookkeeper (talk) 09:33, 7 June 2021 (UTC)

There should be no difference (except the title= attribute ):

{{lang|bo-Latn|Gzhis-ka-rtse}} → <span title="Standard Tibetan-language text"><i lang="bo-Latn">Gzhis-ka-rtse</i></span> → Gzhis-ka-rtse

{{Transliteration|bo|Gzhis-ka-rtse}} → <span title="Standard Tibetan-language romanization"><i lang="bo-Latn">Gzhis-ka-rtse</i></span> → Gzhis-ka-rtse

Editor Error noted that the browser used different fonts for the 'small' and 'normal' renderings. {{lang}} and {{transl}} do not apply fonts when rendering.

—Trappist the monk (talk) 12:44, 7 June 2021 (UTC)

I was too lazy to try to solve it, so I still see the small text. Both last examples by Trappist render too small. --Error (talk) 23:04, 7 June 2021 (UTC)

I wanted to tag Sercquiais but it does not recognize [[CQ]] as a valid region for Sark. The same with Sarkese. Shouldn't it be recognized like other ISO_3166-1_alpha-2#Exceptional_reservations? --Error (talk) 23:21, 25 June 2021 (UTC)

I think that that is a topic that you must raise with IANA (and perhaps ISO). The language-subtag-registry file does not include CQ as a region subtag. Because it is not included there, we should not include it in the html rendered by {{lang}}.

—Trappist the monk (talk) 23:47, 25 June 2021 (UTC)

Strange. From the exceptional reservations, only CQ and UK are not in the IANA list. --Error (talk) 02:48, 26 June 2021 (UTC)

For Greek Letters in articles about Fraternities and Sororities be enclosed in the template?Naraht (talk) 12:12, 30 June 2021 (UTC)

I would think that using {{lang}} for the Greek-letter organizations would be a good idea. When written with just the Greek letters, browsers are more likely to render them correctly; don't know how screen readers react to a sequence of uppercase Greek letters so no matter what you do, the name might be mispronounced. So I would think that the correct thing is:

{{lang|el|ΧΦ}} → ΧΦ

and for the romanization:

{{Transliteration|el|Chi Phi}} → Chi Phi

—Trappist the monk (talk) 14:13, 30 June 2021 (UTC)

I've been attempting to get more editors than just me adding language tags to the articles they edit recently - either by adding {{cleanup lang}} to articles, or by contacting editors directly on their Talk pages after seeing some of their edits. One issue that keeps coming up is the matter of lang tag-wrapped text displaying in different fonts on various browsers.

Now, I know why this happens - the markup specifies the text is in a certain language and writing system, and it leaves it up to the browser to decide exactly what to display this in. This means that even someone running the crustiest version of Internet Explorer can display the same text as the shiniest version of Firefox. (I think.)

However, what keeps coming up is that it's unsightly. The fonts used to display some text stick out from the font used for the rest of article. Editors remark that on some browsers or for some languages, text that's been encoded in language tags just looks ugly - it upsets the flow of the article, stands out like a pork pie at a Jewish wedding - and for some, is a reason not to use language tags, as the "net benefit" (as described to me by one editor) just isn't convincing enough, or large enough, to justify using them.

I know that use of language tags is mandated through MOS:ACCESS. I know it's entirely justified, and that for me at least, fonts are such a bottom-of-the-pile concern that a minor trip hazard in an article's display is worth the basic accessibility of an article someone with a screenreader can actually read and interact with. But I have to ask - is there anything that can be done for this, at all? I want to keep on encouraging editors to use language tags, but I need to know if there's a workaround, or something that can be done, so that when this issue comes up again - and it invariably will - I have some kind of answer to give them. Thanks! --Ineffablebookkeeper (talk) 11:45, 2 February 2021 (UTC)

I presume that you are describing something like this:

• for lang ja ← {{lang|ja|for lang ja}}
• for lang ja ← {{lang|ja-latn|for lang ja}}

Japanese is not normally normally written using Latn script. Telling {{lang}} that this Japanese is written with Latn script tells my browser to use a Latn-specific font (such cases are probably better handled as romanizations so {{transl}} would be a better choice:

• for lang ja ← {{Transliteration|ja|for lang ja}}

—Trappist the monk (talk) 12:18, 2 February 2021 (UTC)

Editors interested in having their own styles for what should be lang marked text should employ personal CSS as described at Template:Lang#Applying styles. --Izno (talk) 15:53, 2 February 2021 (UTC)

@Izno: I find that answer very disstatisfying. Almost all Wikipedia visitors do not have an account, let alone modify their personal CSS or know that they need to do that. Is there really no solution to make sure Wikipedia doesn't look ugly to most people? ―Jochem van Hees (talk) 11:47, 5 July 2021 (UTC)

I want to see something that you think look[s] ugly to most people. So far in this conversation, I am the only editor who has shown examples of {{lang}} that causes the browser to display non-English text in other than the standard font. Give examples of this ugly text please.

—Trappist the monk (talk) 12:03, 5 July 2021 (UTC)

Well for me it looks fine, but I come from a conversation at Talk:Netherlands in the Junior Eurovision Song Contest 2021#Font issue where someone says it still looks ugly to them, despite the article using the ja-Latn language code. It's browser-dependent. ―Jochem van Hees (talk) 12:19, 5 July 2021 (UTC)

They probably use Safari, it is currently the only remaining browser that still changes the font even when -Latn is specified.

The bug could be reported to Apple or solved through MediaWiki:Common.css. --Thibaut (talk) 12:30, 5 July 2021 (UTC)

If it is an issue affecting certain browsers, it should be reported to the responsible vendors. Izno (talk) 01:51, 6 July 2021 (UTC)

Hi. {{tl:lang|rap}} shrinks the font rather than just italicizing it. Could someone fix, please? — kwami (talk) 02:31, 17 July 2021 (UTC)

Can you provide a definitive example of that happening? For me this looks normal:

Rongorongo ← {{lang|rap|Rongorongo}}

and just for the purposes of a rendering comparison change the language to es:

Rongorongo ← {{lang|es|Rongorongo}}

Both of these look the same to me.

—Trappist the monk (talk) 02:40, 17 July 2021 (UTC)

Looks also fine here on Firefox 90.0 and Edge 91.0.864.70 on Windows 10. --Thibaut (talk) 02:42, 17 July 2021 (UTC)

I'm using FF 90.0 for Linux Mint. On my display, the Rapa Nui is smaller than the Spanish: slightly smaller than the html subscript in Spanish Rongo_rongo. Also, the inclination and letter shapes are very slightly different, as if the Rapa Nui were faux (html) italics imposed on the roman typeface rather than the italic typeface of the Spanish. (Looks like the same font family, though.)

I've seen this before. I don't remember which language, but Rongorongo formatted as Hawaiian looks the same as the Spanish, while Rongorongo formatted as Nahuatl looks like the Rapa Nui. Swahili looks good (like Spanish), Hadza looks bad (like Rapa Nui).

Could this be a difference between languages with dedicated formatting, and the {{lang}} default used for unsupported languages?

I'm not recognizing anything in my js or css that would make a difference. I have Andika set for Unicode, but I think I'm seeing Andika for both Spanish and Rapa Nui, so that wouldn't explain the difference in size. — kwami (talk) 04:06, 17 July 2021 (UTC)

Sounds like a browser/OS font problem, not something that can be or should be 'fixed' in {{lang}}. Both your haw and nah examples look fine to me (chrome latest; win10). Module:Lang does not apply fonts. When the module thinks that a piece of text should be italicized, it wraps that text in <i>...</i> tags:

<span title="Rapa Nui-language text"><i lang="rap">Rongorongo</i></span>

It is up to the broswer/OS to apply a font appropriate to the lang= attribute.

Sometimes we get complaints about how Japanese Romanizations look odd; these are usually because the language tag is ja instead of ja-Latn:

Rongorongo ← {{lang|ja|Rongorongo}}

Rongorongo ← {{lang|ja-Latn|Rongorongo}}

Perhaps this is what you are remembering?

What happens if you comment out line 3? I added it to my common.css but it didn't change the appearance the rap text.

—Trappist the monk (talk) 11:04, 17 July 2021 (UTC)

Yeah, it must be s.t. in my browser. I tried another and it didn't happen there. Sorry to bother you.

Rm'ing that line has no effect.

The non-Latin Japanese example has the same problem. — kwami (talk) 04:03, 19 July 2021 (UTC)

I tried to tag text in Gascon language with Mistralian orthography (there is an example in the caption for the pic in Gascon language#Examples) but it doesn't work:

• [gascoun] Error: {{Lang}}: unrecognized language tag: oc-gascon-grmistr (help)
• [gascoun] Error: {{Lang}}: unrecognized language tag: oc-grmistr-gascon (help)

However

• gascoun
• gascoun

work. Shouldn't the combination of dialect and spelling work? This applies to all plausible combinations of Occitan dialect and spelling subtags. --Error (talk) 00:55, 16 April 2021 (UTC)

Hi Error, those tags are not valid IETF tags therefore they can't be recognized. This is an easy guide to how language tags work but to summarize: IETF tags can have language (2-3 characters lowercase), extlang (2-3 characters lowercase), script (4 characters title case, e.g. Latn), region (alphanumeric 2-3 characters uppercase, e.g. US) and variant (up to 8 characters lowercase). "oc-gascon-grmistr" has language-variant-???? while "oc-gascon" has language-variant.

The standard also leaves space for extension and private tags but I don't know if those are supported by Module:Lang and to what extent, probably Trappist the monk can tell you about that. Cheers, josecurioso ❯❯❯ Tell me! 09:19, 16 April 2021 (UTC)

The "unofficial" check tool says both:

The language tag oc-gascon-grmistr is well-formed and the subtags are valid IANA subtags, however, you should check the comments related to usage below.

Warning: The subtags preceding the variant subtag grmistr did not match the expected pattern: oc-grmistr.

It seems that the IETF has not a mechanism for this semantically valid usage. :(

--Error (talk) 09:56, 16 April 2021 (UTC)

Is r12a actually associated with IANA or IETF? Looks to me like r12a is a private individual who has written some really useful tools; I see no indication from what I've read at their various web postings that they are associated with IANA or IETF.

—Trappist the monk (talk) 14:11, 16 April 2021 (UTC)

W3 says:

There is also an unofficial, user-friendly tool for searching the registry.

pointing to r12a.

--Error (talk) 22:44, 16 April 2021 (UTC)

@Josecurioso: It sounds like you're saying that there can't be multiple variant subtags, but BCP 47 says that there can be, giving several examples, such as sl-rozaj-biske-1994. But as mentioned above apparently oc-gascon-grmistr is not valid because Module:Language/data/iana_variants doesn't list oc-gascon as a prefix for grmistr. Last time I checked, years ago, Module:Lang didn't support multiple variants, though it's not surprising nobody had brought it up because there are so few of them. At that time I made a function that did support multiple variants, currently broken because of module changes. — Eru·tuon 10:27, 16 April 2021 (UTC)

@Error @Erutuon: Just re-read that BCP section and you are right. And I thought I knew it all about language tags after porting Module:Lang to eswiki but it never ceases to amaze me!.

Even if it is not listed as a prefix, the prefix field is only a recommendation so seems like the problem here is also in the get_ietf_parts regex not being prepared to recognize all the quirks of BCP 47. When porting it over to eswiki I added support for extlang in a crude way so in order to fully fix these kind of issues we would need to rethink the parser. josecurioso ❯❯❯ Tell me! 11:35, 16 April 2021 (UTC)

As I understand it, a variant tag must match at least one of the preceding tags. So for oc-gascon-grmistr, grmistr must match one of oc (it does) or gascon (it does not). Because grmistr matches oc, oc-gascon-grmistr is valid.

—Trappist the monk (talk) 14:11, 16 April 2021 (UTC)

@Trappist the monk: I hadn't looked into this before, but the relevant section of BCP 47 seems to be saying that oc being the prefix of grmistr means that another type of subtag could intervene but not another variant subtag: particularly "The 'Prefix' also indicates when variant subtags make sense when used together". That is, oc-Latf-grmistr might be valid but not oc-gascon-grmistr. However, the Extended Filtering section of RFC 4647, which describes the type of matching to use, also says that the subtag-matching loop must consume all subtags and that there are implicitly inserted wildcards for any subtag types that are not specified in the list of subtags being matched against. That is, oc would at least be equivalent to oc-*-*-*, with wildcards for the extlang and script and region. Neither place says explicitly whether there would also be an implicit wildcard in the variant subtag place as well (oc-*-*-*-*), which would allow oc to match oc-gascon. The BCP 47 section would make less sense to me if there was a variant wildcard because then the matching rules would not clearly enforce ordering of variant tags and would not clearly express which variants made sense together, because each prefix would match itself plus any number of variant subtags. — Eru·tuon 20:14, 17 April 2021 (UTC)

Module:Lang has never supported multiple variant tags because it hasn't ever needed to; Editor Error's use-case is the first known to me. When I hacked the original version of get_ietf_parts(), support for variable numbers of variant tags was just a huge complicating factor that would, in the end, yield little reward. Module:Lang does not support extlang tags because there are none that haven't been superseded by other tags. Wikis-being-wikis, that meant that any instances of the old wikitext {{lang}} templates could be upgraded to remove extlang tags; no legacy to support. Module:Lang does support private tags that we define in Module:Lang/data; these are mostly used to allow the {{lang-??}} templates using these tags to link to the appropriate en.wiki article.

—Trappist the monk (talk) 14:11, 16 April 2021 (UTC)

When updating the module, you may keep in mind that while variant chaining may be syntactically right, not every combination is right in practice. I am not an expert but I doubt that oc-aranese-grital will ever be needed. And oc-aranese-aranese-provenc is absurd, as is oc-grmistr-grclass.

--Error (talk) 21:02, 17 April 2021 (UTC)

The 2021-07-21 version of the subtag registry has defined which variant spelling tags go with each variant dialect tag. It also has a South Jutlandic variant tag.

--Error (talk) 10:43, 30 July 2021 (UTC)

I posted about a problem at Template talk:Lang-sh#Two parameters and "romanized" - can someone here help? --Joy [shallot] (talk) 09:42, 31 July 2021 (UTC)

Hello,

I'm not sure where to go for help with this but an editor has a language userbox that keeps placing them in a redirect category, Category:User zh-Hans, instead of the regular category, Category:User zh-hans. The user page is User:KisaragiAyami and, unbeknownst to them, I have messed around with the code but didn't want to remove the language element completely but I was unsuccessful. I've looked at the relevant template pages but didn't find any information about this specific issue and miscategorizations.

If anyone else can fix this, it would be greatly appreciated. Thanks! Liz ^{Read! Talk!} 21:17, 3 August 2021 (UTC)

Nothing to do with {{lang}} or Module:Lang. The userboxen are produced by the magic word {{#babel}} see mw:Extension:Babel. The documentation, such as it is, doesn't mention IETF language tags, ISO 15924 script tags, or casing in category names.

I think that the form zh-Hans is correct and should be preferred because that is the 'canonical' form used for IETF tags (see BCP 47/RFC5646 page 7) so the regular category pages should be Category:User zh-Hans and the redirect category should be Category:User zh-hans.

—Trappist the monk (talk) 22:20, 3 August 2021 (UTC)

Weird. I'll just keep on watching this conversation. I have no idea what's going on.

—Kisaragi Ayami (如月あやみ) (talk) 17:23, 4 August 2021 (UTC)

Circa in historical languages should be rendered c. instead of ca. per MOS:CIRCA. See e.g. the tooltip in: Some text in Middle French. – Finnusertop (talk ⋅ contribs) 10:28, 7 August 2021 (UTC)

The names that Module:lang uses for tooltips and for categories are the names that the ISO 639 custodians have chosen for the associated language codes. The custodians also use U+002D hyphen-minus instead of the spaced or unspaced en dash in violation of MOS:YEARRANGE – they also write 'B.C.' instead of MOS-approved 'BC' (peo) in violation of MOS:ERA yet they also write MOS-approved 'CE' (tmr). IANA uses the ISO 639-3 names in the language-subtag-registry file which is the data source for all name, language, script, region, and variant subtags used by Module:Lang.

The ISO 639-2 custodians use 'ca.' (unspaced) for these languages:

ang ← English, Old (ca.450-1100)

dum ← Dutch, Middle (ca.1050-1350)

frm ← French, Middle (ca.1400-1600)

gmh ← German, Middle High (ca.1050-1500)

goh ← German, Old High (ca.750-1050)

peo ← Persian, Old (ca.600-400 B.C.)

The ISO 639-3 custodians use 'ca.' (spaced) for these languages:

ang ← Old English (ca. 450-1100) – Category:Articles containing Old English (ca. 450-1100)-language text

dum ← Middle Dutch (ca. 1050-1350) – Category:Articles containing Middle Dutch (ca. 1050-1350)-language text

frm ← Middle French (ca. 1400-1600) – Category:Articles containing Middle French (ca. 1400-1600)-language text

fro ← Old French (842-ca. 1400) – Category:Articles containing Old French (842-ca. 1400)-language text

gmh ← Middle High German (ca. 1050-1500) – Category:Articles containing Middle High German (ca. 1050-1500)-language text

goh ← Old High German (ca. 750-1050) – Category:Articles containing Old High German (ca. 750-1050)-language text

peo ← Old Persian (ca. 600-400 B.C.) – Category:Articles containing Old Persian (ca. 600-400 B.C.)-language text

tmr ← Jewish Babylonian Aramaic (ca. 200-1200 CE) – Category:Articles containing Jewish Babylonian Aramaic (ca. 200-1200 CE)-language text

Do we really need to harmonize these names and categories with MOS?

—Trappist the monk (talk) 12:00, 7 August 2021 (UTC)

Yes, we should. We are Wikipedia, we have our own MOS that is (thankfully) sometimes prescriptive instead of wishy-washy, and we do this sort of adaptation all the time. I'm happy to do as much of the changing as I can if you can provide pointers to the relevant modules. – Jonesey95 (talk) 20:12, 7 August 2021 (UTC)

If we must, then it is probably best to write a function that harmonizes tooltips and category names with MOS; likely not that difficult. If we do that, we minimize the maintenance burden as language names come and go from the IANA language-subtag-registry file. The pain-in-the-ass, as I see it, is WP:CFD for the categories. Sure, we could just rename them and be done but, if we do that, someone will complain and I'm sick to death of drama.

—Trappist the monk (talk) 21:39, 7 August 2021 (UTC)

I tried to create Template:lang-jax copying the code from Template:lang-id with jax as the code but it shows an error:

Lua error in Module:Lang/documentor_tool at line 60: attempt to index local 'content' (a nil value).

Can the template be created? --Error (talk) 18:04, 8 August 2021 (UTC)

Since you didn't save the result of your creation I can't say what you did wrong. You must have changed more than:

|code=id → |code=jax

jax is legitimate so {{lang-jax}} can work:

{{lang|fn=lang_xx_italic|code=jax|text}} → Jambi Malay: text

—Trappist the monk (talk) 18:13, 8 August 2021 (UTC)

The error message only appeared in the preview. I created the template. Thanks. --Error (talk) 19:53, 8 August 2021 (UTC)

Why are the clean-up banners for this template suddenly popping up in articles demanding that this template be used? Yet another example of WP:Overtagging putting up huge disruptive (for readers) banners for what should be background clean-up work, but that's another matter.

The rationale isn't enough for this to become compulsory. Especially for languages which use latin script, and words which by context are already pretty clear on which language they are from (including their meaning). For the vast majority of foreign text, you don't need web browser support. Neither are there special screen readers that can read different languages out loud correctly for most languages. That only exists for the major languages.

The sheer amount of effort needed to implement this is insane in articles which use multiple non-English words (like most of the articles I work on). You have to look up each individual language tag, which can't be found on one page either. You can't search and replace, because you might hit the urls and the references if you do. So you manually have to type the template out each time.

There are no provisions for shared terms either. You have to pick one specific language code, even when the same term is used for several closely-related languages that have the same name (like Kalinga language for example). At the very least, can't this be integrated into the edit box? With a search function for ISO codes?-- OBSIDIAN†SOUL 13:05, 10 August 2021 (UTC)

You are attacking the wrong front. Whatever recommendation or policy or movement or whatever, is not the provenance of {{lang}}, the {{lang-??}} templates, or of Module:Lang. There is likely a place to raise your complaints, but that place is not here.

—Trappist the monk (talk) 13:29, 10 August 2021 (UTC)

Sigh. And delve into Wikipedia politics again? As if that goes anywhere. I guess I'll stew in my frustration then.-- OBSIDIAN†SOUL 13:46, 10 August 2021 (UTC)

The ISO 639-3 code for the Tagish language (tgx) is not recognized as a valid template OlliverWithDoubleL (talk) 22:32, 17 August 2021 (UTC)

You mean {{lang-tgx}}? Templates of this form are separate from {{lang}} and each one needs to be created on its own. I've just done that, so the template should work now. – Uanfala (talk) 23:00, 17 August 2021 (UTC)

@Trappist the monk: Kan Qingzi is displaying an unmatched quote mark in the hatnote. Is this perhaps because at line 1184 of Module:Lang, there is \'' rather than \'\' ? – Fayenatic London 10:34, 9 September 2021 (UTC)

Not the fault of {{lang}}.

From this:

{{family name hatnote|[[Kan (surname)|Kan]] ''({{lang|zh-hans|阚}})''|lang=Chinese}}

MediaWiki makes this:

<templatestyles src="Module:Hatnote/styles.css"></templatestyles><div role="note" class="hatnote navigation-not-searchable">In this [[Chinese name]], the [[Chinese surname|family name]] is '' [[Kan (surname)|Kan]] ''(<span lang="zh-Hans" title="Chinese-language text">阚</span>[[Category:Articles containing Chinese-language text]])''''.</div>

and from that, this:

<div class="mw-parser-output"><style data-mw-deduplicate="TemplateStyles:r1033289096">.mw-parser-output .hatnote{font-style:italic}.mw-parser-output div.hatnote{padding-left:1.6em;margin-bottom:0.5em}.mw-parser-output .hatnote i{font-style:normal}.mw-parser-output .hatnote+link+.hatnote{margin-top:-0.5em}</style><div role="note" class="hatnote navigation-not-searchable">In this <a href="/wiki/Chinese_name" title="Chinese name">Chinese name</a>, the <a href="/wiki/Chinese_surname" title="Chinese surname">family name</a> is <i> <a href="/wiki/Kan_(surname)" title="Kan (surname)">Kan</a> </i>(<span lang="zh-Hans" title="Chinese-language text">阚</span>)'<b>.</b></div></div>

Note the bits at the ends: the ''''. translates to '<b>.</b>

Not the fault of {{lang}}. And why is ({{lang|zh-hans|阚}}) wrapped in italic markup anyway? Non-Latin script text is supposed to be rendered upright:

{{family name hatnote|[[Kan (surname)|Kan]] ({{lang|zh-hans|阚}})|lang=Chinese}}

In this Chinese name, the family name is Kan (阚).

—Trappist the monk (talk) 11:17, 9 September 2021 (UTC)

Thank you! – Fayenatic London 21:00, 17 September 2021 (UTC)

Chinese characters have stopped displaying. I see boxes with Unicode numbers in place of characters. I'm using Firefox on Mint. If I change the language code from zh to ko or ja they display fine. My fonts haven't changed. Logging out makes no difference. If I try Falkon, I mostly see boxes, but an occasional character displays correctly. — kwami (talk) 03:26, 20 September 2021 (UTC)

Examples where this can be seen?

In the section just above this one is this:

{{lang|zh-hans|阚}} → 阚.

If I simplify that:

{{lang|zh|阚}} → 阚.

I see the Chinese character in both cases (chrome win 10). There have been no changes to Module:Lang since June 2021.

—Trappist the monk (talk) 11:12, 20 September 2021 (UTC)

I see a character on the left of each and a box on the right. Same if it's lang-zh. I can always the the characters in the edit window.

If it's not a change to the module, then it must be FF or Mint. Apparently the module is no longer compatible with one or the other. — kwami (talk) 16:39, 20 September 2021 (UTC)

The character on the left is not wrapped in html markup whereas the character on the right is:

{{lang|zh-hans|阚}} → <span title="Chinese-language text"><span lang="zh-Hans">阚</span></span> → 阚

{{lang|zh|阚}} → <span title="Chinese-language text"><span lang="zh">阚</span></span> → 阚

If we simplify to just the minimal html and avoid Module:Lang entirely:

<span lang="zh-Hans">阚</span> → 阚

<span lang="zh">阚</span> → 阚

If you still see boxes in the simplified examples then the problem is definitely not caused by Module:Lang.

—Trappist the monk (talk) 17:11, 20 September 2021 (UTC)

Yes, still boxes. Thanks. — kwami (talk) 23:56, 20 September 2021 (UTC)

In my experience Firefox can do odd things, with languages. It has the rather unique feature of letting you specify multiple fonts for every language: under "Language and Appearance" click on "Advanced...". You can specify settings for a large number of scripts. And these settings make a difference and can override what you would expect from the CSS and HTML on the page. So maybe someone made some odd choices in these settings, or maybe they've been corrupted by one of Firefox's frequent upgrades. 2A00:23C8:4583:9F01:1DC6:B8A5:D274:DE23 (talk) 17:29, 20 September 2021 (UTC)

Yeah, that was it. I hadn't changed my default fonts, so perhaps it was a FF upgrade issue. Sorry to waste your time -- again. (Shoulda learned by now.) The templates and html span tags still reduce the font size by about half, but that's another issue. — kwami (talk) 23:56, 20 September 2021 (UTC)

Often when translating an article I use this template for marking individual words as foreign. Partly I do this just to get italic font, although I can of course just use plain markup for that; mainly so that it's clear to any subsequent editor that it's a translated word and from which language. After that, I tend to put the English translation in parentheses and quotation marks. For example {{lang|hu|hulye majom}} ("stupid monkey"), when it's important to give the original.

Perhaps I'm over-thinking this, but it would be good to have a named parameter "en=" to do the bit of English afterwards, in the parens and quotes. Of course this would only make sense for short uses, but I could then write {{lang|fr|étranger|en=alien}} and be done. It's quite minor, I suppose, but for the next editor makes it clearer exactly what part of the foreign-language text corresponds to the translation. In theory it would work for longer translations, but in practice it's probably less useful because of markup etc.

Is it worth it? 85.67.32.244 (talk) 06:35, 14 October 2021 (UTC)

Just FYI, there is also {{lang-en}} which can be used for this: {{lang|fr|étranger}} ({{langx|en|alien}}), but yeah an extra parameter would make it shorter. I'd then also support adding a parameter for {{transl}}. ―Jochem van Hees (talk) 09:00, 14 October 2021 (UTC)

For simple glosses, single quotes without the parentheses. See MOS:SINGLE.

{{langx|hu|hulye majom|lit=stupid monkey|label=none}} → hulye majom, 'stupid monkey'

—Trappist the monk (talk) 10:53, 14 October 2021 (UTC)

Moved from Template talk:Lang-grc#Different separators when label=none is set?

 –  — sbb (talk) 02:18, 15 October 2021 (UTC)

Regarding {{lang-grc}} (and any other {{lang-xxx}} this might apply to):

Compare, default (with and without a |translit= parameter):

• Ancient Greek: κινέω, romanized: kinéō, lit. 'to move, to change'
• Ancient Greek: κινέω, lit. 'to move, to change'

... vs. |label=none:

• κινέω, kinéō, 'to move, to change'
• κινέω, 'to move, to change'

With the |label=none parameter, the extra comma separating the Greek word and its translation does not follow MOS:SINGLE ("Simple glosses that translate or define unfamiliar terms take single quotes, with no comma before the definition").

Requested changes if |label=none is provided:

1. no comma after the Greek-language term. Desired output: κινέω 'to move, to change'
2. if |translit= is given, the transliteration is placed in parentheses. Desired output: κινέω (kinéō) 'to move, to change'

Alternately, perhaps a new parameter specifying separator format (default to current style, and some other non-default value would produce no commas, and put the translit. in parens) would be great. However it's implemented, I don't care, would be fine.  — sbb (talk) 18:14, 14 October 2021 (UTC)  — sbb (talk) 02:18, 15 October 2021 (UTC)

To minimize copy/paste error propagation, it would be nice if {{lang-grc}} automatically transliterated the first parameter if |translit=auto were given. Currently, in order to rely on Module:Ancient Greek transliteration with {{lang-grc}}, the following is necessary, {{langx|grc|κινέω|translit={{grc-transl|κινέω}}}}, to produce: Ancient Greek: κινέω, romanized: kinéō.

With requested the change, this syntax would produce the same result: {{langx|grc|κινέω|translit=auto}}.  — sbb (talk) 03:51, 15 October 2021 (UTC)

I'm inclined to say that this ought not be done. Were 'auto-transliteration' something that all (or most) of the {{lang-??}} templates could do then, sure, we might support |translit=auto but if {{lang-grc}} is the only template and there is sufficient need, then a special template that calls {{grc-transl}} might be written (this example is almost wholly untested):

{{#invoke:lang|lang_xx_inherit
|code=grc
|translit={{grc-transl|{{{1|}}}}}
|rtl=no
}}

I don't know what 'sufficient need' is but templates with few transclusions are often subst'd and deleted so WP:TFD should be part of your calculations.

—Trappist the monk (talk) 18:23, 17 October 2021 (UTC)

Fair enough, and I do appreciate the rationale. Template {{lang-ka}} does this, however. Additionally, we could start importing automatic transliteration modules from Wiktionary (see wikt:Category:Languages with automatic transliteration) to provide auto translit. for several non-Latin languages in a standardized way.  — sbb (talk) 02:51, 18 October 2021 (UTC)

This edit request to Template:Lang has been answered. Set the |answered= parameter to no to reactivate your request.

Please change Eskimo-Aleut languages to Eskimo–Aleut languages (change hyphen to en dash), for lang code "esx", somewhere in this template or its data; I don't see exactly where that would be. Dicklyon (talk) 18:00, 21 November 2021 (UTC)

There are some 470ish language names in Module:Language/data/iana languages that use hyphens; none use an endash. Are all of those 470ish language names subject to this same request? If they are, and we know that there will be no broken links, we could force convert hyphenated language names to endash separated names. But, that brings with it the possibility that some hyphenated names should properly be hyphenated so forced conversion is probably a bad idea. If not, then we might add the endash form to Module:Lang/data.

If this issue is raised because of one of the two articles that use {{lang-esx}}, then perhaps this:

Eskimo–Aleut languages: text ← {{langx|esx|text|label=[[Eskimo–Aleut languages]]}}

—Trappist the monk (talk) 18:42, 21 November 2021 (UTC)

I went ahead and did that manual fix at the two articles I had found, which you also noticed. But we might as well keep working toward the better fix. Thanks. Dicklyon (talk) 03:44, 22 November 2021 (UTC)

I would think not all of them. If you can get me a list, I'll check. The ones where the hyphen form redirects to the en dash form probably should be auto-fixed. Some others use a hyphen, e.g. when the involve a "combining form" instead of parallel terms. The Eskimo–Aleut languages article was moved to the dashed from 10 years ago by Kwamikagami. It looks to me like he did the same, 10 years ago, for pretty much everything in Category:Language families. Individual languages I would guess would use dashes less often, but haven't checked. Dicklyon (talk) 22:45, 21 November 2021 (UTC)

Put this in a sandbox page to get the list of language names that use hyphens (omits hyphens associated with digits)

{{#invoke:Sandbox/trappist_the_monk/hyphenated_language_names|list}}

—Trappist the monk (talk) 23:31, 21 November 2021 (UTC)

Thanks; got the list at User:Dicklyon/sandbox/dash. Those with Afro- and Austro- combining forms shouldn't go to en dash. But Atlantic-Congo languages was moved to the en dash 10 years ago and should be fixed here. I'll do some more looking... Dicklyon (talk) 03:17, 22 November 2021 (UTC)

I was thinking that "Chukatko" might be a combining form; it's never seen alone, and often set with hyphen. But then this book uses an en dash in "Chukotko–Kamchatkan family", so now I'm not sure. Haven't looked at others. Someone more into languages should say whether such things are parallel terms or not (i.e. would Kamchatkan–Chukotko make just as much sense?). Dicklyon (talk) 22:54, 21 November 2021 (UTC)

@ValtteriLahti12: Based on Chukotko-Kamchatkan–Amuric languages, it looks like you'll know something about this. Dicklyon (talk) 03:41, 22 November 2021 (UTC)

@Kwamikagami: I see you're still at it here, too. I mentioned your dash fixes of a decade ago. They're not fully completed. Dicklyon (talk) 03:43, 22 November 2021 (UTC)

This one looks like a plain bug: Finland-Swedish Sign Language language should be Finland-Swedish Sign Language. Dicklyon (talk) 03:23, 22 November 2021 (UTC)

Fixed that. I have also added an (expensive) check to look for language names that redirect to endash-separated targets.

—Trappist the monk (talk) 13:05, 22 November 2021 (UTC)

I"ve always assumed "Chukotko-" was the combining form of Chukotka, equivalent to "Nilo-" or "Americo-". I would assume that the use of the en dash in the book you found is a copy-edit error, perhaps an over-generalization. — kwami (talk) 04:14, 22 November 2021 (UTC)

But you agree, I assume, that all those with hyphens redirecting to dash fixes you made a decade ago should be fixed in this template. Yes? Dicklyon (talk) 04:42, 22 November 2021 (UTC)

OK, I would suggest changing the following:

1. Atlantic-Congo languages → Atlantic–Congo languages
2. Bukar-Sadung Bidayuh language → Bukar–Sadong language
3. Eskimo-Aleut languages → Eskimo–Aleut languages
4. Havasupai-Walapai-Yavapai language → Havasupai–Hualapai language
5. Hmong-Mien languages → Hmong–Mien languages
6. Niger-Kordofanian languages → Niger–Congo languages
7. Omaha-Ponca language → Omaha–Ponca language
8. Trans-New Guinea languages → Trans–New Guinea languages
9. Mon-Khmer languages → Mon–Khmer languages

Dicklyon (talk) 21:44, 24 November 2021 (UTC)

@Trappist the monk: are you willing/able to do this for the above now? Dicklyon (talk) 19:45, 30 November 2021 (UTC)

cf:

1. Atlantic-Congo languages → Atlantic–Congo languages
2. Bukar-Sadung Bidayuh → Bukar–Sadong
3. Eskimo-Aleut languages → Eskimo–Aleut languages
4. Havasupai-Walapai-Yavapai → Havasupai–Hualapai
5. Hmong-Mien languages → Hmong–Mien languages
6. Niger-Kordofanian languages → Niger–Congo languages
7. Omaha-Ponca → Omaha–Ponca
8. Trans-New Guinea languages → Trans–New Guinea languages
9. Mon-Khmer languages → Mon–Khmer languages

—Trappist the monk (talk) 20:33, 30 November 2021 (UTC)

Yes, it looks like you fixed it. Thanks. Dicklyon (talk) 04:13, 8 December 2021 (UTC)

I'm trying to find where the definition of the class "languageicon" is found, as this module and template don't use templatestyles and it isn't found at MediaWiki:Common.css. Also, since these don't actually show an icon, can we rename the class to remove the word "icon" from it? Gonnym (talk) 12:01, 27 December 2021 (UTC)

class="languageicon" is not defined anywhere. It was originally included in {{link language}} which was used by all of the {{xx icon}} templates before the consolidation into {{in lang}}. Template:Link lang/doc had this:

Logged in users can change the appearance of the template's output using CSS with the languageicon class. For example, edit Special:MyPage/common.css and add span.languageicon { font-weight: bold; }. That would result in {{link language|fr}} being displayed as {{link language|fr}} instead of {{link language|fr}}.

Also appears in {{native name}} but is not documented.

Apparently only used by two editors.

—Trappist the monk (talk) 12:41, 27 December 2021 (UTC) 12:47, 27 December 2021 (UTC) (add) 12:51, 27 December 2021 (UTC) (add more)

I think the very low usage means that the name can be changed without any real issues. Gonnym (talk) 13:32, 27 December 2021 (UTC)

I noticed a signature that is misusing this template for {{lang|ko|☆}}. Can a tracking category be added if the characters are not a word characters? Gonnym (talk) 14:33, 22 December 2021 (UTC)

sumbols → symbols

meh. That particular character is U+2606 WHITE STAR which is part of U+2600–U+26FF Miscellaneous Symbols. So, constrained to that group of contiguous symbols, probably not difficult but... If we start complaining about these symbols then ought we not also complain about emoji? The problem with emoji is that they are not in a single contiguous group of code points; and there are a lot of them.

Yeah, {{lang|ko|☆}} is probably a misuse but is also more-or-less harmless in that the browser renders it using a Korean-script font instead of a Latn-script font. No idea how screen-readers pronounce that character in either English or Korean.

—Trappist the monk (talk) 15:11, 22 December 2021 (UTC)

At least ☆/★, =/＝ etc. are sometimes used in proper names in some languages.

(E.g. 魔法少女まどか☆マギカ, more examples)

Arfrever (talk) 10:20, 26 December 2021 (UTC)

See how correct usage is handled at Tom Cat (band). Gonnym (talk) 15:30, 26 December 2021 (UTC)

• That page actually contains e.g. *''TOM{{lang|ja|★}}CAT'' - June 21, 1985. I thought that you were objecting to this usage.
• Japanese_punctuation#Interpunct says:

  in creative writing, especially manga and light novels when transcribing proper nouns, there's a fad of replacing the interpunct with an equal sign, a white star or any other "fitting" symbol

• Returning to TOM★CAT example, there is difference in rendering as seen in these examples:

• TOM★CAT: TOM★CAT
• TOM{{lang|en|★}}CAT: TOM★CAT
• TOM{{lang|ja|★}}CAT: TOM★CAT
• ''TOM★CAT'': TOM★CAT
• ''TOM{{lang|en|★}}CAT'': TOM★CAT
• ''TOM{{lang|ja|★}}CAT'': TOM★CAT
• ''{{lang|en|TOM★CAT}}'': TOM★CAT
• ''{{lang|ja|TOM★CAT}}'': TOM★CAT

Other comparisons:

• {{lang|en|☆}}: ☆
• {{lang|ja|☆}}: ☆
• {{lang|ko|☆}}: ☆
• ''{{lang|en|☆}}'': ☆
• ''{{lang|ja|☆}}'': ☆
• ''{{lang|ko|☆}}'': ☆
• {{lang|en|♪}}: ♪
• {{lang|ja|♪}}: ♪
• {{lang|ko|♪}}: ♪
• ''{{lang|en|♪}}'': ♪
• ''{{lang|ja|♪}}'': ♪
• ''{{lang|ko|♪}}'': ♪

Japanese/Korean stars and musical notes are bigger than English ones. When italic type is used, Japanese/Korean stars and musical notes are slanted, but English ones are not.

This strongly says to me that characters like stars and musical notes should be allowed with {{lang}}.

Arfrever (talk) 17:34, 27 December 2021 (UTC)

I noticed that on the W3C website, it is explained here that the lang attribute not only applies to the content of an element, but also its other attributes such as title. So in <i lang="de" title="German-language text">Beispiel</i> (which is currently the result of {{lang|de|Beispiel}}), the lang="de" is also applied to the "German-language text" title, even though that's obviously in English. The W3C website recomments putting the lang attribute on a <span> tag inside the element that contains the title attribute. Is this something that would be worth fixing? ―Jochem van Hees (talk) 22:52, 10 January 2022 (UTC)

Yep, thanks for the notification. I'll think about how that should be accomplished.

—Trappist the monk (talk) 23:24, 10 January 2022 (UTC)

Can we add parameter for IPA pronunciation? It is very often used along this template, and it would be easier to just have it in it, than using another IPA template. Piotr Bart (talk) 15:12, 20 January 2022 (UTC)

This edit request to Module:Lang has been answered. Set the |answered= parameter to no to reactivate your request.

Please edit this module similar to fa:Special:Diff/33792781 so that the text is wrapped in <bdi> tags. If the text contains spaces and its directionality is opposite that of the wiki language (in case of enwiki, if text is rtl) browsers may not render it properly without a bdi tag. Please {{ping}} me if you have any questions. huji—TALK 01:10, 24 December 2021 (UTC)

 Done. P.I. Ellsworth - ed. ^put'r there 07:05, 24 December 2021 (UTC)

@Huji:, can you have a look at Template:Interlanguage link (also known as, {{ill}}) and see if that template would benefit from similar treatment of the foreign element, at least for cases when the language parameter indicates that the third positional parameter (foreign language article title) is in an RTL language? I'm thinking of cases where a Hebrew title, let's say, which would normally be rtl, could be ltr for some titles imported from English or other ltr languages, such as "IBM" in Hebrew Wikipedia. Or do you think this is too much of an edge case to worry about? Adding Paine Ellsworth. Mathglot (talk) 09:24, 24 December 2021 (UTC)

I'm not convinced that this is a proper solution. Slapping <bdi>...</bdi> tags around all <other-language-text> regardless of its directionality and the directionality of the surrounding text is wrong for a couple of reasons. When the directionality of the <other-language-text> is the same as the directionality of the local wiki, there is no need to isolate <other-language-text> inside <bdi>...</bdi> tags. <bdi>...</bdi> tags are appropriate when we don't know the directionality of <other-language-text>. But we do know the directionality of <other-language-text> so, here at en.wiki, we set the appropriate attributes in the wrapping <span>...</span>.

Not really surprising that what works at en.wiki does not work at fa.wiki. Module:Lang was not written with internationalization in mind. I suspect that the real issue with Module:Lang at fa.wiki is a matter of inadequate attention to i18n that just happens to get fixed by slapping in the <bdi>...</bdi> tag patch.

There has been no evidence here that Module:Lang does not work properly at en.wiki so I am going to revert this change. We should discuss i18n and make a plan to address it. @Huji, for the duration of the i18n discussion, please watchlist this page.

—Trappist the monk (talk) 15:12, 24 December 2021 (UTC)

To editor Trappist the monk: forgive my overly-bold edit – been kickin' meself for not checking with you first. Happy holidays to you and yours! P.I. Ellsworth - ed. ^put'r there 15:40, 24 December 2021 (UTC)

@Paine Ellsworth: With all due respect, while I agree that the "perfect" solution here is to make Module:Lang compatible with i18n, I think the bdi tag solution is good-enough (having bdi tags around text that is in the same direction does not hurt anything) and you are letting perfect be the enemy of the good here. Bur your mileage may vary.

For all I know, enwiki templates and modules rarely support i18n and specifically are not rtl-friendly, and many other wikis copy them directly (and update their local copy periodically by copying the latest version off enwiki) so lots of time is wasted downstream in addressing issues like these. We spent a good 100+ hours to get CS1 module series (for citations) work properly on fawiki and I'm 100% confident that enwiki community will never care to backport our changes into the enwiki version to make it i18n-able. Incentives are not aligned here (those who cause the problem are not those who pay the price) so there is no surprise in lack of i18n in enwiki templates and modules.

I added this page to my watchlist. Look forward to responding here in 2-3 years with a "told you so", as I am fairly confident this module won't get i18n'ed either. huji—TALK 17:25, 24 December 2021 (UTC)

I suspect that you are targeting your anger at the wrong editor. I am the editor who suggested that the fa.wiki 'fix' is improper. For the nonce, I think that a better solution is to:

1. at Module:Lang line 28, add this:

   local this_wiki_lang_dir = mw.language.getContentLanguage():getDir(); -- get this wiki's language direction

2. replace lines 515–517 with:

   	if (rtl or unicode.is_rtl(text)) and ('ltr' == this_wiki_lang_dir) then		-- text is right-to-left on a left-to-right wiki
   		table.insert (html, ' dir="rtl"');										-- add direction attribute for right-to-left languages
   	elseif not (rtl or unicode.is_rtl(text)) and ('rtl' == this_wiki_lang_dir) then	-- text is left-to-right on a right-to-left wiki
   		table.insert (html, ' dir="ltr"');										-- add direction attribute for left-to-right languages
   	end
   

3. delete lines 548–550 as unneeded

Other stuff that could be done to further i18n:

1. use the mw:Extension:Scribunto/Lua reference manual § Ustring library where appropriate
2. create tables of static text rendered or used by the module as a separate ~/Configuration module; some work on this has already been done and can be found in the ~/sandbox; don't know why it was never implemented

Most of my en.wiki 'career' has been with the cs1|2 module suite. Over time we have made some improvement to aid i18n. Often of those improvements have come from suggestions made at Help talk:Citation Style 1 by editors who were attempting to use the en.wiki module suite on their home wiki. I searched the archives of that page for your name; did not find it. If we don't know about changes that you think should be made to the cs1|2 module suite, the changes want to see will never be made.

—Trappist the monk (talk) 19:49, 24 December 2021 (UTC)

@Trappist the monk: No anger here whatsoever. I am highly critical of what is going on, but I am not angry. You are doing what you think is the right thing. (I did send the ping to the wrong person though, so thanks for clarifying that and sorry User:Paine Ellsworth for the confusion I may have caused).

See my comment below too. Hopefully the 'pudding' part makes it a bit more sweet and less bitter ;) In all seriousness, I think no individual user is at fault here. The problem is systemic, not personal. So why should I be angry at one person? huji—TALK 01:26, 25 December 2021 (UTC)

It's all good huji, all good. We're all volunteers here so I think we do the best we can with the tools given us. And it does seem to get better over time thanks to editors like you who keep us on our toes. Thanks for that and for your patience! P.I. Ellsworth - ed. ^put'r there 02:24, 25 December 2021 (UTC)

Thank you, huji, I usually don't get no respect when I edit templates and modules. One I do have great respect for is Trappist the monk, so when it comes to templates and modules, we both would do well to listen and learn. There will always be challenges when it comes to making one wiki's stuff work on other wikis, but we should never classify improving Wikipedia as a waste of time of any fashion. It is what we are all here for, after all. Happy holidays to you and yours! P.I. Ellsworth - ed. ^put'r there 00:36, 25 December 2021 (UTC)

@Paine Ellsworth: The phrase "we should never classify improving Wikipedia as a waste of time of any fashion" is not an accurate description of what is going on with regards to lack of i18n in templates and modules created in enwiki. It is not like enwiki editors (particularly, its more advanced users who edit modules and esoteric templates) are unaware of the fact that enwiki templates and modules are being copied by many other sister projects. The model in which one makes a non-i18n module here and leaves it for others to "improve" it elsewhere, is wasteful. Yes, both parties have produced something useful or "improved" it and thereby generated value. But the value that could have been generated if things were more thoughtfully designed in the first placed would substantially surpass the sum of values generated in this dysfunctional model.

Then again, I know there have been many efforts to create a central template/module/gadget platform with de facto i18n support (e.g., see phab:T121470 and linked tasks there) and it hasn't gotten anywhere meaningful. Once again, i think this is because incentives are not aligned.

I am glad you say you like to listen and learn. I just spent 10 or so minutes and reviewed a random sample of pages in the Module namespace that either you or User:Trappist the monk have edited in the last few months. Notably, none of them supported i18n (separation of messages from code logic) and at least for the ones I checked, I did not see any specific code addressing RTL/LTR specifics. The proof is in the pudding. huji—TALK 01:23, 25 December 2021 (UTC)

Early in this discussion I looked at fa:پودمان:Language/data/iana_languages and noticed that someone had (laboriously) replaced some of the English-language language names with their Persian equivalents. I have tweaked Module:lang/data so that it can, when directed, overwrite some of the English-language names with the names that MediaWiki knows about. The MediaWiki lists of tag/name pairs are much shorter than the IANA list that Module:Lang uses natively. Also, when MediaWiki does not have a language name in the local language for a particular tag, it falls-back to another language (typically English, but not always). Still, most if not all of the ISO 639-1 tags are covered plus a smattering of ISO 639-2, -3 tags. The module ignores the IETF-like language tags that MediaWiki supports. If those are needed, they must be added to the main override table.

—Trappist the monk (talk) 23:46, 5 February 2022 (UTC)

Hi, I have recent reasons to wonder if the Lang template is controversial among Wikipedia editors. Is it, and if so, can you direct me to or elaborate on why? Thought this might be a good place to inquire. – Elizabeth (Eewilson) (tag or ping me) (talk) 17:55, 10 January 2022 (UTC)

Why would you think so? Examples of the controversy?

—Trappist the monk (talk) 18:15, 10 January 2022 (UTC)

My reason for wondering is that in an article that appeared on DYK on 7 January, I had used the template to wrap German words and sentences, using the italic=no setting for the words that were proper nouns. Another editor removed them (not the latest version) soon after it was posted to the main page which, in turn, became a non-productive discussion on the talk page of the article. Another editor suggested I ask around to find out if there are opinions about the template. So I'm asking around. I need help, because either I have the wrong idea of how and/or when it should be used, or the other editor does. The Rationale section and documentation in the MOS explain its usage pretty clearly, I think. – Elizabeth (Eewilson) (tag or ping me) (talk) 18:27, 10 January 2022 (UTC)

This is not a {{lang}} issue per se because the template doesn't define en.wiki style. Rather, {{lang}} follows the style set by WP:MOS. So, I think that you should close this discussion and open one at a MOS talk page.

—Trappist the monk (talk) 18:48, 10 January 2022 (UTC)

Will do. So the Rationale section is based on the MOS? – Elizabeth (Eewilson) (tag or ping me) (talk) 18:53, 10 January 2022 (UTC)

That may be a chicken and egg question. The earliest 'justification' began as the second post in this talk page. Was there any discussion about rationale before that? Don't know.

—Trappist the monk (talk) 19:31, 10 January 2022 (UTC)

Per W3C conventions, {{lang}} shouldn’t be used on proper names. Thibaut (talk) 12:14, 6 February 2022 (UTC)

Hi, I was just adding a section on how to apply {{lang}} to links to the documentation and was mentioning three forms which do not work properly in article space. Oddly enough I found two of them to work in template docs and on article talk:

• [[{{lang|en|Book of hours}}]] → [[Book of hours]] (never works, obvious)
• [[Book of hours|{{lang|de|Stundenbuch}}]] → Stundenbuch (does not work in article space, works on talk and some other types of pages)
• {{ill|Machsor Lipsiae|de|lt={{lang|he-LA|Machsor Lipsiae}}}} → Machsor Lipsiae [de] (does not work in article space, works on talk and some other types of pages)

So, why do the two latter forms not work in article space either? --Matthiaspaul (talk) 22:14, 11 February 2022 (UTC)

[[{{lang|en|Book of hours}}]] doesn't work because there is html markup in what should become the url which becomes part of an <a href=<url goes here>>...</a> tag:

[[<span title="English-language text"><span lang="en">Book of hours</span></span>]]

[[Book of hours]]

For the others in main space, categories.

[[Book of hours|{{lang|de|Stundenbuch}}]]

[[Book of hours|<span title="German-language text"><i lang="de">Stundenbuch</i></span>[[Category:Articles containing German-language text]]]]

[[Book of hours|Stundenbuch]]

can't have a category link nested inside a wikilink

Module:Lang notes the namespace that the calling template is in and allows or inhibits categorization accordingly. Categories are allowed only in main space.

To link {{lang}} renderings in mainspace you must set |nocat=yes (or |cat=no).

—Trappist the monk (talk) 00:13, 12 February 2022 (UTC)

Hi Trappist, the first case was obvious, but I didn't thought of the embedded categories (and was in a hurry and didn't check the code to find it out myself). Thanks for the explanation.

--Matthiaspaul (talk) 15:47, 13 February 2022 (UTC)

I would like to suggest to extend the language-recognizing code in all related templates ({{lang}}, {{lang-x}}, {{transl}} for unnamed and relevant named parameters like |code=) so that they also accept language names and automatically convert them into the corresponding codes internally. Many people are not familiar with the language codes and for them it would be easier to enter something like:

{{lang|German|Tundra}}

and

{{lang|code=German|text=Tundra}}

rather than only

{{lang|de|Tundra}}

and

{{lang|code=de|text=Tundra}}

This would be easy to implement (basically, the code exists already) and consistent with what CS1/CS2, {{r}}, {{rp}} and {{ran}} do already, so it would also be good in regard to achieving a higher level of consistency among template interfaces. (Optionally and without any prio, a bot could occasionally go through articles and replace language names by language codes as it already happens for citations, but personally I would not care if the language names remain in the articles.) --Matthiaspaul (talk) 14:22, 14 February 2022 (UTC)

Hello. Currently the "Ancient Greek" link is set to Ancient Greek language, which is a redirect and isn't really relevant for this use. I'd like to send an edit request that this be fixed to use the direct link, which is Ancient Greek. Thanks. Mr. Lechkar (talk) 15:53, 29 October 2021 (UTC)

Lang templates automatically link to the article called "XXX language", which is why the redirect exists. Is there something that is broken? – Jonesey95 (talk) 16:23, 29 October 2021 (UTC)

Redirects are not bad. Wikipedia uses them a lot and has an efficient mechanism for handling them. They work regardless of how the target articles are actually named. Your request appears to have been made to suit your personal preference, is there a more substantive reason for your request? Are there technical or reader-facing issues that will be resolved were we to somehow code-around the use of redirects?

—Trappist the monk (talk) 16:36, 29 October 2021 (UTC)

I haven't check but assume that for some of the {{lang-x}} templates, the "X language" link target is the actual page name rather than a redirect.

I think we should even go one step further and make it a rule that all templates of the {{lang-x}} group should go through a specially crafted (and correspondingly r-cat'ed) redirect for this very purpose like "X (language)" instead of "X language". This would be similar to what we do with all identifiers going through "X (identifier)" redirects. This would help a lot to (further) unclutter "WhatLinksHere" and make it useable again.

--Matthiaspaul (talk) 14:53, 14 February 2022 (UTC)

While for us at enwiki this is most cosmetical only, I think, if we aim to produce a template which is easily portable into other languages (among many other things) we also need to ensure that the parameter interface logic is language-agnostic (even if the parameter names aren't). Our |rtl=yes/no is seeing the issue from our side only, whereas elsewhere they would rather come up with |ltr=yes/no. Trying to remain neutral on directionality I think we should offer |direction/dir=ltr/rtl instead (like HTML does). It would be easy to implement this as alternative (and then slowly fade out the |rtl=yes/no parameter over the years). --Matthiaspaul (talk) 15:18, 14 February 2022 (UTC)

Wondered if we had codes for, specifically, Anglo-Norman, Middle French or Old and Middle English, like we do with e.g. medieval Latin? Or a facility to create them? Not the most common choices I do understand  :) TIA! SN54129 16:03, 15 March 2022 (UTC)

Follow the links in your post and look in the infoboxen.

—Trappist the monk (talk) 16:08, 15 March 2022 (UTC)

Thanks very much! Mentioned you in despatches. SN54129 14:33, 16 March 2022 (UTC)