Template talk:Lang/Archive 15

Archive 10

←

Archive 13

Archive 14

Archive 15

Broken usage of langx

I'm not sure how this template works, but this page is complaining about a missing parameter "p", and I'm not sure how to fix it. x42bn6 Talk Mess 18:24, 15 November 2024 (UTC)

The page was calling {{lang-ru}} with |p=. The template has been deleted, so I don't know if |p= (for "pronunciation", possibly) was a valid parameter. An admin will be able to check. – Jonesey95 (talk) 18:51, 15 November 2024 (UTC)

Some history – I didn't go back to the very beginning:

• changed from {{lang-ru}} to {{lang-rus}} at this edit – {{lang-rus}} supports the |p= parameter
• changed from {{lang-rus}} to {{lang-ru}} at this edit – {{lang-ru}} ignored the unsupported |p= parameter
• changed from {{lang-ru}} to {{langx|ru|...}} at this edit – {{langx}} ignored the unsupported |p= parameter until just a day or so ago; now it emits an error message when editors give it parameters that it does not support.

—Trappist the monk (talk) 19:00, 15 November 2024 (UTC)

So it looks like one possible fix is to change the template transclusion back to {{lang-rus}}. Or is that creating more work in the future? This error is present in other articles, such as Denis Cheryshev. – Jonesey95 (talk) 19:17, 15 November 2024 (UTC)

For now changing is the fix. I did however propose that we either disentangle the unsupported features from -rus or add support for them so other languages can use. There is really almost no reason at all for any specific-language template to stay after the creation of langx. Gonnym (talk) 19:24, 15 November 2024 (UTC)

Pending more granular tracking categories or sorting within the category, an insource search shows 63 articles with this particular error. Most appear to be using lang|ru, but at least a few are using lang|zh, which I have not investigated. – Jonesey95 (talk) 14:32, 16 November 2024 (UTC)

It looks like there is also an error message with "sc", which presumably refers to script. Mellk (talk) 13:35, 22 November 2024 (UTC)

Thanks, but it is not necessary for you to report each instance of unknown parameters causing error messages. They are all collected in Category:Lang and lang-xx template errors which at present lists 67 pages.

—Trappist the monk (talk) 13:57, 22 November 2024 (UTC)

Since this is related to lang-rus, the issue is not just "p=". Mellk (talk) 14:06, 22 November 2024 (UTC)

The 'issue' is {{lang}} and {{langx}} with parameters that are not know to those templates. The issue is not confined to {{lang-rus}} or {{lang-zh}} templates that have been improperly changed to {{lang}} or {{langx}}. Here are searches that are not parameter specific for both templates:

• {{lang}} ~680 articles
• {{langx}} ~190 articles

Yep, there is a lot of junk out there. You still don't need to make a report here for every subgroup of errors that you encounter out there.

—Trappist the monk (talk) 14:43, 22 November 2024 (UTC)

I did not plan to make a report for every error. I also did not say that the errors are confined to lang-rus (that is pretty obvious when the search above showed that it was not just ru). I was referring to the fix suggested above. Mellk (talk) 14:59, 22 November 2024 (UTC)

I think it is also possible to move pronunciation to the IPA template. I was under the impression that lang-rus would eventually be replaced, but it seems like this is not the case yet? Mellk (talk) 09:38, 22 November 2024 (UTC)

Lang error category without error message?

Resolved

Church Slavonic is in Category:Lang and lang-xx template errors, but I am unable to find a red error message. Maybe I just can't see it. – Jonesey95 (talk) 19:30, 15 November 2024 (UTC)

Do you see it here:

[ⱌⱃⰽⰲⰰⱀⱁⱄⰾⱁⰲⱑⱀⱄⰽⱜ ⰵⰸⰻⰽⱜ] Error: {{Langx}}: invalid parameter: |script= (help)

Fixing the deprecated |script= parameter (cu → cu-Glab) resolves the problem.

Croatian Church Slavonic: ⱌⱃⰽⰲⰰⱀⱁⱄⰾⱁⰲⱑⱀⱄⰽⱜ ⰵⰸⰻⰽⱜ, romanized: crkavnoslověnskь jezikь

It has been a while, but I've seen these before and if my failing memory is correct, always associated with {{efn}}. I was never able to figure out why the invalid error message gets sandwiched into and corrupts the maintenance message.

—Trappist the monk (talk) 20:04, 15 November 2024 (UTC)

No, I do not see an error message in this talk page section. Maybe my custom CSS is suppressing it? When I inspect the page, I see

<span class="lang-comment" style="font-style: normal; display: none; color: #33aa33; margin-left: 0.3em;">{{langx}} uses deprecated parameter(s) </span>

Note the display:none. – Jonesey95 (talk) 14:33, 16 November 2024 (UTC)

I can see error messages above now, and in the 20 October 2024 version of Church Slavonic. This appears to be resolved. – Jonesey95 (talk) 18:47, 22 November 2024 (UTC)

Non-latn text/Latn script subtag mismatch errors in ancient Iranian articles

