Jump to content

Template talk:Lang/Archive 13

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 10Archive 11Archive 12Archive 13

Are there times this template shouldn't be used?

Should all text in a foreign language have this template? Should books, building names etc. also use this? I ask from a position of complete ignorance on the point! Cheers - SchroCat (talk) 16:34, 28 October 2023 (UTC)

{{lang}} should not be used in citation templates ({{cite book}} etc.) except in the |quote= parameter (though I think that if a quotation is important to the article, the quotation should be placed in the article body and properly cited – quotations need citations, citations do not need quotations). Outside of citation templates, I think that {{lang}} should be used for all non-English text so that browsers display the text using appropriate fonts and screen readers have the opportunity to pronounce the non-English text as it should be pronounced.
—Trappist the monk (talk) 16:56, 28 October 2023 (UTC)
So! A bit of backstory, but it shouldn't be too technical: This template has to do with the HTML standard, which semantically organizes documents. It takes care of underlying HTML markup: according to the standard, all documents must declare their language (or specifically declare an unknown or no language). Since this is the English Wikipedia, at the very top of the document, it declares that the whole page (the root <html>...</html>) is in English with the lang="en" parameter. Documents without a lang parameter are invalid. You can read more here, at MDN.
Specific parts within the document, actually any HTML tag, can have another language specified. This is very important for applications like screen readers (which can switch to a voice spoken in another language), for example. Screen readers are a good example of the general issue: logically, the document has said it's in English. If there's non-English text there that doesn't declare it's in another language, this makes the document's statement incorrect, and can lead to problems if software is built to take advantage of HTML language specification.
As stated on the template page, the place it shouldn't be used is in certain citation templates, because the order in which templates are parsed becomes an issue, and it clogs the citation metadata. There are parameters within those templates that allow you to specify when that metadata is in another language, which will appropriately apply the lang parameter within the HTML document.
So that is to say: yes, absolutely. If a word is not an English word, it should be tagged. (Though, of course, with place names and such, the boundary is distinctly less clear, so I am not bemoaning that. But keep the principle in mind!) Remsense聊 17:00, 28 October 2023 (UTC)
  • Excellent - thanks very much to you both. Cheers - SchroCat (talk) 18:59, 28 October 2023 (UTC)
    In practice, lang templates have generally not been used with proper names very much in our articles, though probably they should be, e.g. {{lang|ga|Caoimhín Ó Raghallaigh|italic=unset}} – that last parameter to keep from italicizing it, since we wouldn't italicize a personal or geographical name, except when contrasting it with an anglicization, as in "Munich (German: München)". It would actually be helpful to screen readers and such to use the template this way (I shudder to think what a screen reader does when trying to interpret "Caoimhín Ó Raghallaigh" as something to pronounce as if it's English), but it would be a really large job to actually implement that, and some resistance might be met, since it complicates the wikicode.  — SMcCandlish ☏ ¢ 😼  01:11, 29 October 2023 (UTC)
    SMcCandlish, with regard to 'probably should be used more', I've just gone and created {{langr}} (for 'roman') that's a quick alias for {{lang|italic=unset}}. I know it's a few characters, but the lack of an extra parameter really seems to incentivize the quicker use of templates—does for me anyhow. — Remsense聊 01:29, 29 October 2023 (UTC)
    Thank you for that gift! I don't think I will fix the thousand of "italic=no", but one letter instead of an extra parameter is a relief! Perhaps a bot could change the older ones, to make users aware it exists. --Gerda Arendt (talk) 07:29, 29 October 2023 (UTC)
    Gerda Arendt, i certainly think it's worth the extra category entry/name to remember/what have you, it's a relief that others seem to agree :)! i just tend to swap it out in articles i'm editing to make things easier to read within the article (alongside adding to other places of course) — Remsense聊 10:48, 29 October 2023 (UTC)
    Hopefully that will actually work out in getting people to use it.  — SMcCandlish ☏ ¢ 😼  02:09, 29 October 2023 (UTC)
    I will be using it, in any case. My main thing is Chinese, and the screenreader I tested doesn't do very well with nondiacritical pinyin, even though it could, so I was wondering if there was even a point to tagging it, but I definitely should regardless, per my own essay above. Remsense聊 02:15, 29 October 2023 (UTC)
    I tried an implementation of this in a live article [1] at Caoimhín Ó Raghallaigh (along with some other cleanup there). I haven't pored over the code of {{langr}}, but I assume it passes-through other parameters like for RtL text, etc. As for Chinese rendering, I'm really not sure what the best approach is, when it comes to various different romanization systems. There may be advice about this somewhere, at Wikipedia:Manual of Style/China- and Chinese-related articles or talk page thereof, or at Template:Lang-zh. May need to account for parameters that specify transliteration.  — SMcCandlish ☏ ¢ 😼  02:36, 29 October 2023 (UTC)
    SMcCandlish, all it does is call the same module {{lang}} does, but sets the italics parameter for you. So, if it has issues, I would be really worried! — Remsense聊 02:38, 29 October 2023 (UTC)
    Ah, I think it will need to handle additional parameters of {{lang}}, like |rtl= and |size= and definitely |nocat= and |cat=, in a pass-through manner. I don't know if any of the special parameters for {{lang-zh}} are also supported (or needed) by {{lang|zh}}.  — SMcCandlish ☏ ¢ 😼  02:43, 29 October 2023 (UTC)
    I will do some testing of those ASAP, thanks for letting me know. Remsense聊 02:44, 29 October 2023 (UTC)
    Update: I don't think you need to do anything manually to the template code. I'm really old-school with templates, and don't spend much time messing about with Lua modules; it wasn't clear to me that by invoking the same module it just auto-handles the parameters. I just tested [[Caoimhín Ó Raghallaigh|{{langr|ga|Ó Raghallaigh|nocat=y}}]] in a mainspace sandbox (the categorization stuff only happens in mainspace), and it worked fine. If the module wasn't "magically" getting the |nocat=y despite it not being explicitly named in the template code, then the link would have been mangled, by having a category link jammed inside of it.  — SMcCandlish ☏ ¢ 😼  12:09, 29 October 2023 (UTC)

