Module talk:Lang-zh

Trailing bold in l= not being removed

In

{{zh|t=竹子林站|j=Zuk1 Zi2 Lam4 Zaam6|l = '''Bamboo Forest station'''}}

, the opening bold markup is properly removed, but the trailing bold markup is not removed. It looks like the regular expression at

term = string.gsub(term, "^([ \"']*)(.*)([ \"']*)$", "%2")

needs some adjustment to the middle wildcard search. – Jonesey95 (talk) 13:23, 16 September 2024 (UTC)

@Jonesey95: This is because the * operator is greedy, so .* matches everything else in the string. Changing .* to .*? would make it lazy, so that the final term catches all trailing characters. In other words, change the line of code to:

term = string.gsub(term, "^([ \"']*)(.*?)([ \"']*)$", "%2")

Freelance Intellectual (talk) 13:51, 16 September 2024 (UTC)

Thanks! That fixed the problem at Zhuzilin station and probably other pages. – Jonesey95 (talk) 17:26, 16 September 2024 (UTC)

Thank you for fixing my shoddy regex, by the way. Remsense ‥ 论 13:05, 19 September 2024 (UTC)

@Jonesey95 and Remsense: On further reflection, this doesn't work as intended. I had thought the string was a regex, but it is in fact a Lua pattern, which is slightly different. The Lua equivalent of *? is - which would give:

term = string.gsub(term, "^([ \"']*)(.-)([ \"']*)$", "%2")