Articles regarding ancient Iranian society like Mithra, Mantra (Zoroastrianism)#Etymology and Saoshyant#Etymology are showing this error recently, and I'm not sure how to fix them. —CX Zoom[he/him] ^{(let's talk • {C•X})} 13:09, 26 November 2024 (UTC)

Do you really mean to romanize Miθra and Miθraʰ with 'θ' (Greek small letter theta)? Do you really mean to romanize Astwat̰-әrәta and astvat-әrәta with 'ә' (Cyrillic small letter schwa)?

Apparently there is no unicode for Latin theta so that may require some sort of modification to Module:Lang if, in fact, you did really mean to use the Greek theta character. There is a Latin small letter schwa: 'ə'. Wouldn't that be the correct choice when romanizing Astwat̰-әrәta and astvat-әrәta?

—Trappist the monk (talk) 15:15, 26 November 2024 (UTC)

Sorry, I don't know much about how romanization works, but I believe you are correct about the schwa symbol. For Latin theta, I think there needs to be an exception. Or maybe {{transliteration}} would fit better here? I saw it work fine in some other articles. —CX Zoom[he/him] ^{(let's talk • {C•X})} 17:41, 26 November 2024 (UTC)

{{transliteration|ae|Miθra}} should emit an error message because Greek theta is not Latin theta and in the rendering, 'Miθra' is marked up as Latin text:

<span title="Avestan-language romanization"><i lang="ae-Latn">Miθra</i></span>

Miθra

For the same reason, were we using {{langx}}, there should be an error message:

{{langx|ae|𐬨𐬌𐬚𐬭𐬀|Miθra}}

[[Avestan language|Avestan]]: <span lang="ae" dir="rtl">𐬨𐬌𐬚𐬭𐬀</span>, <small>romanized:&nbsp;</small><span title="Avestan-language romanization"><i lang="ae-Latn">Miθra</i></span>

Avestan: 𐬨𐬌𐬚𐬭𐬀, romanized: Miθra

These need to be fixed.

I think that I have a solution to the {{lang|ae-Latn|Miθra}} where 'θ' is the Greek form but I'll hold off on implementing that until I've fixed the missing transliteration error messaging.

—Trappist the monk (talk) 19:21, 26 November 2024 (UTC)

I have tweaked the sandbox so that when the Greek theta (U+03B8) is the only non-Latin character in a string of text, it is assumed to represent the non-existent (in Unicode) Latin theta. Here are a variety of illustrations:

For {{lang}}:

• {{Lang/sandbox|ae-Latn|Miθraʰ}} → Miθraʰ – assume Latin theta because Latn script specified and all other characters in <text> are Latin script
• {{Lang/sandbox|ae-Cyrl|Miθraʰ}} → [Miθraʰ] Error: {{Lang}}: Latn text/non-Latn script subtag mismatch (help) – assume Latin theta because all other characters in <text> are Latin script; script/text mismatch: Cyrl script specified but <text> is Latin script
• {{Lang/sandbox|ae|Miθraʰ}} → Miθraʰ – assume Latin theta because all other characters in <text> are Latin script

When theta is the only character in <text>:

• {{Lang/sandbox|ae-Latn|θ}} → θ – assume Latin theta because Latn script specified
• {{Lang/sandbox|ae-Cyrl|θ}} → [θ] Error: {{Lang}}: Latn text/non-Latn script subtag mismatch (help) – assume Cyrillic theta because Cyrl script specified – Greek/Cyrillic Unicode mismatch not checked
• {{Lang/sandbox|ae|θ}} → θ – assume Greek theta because script not specified

For {{langx}}:

• {{Langx/sandbox|ae-Latn|Miθraʰ}} → Avestan: Miθraʰ – assume Latin theta because Latn script specified and all other characters in <text> are Latin script
• {{Langx/sandbox|ae-Cyrl|Miθraʰ}} → [Miθraʰ] Error: {{Langx}}: Latn text/non-Latn script subtag mismatch (help) – assume Latin theta because all other characters in <text> are Latin script; script/text mismatch: Cyrl script specified but <text> is Latin script
• {{Langx/sandbox|ae|Miθraʰ}} → Avestan: Miθraʰ – assume Latin theta because all other characters in <text> are Latin script

When theta is the only character in <text>:

• {{Langx/sandbox|ae-Latn|θ}} → Avestan: θ – assume Latin theta because Latn script specified
• {{Langx/sandbox|ae-Cyrl|θ}} → [θ] Error: {{Langx}}: Latn text/non-Latn script subtag mismatch (help) – assume Cyrillic theta because Cyrl script specified – Greek/Cyrillic Unicode mismatch not checked
• {{Langx/sandbox|ae|θ}} → Avestan: θ – assume Greek theta because script not specified

For {{langx}} with <translit>:

• {{langx/sandbox|ae|𐬨𐬌𐬚𐬭𐬀|Miθra}} → Avestan: 𐬨𐬌𐬚𐬭𐬀, romanized: Miθra – assume latin theta because all other characters in <translit> are Latin script
• {{langx/sandbox|ae|𐬚|θ}} → Avestan: 𐬚, romanized: θ – assume latin theta because this is the <translit> parameter