Whole-page wrapper idea

"but it would be a really large job to actually implement that, and some resistance might be met, since it complicates the wikicode"

That's why we need some template that will be wrapped around the whole article with lang parameters for every non-English word used in the article. E.g. in Alvar Aalto: 
{{Lang-wrapper|fi=Alvar,Aalto,Aino,Jyväskylä|sv=Ahlström-Gullichsen|de=Gesamtkunstwerk|article=
*START OF THE ARTICLE; i.e. {{Short description}}, {{Infobox}} etc.*
'''Hugo Alvar Henrik Aalto''' ({{IPA-fi|ˈhuːɡo ˈɑlʋɑr ˈhenrik ˈɑːlto|pron}}; 3 February 1898 – 11 May 1976) was a Finnish [[architect]] and designer.&lt;ref name=Chilvers&gt;{{harvnb|Chilvers|2004|p=1}}&lt;/ref&gt; His work includes architecture, furniture, [[textiles]] and [[glassware]], as well as sculptures and paintings. He never regarded himself as an artist, seeing painting and sculpture as "branches of the tree whose trunk is architecture."&lt;ref name=Enckell&gt;{{harvnb|Enckell|1998|p=32}}&lt;/ref&gt; Aalto's early career ran in parallel with the rapid economic growth and industrialization of Finland during the first half of the 20th century. Many of his clients were industrialists, among them the [[Ahlström-Gullichsen family]], who became his patrons.&lt;ref name="Ahlström"&gt;{{harvnb|Anon|2013}}&lt;/ref&gt; The span of his career, from the 1920s to the 1970s, is reflected in the styles of his work, ranging from [[Nordic Classicism]] of the early work, to a rational [[International Style (architecture)|International Style]] Modernism during the 1930s to a more organic modernist style from the 1940s onwards.

His architectural work, throughout his entire career, is characterized by a concern for design as [[Gesamtkunstwerk]]—a ''total work of art'' in which he, together with his first wife [[Aino Aalto]], would design not only the building but the interior surfaces, furniture, lamps, and glassware as well. His furniture designs are considered [[Scandinavian design|Scandinavian Modern]], an aesthetic reflected in their elegant simplification and concern for materials, especially wood, but also in Aalto's technical innovations, which led him to receiving patents for various manufacturing processes, such as those used to produce bent wood.&lt;ref name=Boy&gt;{{harvnb|Boyce|1985|p=1}}&lt;/ref&gt; As a designer he is celebrated as a forerunner of [[Mid-century modern|midcentury modernism]] in design; his invention of bent plywood furniture&lt;ref&gt;{{Cite book|last=Norwich|first=John Julius|title=Oxford Illustrated Encyclopedia of the Arts|publisher=Oxford University Press|year=1990|isbn=978-0-19-869137-2|location=US|pages=1}}&lt;/ref&gt; had a profound impact on the aesthetics of [[Charles and Ray Eames]] and [[George Nelson (designer)|George Nelson]].&lt;ref&gt;{{Cite web|title=Alvar Aalto|url=https://www.dwr.com/designer-alvar-aalto?lang=en_US|website=www.dwr.com}}&lt;/ref&gt; The [[Alvar Aalto Museum]], designed by Aalto himself, is located in what is regarded as his home city, [[Jyväskylä]].&lt;ref&gt;{{harvnb|Alvar Aalto Museum|2011}}&lt;/ref&gt;

(...)

*END OF THE ARTICLE; i.e. navigation boxes, [[Category:Finnish people]] etc.*

}} (-> closing curly brackets of "Lang-wrapper")
So, |fi=Alvar,Aalto,Aino,Jyväskylä would mark all occurrences of the words Alvar, Aalto, Aino and Jyväskylä as Finnish-language text in the whole article, |sv=Ahlström-Gullichsen would mark Ahlström-Gullichsen as Swedish-language text and |de=Gesamtkunstwerk would mark Gesamtkunstwerk as German-language text. Now I don't know if this is technically possible to implement, so this is just an idea for now. 2001:14BA:9CE5:8400:9D39:7444:AD64:FBB1 (talk) 03:02, 29 October 2023 (UTC)
That seems particularly resource intensive and non-canonical for how Wikipedia operates. Remsense聊 03:06, 29 October 2023 (UTC)
I'm not sure that it's technically even doable. Even if it were, there are instances where the underlying HTML lang="xx" markup cannot be imposed (with <span>...</span> or otherwise), e.g. on most parameter values in citation templates other than |quote=. Or on terms that are bare wikilinks or are on the left side of piped links. Or terms inside URLs. Or .... And certainly nothing like this would be done as a page-wide wrapper for the entire article content. Ever. For any reason.  — SMcCandlish ☏ ¢ 😼  06:40, 29 October 2023 (UTC)

HTML code streamlining question

Resolved

Is there a good reason this is emitting double spans, or a span plus italics?

Given code of the form {{lang|ga|srón}} and {{lang|ga|Pádraig|italic=unset}}, the output is, respectively:

<span title="Irish-language text"><i lang="ga">srón</i></span>
<span title="Irish-language text"><span lang="ga">Pádraig</span></span>

That looks like code bloat, and would be better rendered as:

<span title="Irish-language text" lang="ga"><i>srón</i></span>
<span title="Irish-language text" lang="ga">Pádraig</span>

using a single span for language-related metadata, and just adding a bare <i>...</i> if it is needed.

Likewise for other parameter stuff that needs to translate into language-related metadata. E.g. {{lang|he|עבר‎}} gives:

<span title="Hebrew-language text"><span lang="he" dir="rtl">עבר‎</span></span>

which would be leaner and cleaner as:

<span title="Hebrew-language text" lang="he" dir="rtl">עבר‎</span>

 — SMcCandlish ☏ ¢ 😼  11:50, 29 October 2023 (UTC)

Template talk:Lang/Archive 11 § Lang and title param
—Trappist the monk (talk) 12:03, 29 October 2023 (UTC)
Ah, yes, that would explain it. Thank you.  — SMcCandlish ☏ ¢ 😼  12:12, 29 October 2023 (UTC)

