Module talk:Lang-zh

Today I was editing Jing (philosophy) and I realized that the article began with "(Chinese: 敬; Chinese: 敬)". This is because the editor had written {{zh|c=敬|t=敬}} and gotten Chinese: 敬; Chinese: 敬. I tried to correct this to {{zh|s=敬|t=敬}} and got a single "Chinese: 敬" instead, which does not adequately display the difference in the grass radical. I write this here as support for the merge=no option, which I read about in the talk page archives of this template while trying to figure this situation out. Then again: I don't know Chinese, so maybe this is an unimportant difference.

(After dabbling with variation selectors, I ended up just using a zero width space to differentiate the fields.) Dingolover6969 (talk) 14:22, 20 April 2025 (UTC) [reply ]

@Dingolover6969: I see the motivation for occasionally needing to distinguish character variants that share a Unicode code point, but the need for an extremely lengthy invisible comment indicates that using a non-breaking space is not a good solution. It also allows a linebreak between the character and the semi-colon, which is incorrect.

In the particular case of Jing (philosophy), highlighting the distinction is unnecessary. In the talk page archive that you mentioned (where the conclusion was not to include a no-merge option), I fully agree with the comment by @Kanguole: "What is the purpose of this template? I think it is to convey the Chinese name of the person, book, etc that is the subject of article, for readers who understand characters. It's not to give lessons in typography to people who don't understand hanzi – we have specialist articles for that."

On Wade–Giles#Tones where you have also added a non-breaking space, the same effect can be more transparently achieved by using the template twice. In that case, the difference is again unimportant, but I support displaying both variants because it aligns the characters with the other rows in the table. Freelance Intellectual (talk) 09:18, 22 April 2025 (UTC) [reply ]

I see what you mean. I have no strong opinions about it, really. Whether "for readers who understand characters" this distinction is important is beyond me. Another editor had apparently tried to achieve this, creating an odd result, but maybe they were mistaken to want to.

Good call on the Wade-Giles tone table.

Anyway, for those rare cases when the distinction might be required and the template is invoked only once:

I thought allowing breaking was the right behavior, out of ignorance, but reviewing the Unicode recommendation on the matter makes me think I was wrong, and in fact line breaks shouldn't be allowed before semicolons or close-parentheses. A word joiner ⁠ could be used instead to get the correct behavior.

There also is some intended way to do this in Unicode itself with variation selectors. I'm pretty sure this is the way, but not sure enough that I would want to put in on a page: 敬︀; 敬 (text: 敬︀, 敬) 麻; 麻︀ (text: 麻, 麻︀). The details of which variation selector to use for what is different for every character. It's a simple enough system, and the ideal solution if you're confident, but I'm not confident. The "text" renditions above should also display as the appropriate trad and simp variants — they don't on my system; the template displays them distinctly simply because they are distinct Unicode sequences (post-normalization). Dingolover6969 (talk) 15:27, 28 April 2025 (UTC) [reply ]

Chinese speaker (reader?) here, I usually gloss over the two different versions of the grass radical without noticing it. I've never heard of anyone caring about the difference. Unless we're discussing that radical specifically, I don't see the need to list both characters; if we are discussing that radical specifically, it might be better to use images, where the difference can be more clearly shown. I'm not firmly opposed to adding a merge=no option, but I haven't yet seen a case where it would be useful. Toadspike [Talk] 21:00, 28 April 2025 (UTC) [reply ]

I had a momentary confusion on the article Captain of Destiny where it sort of looks like "literally" doesn't apply to the Chinese text. I've since edited it to clarify, but look at the previous version to see what I mean. I skimmed the template documentation but didn't see a reason given. — W.andrea (talk) 14:48, 1 May 2025 (UTC) [reply ]

The semicolon was outside of the template in the previous version. How would this template or its documentation affect that situation? In your updated version, you have used the |l= parameter, but I would have put "Cheung Po the Kid" as the value, per the linked article. – Jonesey95 (talk) 17:47, 1 May 2025 (UTC) [reply ]

Sorry, I don't think you understand what I'm asking: For most languages, things are separated by commas, while different languages are separated by semicolons, e.g.

French: maison, lit. 'house'; Spanish: casa, lit. 'house'

Why does this template use semicolons instead of commas? e.g.

Chinese: 房屋; lit. 'house'

For a counter-example, {{langx}} uses commas:

Chinese: 房屋, lit. 'house'

— W.andrea (talk) 13:44, 2 May 2025 (UTC) [reply ]