Writing .*? in Lua (as I suggested above) actually means greedily matching all characters (.*) followed by a single question mark (? can also be an operator, but Lua pattern operators can't be nested so in this context it is interpreted as a literal). So actually the new pattern usually doesn't make a substitution, unless there is a question mark. This means it usually fails, e.g. where there are multiple glosses separated by commas and spaces, the spaces are not stripped. However, looking at what the pattern match applies to, I'm not completely sure I understand why the quotes should be stripped in the first place (is there a set of testcases to check against?). At Zhuzilin station, the current code makes no substitution, and so it keeps the bold formatting, presumably as intended. The old code meant that the bold formatting was stripped at the beginning and not the end, so the rest of the article became bold (which was a bad and confusing error). Correcting .*? to .- as above would strip both, making it impossible to add bold formatting. Is the intention to catch cases where an editor unnecessarily adds quotes to the gloss? Is this a common problem? If so, is removing the ability to add bold and italic formatting a fair price to pay?

If we want to strip one quote mark but no more (so that we catch editors manually adding quotes, but allow formatting), pattern matching is a bit more complicated. I think it would be easiest to separate the stripping of whitespace and quotes. When stripping one single quote, we need to check that there isn't more than one, but we also need to allow the string to contain an apostrophe (so we can't just use [^']- in the middle) and a gloss could potentially be a single character (so we can't just use [^'].-[^'] in the middle). So it seems easiest to strip the leading and trailing quotes separately. This gives three lines (I've also removed two sets of brackets that were capturing substrings that weren't used):

term = string.gsub(term, "^ *(.-) *$", "%1")
term = string.gsub(term, "^[\"']?([^\"'].-)$", "%1")
term = string.gsub(term, "^(.-[^\"'])[\"']?$", "%1")

Freelance Intellectual (talk) 15:43, 24 September 2024 (UTC)

I think it's fine to strip all quote marks, in any quantity. That was the original intent of the code, and I don't see any complaints on this page. Adding bold to text is probably against WP:MOS, and adding italics should be done with a parameter. People can use <b>...</b> and <i>...</i> tags if they insist on them. – Jonesey95 (talk) 15:51, 24 September 2024 (UTC)

Okay. I had taken your comment about fixing the Zhuzilin station article to mean that keeping the bold markup was intended, but I can see why it could be discouraged. I've also just found Template:Lang-zh/testcases (I had only looked under Module:Lang-zh before), and I don't see any testcases for stripping markup. So, if stripping markup is the desired functionality, the .- version above would work. I think it would make sense to document this, since there are three different kinds of thing being stripped: whitespace, markup, and quotes (double quotes aren't markup). It could be documented either on Template:Lang-zh/doc or directly as a code comment next to the line we're discussing, e.g. "remove trailing and leading spaces, quotes, and bold/italic markup". Freelance Intellectual (talk) 20:39, 24 September 2024 (UTC)

Currently, this stripping only applies to literal glosses and not translations, but they should reasonably be treated the same. So, fixing the pattern, matching all whitespace (not just spaces), expanding the comments, and applying the same to the translation, I suggest changing lines 236-247 to the following:

			elseif (part == "l") then
				local terms = ""
				-- put individual, potentially comma-separated glosses in single quotes
				-- (first strip leading and trailing whitespace and quotes, including bold/italic markup)
				for term in val:gmatch("[^;,]+") do
					term = string.gsub(term, "^([%s\"']*)(.-)([%s\"']*)$", "%2")
					terms = terms .. "'" .. term .. "', "
				end
				val = string.sub(terms, 1, -3)
			elseif (part == "tr") then
				-- put translations in double quotes
				-- (first strip leading and trailing spaces and quotes, including bold/italic markup)
				val = string.gsub(val, "^([%s\"']*)(.-)([%s\"']*)$", "%2")
				val = """ .. val .. """
			end

Freelance Intellectual (talk) 09:31, 25 September 2024 (UTC)

@Jonesey95 and Remsense: What do you think? Are you happy with the above suggestion?

Also, instead of directly using a Lua string pattern, it might be more readable and maintainable to use an existing function for stripping leading and trailing characters, namely mw.text.trim:

			elseif (part == "l") then
				local terms = ""
				-- put individual, potentially comma-separated glosses in single quotes
				-- (first strip leading and trailing whitespace and quotes, including bold/italic markup)
				for term in val:gmatch("[^;,]+") do
					term = mw.text.trim(term, "%s\"'")
					terms = terms .. "'" .. term .. "', "
				end
				val = string.sub(terms, 1, -3)
			elseif (part == "tr") then
				-- put translations in double quotes
				-- (first strip leading and trailing spaces and quotes, including bold/italic markup)
				val = mw.text.trim(val, "%s\"'")
				val = """ .. val .. """
			end

Freelance Intellectual (talk) 09:02, 27 September 2024 (UTC)

@Jonesey95 and Remsense: pinging again. The current code inserts quotes incorrectly, e.g. on the following pages you can see an opening quote followed by a space: Gun (staff), Indonesian slang, Ping On. The code above would fix this. Freelance Intellectual (talk) 14:23, 8 October 2024 (UTC)

Reping Remsense. Could you please look at this? I think you're one of the only template editors who has enough understanding of Chinese orthography to understand what is being changed here and why. * Pppery * _{it has begun...} 17:19, 16 November 2024 (UTC)

Will have this looked at ASAP. Huge apologies for letting it slip through the cracks for months. Remsense ‥ 论 23:39, 16 November 2024 (UTC)

 Done – so sorry for the delay, again. Remsense ‥ 论 23:37, 18 November 2024 (UTC)

The unnamed parameter

Hiya! I've just only now noticed that if you pass {{lang-zh}} and pals an unnamed parameter in addition to any other parameter (like |p=, fr.ex.), the unnamed parameter does not display, rather than being aliased to |c=.

This is in the documentation, but what's the reason for this behaviour? I'm struggling to imagine any case where an editor calls {{lang-zh}} with an unnamed parameter alongside any other parameter, and puts anything in the |1= spot other than the Chinese text to display (the basic purpose of the template).

Happy to hear I'm just dumb and have overlooked an obvious use case, but if no one knows of any can we just map |1= to |c= excepting where one or more of {|c=, |t=, |s=} is passed to the template? Folly Mox (talk) 18:08, 25 January 2025 (UTC)

@Folly Mox I fully agree with your request. I have no idea why {{lang-zh|实验|p=shíyàn}} displays as pinyin: shíyàn, instead of Chinese: 实验; pinyin: shíyàn. Chinese: 实验 and 实验 work, though. Toadspike [Talk] 21:19, 30 January 2025 (UTC)

Use / between simplified and traditional when labels=no

I was looking at Chinese classifier, which uses a lot of inline Chinese, and realized that it would be better, when labels are off, to have a slash between the simplified and traditional versions of a phrase instead of the current semicolon. As an example, "The classifier 个; 個, pronounced..." would look better as "The classifier 个/個, pronounced...". Since these are alternate versions of the same character (which is not explained when labels are off), I think the slash conveys this better than the semicolon. Toadspike [Talk] 21:12, 30 January 2025 (UTC)

no-merging s and t

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)

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