Inline translations

Is there a mechanism for including English language translations of foreign terms?

Currently I'm using efn for this:

the {{lang|fr|Nid de la Poule}}{{efn|Hen's Nest}} crater
...
{{notelist}}

Which produces this (normally the note is displayed in a tooltip):

the Nid de la Poule[a] crater

  1. ^ Hen's Nest

Something like this would be cleaner though:

the {{lang|fr|Nid de la Poule|translation=Hen's Nest}} crater

See, e.g., Puy_de_Dôme#Tourism

Alex Hajnal (talk) 22:33, 5 November 2023 (UTC)

Not in {{lang}} but you might rewrite that sentence somehow and use:
The summit can be reached by two [[Trail|pedestrian paths]]: a southern one ({{langx|fr|Le sentier des muletiers|translation=The Mule Trail}}, formerly a [[Roman road]]) and a northern one ({{langx|fr|Le sentier des chèvres|translation=The Goat Trail|label=none}}) which runs past the {{langx|fr|Nid de la Poule|translation=Hen's Nest|label=none}} crater.
The summit can be reached by two pedestrian paths: a southern one (French: Le sentier des muletiers, lit. 'The Mule Trail', formerly a Roman road) and a northern one (Le sentier des chèvres, 'The Goat Trail') which runs past the Nid de la Poule, 'Hen's Nest' crater.
or just include the translations parenthetically in the sentence:
...the {{lang|fr|Nid de la Poule}} ('Hen's Nest') crater → ...the Nid de la Poule ('Hen's Nest') crater
—Trappist the monk (talk) 23:06, 5 November 2023 (UTC)
Do you think there's anything inherently wrong with using efn for this? Edit: I presume using lang-fr would be highly enouraged.Alex Hajnal (talk) 23:16, 5 November 2023 (UTC)
You can pretty-much do what you want. From a reader's point of view, using {{efn}} for such short translations seems to require more work than perhaps it's worth because the reader has to, at minimum, float their mouse-pointer over the {{efn}} superscript in order to see what is hidden there. I neither encourage nor discourage the use of {{lang-fr}}; I merely offer it as an option that you can consider.
—Trappist the monk (talk) 23:35, 5 November 2023 (UTC)
Definitely the most common way to do this is with {{lang}} and plain-English after it:
...the {{lang|fr|Nid de la Poule|italic=unset}} ('Hen's Nest') crater → ...the Nid de la Poule ('Hen's Nest') crater
or
...the {{lang|fr|Nid de la Poule|italic=unset}} crater (the name of which means 'Hen's Nest') → ...the Nid de la Poule crater (the name of which means 'Hen's Nest')
(with |italic=unset in this specific kind of case because we don't italicize proper names in most cases). It requires no footnote futzing-around for the reader, and is more flexible and less template-geeky for the editor, compared to something like:
...the {{langx|fr|Nid de la Poule|translation=Hen's Nest|label=none|italic=unset}}, crater → ...the Nid de la Poule, 'Hen's Nest', crater
Japanese is kinda-conventionally a special case, often done with a complex template called {{Nihongo}}, which participants at WP:JAPAN are big fans of, but some of us are not, at least not for cases of this sort (versus, perhaps, the opening line of an article on Japanese subject).  — SMcCandlish ☏ ¢ 😼  15:01, 6 November 2023 (UTC)
OK, thanks for the feedback.
My rationale was to not break up the flow of the sentences too much with a lot of clauses and parentheticals. Of course, requiring/encouraging the mousing-over of the superscript breaks the flow as well. Bit of a double-edged sword.
Browsing though the docs it looks like Template:tooltip is also an option:

{{lang|fr|{{tooltip|Nid de la Poule|Hen's Nest}}}}

Giving:

Nid de la Poule

Thanks again.

Alex Hajnal (talk) 18:54, 7 November 2023 (UTC)

Needs Proto-Germanic

If it's already there, then it just needs to be set to understand Wiktionary's gem-pro code as referring to Proto-Germanic and to add the necessary italics and HTML tags. — LlywelynII 00:38, 11 December 2023 (UTC)

{{lang|fn=name_from_tag|gem-x-proto}} → Proto-Germanic – listed at Template:Lang § Private-use language tags.
gem-pro is not a valid IETF language tag. To be valid, the extlang subtag must be defined in the IANA language-subtag-registry file. That file does not list pro as an extlang. Because all currently defined extlangs refer to languages that have primary language tags, Module:Lang does not support extlangs.
—Trappist the monk (talk) 01:43, 11 December 2023 (UTC)
Can't this be done (using some code or other) with the private-use codes described in #New codes, above? I wouldn't mind having one for Proto-Celtic using cel- as the base.  — SMcCandlish ☏ ¢ 😼  22:51, 11 December 2023 (UTC)
For Proto-Germanic we have the private-use tag: gem-x-proto. Similarly, for Proto-Celtic, we have: cel-x-proto:
{{lang|fn=name_from_tag|cel-x-proto}} → Proto-Celtic
Both are listed at Template:Lang § Private-use language tags.
—Trappist the monk (talk) 22:59, 11 December 2023 (UTC)
Ah so!  — SMcCandlish ☏ ¢ 😼  03:43, 13 December 2023 (UTC)

Common Brittonic

Given the above, I can definitely see a use at various articles (like Yan tan tethera) for cel-x-brittonic for Common Brittonic AKA Common Brythonic, Old British, Proto-Brythonic, etc. There's no ISO base name for this (or the Insular Celtic sub-family it usually gets classified into, and for which I can't think of a private-use-code need), but the root language family is Celtic languages with a code of cel, which we're also already using in cel-x-proto for Proto-Celtic.  — SMcCandlish ☏ ¢ 😼  19:39, 17 December 2023 (UTC)

The subtag following the x singleton must be 1–8 characters; brittonic is 9 characters. See IETF language tag § Syntax of language tags.
—Trappist the monk (talk) 20:01, 17 December 2023 (UTC)
Derp. In that case, we could keep it quite short with cel-x-brit. I don't think that would be ambiguous with anything. cel-x-combrit or cel-x-britton could also work if we wanted to be longer.  — SMcCandlish ☏ ¢ 😼  22:19, 17 December 2023 (UTC)
I chose cel-x-combrit because we have a Brittonic languages article which would use cel-x-brit if it ever becomes necessary.
{{lang|fn=name_from_tag|link=yes|cel-x-combrit}} → Common Brittonic
—Trappist the monk (talk) 23:46, 17 December 2023 (UTC)
Good call, and thanks for adding it.  — SMcCandlish ☏ ¢ 😼  00:40, 18 December 2023 (UTC)

`yue-jyutping`, but not `yue-Latn-jyutping`

Forgive me if I missed this somewhere, but is it canonical that the code for Jyutping romanization of Cantonese should be yue-jyutping, but not yue-Latn-jyutping?
I'm comparing with Hanyu Pinyin for Standard Chinese, which is often tagged either with zh-Latn or zh-Latn-pinyin. Remsense留 00:29, 18 December 2023 (UTC)

Tested, and |yue-Latn-jyutping throws "Error: {{Lang}}: unrecognized variant: jyutping for code-script pair: yue-latn (help)". That's not very intuitive, since -Latn seems to apply to anything that has been transliterated from another character set into Latin-based chars.  — SMcCandlish ☏ ¢ 😼  00:49, 18 December 2023 (UTC)
Also, the |j= parameter of {{zh}} emits a yue-Latn-jyutping tag, so it seems likely that one of the two templates is misbehaving. Remsense留 00:54, 18 December 2023 (UTC)
{{zh}} is not rendered by Module:Lang. We have no control over that template.
—Trappist the monk (talk) 01:04, 18 December 2023 (UTC)
Who knows? By definition, Jyutping is a romanization system so it would seem that Latn is superfluous. The standard is the standard. Complaints about the standard should be directed to the custodians of the standard.
—Trappist the monk (talk) 01:04, 18 December 2023 (UTC)
Sorry if my question was unclear—I was just asking if it might be an error here or at IANA. Thank you for the reply, and thanks for all the work you do in this area of the site. :) Remsense留 01:06, 18 December 2023 (UTC)
According to the IANA language-subtag-registry file: 
%%
Type: variant
Subtag: jyutping
Description: Jyutping Cantonese Romanization
Added: 2010-10-23
Prefix: yue
Comments: Jyutping romanization of Cantonese
%%
so Module:Lang is correct when it emits an error message complaining about yue-Latn-jyutping:
{{lang|yue-Latn-jyutping|yue-Latn-jyutping}} → [yue-Latn-jyutping] Error: {{Lang}}: unrecognized variant: jyutping for code-script pair: yue-latn (help)
I cannot explain why zh-Latn-pinyin is preferred over zh-pinyin. If you think that IANA are wrong, you must take it up with them.
—Trappist the monk (talk) 01:04, 18 December 2023 (UTC)

De-italicization glitch

Shelta uses English orthography, sometimes with some Irish diacritics, and sometimes the additional character χ. The presence of that character in any {{lang|sth|...}} string causes the entire string to be de-italicized automagically, and this is undesirable. See, e.g., Shelta#Grammar, and note how the first and last items in the table have been forced into roman mode.  — SMcCandlish ☏ ¢ 😼  00:39, 18 December 2023 (UTC)

It does that because χ is U+03C7 Greek small letter chi. Any non-Latn character in the text causes Module:Lang to render the text in upright font. Is χ really the proper character or did someone simply search the characters in the char-insert tables and use whatever they found that looked more-or-less correct?
You can override the upright font:
{{lang|sth|gloχi|italic=yes}} → gloχi
—Trappist the monk (talk) 01:28, 18 December 2023 (UTC)
There is ꭕ (U+AB55 Latin small letter chi with low left serif) in Latin Extended-E:
{{lang|sth|gloꭕi}} → gloꭕi
—Trappist the monk (talk) 02:05, 18 December 2023 (UTC)
Given that all of this is based on printed books, it is likely that someone editing here just used χ as the first visual match they found for what they saw in the book, which could equally well be rendered with ꭕ, so might as well switch to that, since it's within the extended Latin character set and is not jumping ship to Greek.  — SMcCandlish ☏ ¢ 😼  02:38, 18 December 2023 (UTC)
PS: I think it happened because the IPA symbol for the sound is actually the Greek glyph χ; trying to replace that in the IPA chart with ꭕ broke the IPA template. The article has to use both in differen places, the IPA symbol for the sound in the IPA chart, and the extended Latin variant in running text for the word spellings.  — SMcCandlish ☏ ¢ 😼  02:44, 18 December 2023 (UTC)

Samaritan

See also: Module talk:Language § Samaritan

{{lang|smp|example}} (the code for Samaritan Hebrew language) adds a page to Category:Articles containing Samaritan-language text but Samaritan language redirects to Samaritan Aramaic language sam. Error (talk) 01:22, 18 January 2024 (UTC)

 Fixed. The redirect was pointing to the wrong page (per https://iso639-3.sil.org/code/smp at least). – Jonesey95 (talk) 14:34, 18 January 2024 (UTC)
Now Category:Articles containing Samaritan-language text points to a disambiguation page. It shouldn't. --Error (talk) 16:22, 19 January 2024 (UTC)
I reverted a good-faith change to that redirect. "xxx language" redirects, where "xxx" matches the ISO name, always point to the article for that language. – Jonesey95 (talk) 17:47, 19 January 2024 (UTC)
In Module:Language/data/iana languages, searching for "Samaritan", I find: ["sam"] = {"Samaritan Aramaic"}, ["smp"] = {"Samaritan"} – This module contains data taken directly from a local copy of an IANA language-subtag-registry file, and is supposed to be kept in sync with that external site.
That external site apparently makes Samaritan Hebrew the primary topic for "Samaritan", by simply calling it that, rather than "Samaritan Hebrew".
I see, Category:Articles containing Samaritan Aramaic-language text. Category:Articles containing Samaritan Hebrew-language text. Hmm.
Samaritan Aramaic language was the primary topic for Samaritan language for 17 1⁄2 years, until Jonesey95 changed that.
Just two articles currently link to "Samaritan language", though – Salbit and ‎George Nicholl.
Not sure I'm comfortable with letting a third-party website decide whether the term "Samaritan language" has a primary topic or is ambiguous, though. – wbm1058 (talk) 20:08, 19 January 2024 (UTC)
I'm not sure why a category red link was pasted above; the relevant category is Category:Articles containing Samaritan-language text. In my experience, articles about languages are all either called "XXX language", or a redirect exists at "XXX language" pointing to the article name that the English Wikipedia has decided upon. This lang template/module set uses the ISO and IANA files to map language codes to language names; those language names are used for the relevant categories. In the case that the OP posted about, the redirect was pointing to the wrong place, so I fixed it. Since, as you say, there are minimal links to both pages, it should be fine to have {{for}} links at the top of each of the language pages; I have added those. [Edited to add: Since we call it "Samaritan Hebrew" here, as does Ethnologue, a reputable language source, maybe the lang templates should override the default "Samaritan" with "Samaritan Hebrew", which would free up "Samaritan language" to be a disambuiguation page. I don't know how to do that override.] – Jonesey95 (talk) 22:50, 19 January 2024 (UTC)
Easily enough done if and when the editors here can figure out, and clearly state, what it is that they want. Thus far, that has not happened. This discussion was originally at Module talk:Language § Samaritan. I'm not inclined to change anything until there is at least a minimal consensus, clearly stated, to override ISO 639-3/IANA or repoint the redirect.
—Trappist the monk (talk) 23:10, 19 January 2024 (UTC)
OK, so ["smp"] = "Samaritan Hebrew", -- to match en.wiki article title: Samaritan Hebrew.
Now, Category:Articles containing Samaritan-language text says: Error: Samaritan is not a valid ISO 639 or IETF language name. Please see Template talk:Lang for assistance.
Go figure. Have you figured out what we want yet? wbm1058 (talk) 02:53, 20 January 2024 (UTC)
That follows logically from the diff. I guess that's what we want then. The next step was to create Category:Articles containing Samaritan Hebrew-language text. I have restored and spruced up the disambiguation page at Samaritan language and marked the old category for deletion. I think this may be resolved. – Jonesey95 (talk) 05:21, 20 January 2024 (UTC)
Very good, thanks. You figured it out for me. Category:Articles containing Samaritan-language text history-merged to Category:Articles containing Samaritan Hebrew-language text and deleted. – wbm1058 (talk) 14:12, 20 January 2024 (UTC)

Lang-ktz

returns the wrong spelling, even though the name is spelled correctly [Juǀʼhoan] at Module:Language/data/ISO 639-3. Where do I go to fix? — kwami (talk) 00:34, 21 January 2024 (UTC)

Where are you seeing a misspelling? If I write:
<code>[{{lang|fn=name_from_tag|ktz}}]</code> → [Juǀʼhoan]
and without the <code>...</code> tags:
[{{lang|fn=name_from_tag|ktz}}] → [Juǀʼhoan]
Where are you seeing a different spelling?
—Trappist the monk (talk) 00:50, 21 January 2024 (UTC)
In both. (A quick test on my system is to double click on the result. Only part of the name highlights.) — kwami (talk) 00:54, 21 January 2024 (UTC)
Don't know that that is much of a test. If I double click your example and both of my examples, all eight characters are highlighted in each case.
If I examine all three examples at https://r12a.github.io/uniview/, the only difference between your example and the output from Module:Lang is the apostrophe. You use U+02BC: MODIFIER LETTER APOSTROPHE and Module:Lang uses U+0027: APOSTROPHE which is in keeping with en.wiki's preference (MOS:CURLY). Is that where the highlighting stops?
—Trappist the monk (talk) 01:15, 21 January 2024 (UTC)
If I double-click on the word "Don't" in Trappist's response above, only "Don" or "t" is highlighted. That does not indicate an error. – Jonesey95 (talk) 14:34, 21 January 2024 (UTC)
You know? I was just going to ask about that ...
—Trappist the monk (talk) 15:17, 21 January 2024 (UTC)
Might be OS or some other thing dependent, but if I double click "don't" or "[Juǀ'hoan]", the whole text is highlighted for me. Gonnym (talk) 16:35, 21 January 2024 (UTC)
Yes, it's OS or something dependent. For me, it's a convenient test to check if a word contains punctuation substitutes for letters. E.g. Juǀʼhoan with a click letter highlights as a word, but Ju|ʼhoan with a punctuation mark substituted does not. — kwami (talk) 19:10, 21 January 2024 (UTC)
Wait, what? Earlier, you wrote: Only part of the name highlights. Now you write: Juǀʼhoan with a click letter highlights as a word. Is this not contradictory? None of the example language names, except the latter one in your most recent post, use a pipe character (U+007C: Vertical line). What am I missing? Is there still a wrong spelling issue here?
—Trappist the monk (talk) 19:27, 21 January 2024 (UTC)
Only part of the name highlighted because there was a punctuation substitution for proper orthography. That happens with either the click letter or the modifier apostrophe. For the whole name to highlight, all of the characters need to be letters. — kwami (talk) 19:35, 21 January 2024 (UTC)
So what you are saying is that your OS objects to U+0027: APOSTROPHE (a punctuation character)? And you didn't answer my other question: Is there still a 'wrong spelling' issue here?
—Trappist the monk (talk) 19:49, 21 January 2024 (UTC)
It doesn't object to it, it just recognizes that it's a punctuation mark rather than a letter. Quite convenient to test whether someone used a curly quotation mark instead of IPA for ejective consonants, for example.
Yes, the spelling issue is that we use a punctuation mark for a letter. If there's consensus that we should do that, then fine; I thought it was an error. — kwami (talk) 19:54, 21 January 2024 (UTC)
Ok thanks. Nothing to do here.
—Trappist the monk (talk) 20:05, 21 January 2024 (UTC)
Kwami, if that character should be used, you should bring it up at Wikipedia:Manual of Style. MOS:APOSTROPHE allows the following: Letters resembling apostrophes, such as the ʻokina ( ʻ – markup: ʻ), saltillo ( ꞌ – markup: ꞌ), Hebrew ayin ( ʽ – markup: ʽ) and Arabic hamza ( ʼ – markup:ʼ), should be represented by those templates or by their Unicode values. Gonnym (talk) 20:53, 21 January 2024 (UTC)
That's exactly the issue.
Why would I bring it up at the MOS? That section is pretty clear already: letters should be encoded as letters. They even provide for the {hamza} template to be used for ejective consonants, which is essentially what this is. — kwami (talk) 20:55, 21 January 2024 (UTC)
If the character you want to add (to me it looks like a curly apostrophes so I don't know which one it is) an ʻokina, saltillo, ayin or hamza? If it isn't one of those, it isn't essentially what this is, which is why I said that you should bring it up at the MoS page. Gonnym (talk) 21:02, 21 January 2024 (UTC)
It's the hamza. — kwami (talk) 21:15, 21 January 2024 (UTC)
Also, they say "such as". They're not going to list every single character. The point is that the MOS stuff about apostrophes (no curly apostrophes etc.) applies to punctuation. It doesn't require us to distort a language's orthography.
(When I said "pretty much", I meant it's arguable whether it's really an ejective in this case -- a few KS languages make a distinction between glottalized and ejective clicks -- but it's written as if it were an ejective, just as glottalized letters are in many alphabets.) — kwami (talk) 21:17, 21 January 2024 (UTC)
So we're not done? Do we undo the override or keep it as it is? As far as I can tell, the override (imported from the now deleted Module:Language/data/wp_languages) has been in place for nearly a decade (since 15 April 2014). The associated article, Juǀʼhoan language, uses the curly apostrophe.
—Trappist the monk (talk) 21:39, 21 January 2024 (UTC)
I don't know what the consensus is here. If it's to follow the MOS, then yes, we should change it to the modifier apostrophe (the letter, not the quotation mark). If it's to use ASCII substitutions, then it's fine as is.
Personally, I think that if we use the proper Unicode characters for languages with some political clout in the US, like Hawaiian where people insist on a proper okina letter, then we should do the same for languages that don't have such clout. — kwami (talk) 23:31, 21 January 2024 (UTC)
I don't have a problem with that. Given my druthers, en.wiki would follow ISO 639 naming conventions so that overrides are unnecessary. I'm not going to hold my breath for that. So, I will undo the override so that ktz uses the name as given in the IANA language-subtag-registry file: Juǀʼhoan which uses U+02BC: MODIFIER LETTER APOSTROPHE.
—Trappist the monk (talk) 23:47, 21 January 2024 (UTC)
And done:
<code>{{lang|fn=name_from_tag|ktz}}</code> → Juǀʼhoan
—Trappist the monk (talk) 23:50, 21 January 2024 (UTC)
Thanks!
BTW, a couple years ago ISO was going through all their language names to treat such ASCII/Unicode issues consistently after making a few sporadic fixes. (That is, fixes for languages that had someone to speak up and make a formal request.) I don't know if it ever got anywhere. — kwami (talk) 23:51, 21 January 2024 (UTC)

Changes

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

Nothing has changed in the module. Here is the history of that template in 2022 Comhairle nan Eilean Siar election:
  • at this edit, you added the template {{lang-for||Scottish Gaelic|Council of the Western Isles}}
  • at this edit, using AWB, I changed it to {{lang-for|gd||Council of the Western Isles}}
  • at this edit, I changed it to {{lang-for|gd|'''[[Comhairle nan Eilean Siar]]'''|Council of the Western Isles}}
  • at this edit, Editor Pedia9jb6l changed it to {{lang-for|gd|[[Comhairle nan Eilean Siar]]|Council of the Western Isles}}
On 10 April 2024, this edit by Editor PK2 changed {{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.
I have reverted the edit at {{lang-for}}.
—Trappist the monk (talk) 15:14, 11 April 2024 (UTC)
Thanks very much for looking into this and for fixing it. Stevie fae Scotland (talk) 09:00, 12 April 2024 (UTC)

Code for Anatolian languages

@Trappist the monk: I need a private-use language tag for Anatolian languages. Antiquistik (talk) 20:32, 6 April 2024 (UTC)

Propose one. You know the rules for making a private-use tag.
—Trappist the monk (talk) 21:45, 6 April 2024 (UTC)
@Trappist the monk: Does anat work? Or is it already assigned? Antiquistik (talk) 21:51, 6 April 2024 (UTC)
and the rest of it?
—Trappist the monk (talk) 22:01, 6 April 2024 (UTC)
@Trappist the monk: I have no idea. I will need your help for that. Antiquistik (talk) 00:00, 7 April 2024 (UTC)
I'm just the coder. Perhaps you can consult with WP:Languages or WP:Linguistics or some other such wikiproject.
—Trappist the monk (talk) 00:07, 7 April 2024 (UTC)
@Trappist the monk: Would ine-x-anatolia work? Antiquistik (talk) 17:59, 15 April 2024 (UTC)
{{lang|ine-x-anatolia|text}} → text
—Trappist the monk (talk) 18:20, 15 April 2024 (UTC)
@Trappist the monk: Thanks! Antiquistik (talk) 19:00, 15 April 2024 (UTC)

Quoting multiple alternative translations

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 

{{langx|de|'''Luftwaffe'''|lit=air weapon or air arm}}

which is not quoted correctly. I can fix this by doing 

{{langx|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, Ainlina(box)? 15:30, 29 April 2024 (UTC)

In context, it would seem to me that |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.
Recently, there has been discussion at Wikipedia talk:WikiProject Military history § Luftwaffe, lang template/italics or not? that you might find interesting.
—Trappist the monk (talk) 15:51, 29 April 2024 (UTC)
Thanks for the info, unfortunately I have very little subject matter knowledge, and was just browsing and encountered some bad formatting. Is there a correct way to do this if two translations are both needed due to ambiguity? Thanks, Ainlina(box)? 17:05, 29 April 2024 (UTC)

Create {{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.
—Trappist the monk (talk) 11:42, 27 April 2024 (UTC)
It is now. "Added: 2024-05-15" -- --Error (talk) 11:43, 22 May 2024 (UTC)

Foreign-language article titles

archived to Wikipedia talk:Manual of Style/Text formatting/Archive 7#Foreign-language_article_titles

Moved to Wikipedia talk:Manual of Style/Text formatting § Foreign-language article titles

— Preceding unsigned comment added by Jochem van Hees (talk • contribs) 12:29, 31 August 2021 (UTC)

Question about Category:Articles containing Dogrib-language text

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)

The 2024-04-15 update to the ISO 639-3 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.
When multiple names are provided by IANA, Module:Lang takes the first name in the list – in this case 'Tlicho'. This may be overridden in Module:Lang/data when there is consensus to do so.
—Trappist the monk (talk) 18:01, 28 May 2024 (UTC)
I believe that the stable title (for the last eight years or so) of our Dogrib language article constitutes sufficient consensus to override. I poked around the sources, and they seem to be split somewhat evenly among "Dogrib", "Tlicho", and "Tłı̨chǫ Yatıì", the latter of which would be a challenging article name for the English Wikipedia. If the article is moved, the override can easily be removed. – Jonesey95 (talk) 00:27, 29 May 2024 (UTC)

Mild performance improvement

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)

Renaming a template per ISO 639 changes?

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)

Anything is possible. What is the end goal? Change instances that use {{Lang-sh}} to {{Lang-hbs}} or just switch between the current template and the "hbs" redirect? If the first and there is consensus on the page, a bot operator could help with the 800s transclusions, if just rename, then anyone that can rename pages can do that or WP:RM/T. Also a small edit to the template to change the code parameter. Gonnym (talk) 15:16, 8 June 2024 (UTC)
So if I get this right, you wouldn't use a TFD tagging procedure? --Joy (talk) 19:15, 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)
@Vipz well, that's actually making things a tad more confusing because there it says for "sh":
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).
We're not just using it for legacy applications. --Joy (talk) 19:14, 8 June 2024 (UTC)
Interestingly, that quoted material doesn't mention "hbs".  — SMcCandlish ☏ ¢ 😼  04:38, 10 June 2024 (UTC)

Side question on Proto-[Foo]

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)

Forced prefixing of *

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)

Two thoughts: there is some value to the asterisk symbol as unattested (especially if we tooltip the first occurrence à la {{c.}}), so could we use {{asterisk}}, or perhaps (new) {{unattested}} and have that resolve to {{asterisk}}? Alternatively, what about just using one of the many star-shaped thingies that look like asterisk, but aren't, e.g.,
❋ (U+274B HEAVY EIGHT TEARDROP-SPOKED PROPELLER ASTERISK) (my favorite, but several more hidden in the wikicode).
Thanks, Mathglot (talk) 11:17, 2 March 2024 (UTC)
Using an alternative character would be WP making up a "fake style" out of nowhere. The standard across all linguistics writing since at least the Victorian era is the * symbol (asterisk).  — SMcCandlish ☏ ¢ 😼  05:07, 10 June 2024 (UTC)
Already exists but, alas, not documented:
{{lang|cel-x-proto|kal-}} → *kal-
{{lang|cel-x-proto|kal-|proto=no}} → kal-
{{langx|cel-x-proto|kal-}} → Proto-Celtic: *kal-
{{langx|cel-x-proto|kal-|proto=no}} → Proto-Celtic: kal-
—Trappist the monk (talk) 15:02, 2 March 2024 (UTC)

Testing bullet-asterisk interaction with proto asterisk:

  • one asterisk, to make a bullet item
  • *kal- one asterisk, followed immediately by {{lang|cel-x-proto|kal-}}
  • one asterisk to make another bullet item

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)

But wait—you said in sentence 2, but this produces a double ** which has to be manually fixed, so what was your example that produced a double asterisk? It seems to be the identical code that works just above. Can you reproduce your error case below? Mathglot (talk) 20:14, 2 March 2024 (UTC)
To repeat from the OP: 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. If the solution is changing *''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)

Early Modern English?

Not sure of the process here, but is it possible to make the template accept Early Modern English as a language? There are some long quotations on Elinor Fettiplace which, while definitely not in Middle English, must be extremely confusing to a screen reader. ISO 639-6 proposed emen as a code for it, but as I gather was not accepted. UndercoverClassicist T·C 08:40, 22 June 2024 (UTC)

{{lang|en-emodeng|text}} → text
{{langx|en-emodeng|text}} → Early Modern English: text
—Trappist the monk (talk) 11:39, 22 June 2024 (UTC)
Wonderful: thank you! UndercoverClassicist T·C 15:11, 22 June 2024 (UTC)

Limitations possibly requiring template modification

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:

  1. the {{lang- form of the template should also display a label for the name of the language used similar to when using the {{lang| form;
  2. the {{lang| form needs a |translit= option that works just like it does with the {{lang-... form;
  3. the |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;
  4. there needs to be an option for adding multiple spellings and multiple transliterations; for example:
    1. the name Tuwaddis was recorded as 𔕬𔗬𔑣𔓯𔗔 and 𔕬𔓬𔑣𔕣, and presenting them in an article currently requires me to write
      the code {{langx|hlu|𔕬𔗬𔑣𔓯𔗔}} <small>and</small> {{lang|hlu|𔕬𔓬𔑣𔕣}}, <small>romanized</small> {{transl|akk-x-neobabyl|Tuwaddis}}
      to obtain Hieroglyphic Luwian: 𔕬𔗬𔑣𔓯𔗔 and 𔕬𔓬𔑣𔕣, romanized Tuwaddis;
    2. similarly, if I want to make a list of the various forms of the Hieroglyphic Luwian name Ḫartapus in an article, I would need to write it
      as {{langx|hlu|𔓟‎𔖱𔐞𔕯𔗔‎}}, {{lang|hlu|𔓟‎𔖱𔐞𔗣𔗔‎}} and {{lang|hlu|𔗖‎𔐞𔕯𔗔}}, <small>romanized:</small> {{transl|hlu|Ḫartapus}}
      to obtain Hieroglyphic Luwian: 𔓟‎𔖱𔐞𔕯𔗔‎, 𔓟‎𔖱𔐞𔗣𔗔‎ and 𔗖‎𔐞𔕯𔗔, romanized: Ḫartapus;
    3. meanwhile, the name 𒁹𒌇𒁮𒈨𒄿 is interpreted as either Tugdammî and Dugdammî, and presenting them in an article currently requires me to write
      the code {{langx|akk-x-neoassyr|𒁹𒌇𒁮𒈨𒄿|translit=Tugdammî}} <small>or</small> {{transl|akk-x-neoassyr|Dugdammî}}
      to obtain Neo-Assyrian Akkadian: 𒁹𒌇𒁮𒈨𒄿, romanized: Tugdammî or Dugdammî;
    4. and the name 𒁹𒄖𒊌𒄖 is interpreted as both Gugu and Guggu, but presenting it in an article would require that I write
      the code {{langx|akk-x-neoassyr|𒁹𒄖𒊌𒄖|translit=Gugu}} <small>and</small> {{transl|akk-x-neoassyr|Guggu}}
      to obtain Neo-Assyrian Akkadian: 𒁹𒄖𒊌𒄖, romanized: Gugu and Guggu
    5. if I need to make a list of the various spellings of the name māt Tabali, for example, I need to write
      the code {{transl|akk-x-neoassyr|māt Tabali}} ({{lang|akk-x-neoassyr|𒆳𒋫𒁀𒇷}}, {{lang|akk-x-neoassyr|𒆳𒋫𒁀𒀀𒇷}}, {{lang|akk-x-neoassyr|𒆳𒋫𒁄𒇷}}, {{lang|akk-x-neoassyr|𒆳𒋰𒀀𒇷}})
      to obtain māt Tabali (𒆳𒋫𒁀𒇷, 𒆳𒋫𒁀𒀀𒇷, 𒆳𒋫𒁄𒇷, 𒆳𒋰𒀀𒇷);
    6. and if I want to make a list of the various forms of the name Qedar, I need to write
      the code Neo-Assyrian Akkadian: 𒆳𒆤𒊑, Qidri; 𒆳𒆤𒊏𒀀𒀀, Qidrāya; 𒆳𒆥𒁕𒀀𒊑, Qidāri; 𒆳𒋡𒁕𒊑, Qadari; 𒆳𒋡𒀜𒊑, Qadri; 𒇽𒆤𒊏𒀀𒀀, Qidrāya; 𒇽𒆥𒁯𒊏𒀀𒀀, Qidarāya; 𒌷𒆥𒁕𒊑, Qidari; and 𒇽𒄣𒁕𒊑, Qudari
  5. I would also require a transcription parameter because some scripts are not transcribed in the exact same was as their reconstructed pronunciation, and this sometimes needs to be shown in the text.
    1. For example, Mycenaean Greek kʰalkós was written as 𐀏𐀒 in Linear B script, which is transcribed as ka-ko, but the template as it now exists only allows me to add the Linear B text and the word as it was pronounced, but not the transcription of the text;
  6. Integrating the functions of {{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.
    1. For example, {{langx|ae|}} and {{lang|ae|}} should have a parameter that functions in the same way as if {{langx|ae|{{script|Avst|}}}} and {{lang|ae|{{script|Avst|}}}} were used.
      1. Some scripts, like cuneiform, however use multiple variants due to how widespread and long-lived their use was, and, if creating such a parameter is possible, it would need to be able to render the various fonts used in Template:Script/Cuneiform.
      2. This parameter should be optional, however, because some of the script templates, like {{script|Grek|}} and {{script|Latn|}} render the text in a font that is difficult to read and are therefore already discouraged.
  7. There also needs an option where interting - in the text parameter followed by the transliteration in the template displays the language followed by the transliteration.
    1. For example, {{langx|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)

@Trappist the monk: can any of these issues be resolved? Antiquistik (talk) 08:13, 3 June 2024 (UTC)
I numbered your list to make it easier to answer.
1. because {{lang-??}} already has a wikilinked language label, using the label= html attribute is considered redundant or superfluous
2. might be done but probably not necessary because {{transliteration}} exists to serve that purpose
3. see 4
4. if you do a lot of these custom lists, you might be better served to create one or more templates to do the grunt work
5. a new template, {{transcript}} might be created; you will need to work out details of its implementation
6. nesting templates in {{lang}} may take more space, but space in a Wikipedia article is not an issue; this is not a dead tree encyclopedia
7. {{transliteration-??}} templates might be created; you will need to work out the implementation details
In general, Module:Lang works well for the vast majority of its uses; mucking about with that for a small number of articles seems to me to be counterproductive.
—Trappist the monk (talk) 14:22, 3 June 2024 (UTC)
@Trappist the monk: For #6, I've faced problems with pages I rewrote becoming too big per WP:TOOBIG before, so space is unfortunately an issue.
For #2, editing using both {{transliteration}} and {{lang|}} for this purpose is too cumbersome and unwieldy. Adding a |translit= parameter to {{lang|}} would be the best option.
For #3, I am not sure I understand how #4 relates to this issue. You might need to spell it out for me.
For #4, yes, a separate template for lists would be ideal. It should work like Wiktionary's {{desc| template, minus creating a link for the term. However, the options for the first four sub-issues should be integrated into {{lang|}}/{{lang-}}.
For #5, an additional transcript template would definitely be a very useful addition. However, I also have no choice in needing the transcription option to be part of {{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.
For #7, what would be ideal would be both a {{transliteration}} template and the option to insert a nil parameter in the present template as well.
As for #1, well, I can do without it for now. But I would still support adding a label if the question arises again in the future. In my (personal) opinion, the label in fact makes it more easily to read the pages.
Additionally, could you modify the private-use tag akk-x-latbabyl to render as "Late Babylonian Akkadian" rather than simply as "Late Babylonian" as it now does?
Antiquistik (talk) 19:31, 7 June 2024 (UTC)
@Trappist the monk: Can you have a look at my response and see what can be done please? Antiquistik (talk) 06:26, 25 June 2024 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Lang/Archive_13&oldid=1255370719"