The semicolon was outside of the template in the previous version. How would this template or its documentation affect that situation?

Oh sorry, I might have misunderstood what you meant by this. Yes the semicolon was outside the template, but it was following the convention of the template, and after editing, the semicolon is inside the template. — W.andrea (talk) 13:51, 2 May 2025 (UTC) [reply ]

In your updated version, you have used the |l= parameter, but I would have put "Cheung Po the Kid" as the value, per the linked article.

I just used what was already there and it's the title of the linked article. I don't speak Chinese anyway so I wouldn't feel comfortable changing it. But this is beside the point of my question. — W.andrea (talk) 13:53, 2 May 2025 (UTC) [reply ]

I see what you mean. This module appears to separate each parameter with semicolons. The list of parameters in lines 18–52 are undifferentiated. I think someone would have to adjust the module code to precede "lit." with a comma. – Jonesey95 (talk) 17:24, 2 May 2025 (UTC) [reply ]

Just noticed this on the Mangtong page while clearing old "missing end tag" errors:

It seems like passing a value ending with an italicized value via the l= parameter throws the Linter error. Adding a &nbsp or equivalent parameter after the closing italics tag won't resolve the error...

The only solution appears to be if a non-apostrophe/non-quotation after the close-italics tag but before the }}:

...which seems a bit of a hack.

Interestingly, attempting to italicize the entire value results in both italics tags being ignored (same as when leaving italics tags out altogether)...

Any chance this can be fixed?

SirOlgen (talk) 16:28, 21 August 2025 (UTC) [reply ]

So to put it in non-Lint terms, it doesn't appear as though this template's "literal" parameter is properly handling italics tags which occur either first or last in the passed string. SirOlgen (talk) 18:09, 21 August 2025 (UTC) [reply ]

Yes, see this previous discussion: Module_talk:Lang-zh/Archive_5#Trailing_bold_in_l=_not_being_removed. A workaround is to use HTML italic tags, e.g. {{zh|l=reformed <i>mangtong</i>}} for lit. 'reformed mangtong'. The stripping of bold and italic markup is commented in the code but not mentioned in the template documentation. At the time of the previous discussion, I wasn't convinced that stripping quotation marks was necessary, but I also didn't know of any use cases where it would cause a problem and so I didn't push the point further. However, this looks like a valid use case, and I think we should revisit the question of why quotes should be stripped. In contrast, this doesn't happen for {{lit }}, which otherwise has extremely similar functionality to the |l= parameter. Freelance Intellectual (talk) 21:57, 22 August 2025 (UTC) [reply ]

Thanks a million for the background info and workaround (I'm embarrassed for not having thought to try that, LOL). This does seem like a pretty obscure use case, but it also seems a near certainty there will be more examples out there among the 1.9M outstanding "missing end tag" errors.

Thanks again!

SirOlgen (talk) 02:11, 24 August 2025 (UTC) [reply ]

I have boldly removed the stripping of ' marks from the |l= parameter in the module sandbox. I added test cases from the previous discussion to Template:Lang-zh/testcases (see the "miscanthus" example and the following three tests). Does anyone see any problems on the testcases page? The potential downside is that bold formatting is applied, as in the "Bamboo Forest station" example. Given that this bold/italic stripping is not mentioned in the documentation, removing this stripping may be fine. Pinging Remsense from the previous conversation. – Jonesey95 (talk) 13:50, 11 September 2025 (UTC) [reply ]

Thanks for this! I added testcases for simple literal string italicization of (A) the full string, (B) the first word, and (C) the last word. Looks solid. I didn't notice anything out of whack in the other testcases (other than what's flagged in red). – SirOlgen (talk) 20:42, 11 September 2025 (UTC) [reply ]

Good test cases. I have somewhat trepidatiously migrated this change to the live module. This will cause bold in places where it has been hidden until now. It is not clear to me why this template was stripping bold markup, or whether that was a side-effect of trying to remove single ' characters used as quotation marks. I expect that if this change causes any harm, we'll get a note on this page. – Jonesey95 (talk) 21:47, 11 September 2025 (UTC) [reply ]

Minor change, but a comment refers to Tongyong Pinyin as "Tongyu Pinyin". This should be changed, for clarity for readers of the module.

Diff:

Ookap (talk) 20:01, 20 December 2025 (UTC) [reply ]

Completed. P.I. Ellsworth , ed. – welcome! – 10:27, 22 December 2025 (UTC) [reply ]