Module talk:Lang-zh

Template-protected edit request on 5 February 2024
This may be politically inclined, but I am highly unsure if Tongyong Pinyin should be our generic, as the mainland Pinyin wins by a very large margin in users.

I propose the following changes:

Alternatively, if Pinyin is not a suitable generic, we should still add variant tags for Tongyong Pinyin:

NasssaNsertalk 11:01, 5 February 2024 (UTC)


 * This seems sensible to me – hanyu pinyin is more widely used than tongyong pinyin, and indeed MOS:PINYIN mentions that hanyu pinyin is the default romanization we use. What would the effect of this change be from the reader's perspective? —Mx. Granger (talk · contribs) 15:30, 10 February 2024 (UTC)
 * Like the rest of the language metadata, it adds specificity for screenreaders, as well as other possible presentations of articles. Remsense  诉  23:21, 10 February 2024 (UTC)
 * ✅– I double-checked, and IANA added Tongyong as a valid language subtag variant in 2020. Remsense  诉  23:20, 10 February 2024 (UTC)
 * ✅ * Pppery * it has begun... 04:53, 11 February 2024 (UTC)

Template-protected edit request on 5 April 2024
I would like to enable the option "first=poj" analogously to "first=j". The "first=j" option allows Cantonese romanisations to be given before Mandarin romanisations, in articles where Cantonese is more relevant. The proposed "first=poj" option would allow Hokkien romanisation (POJ) to be given first, in articles where Hokkien more relevant, e.g. for Bukit Ho Swee, Hong-Gah Museum, Tamsui District.

I believe this could be achieved by adding the following:

From line 114, after:

local j1 = false -- whether Cantonese Romanisations go first

insert:

local poj1 = false -- whether Hokkien Romanisations go first

From line 121, after:

if (testChar == "j") then j1 = true end

insert:

if (testChar == "poj") then poj1 = true end

(The variable is named "testChar" but it is defined by the regular expression "%a+", which will match not only a single character but also longer strings.)

(On a separate note, there seems to be a superfluous space before "end" on lines 120 and 123.)

From line 137, after:

if (j1) then orderlist[4] = "j" orderlist[5] = "cy" orderlist[6] = "sl" orderlist[7] = "p" orderlist[8] = "tp" orderlist[9] = "w" end

insert:

if (poj1) then orderlist[4] = "poj" orderlist[5] = "p" orderlist[6] = "tp" orderlist[7] = "w" orderlist[8] = "j" orderlist[9] = "cy" orderlist[10] = "sl" end

This puts POJ before the Mandarin and Cantonese romanisations. Freelance Intellectual (talk) 08:49, 5 April 2024 (UTC)
 * ✅ * Pppery * it has begun... 02:53, 15 April 2024 (UTC)

Double-quotes around glosses
Is there a reason we use double-quotes rather than single-quotes to show the output of tr? MOS:SIMPLEGLOSS suggests we should prefer singles. — OwenBlacker (he/him; Talk) 17:37, 18 June 2024 (UTC)


 * Because l is used for literal translations & glosses, and tr is (much more rarely) used for non-literal translations. Remsense  诉  17:39, 18 June 2024 (UTC)
 * Aha, that makes sense. So I have probably been misusing tr when I should have been using l. Thank you! — OwenBlacker (he/him; Talk) 18:03, 18 June 2024 (UTC)

Commas within literal glosses
What should we do if there needs to be a comma within a literal translation? I noticed this on Yi Jian Mei (song), where the quotes should be placed around the whole comma-separated phrase, not individually around each side of the comma. pacificboy (talk) 03:56, 11 July 2024 (UTC)


 * My assumption when adding this feature was that if one needed to add a comma, it should probably be treated as a proper translation, not a gloss. It turns out I never use this formatting, so I could very plausibly disable it. Remsense  诉  05:49, 11 July 2024 (UTC)
 * Ah, that makes sense! I’ll convert it to a translation. Thanks. pacificboy (talk) 02:45, 12 July 2024 (UTC)