For: {{transliteration}}

• {{transliteration/sandbox|ae|Miθra}} → Miθra – assume latin theta because <code> is a language tag
• {{transliteration/sandbox|ae|θ}} → θ – assume latin theta because <code> is a language tag
• {{transliteration/sandbox|latn|θ}} → [θ] Error: {{Transliteration}}: transliteration text not Latin script (pos 1: θ) (help) – assume latin theta because <code> is a script tag
• {{transliteration/sandbox|cyrl|θ}} → [θ] Error: {{Transliteration}}: transliteration text not Latin script (pos 1: θ) (help) – assume latin theta because <code> is a script tag
• {{transliteration/sandbox|ru|ш}} → [ш] Error: {{Transliteration}}: transliteration text not Latin script (pos 1: ш) (help) – error because <translit> not latn script
• {{transliteration/sandbox|cyrl|ш}} → [ш] Error: {{Transliteration}}: transliteration text not Latin script (pos 1: ш) (help) – error because <translit> not latn script

Without objection, I shall update the live module.

—Trappist the monk (talk) 20:38, 27 November 2024 (UTC)

Updated.

—Trappist the monk (talk) 17:33, 28 November 2024 (UTC)

Category:Transliteration template errors $2

The article First Sino-Japanese War, in the sidebar box entitled "First Sino-Japanese War", contains a transliteration error and also appears to be assigning the nonexistent category Category:Transliteration template errors $2. I suspect that recent changes to this module or one of its subpages has caused this new, nonexistent category to appear. – Jonesey95 (talk) 18:45, 28 November 2024 (UTC)

Fixed I think; the miscoding (on my part) also added articles to Category:Lang and lang-xx template errors $2. The article count in Category:Lang and lang-xx template errors was going down, which is an expected result of the change. On the other hand, Category:Transliteration template errors was not changing so I was beginning to wonder why. Now I know why.

—Trappist the monk (talk) 19:35, 28 November 2024 (UTC)

I figured it was a small typo like this. I don't go looking for these things, but I look at a lot of pages with errors in my travels, and I often stumble across new entries in error reports and categories that are caused by template and module changes. – Jonesey95 (talk) 21:03, 28 November 2024 (UTC)

lang sandbox edits

@Gonnym: Something about this edit broke Module:Lang/sandbox so that the testcases fail.

Also: maker_error_span() should be make_error_span()?

—Trappist the monk (talk) 15:41, 30 November 2024 (UTC)

Fixed both. make_error_span() could probably be replaced with make_error_msg() which also handles the span. I just created it to have that code be in one place while it was there. Gonnym (talk) 22:37, 30 November 2024 (UTC)

Wrong font for lzh (Literary Chinese)

When using "lang|lzh" for Literary Chinese texts, it seems to be using a Taiwanese font?

For example, 有 is typically written as 月 which is also seen in historical texts such as in the Kangxi dictionary (inherited glyphs). But in the Taiwanese standard, they prefer to write it as ⺼ which is modern orthography (Traditional Chinese characters ≠ Literary Chinese characters). Another example would be 遣 where the radical ⻌ would be written as ⻍ according to the inherited glyphs, while the Taiwanese standard is ⻎. The template uses ⻎ instead of ⻍. How would one change it so that the template would use fonts (such as I.Ming) that are based on the inherited glyphs rather than the Taiwanese Traditional characters fonts (which are based on handwriting and their own standard)? Lachy70 (talk) 07:25, 4 December 2024 (UTC)

This is only related to the fonts your system picks to render specific languages, and has nothing to do with Wikipedia. Remsense ‥ 论 08:04, 4 December 2024 (UTC)

It doesn't use Taiwanese font for me. Unfortunately browsers allow configuring default fonts only for handful of languages (if at all) and lzh isn't among them. And system configuration might be difficult. The easiest way is to add something like [lang]:lang(lzh){font-family:"I.Ming"} to your user style either in your browser, or just for when you're logged in to Wikipedia at common.css or global.css. The template documentation already covers that at § Applying styles. But if you think of something like overriding default fonts for everyone regardless of their system configuration, then this is something that definitely should not be done (MOS:FONTFAMILY). – MwGamera (talk) 05:51, 5 December 2024 (UTC)

Update to Module:Lang/sandbox

I've modified Module:Lang/sandbox to allow {{Wikt-lang}} to use the language html attribute logic instead of having to duplicate the entire code. Testcases at Module talk:Lang/testcases have all passed so nothing seems to have been broken. Let me know if you have any comments before I update. Gonnym (talk) 09:58, 16 December 2024 (UTC)

Transliteration whitelist

@Trappist the monk I don't think having a blanket whitelist of arbitrary non-Latin script characters makes sense, and especially not one which is as random as [ʻʼʾʿΔαβγδθσφχϑьᾱῑ῾上入去平]. This is totally unsustainable, since it will constantly need to be expanded (e.g. I can already see that ъ is missing, which crops up in various Slavicist transcripitons), and it also opens the door to false-negatives, because most of these will not be acceptable characters in the vast majority of languages. This seems like an artificially-imposed maintenance burden for increasingly little gain.

