This is the
talk page for discussing improvements to the
Lang template. |
|
Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13Auto-archiving period: 120 days |
Template:Lang is permanently
protected from editing because it is a
heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by
consensus, editors may use {{
edit template-protected}} to notify an administrator or template editor to make the requested edit. Usually, any contributor may edit the template's
documentation to add usage notes or
categories.
Any contributor may edit the template's sandbox. Functionality of the template can be checked using test cases. |
This template was considered for deletion on 2006 February 20. The result of the discussion was "keep". |
To help centralise discussions and keep related topics together, the talk pages for all help pages, categories, MediaWiki messages and templates related to cite errors redirect here. |
Languages Template‑class | |||||||
|
|
|||||||||||||
This page has archives. Sections older than 120 days may be automatically archived by Lowercase sigmabot III. |
archived to Wikipedia_talk:Manual_of_Style/Text_formatting/Archive_7#Foreign-language_article_titles
31 August 2021 (UTC)
I've just noticed that use of codes for protolanguages, as in {{
lang|cel-x-proto|...}}
, forces a prepended * (indicating a construction unattested in surviving materials). This is undesirable, since in the vast majority of cases what we're going to be doing is replacing existing in-article strings with bare italics and no lang markup, like *''kal-''
, with templated replacements, e.g. *{{lang|cel-x-proto|kal-}}
, but this produces a double ** which has to be manually fixed. And there are apt to be tabular-data cases (interlinear glosses, etc.) in which an entire row of cells is prefixed with * and specific words or morphemes in particular cells follow this and should not each individually have * but should still have language markup. At bare minimum we need a way to suppress this "auto-*" behavior, but ideally it would be off by default and turned on only by a parameter switch, since it is unexpected, inconsistent, completely undocumented, and almost always editorially unhelpful. PS: If this does get changed, please ping me, since I will need to go fix
Caledonians#Etymology and some other things to have non-templated * again. —
SMcCandlish
☏
¢ 😼 07:35, 2 March 2024 (UTC)
{{lang|cel-x-proto|kal-}}
→ *kal-{{lang|cel-x-proto|kal-|proto=no}}
→ kal-{{lang-cel-x-proto|kal-}}
→
Proto-Celtic: *kal-{{lang-cel-x-proto|kal-|proto=no}}
→
Proto-Celtic: kal-Testing bullet-asterisk interaction with proto asterisk:
{{lang|cel-x-proto|kal-}}
Looks good. We should document Module code starting at line 791 of the Module in a new, level-4 subsection 'Proto' at Template:Lang, probably to live under section § Formatting. Mathglot ( talk) 20:05, 2 March 2024 (UTC)
in the vast majority of cases what we're going to be doing is replacing existing in-article strings with bare italics and no lang markup, likeIf the solution is changing*''kal-''
, with templated replacements, e.g.*{{lang|cel-x-proto|kal-}}
, but this produces a double ** which has to be manually fixed.
*''kal-''
to *{{lang|cel-x-proto|kal-|proto=no}}
or to {{lang|cel-x-proto|kal-}}
, I guess I can live with that, but I still think it would be preferable for the template to not force the * by default. —
SMcCandlish
☏
¢ 😼 05:07, 10 June 2024 (UTC)@ Trappist the monk: I need a private-use language tag for Anatolian languages. Antiquistik ( talk) 20:32, 6 April 2024 (UTC)
anat
work? Or is it already assigned?
Antiquistik (
talk) 21:51, 6 April 2024 (UTC)
ine-x-anatolia
work?
Antiquistik (
talk) 17:59, 15 April 2024 (UTC)
{{lang|ine-x-anatolia|text}}
→ textHas something changed with this? I don't know the ins and outs of the module/template but the way it displays at 2022 Comhairle nan Eilean Siar election has changed and I'm not sure what I'd need to alter so it displays correctly. Stevie fae Scotland ( talk) 13:35, 11 April 2024 (UTC)
{{lang-for||Scottish Gaelic|Council of the Western Isles}}
{{lang-for|gd||Council of the Western Isles}}
{{lang-for|gd|'''[[Comhairle nan Eilean Siar]]'''|Council of the Western Isles}}
{{lang-for|gd|[[Comhairle nan Eilean Siar]]|Council of the Western Isles}}
{{
lang-for}}
from a redirect to {{
Language with name/for}}
to a {{lang-??}}
template. That change broke the template on 2022 Comhairle nan Eilean Siar election. The editor did not explain why that change was made.
Special:WhatLinksHere/Template:Lang-for indicates that there may be more articles that were broken by this edit.{{lang-for}}
.{{
lang-isv}}
and other relevant templates for Interslavic
Interslavic has recently received an
ISO 639-3 code: isv
. Latin and Cyrillic are equal in status in Interslavic, just like in
Serbo-Croatian. –
Vipz (
talk) 09:34, 27 April 2024 (UTC)
isv
not listed in the current (2024-03-07) version of the IANA
language-subtag-registry file so nothing to be done yet.How does one correctly quote multiple translations using this template? I am trying to fix an issue on German Air Force, which includes in its lede the problematic lang-de template
German: Luftwaffe, lit. 'air weapon or air arm'
from the source code
{{lang-de|'''Luftwaffe'''|lit=air weapon or air arm}}
which is not quoted correctly. I can fix this by doing
{{lang-de|'''Luftwaffe'''|lit=air weapon' or 'air arm}}
leading to
German: Luftwaffe, lit. 'air weapon' or 'air arm'
but this is a rather inelegant hack. Is there a better way to quote multiple lit values?
I have searched the talk archives here but couldn't find anything if this had been asked before. Thanks, Ain lina (box) ? 15:30, 29 April 2024 (UTC)
|lit=air force
is a better choice for the lead. If you wish to delve into the etymology of the word, perhaps a footnote linking the Wiktionary German entry for
Luftwaffe is appropriate.For some reason, Category:Articles containing Dogrib-language text has started showing an error message (Error: Dogrib is not a valid ISO 639 or IETF language name. Please see Template talk:Lang for assistance.), is empty, and has been tagged for speedy deletion. We still have an article at Dogrib language, and the ISO 639 code is still dgr. It appears that articles that should be placed into that category are now being placed into the new (as of 22 May 2024) Category:Articles containing Tlicho-language text. I don't know what happened behind the scenes (maybe this change?), but we have an inconsistency between our article name and our category naming, which is undesirable. – Jonesey95 ( talk) 23:41, 27 May 2024 (UTC)
dgr
name list is the result of
this change request. That update is reflected in
this update to
Module:Language/data/ISO 639-3. Subsequently, IANA incorporated that change (in reverse name-order in the 2024-05-16 update to their
language-subtag-registry file which is reflected in
this update to
Module:Language/data/iana languages.Given that I edit ancient history articles, I have to use this template extensively for a large range of languages, and I'm finding some lacks in it that limit my ability to edit:
{{lang-
form of the template should also display a label for the name of the language used similar to when using the {{lang|
form;{{lang|
form needs a |translit=
option that works just like it does with the {{lang-...
form;|translit=
needs an option where there is a comma instead of the romanized: label usually preceding the transcription in addition to the already existing format with the romanized: label;{{lang-hlu|𔕬𔗬𔑣𔓯𔗔}} <small>and</small> {{lang|hlu|𔕬𔓬𔑣𔕣}}, <small>romanized</small> {{transl|akk-x-neobabyl|Tuwaddis}}
{{lang-hlu|𔓟𔖱𔐞𔕯𔗔}}, {{lang|hlu|𔓟𔖱𔐞𔗣𔗔}} and {{lang|hlu|𔗖𔐞𔕯𔗔}}, <small>romanized:</small> {{transl|hlu|Ḫartapus}}
{{lang-akk-x-neoassyr|𒁹𒌇𒁮𒈨𒄿|translit=Tugdammî}} <small>or</small> {{transl|akk-x-neoassyr|Dugdammî}}
{{lang-akk-x-neoassyr|𒁹𒄖𒊌𒄖|translit=Gugu}} <small>and</small> {{transl|akk-x-neoassyr|Guggu}}
{{transl|akk-x-neoassyr|māt Tabali}} ({{lang|akk-x-neoassyr|𒆳𒋫𒁀𒇷}}, {{lang|akk-x-neoassyr|𒆳𒋫𒁀𒀀𒇷}}, {{lang|akk-x-neoassyr|𒆳𒋫𒁄𒇷}}, {{lang|akk-x-neoassyr|𒆳𒋰𒀀𒇷}})
{{script}}
into the {{lang}}
template would also be useful because sometimes the coding takes too much space in the article or using it makes the article unnecessarily big so that it would be preferable to shift this onto the templates instead.
{{lang-ae|}}
and {{lang|ae|}}
should have a parameter that functions in the same way as if {{lang-ae|{{script|Avst|}}}}
and {{lang|ae|{{script|Avst|}}}}
were used.
{{script|Grek|}}
and {{script|Latn|}}
render the text in a font that is difficult to read and are therefore already discouraged.-
in the text parameter followed by the transliteration in the template displays the language followed by the transliteration.
{{lang-sa|-|bharu}}
should give something that displays like
Sanskrit: bharu.Would it be feasible to modify the template so as to remove any or some or even all of these current limitations? Antiquistik ( talk) 15:01, 28 May 2024 (UTC)
{{lang-??}}
already has a wikilinked language label, using the label=
html attribute is considered redundant or superfluous{{
transliteration}}
exists to serve that purpose{{
transcript}}
might be created; you will need to work out details of its implementation{{
lang}}
may take more space, but space in a Wikipedia article is not an issue; this is not a dead tree encyclopedia{{transliteration-??}}
templates might be created; you will need to work out the implementation details{{
transliteration}}
and {{lang|}}
for this purpose is too cumbersome and unwieldy. Adding a |translit=
parameter to {{lang|}}
would be the best option.{{desc|
template, minus creating a link for the term. However, the options for the first four sub-issues should be integrated into {{lang|}}
/{{lang-}}
.{{
lang}}
as well. There are articles in some scripts that really do need a Name in script, followed by a transliteration, followed by a transcription, option. This is especially important because the present |translit=
parameter is presently used for transcription instead than transliteration but otherwise still require both transcription and transliterations, including in articles that are not part of the topics that I cover.{{transliteration}}
template and the option to insert a nil parameter in the present template as well.akk-x-latbabyl
to render as "Late Babylonian Akkadian" rather than simply as "Late Babylonian" as it now does?I have been looking at Kashmiri language and wondering why it takes a long time to build the page.
In the timing stats on the page, the lua function gcodepoint_init is high on the list. Looking at the wikitext of the page, templates of the form {{#invoke:lang|lang|ks|{{uninastaliq... (of which there are over 900) are responsible for this timing. For each of these calls, gcodepoint_init is called three times.
The call to gcodepoint_init actually comes from Module:Unicode_data is_Latin
Now to the point, Module:Lang calls is_Latin from line 988 and is_rtl (which calls is_Latin) from lines 549 and 551.
The call to is_rtl could be made once and then used in the two succeeding if statements - hence saving a call Desb42 ( talk) 08:16, 7 June 2024 (UTC)
At Template talk:Lang-sh#HBS?, we've had a question whether to use "sh" or "hbs" as the template name/code. Is this a doable change, is there something to think about? The first thing that occurs to me is that the TFD notice would clutter a lot of lead sections... -- Joy ( talk) 15:05, 8 June 2024 (UTC)
sh
is the
IETF BCP 47 language subtag utilized for
Serbo-Croatian, and these are the basis for Wikipedia's lang templates and by extent subdomains (which is the reason sh.wikipedia.org does not need to move to hbs.wikipedia.org). –
Vipz (
talk) 16:37, 8 June 2024 (UTC)
Registry comment: sr, hr, bs are preferred for most modern uses
sh is a macrolanguage that encompasses the following more specific primary language subtags: bs hr sr cnr. If it doesn't break legacy usage for your application, you should use one of these more specific language subtags instead. On the other hand, sh is often preferred by legacy applications rather than sr (Serbian).
Why are we at en.wp using, e.g., gem-x-proto while en.wikt is using gem-pro? Is one site or other making a grave mistake? — SMcCandlish ☏ ¢ 😼 04:39, 10 June 2024 (UTC)
This is the
talk page for discussing improvements to the
Lang template. |
|
Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13Auto-archiving period: 120 days |
Template:Lang is permanently
protected from editing because it is a
heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by
consensus, editors may use {{
edit template-protected}} to notify an administrator or template editor to make the requested edit. Usually, any contributor may edit the template's
documentation to add usage notes or
categories.
Any contributor may edit the template's sandbox. Functionality of the template can be checked using test cases. |
This template was considered for deletion on 2006 February 20. The result of the discussion was "keep". |
To help centralise discussions and keep related topics together, the talk pages for all help pages, categories, MediaWiki messages and templates related to cite errors redirect here. |
Languages Template‑class | |||||||
|
|
|||||||||||||
This page has archives. Sections older than 120 days may be automatically archived by Lowercase sigmabot III. |
archived to Wikipedia_talk:Manual_of_Style/Text_formatting/Archive_7#Foreign-language_article_titles
31 August 2021 (UTC)
I've just noticed that use of codes for protolanguages, as in {{
lang|cel-x-proto|...}}
, forces a prepended * (indicating a construction unattested in surviving materials). This is undesirable, since in the vast majority of cases what we're going to be doing is replacing existing in-article strings with bare italics and no lang markup, like *''kal-''
, with templated replacements, e.g. *{{lang|cel-x-proto|kal-}}
, but this produces a double ** which has to be manually fixed. And there are apt to be tabular-data cases (interlinear glosses, etc.) in which an entire row of cells is prefixed with * and specific words or morphemes in particular cells follow this and should not each individually have * but should still have language markup. At bare minimum we need a way to suppress this "auto-*" behavior, but ideally it would be off by default and turned on only by a parameter switch, since it is unexpected, inconsistent, completely undocumented, and almost always editorially unhelpful. PS: If this does get changed, please ping me, since I will need to go fix
Caledonians#Etymology and some other things to have non-templated * again. —
SMcCandlish
☏
¢ 😼 07:35, 2 March 2024 (UTC)
{{lang|cel-x-proto|kal-}}
→ *kal-{{lang|cel-x-proto|kal-|proto=no}}
→ kal-{{lang-cel-x-proto|kal-}}
→
Proto-Celtic: *kal-{{lang-cel-x-proto|kal-|proto=no}}
→
Proto-Celtic: kal-Testing bullet-asterisk interaction with proto asterisk:
{{lang|cel-x-proto|kal-}}
Looks good. We should document Module code starting at line 791 of the Module in a new, level-4 subsection 'Proto' at Template:Lang, probably to live under section § Formatting. Mathglot ( talk) 20:05, 2 March 2024 (UTC)
in the vast majority of cases what we're going to be doing is replacing existing in-article strings with bare italics and no lang markup, likeIf the solution is changing*''kal-''
, with templated replacements, e.g.*{{lang|cel-x-proto|kal-}}
, but this produces a double ** which has to be manually fixed.
*''kal-''
to *{{lang|cel-x-proto|kal-|proto=no}}
or to {{lang|cel-x-proto|kal-}}
, I guess I can live with that, but I still think it would be preferable for the template to not force the * by default. —
SMcCandlish
☏
¢ 😼 05:07, 10 June 2024 (UTC)@ Trappist the monk: I need a private-use language tag for Anatolian languages. Antiquistik ( talk) 20:32, 6 April 2024 (UTC)
anat
work? Or is it already assigned?
Antiquistik (
talk) 21:51, 6 April 2024 (UTC)
ine-x-anatolia
work?
Antiquistik (
talk) 17:59, 15 April 2024 (UTC)
{{lang|ine-x-anatolia|text}}
→ textHas something changed with this? I don't know the ins and outs of the module/template but the way it displays at 2022 Comhairle nan Eilean Siar election has changed and I'm not sure what I'd need to alter so it displays correctly. Stevie fae Scotland ( talk) 13:35, 11 April 2024 (UTC)
{{lang-for||Scottish Gaelic|Council of the Western Isles}}
{{lang-for|gd||Council of the Western Isles}}
{{lang-for|gd|'''[[Comhairle nan Eilean Siar]]'''|Council of the Western Isles}}
{{lang-for|gd|[[Comhairle nan Eilean Siar]]|Council of the Western Isles}}
{{
lang-for}}
from a redirect to {{
Language with name/for}}
to a {{lang-??}}
template. That change broke the template on 2022 Comhairle nan Eilean Siar election. The editor did not explain why that change was made.
Special:WhatLinksHere/Template:Lang-for indicates that there may be more articles that were broken by this edit.{{lang-for}}
.{{
lang-isv}}
and other relevant templates for Interslavic
Interslavic has recently received an
ISO 639-3 code: isv
. Latin and Cyrillic are equal in status in Interslavic, just like in
Serbo-Croatian. –
Vipz (
talk) 09:34, 27 April 2024 (UTC)
isv
not listed in the current (2024-03-07) version of the IANA
language-subtag-registry file so nothing to be done yet.How does one correctly quote multiple translations using this template? I am trying to fix an issue on German Air Force, which includes in its lede the problematic lang-de template
German: Luftwaffe, lit. 'air weapon or air arm'
from the source code
{{lang-de|'''Luftwaffe'''|lit=air weapon or air arm}}
which is not quoted correctly. I can fix this by doing
{{lang-de|'''Luftwaffe'''|lit=air weapon' or 'air arm}}
leading to
German: Luftwaffe, lit. 'air weapon' or 'air arm'
but this is a rather inelegant hack. Is there a better way to quote multiple lit values?
I have searched the talk archives here but couldn't find anything if this had been asked before. Thanks, Ain lina (box) ? 15:30, 29 April 2024 (UTC)
|lit=air force
is a better choice for the lead. If you wish to delve into the etymology of the word, perhaps a footnote linking the Wiktionary German entry for
Luftwaffe is appropriate.For some reason, Category:Articles containing Dogrib-language text has started showing an error message (Error: Dogrib is not a valid ISO 639 or IETF language name. Please see Template talk:Lang for assistance.), is empty, and has been tagged for speedy deletion. We still have an article at Dogrib language, and the ISO 639 code is still dgr. It appears that articles that should be placed into that category are now being placed into the new (as of 22 May 2024) Category:Articles containing Tlicho-language text. I don't know what happened behind the scenes (maybe this change?), but we have an inconsistency between our article name and our category naming, which is undesirable. – Jonesey95 ( talk) 23:41, 27 May 2024 (UTC)
dgr
name list is the result of
this change request. That update is reflected in
this update to
Module:Language/data/ISO 639-3. Subsequently, IANA incorporated that change (in reverse name-order in the 2024-05-16 update to their
language-subtag-registry file which is reflected in
this update to
Module:Language/data/iana languages.Given that I edit ancient history articles, I have to use this template extensively for a large range of languages, and I'm finding some lacks in it that limit my ability to edit:
{{lang-
form of the template should also display a label for the name of the language used similar to when using the {{lang|
form;{{lang|
form needs a |translit=
option that works just like it does with the {{lang-...
form;|translit=
needs an option where there is a comma instead of the romanized: label usually preceding the transcription in addition to the already existing format with the romanized: label;{{lang-hlu|𔕬𔗬𔑣𔓯𔗔}} <small>and</small> {{lang|hlu|𔕬𔓬𔑣𔕣}}, <small>romanized</small> {{transl|akk-x-neobabyl|Tuwaddis}}
{{lang-hlu|𔓟𔖱𔐞𔕯𔗔}}, {{lang|hlu|𔓟𔖱𔐞𔗣𔗔}} and {{lang|hlu|𔗖𔐞𔕯𔗔}}, <small>romanized:</small> {{transl|hlu|Ḫartapus}}
{{lang-akk-x-neoassyr|𒁹𒌇𒁮𒈨𒄿|translit=Tugdammî}} <small>or</small> {{transl|akk-x-neoassyr|Dugdammî}}
{{lang-akk-x-neoassyr|𒁹𒄖𒊌𒄖|translit=Gugu}} <small>and</small> {{transl|akk-x-neoassyr|Guggu}}
{{transl|akk-x-neoassyr|māt Tabali}} ({{lang|akk-x-neoassyr|𒆳𒋫𒁀𒇷}}, {{lang|akk-x-neoassyr|𒆳𒋫𒁀𒀀𒇷}}, {{lang|akk-x-neoassyr|𒆳𒋫𒁄𒇷}}, {{lang|akk-x-neoassyr|𒆳𒋰𒀀𒇷}})
{{script}}
into the {{lang}}
template would also be useful because sometimes the coding takes too much space in the article or using it makes the article unnecessarily big so that it would be preferable to shift this onto the templates instead.
{{lang-ae|}}
and {{lang|ae|}}
should have a parameter that functions in the same way as if {{lang-ae|{{script|Avst|}}}}
and {{lang|ae|{{script|Avst|}}}}
were used.
{{script|Grek|}}
and {{script|Latn|}}
render the text in a font that is difficult to read and are therefore already discouraged.-
in the text parameter followed by the transliteration in the template displays the language followed by the transliteration.
{{lang-sa|-|bharu}}
should give something that displays like
Sanskrit: bharu.Would it be feasible to modify the template so as to remove any or some or even all of these current limitations? Antiquistik ( talk) 15:01, 28 May 2024 (UTC)
{{lang-??}}
already has a wikilinked language label, using the label=
html attribute is considered redundant or superfluous{{
transliteration}}
exists to serve that purpose{{
transcript}}
might be created; you will need to work out details of its implementation{{
lang}}
may take more space, but space in a Wikipedia article is not an issue; this is not a dead tree encyclopedia{{transliteration-??}}
templates might be created; you will need to work out the implementation details{{
transliteration}}
and {{lang|}}
for this purpose is too cumbersome and unwieldy. Adding a |translit=
parameter to {{lang|}}
would be the best option.{{desc|
template, minus creating a link for the term. However, the options for the first four sub-issues should be integrated into {{lang|}}
/{{lang-}}
.{{
lang}}
as well. There are articles in some scripts that really do need a Name in script, followed by a transliteration, followed by a transcription, option. This is especially important because the present |translit=
parameter is presently used for transcription instead than transliteration but otherwise still require both transcription and transliterations, including in articles that are not part of the topics that I cover.{{transliteration}}
template and the option to insert a nil parameter in the present template as well.akk-x-latbabyl
to render as "Late Babylonian Akkadian" rather than simply as "Late Babylonian" as it now does?I have been looking at Kashmiri language and wondering why it takes a long time to build the page.
In the timing stats on the page, the lua function gcodepoint_init is high on the list. Looking at the wikitext of the page, templates of the form {{#invoke:lang|lang|ks|{{uninastaliq... (of which there are over 900) are responsible for this timing. For each of these calls, gcodepoint_init is called three times.
The call to gcodepoint_init actually comes from Module:Unicode_data is_Latin
Now to the point, Module:Lang calls is_Latin from line 988 and is_rtl (which calls is_Latin) from lines 549 and 551.
The call to is_rtl could be made once and then used in the two succeeding if statements - hence saving a call Desb42 ( talk) 08:16, 7 June 2024 (UTC)
At Template talk:Lang-sh#HBS?, we've had a question whether to use "sh" or "hbs" as the template name/code. Is this a doable change, is there something to think about? The first thing that occurs to me is that the TFD notice would clutter a lot of lead sections... -- Joy ( talk) 15:05, 8 June 2024 (UTC)
sh
is the
IETF BCP 47 language subtag utilized for
Serbo-Croatian, and these are the basis for Wikipedia's lang templates and by extent subdomains (which is the reason sh.wikipedia.org does not need to move to hbs.wikipedia.org). –
Vipz (
talk) 16:37, 8 June 2024 (UTC)
Registry comment: sr, hr, bs are preferred for most modern uses
sh is a macrolanguage that encompasses the following more specific primary language subtags: bs hr sr cnr. If it doesn't break legacy usage for your application, you should use one of these more specific language subtags instead. On the other hand, sh is often preferred by legacy applications rather than sr (Serbian).
Why are we at en.wp using, e.g., gem-x-proto while en.wikt is using gem-pro? Is one site or other making a grave mistake? — SMcCandlish ☏ ¢ 😼 04:39, 10 June 2024 (UTC)