What I suggest is:

1. Convert to form NFD before checking, which removes the need to have precomposed characters like ᾱῑ.
2. Allow all common script characters.
3. Allow any characters marked with Latn in the Unicode ScriptExtension.txt file.
4. Generate a warning message via mw.message instead of a big error message, as it's overkill.
5. Create a maintenance category, and add all transcriptions containing non-Latin-script characters to it by default.
6. Allow language-specific exceptions, specified in the data somewhere. These should only be added for really common cases.
7. Implement an override, which can be specified using a parameter. This should be used in all other cases. Suggest it in the warning, too ("If this is correct, please...").

Theknightwho (talk) 16:34, 2 January 2025 (UTC)

Yeah, I know, really crude. I did that for the avoidance of conflict.

Hadn't thought about NFD and ScriptExtensions; I will.

mw.message? Not sure how that would be used. My experience with mw.message() is limited to rendering error messages with $1, $2, etc replacements. Can it be used to render messages someplace other than directly in the rendered article? Or were you perhaps thinking of mw.addWarning()?

Maintenance categories are problematic because quite often, {{transliteration}} is used in wikilinks and {{ill}} templates:

[[wikt:نسیم|{{Transliteration|ar|nasim}}]] → nasim

[[Yupei#Jinbu (禁步)|{{Transliteration|zh|Jinbu}}]] → Jinbu

{{ill|yuta (priestess)|lt={{transliteration|ryu|yuta}}|ja|ユタ}} → yuta

Emitting a category wikilink inside another wikilink breaks the rendering.

Yep, overrides are necessary because stuff like this: {{Transliteration|ja|Ama Kakeru ﾐ☆ Jōshikōsei}}.

—Trappist the monk (talk) 19:57, 2 January 2025 (UTC)

I strongly agree with User:Theknightwho on the problems with the whitelist. I think underlying problem with this breaking change stems from mixing two separate uses of the term 'Latn', without being clear about transliteration requirements.

1. -Latn is the script portion of the IETF language tag, which is used to set the lang= attribute (RFC-4646), which affects the display style of the inline text containing element (among other things,as noted by Template:Lang#Rationale). It is important that a single transliterated string has a consistent display style across all its characters, and with other transliterations in the same document. It's a sensible requirement for a en-wiki transliteration template where 'romanization' is a near synonym to use a 'Latn' display style.
2. Latn is also used in Unicode for the "predominant" [script value] of a single code-point. if the predominant use of the character is in one script, but it is also used in others, then it takes the Script property value associated with that predominant use. This is a different (glyph level) classification, and doesn't directly relate to transliteration.

It's hard to find a concrete example in the specs, so this could perhaps be explained better, but it is in fact completely reasonable to have a Greek theta character displayed side-by-side with Latn characters, all using the same Latn display style. This is what is required for Etruscan transliterations, and all the other non-Latn Unicode-script-class examples previously mentioned, including the "modifier" half circles used for Arabic, and the ъ mentioned above.

The same string could be displayed using Greek display rules, but it would look wrong. It would also be wrong to use mixed styles in the same string. A 'Latin theta' is a semantically different symbol, which is why it has a different Unicode code point, and is also incorrect to substitute.

The number of characters, or the Unicode script classification of any adjacent characters, are irrelevant for the display purposes if the transliteration is valid. Single character transliterations are totally valid. Ironically, the most obvious use is in transliteration tables.

[ʻʼʾʿΔαβγδθσφχϑьᾱῑ῾上入去平] demonstrates that Unicode Script classification of individual glyphs is a different concern from a consistent transliteration display style. I have no idea what the CJK glyphs are doing there, I cannot verify any of it. It looks like nonsense. I know what the Greek symbols are, and don't even doubt those CJK are valid in some transliteration of something, but this partial list has no value AFAICT.

The current IS-LATIN whitelist function is misnamed. It's more of a is-valid-transliteration-string/char, but as stated above is of little value, impossible to maintain, and additionally seems to be based on misunderstandings.

Not only is it prone to false-positives, but every "true"-positive error it catches mis-characterises the problem. It's not that the string contains a non-"Unicode Script = Latn" character, rather the character possibly is not a valid transliteration symbol. At best, this is a heuristic for maintenance purposes, but even then it needs to be considerably smarter and have a better idea of what is and isn't valid transliteration. It is not appropriate for this to be raising error messages. Warnings at most, but it'd still be annoyingly noisy.

Template:Transliteration/testcases are appallingly light and most of these basic transliteration cases that broke and seem to be a total surprise should be covered. Salpynx (talk) 21:08, 3 January 2025 (UTC)

@Salpynx Just FYI, 上入去平 refer to the four tones of Middle Chinese, which are of fundamental importance in Chinese linguistics, so it's not that weird that they've come up. No modern variety has retained the Middle Chinese tone system (Mandarin having 4 tones is a coincidence - it's not a one-to-one conversion), and they're diaphonemic anyway (so IPA is out), so you sometimes see them given next to readings in a similar fashion to the tone numbers used in Wade-Giles or Jyutping. Theknightwho (talk) 02:16, 4 January 2025 (UTC)

The re-use of 'is-latin' with the unjustified whitelist now breaks more things:

• The Chinese character {{lang|und-Hani|上}} has 3 strokes (modelled after an example from Template:Lang#Undetermined_language)

The Chinese character 上 has 3 strokes

• {{lang|und-Grek|σαβαθ}}

σαβαθ

• {{lang|ota-Grek|χαβα}} / {{lang|ota-Arab|هوا}} (Weather)

χαβα / هوا (Weather)

It's not clear what the original change was for, but it broke things without pre-discussion (AFAICT), despite the warnings on Template:Lang and Template:Transliteration. Patching it up piecemeal doesn't seem to be helping. Salpynx (talk) 05:30, 5 January 2025 (UTC)

Two languages?

Does langx support two languages in a single template setting? Like this: ({{langx|bn|ক|en|K}}) = (Bengali: ক, English: K). It would be great. Mehedi Abedin 19:58, 10 January 2025 (UTC)

It does not.

—Trappist the monk (talk) 20:54, 10 January 2025 (UTC)

x2 swap weirdness

For some reason, Lake Grahovo lead use of an x2-using template is not rendering, it says '<text1> is not Latin script', but this is a swapped variant, text2 is supposed to be Latin...? --Joy (talk) 21:46, 8 January 2025 (UTC)

This is about this template:

{{lang-cnr-Cyrl-Latn|Граховско језеро|Grahovsko јezero}}

{{lang-cnr-Cyrl-Latn}} wraps {{lang-x2}}. {{lang-x2}} requires Latn-script text in positional parameter {{{1}}}, Cyrl-script text in positional parameter {{{2}}}. I suppose for consistency, {{lang-cnr-Cyrl-Latn}} requires Cyrl-script text in positional parameter {{{1}}} and Latn-script text in positional parameter {{{2}}}. It then swaps them to the order required by {{lang-x2}} by way of |_alias_map=1:text2, 2:text1 and applies |swap=yes to render Cyrl-script text first.

The error message is supplied by {{lang-x2}}. Because {{lang-x2}} is wrapped by {{lang-cnr-Cyrl-Latn}}, {{lang-x2}} uses {{lang-cnr-Cyrl-Latn}} in the error message. Editors looking to fix the error, won't find {{lang-x2}} in the article wikitext so using the name of the wrapping template helps to locate the source of the error. {{lang-x2}} cannot know that {{lang-cnr-Cyrl-Latn}} swaps the inputs; all it sees is non-Latn-script text where Latn-script text ought to be.

For this template, {{lang-cnr-Cyrl-Latn}} parameter {{{2}}} needs fixing.

—Trappist the monk (talk) 00:14, 9 January 2025 (UTC)

I don't understand. How does it work with {{lang-cnr-Cyrl-Latn|Скадарско језеро|Skadarsko jezero}} at Lake Skadar?

Here's both of them evaluated here:

Error: {{lang-cnr-Cyrl-Latn}}: <text1> is not Latin script (pos 11) (help)

Montenegrin: Скадарско језеро, Skadarsko jezero

What's the actual difference? --Joy (talk) 09:11, 9 January 2025 (UTC)

I noticed it also complains in the inverse variant:

Error: {{lang-cnr-Latn-Cyrl}}: <text1> is not Latin script (pos 11) (help)

Montenegrin: Skadarsko jezero, Скадарско језеро

Is it possible that one of those letters looks like a Latin letter but is actually Cyrillic as well? I think at some point I saw an error message saying "at position XY" but it's not showing that right now... I wonder what are the best tools we would have for editors to detect this. Something like od -a but in Mediawiki syntax? --Joy (talk) 09:13, 9 January 2025 (UTC)

The ostensibly Latin letter was "ј" (I used an external program to find it). With that retyped using a Latin keyboard layout, it works:

Montenegrin: Grahovsko jezero, Граховско језеро

--Joy (talk) 09:16, 9 January 2025 (UTC)

I've added position indicator to the error message.

My favorite tool for this is Uniview.

—Trappist the monk (talk) 14:22, 9 January 2025 (UTC)

Thanks! --Joy (talk) 10:37, 11 January 2025 (UTC)

Typo in "Langx |italic= parameter operation" section

In the Italic=value (last section of table), in the second entry, we see {{Langx|ru|''тундра''|italic=}invert}}. There appears to be an extra right-brace right after "italic=". Tarl N. (discuss) 13:19, 28 October 2024 (UTC)

I didn't realize my request was going to Template talk:Lang. The typo I'm referring to is in the Template:Langx section "Langx |italic= parameter operation" section. Why does the talk page for langx drop one here? Tarl N. (discuss) 02:21, 31 October 2024 (UTC)

That error was fixed with this edit. This talk page is the centralized discussion page for several related templates and modules.

—Trappist the monk (talk) 02:52, 31 October 2024 (UTC)

Ah, thanks. Tarl N. (discuss) 00:26, 1 November 2024 (UTC)

Further, I think the section name should be changed to "Lang" instead of "Langx" on the Template:Lang article, right? Kilvin the Futz-y Enterovirus (talk) 07:28, 12 January 2025 (UTC)

Issue with use in links

Discussion at Wikipedia:Main Page/Errors#Friday's FA has identified an issue with (some browsers') display of the title attribute for code like:

''[[École Polytechnique massacre|{{Lang|fr|École Polytechnique|italic=no}} massacre]]'''

where the displayed link contains text in more than one language (arguable in this case, but the point is general).

This could be remedied by allowing suppression of the title attribute, by writing, say:

''[[École Polytechnique massacre|{{Lang|fr|École Polytechnique|italic=no|title=no}} massacre]]''

or possibly better still by simply removing the title attribute completely.

Why do we need that attribute?

Can we apply one or other solution? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:26, 30 November 2024 (UTC)

Correct me if I'm wrong, but isn't this fixed by the nocat parameter? Not sure about the title attribute though.

Also, @Trappist the monk, I believe the documentation has a typo when it references a hyphenated no-cat parameter as this resulted in an error message when I tried it on my end. Kilvin the Futz-y Enterovirus (talk) 07:44, 12 January 2025 (UTC)

Error from Yin and Yang

I think 阳 and 阴 passing as 'Latn' here (via whitelist) is generating an error in Yin and Yang. It is already defined that {{Lang|zh-Hans|{{{s}}}}} in {{Infobox Chinese/Chinese}}. I think 'zh-Hans' in the template conflicts with 'Latn' in the whitelist here when [[wikt:]] (appears to be mixed). But I am not sure ... GKNishimoto (talk) 08:10, 13 January 2025 (UTC)

You may be right. I plucked those two characters from the infobox in Guanyin. There, they are used in transliterations of Suzhounese variety of Wu Chinese text in conjunction with some of the Wu tone indicator characters:

| suz = Kue<sup>阴平</sup> In<sup>阴平</sup>

| suz2 = Kue<sup>阴平</sup> Syu<sup>阴去</sup> In<sup>阴平</sup>

Also found at Morris Chang in this thing:

|wuu=Jiann<sup>阴平去</sup> Zong<sup>阴平去</sup>mœü<sup>阳舒</sup><small> (urban [[Ningbo]])</small><br>
Jia<sup>阴上</sup> Zong<sup>阴平去</sup>mœü<sup>阳舒</sup><small> (rural Ningbo)</small><br>
Jjia<sup>阳舒</sup> Zong<sup>阴平去</sup>mœü<sup>阳舒</sup><small> (rural Ningbo)</small><br>
Jiann<sup>阴平</sup> Jiong<sup>阴平</sup>miu<sup>阳平</sup><small> ([[Ninghai County|Ninghai]])</small><br>
Jjiann<sup>阳平</sup> Jiong<sup>阴平</sup>miu<sup>阳平</sup><small> (Ninghai)</small>

Are 阳 and 阴 valid tone indicators in Suzhounese Wu romanizations? What about 舒 which also appears in that Morris Chang romanization?

Looking at Romanization of Wu Chinese, only one of the four tone characters that frequently appear in Wu transliterations, 去, appears in that article. For me that begs the question: Should en.wiki be using those four 'tone' characters (上, 入, 去, 平)) as tone indicators when our own article on Wu romanization does not use them as such?

—Trappist the monk (talk) 13:49, 13 January 2025 (UTC)

Among us (speakers of at least one of the languages ​​of the CJK triad) these characters are like "drawings/diagrams" expressing ideas/concepts. Even when we don't know how to pronounce them (due to dialect variations), we can deduce their meanings just by superficially visualizing the ideogram. We still have those cases (usually in the Chinese part) in which they are used as tone indicators (perhaps "a form of IPA"). I do think it's interesting that this type of detail can be visualized next to the romanizations, because it makes it bidirectionally easier for bilinguals (the "same" romanization can have completely different meanings, when we don't "get lost from there to here", "get lost from here to there", but we can assimilate the line of reasoning by putting the parts together). I'm not "yet" a fluent speaker of English, Japanese, and Chinese. I prefer not to commit to the working method of linguists.

My proposal regarding the issue of errors generated is that be implemented in the module code a routine that does not take into account the parts that are explicitly flagged (such as creating a parameter |ignore=<part that will not be checked> or a |skip_subscript_tag_check) "only" for mixed cases. Only at the moment when the value of the argument is checked and compared with the script subtag. After the check, it would pass without any problems as it came in. I know it is not easy. I analyze, study, try to understand, and customize several of the modules that you have edited recently. Last night I saw this issue and decided to flag it here. The issue of the infobox in Yin and Yang can be easily "remedied" by removing the wikilink. It is the part related to programming (of the module) that, from my point of view, seems educationally interesting for those who have the knowledge and time available.

Thank you for your attention (and the good work you are doing). I will meditate (read/study) a little on your message.

GKNishimoto (talk) 19:11, 13 January 2025 (UTC)

Yes, they are tone indicators, as you can see at Suzhou dialect#Tones. Please stop disrupting the encyclopedia by insisting that editors come here and explain the use of non-Latin-script characters in transliterations, which were never a problem before your unilateral decision to contrive a Latin-script-checking function that was never intended for this template's purpose. How many more new page sections here and at Template talk:Transliteration do we need before this is over? You actually don't know what you're doing. Hftf (talk) 10:51, 15 January 2025 (UTC)

Template-protected edit request on 16 January 2025

change "["zkt"] = {"Kitan"}," to "["zkt"] = {"Khitan"}," Hanzlan (talk) 15:37, 16 January 2025 (UTC)

i18n request

Can you move common parameters like |code=, |text=, |translit=, |translation=, |lit=, |label=, |label= to Module:Lang/configuration so that it's easier to internationalize the module? Right now I'm trying to implement the module on ku.wiki and having problems with the translation. Thank you! Wikihez (talk) 20:39, 16 January 2025 (UTC)

What on earth is User:Trappist the monk trying to accomplish with the IS LATIN check?

It has broken many tranlisteration templates again on Etruscan language, and presumably elsewhere. The previous whitelist version also had left many invalid error messages on pages for months. Now it is worse. It's proving difficult to have a constructive conversation about this, before or after the breaking changes.

Users raised specific problems with this IS LATIN check on this page and Template:Transliteration, but fundamentally the check and error message are misguided. It's not clear (from the documentation or code) how the current IS LATIN (by checking individual Unicode codepoint primary script classes) code relates to languages or transliteration, or what useful feature it is trying to add -- other than a naive attempt to validate something that is trivailly more complex than that. It seems like it is there for some wiki-gnome homoglyph fixing task for Category:Transliteration_template_errors, but it's not appropriate for an Error message on the module. And, as implemented, is not even fit for a warning or bot fixer task. It requires too much human confirmation.

Spamming fake error messages on multiple pages for months is more disruptive that leaving visually identical characters in strings that are unnoticible to humans, and correctly indexed and matched due to charcter folding. What is this even for? I am dissapointed in how this has been handled. Salpynx (talk) 23:21, 18 January 2025 (UTC)

Thank you User:Trappist the monk for fixing those broken templates on the one page I mentioned with your edit Special:Diff/1270316092. It looks like a typo fix in a overly complex implementation of an unwarranted feature. I am glad my comments are having an incremental effect on improving Wikipedia.

The next page to fix is Proto-Semitic language, if we have to play the "fix specific issues character by character" game. Again, I don't know how to offer specific constructive advice on this one, because non-Latn theta is valid on the Etruscan language page, why is it not valid on Proto-Semitic language? Do we need to have the single character transliterations are fine discussion again?

It's great that there are so many live examples where we can find exceptions to the "must be Latn" falsehood. Testing in production is clearly fine. Salpynx (talk) 22:42, 19 January 2025 (UTC)

User:Trappist the monk I don't understand how Proto-Semitic language came right. Category:Transliteration template errors has changed from around 200 listings to 115 over the course of today, which may be a good indicator of how many of these were spurious errors, and how much noise this is generating. Next live issue as of this message: Scythian languages, with the script theta which was raised in November last year at Template_talk:Transliteration#Underdocumented_error_type. Salpynx (talk) 05:13, 20 January 2025 (UTC)

User:Trappist the monk, your continued recent edits to Module:Lang/data/is_latn_data are what are removing and changing the count of reported transliteration "errors" without leaving a clear history. I figured this out by digging through code. Category:Transliteration template errors now lists 94 errors -- it has more than halved in the last few days with these arbitrary rule changes. There are more unorganised exceptions encoded in the incomplete list than there were "real" problem cases in the first place. This is not a good use of your time, or mine.

Scythian languages no longer has errors. Ghadamès language still does.

We are almost at the point where the IS LATIN check is reporting no errors on existing wiki pages (what was the point?). Now every new use of the transliteration template could potentially require new, illogically framed, exceptions to be added to the code. This is totally unmaintainable (as pointed out previously).

You are using the technical term 'Latn' in a way that was already confusing to other editors, and have now created a totally idiosyncratic personal definition where the 'Latn' class of a symbol depends on "the language" it is transliterating. Not only is this dumb because this is not what 'Latn' is in its own context. It is doubly dumb because it misses the transliteration 101 fact that transliterations apply primarily to scripts. For every language exception currently in the exception list, we need corresponding script exceptions. There are also valid reasons where `und` and `mis` would be appropriate in some cases. It also seems to ignore that there are potentially multiple transliteration schemes for any given script.

• dand-y This has invalid characters in the transliteration. One is arguable, depending on context. This feature does nothing to help.
• [θaurχ] Error: {{Transliteration}}: transliteration text not Latin script (pos 1: θ) (help)
• [θaurχ] Error: {{Transliteration}}: transliteration text not Latin script (pos 1: θ) (help)
• [σa- ςa- sa-] Error: {{Transliteration}}: transliteration text not Latin script (pos 5: ς) (help)
• [λτλβ] Error: {{Transliteration}}: transliteration text not Latin script (pos 4: β) (help)
• [λτλβ] Error: {{Transliteration}}: transliteration text not Latin script (pos 1: λ) (help) The different errors on these two examples are confusing and unhelpful. Can you figure out what is correct?

This continues to be disruptive, and is silently baking in an entire misguided data module into the template architecture. AFAICT all WP:CONSENSUS has been against the breakages this has caused with transliteration, and there have been no concrete examples of anything positive from this for anyone else to support.

Can someone else help here with WP:DISPUTE? Every stupid nitpick I've made above has resulted in User:Trappist the monk adding code to resolve an individual observation on how wrong this is. I can keep generating examples, so we will have code exceptions to handle valid transliterations that only exist on Wikipedia talk pages for the purpose of criticising Module:Lang/data/is_latn_data.

The specific error message added in Special:Diff/1260409561 and all supporting code which affects transliteration templates is:

• Invalid
• Unhelpful (demonstrably has broken more than it has "correctly" flagged)
• Has and continues to be disruptive with red error text where none should be, and in the mental overhead of figuring out what is actually correct, and why the errors are appearing at all
• Introduces a mess of overly-complex code and future maintenance burden, with no clear purpose or documentation
• Is creating new wiki-only definitions of standard externally verifiable terms like "Latn" and "transliteration" as a result of one user's Cognitive dissonance. Surely this is not what we want? Salpynx (talk) 22:14, 20 January 2025 (UTC)

Stop sounding entitled and maybe editors will want to respond to your wall of text. There was obviously errors in ways editors used language templates. Trappist the monk tried fixing some of them. They might have had some bugs in their code, that's how code works. Stop with the wall of text and instead plainly write this:

Error:
Expected result:

Gonnym (talk) 10:44, 21 January 2025 (UTC)

Nobody *wants* any of this BS except for Trappist the monk — though actually even Trappist the monk seems to not want this either as he continues to not actually engage in any conversation and silently continues with his unilateral epicycle-drawing two months on.

Sure, there were a handful of obviously erroneous characters (the only example I even remember at this point was a Cyrillic O with macron used in "Kо̄sen") BUT THE NUMBER OF SUCH ERRORS WAS NOT ANYWHERE NEAR TO THE SCALE that introducing disruptive red error messages for thousands of false positives across the encyclopedia was ever an appropriate solution!!! Why do we even need this code in a submodule called by millions of pages. You can just write a program to periodically search for them and fix the tiny number of issues which need to be reviewed by human hands ANYWAY. How do people not understand this??? Hftf (talk) 11:05, 21 January 2025 (UTC)

It's not surprising to see people getting annoyed when most of the time the error appears is because of incorrect assumptions in the code rather than the inappropriate use of the template. It would be a different story if it were just a maintenance category or a message like cs1-maint or cs1-hidden-error, but this outright breaks the previously correct rendering for all readers. It looks like simply scanning dumps for inappropriate uses of lang/transl/etc would require less person-hours to get the actual misuses fixed. – MwGamera (talk) 11:25, 21 January 2025 (UTC)

Error: Category:Transliteration_template_errors {{transliteration}} expects <text> to be written using Latn-script characters. does not apply generally to transliterations, as evidenced by the many transliterations which require non-Latn / non-Latin characters, so should not be reported as an error.

Expected result:

• Error reports on templates should reliably represent actual errors, and have accurate descriptions.
• Personal code to help fix a few specific transliteration homoglyphs belongs outside Lang module code used on ~1.5M pages.
• Transliteration template code should be protected by more test cases to prevent breakages on basic examples.
• Feature changes to widely used templates should be discussed first per the Template:High use warning on Template:Transliteration
• Developers show willingness and responsiveness to address bug reports and comments on high use template and module code when valid concerns are raised, ideally by reverting breaking changes immediately until a correct approach can be worked out.

Given User:Trappist the monk's otherwise good work on Module:Lang, I assume they can read and understand my text. I clearly struggle to be succinct when discussing nuances of Module and Template coding that is required to cover transliterations of every language and script. I've tried to be informative and accurate.

Concessions to readability weren't made to me (or other editors) as I had to read through hidden, rapidly changing, and insufficiently documented Lua code across multiple templates and module files to process responses to my points. Salpynx (talk) 23:23, 21 January 2025 (UTC)

quotation marks and apostrophes

When writing prose, and there's a need to nest quotations, we have specialized templates (e.g. {{single+double}}) we can use to distinguish apostrophes and quotation marks. For example,

Anthony heard on the subway the other day, "She actually said, 'Oh my god, Beckie, look at her butt.'"

When using a citation template's |quote= parameter, if the text begins or ends with an apostrophe, the citation template also automatically applies that distinguishing spacing, too. For example,

Mix-a-Lot, Sir. "Baby Got Back". Mack Daddy. 'It is so big. She looks like one of those rap guys' girlfriends', she continued.

However, when using this template, combining the translation and nested quoting, we get both punctuations abutting each other. For example,

French: Elle a exprimé sa confusion en précisant : « Qui comprend ces gars du rap ? », lit. 'She expressed her confusion, elaborating, "Who understands those rap guys?"'

Can such automatic quotation mark-apostrophe-spacing be implemented in this template, too? — Fourthords | =Λ= | 14:52, 22 January 2025 (UTC)