Module talk:Lang-zh/Archive 5

Archive 1

←

Archive 3

Archive 4

Archive 5

Cantonese Pinyin?

Hello, how does one indicate use of Cantonese Pinyin romanization? For example, in March Tian Boedihardjo (I assume this is Cantonese Pinyin). Λυδαcιτγ 06:11, 18 July 2018 (UTC)

I can’t find the Romanisation in any of the sources (though many are dead links). It seems unlikely it would be used, as in e.g. English media his Indonesian name is fine, and that seems to be what’s used. In Chinese media his Chinese name is all that’s needed.--JohnBlackburne^words_deeds 07:51, 18 July 2018 (UTC)

I’ve removed it. Seems it was changed from pinyin to this other Romanisation in this change several months ago, with no rationale by an IP editor. Neither it nor the pinyin was sourced that I can see, and as there’s no evidence he uses anything other than his Indonesian name there’s no need for it.--JohnBlackburne^words_deeds 11:05, 18 July 2018 (UTC)

CJKV

Like the various templates that have been merged into {{lang-zh}}, {{CJKV}} is a bit of a sprawling mess of template syntax right now. This module is currently focused on Chinese, but I wonder if we could generalize it to cover Japanese, Korean, and Vietnamese romanizations of Chinese characters as well, since there's already significant overlap between {{CJKV}} and this module. – Minh Nguyễn ^💬 20:54, 18 July 2018 (UTC)

How to display Traditional first, then Simplified, then Cantonese, then Mandarin?

At Verax (film) I want to display Traditional first, then Simplified, then Cantonese, then Mandarin. How may I do this?

Thanks, WhisperToMe (talk) 22:09, 6 August 2018 (UTC)

• WhisperToMe, you can use the parameter |first= with t,j. See Template:Lang-zh#Ordering.--JohnBlackburne^words_deeds 05:08, 14 August 2018 (UTC)

Needs a parameter to stop changing labels to just "Chinese" if either |t= or |s= is missing

Many times we'll want to be specific. It should not be impossible to get "Traditional Chinese:" from {{zh|t=趙豐邦}}.  — SMcCandlish ☏ ¢ 😼  03:00, 25 July 2018 (UTC)

SMcCandlish I disagree. If a sentence article contains just one sort of Chinese, whether simplified or traditional (and all Chinese is one or the other, perhaps both) then by far the most sensible article to link to is Chinese language. The vast majority of readers won’t notice or care which of traditional or simplified is used.

There are exceptions. If both simplified and traditional Chinese text is included then it makes sense to name and link to both articles at least once, and the template does this automatically. If a particular point is being made about it being traditional Chinese then the link should be incorporated into the text that is making that point.

But in normal usage it makes sense to work as it does. It’s worked like that for a very long time, from before I rewrote it to use Lua. If you really need to do it another way on a case by case basis then it’s probably best to do it manually, using e.g. {{lang}} which does not add any links.--JohnBlackburne^words_deeds 05:24, 14 August 2018 (UTC)

re-ping SMcCandlish as I messed it up first time.--JohnBlackburne^words_deeds 05:24, 14 August 2018 (UTC)

Hmm. "I disagree" followed by "There are exceptions" is contradictory. My statement that "it should not be impossible" to be specific, and your statement that there are exceptions to your Chinese language generality link idea, and that we should sometimes be specific, are directly equivalent statements. I'll approach this from a different angle: The only reason I have not simply fixed it is that I suck at Lua. If this were a regular template, I would have resolved this in a few minutes of editing in the template code, and I really don't think anyone would be objecting.  — SMcCandlish ☏ ¢ 😼  16:43, 8 November 2018 (UTC)

Template Data broken

I use the visual editor a lot and I realized in the past week the template data is broken. Has this been a problem for anyone else? --Daviddwd (talk) 19:28, 19 January 2019 (UTC)

Xiao'erjing

Having just noticed Xiao'erjing text in the lead to Taklamakan Desert, I wondered if it's worthwhile to add another argument to this module to allow something like |x=تَاكْلامَاقًا شَاموْ, which would then add Xiao'erjing: تَاكْلامَاقًا شَاموْ (so the equivalent of [[Xiao'erjing]]: {{lang|zh-Arab|تَاكْلامَاقًا شَاموْ}}) to the end of the output? — OwenBlacker (talk; please {{ping}} me in replies) 18:23, 15 August 2018 (UTC)

I'm in favor of this. --Daviddwd (talk) 19:57, 21 January 2019 (UTC)

Requested change

This template displays double quotes with the parameter l=. Could this please be changed to single quotes per MOS:SINGLE and other language templates (e.g. {{lang-ar}}). Shhhnotsoloud (talk) 20:44, 16 December 2018 (UTC)

I support this. --Daviddwd (talk) 19:59, 21 January 2019 (UTC)

MOS:SINGLE

Resolved

The literal gloss (|l= parameter) needs to be bracketed in single not double quotations, per MOS:SINGLE.  — SMcCandlish ☏ ¢ 😼  22:52, 20 February 2019 (UTC)

See #Requested change above. Just need someone competent to do it! Shhhnotsoloud (talk) 07:52, 21 February 2019 (UTC)

Suggestion executed. On a more general note, the fact that this request took three months to get executed is exactly why I think there is far too much use of lua and go around TfDing modules. {{3x|p}}ery (talk) 05:05, 22 February 2019 (UTC)

@Pppery: I agree (though this particular request dates to this month; I think you were looking at a different tab). But discussing it here won't help, since this is a backwater. :-) I've raise a larger thread at TfD talk, as an RfC: Wikipedia talk:Templates for discussion#RfC: Proposal to make TfD more RM-like, as a clearinghouse of template discussions.
 — SMcCandlish ☏ ¢ 😼  05:14, 27 February 2019 (UTC)

@SMcCandlish: It was originally proposed at #Requested change in December. (I was exaggerating a little bit, it was only two months) {{3x|p}}ery (talk) 05:21, 27 February 2019 (UTC)

Noted!  — SMcCandlish ☏ ¢ 😼  05:41, 27 February 2019 (UTC)

Also pinging Shhhnotsoloud.  — SMcCandlish ☏ ¢ 😼  05:15, 27 February 2019 (UTC)

@Pppery: You changed the opening quote but not the closing quote. Toohool (talk) 06:16, 27 February 2019 (UTC)

I noticed that and went to fix it but the module is cascade protected at the moment. Johnuniq (talk) 06:21, 27 February 2019 (UTC)

Wouldn't an edit request template have resolved this more quickly? As you say, this is a backwater, but the edit request lists are watched by many competent editors. – Jonesey95 (talk) 07:22, 27 February 2019 (UTC)

@Jonesey95:  Not done: please make your requested changes to the module's sandbox first; see WP:TESTCASES. (seriously, an edit request template could easily have attracted someone responding with that boilerplate message) {{3x|p}}ery (talk) 20:32, 27 February 2019 (UTC)

Please edit this module to change line 185 from the first of the following lines to the second, per discussion just above.

val = "'" .. val .. '"'
val = "'" .. val .. "'"

This puts an apostrophe on both sides of val. Johnuniq (talk) 08:47, 27 February 2019 (UTC)

 Done —TheDJ (talk • contribs) 09:31, 27 February 2019 (UTC)

A problem with defaulting to simplified

The parameter c renders characters in the simplified typeface. This has resulted in inconsistencies for Taiwan, Hong Kong and Macau names. I propose that the parameter be removed or use be discouraged. Ythlev (talk) 14:31, 19 June 2019 (UTC)

Parameter c= doesn't render anything, it only marks text as Chinese (zh). Which locale incl. typeface is selected for that purpose depends on your browser/​system settings. Love —LiliCharlie (talk) 16:56, 19 June 2019 (UTC)

Minor romanization formatting points

I've noticed when Peh-oe-ji or jyutping is provided, it uses fullwidth characters. Furthermore, |j= does not superscript the numbers included automatically as does Wade-Giles (|w=). Could we fix this? --Daviddwd (talk) 19:59, 21 January 2019 (UTC)

I have the same problem. The troublesome code seems to be this:

["cy"] = "yue",
["sl"] = "yue",
["poj"] = "nan",

which could be simply changed to

["cy"] = "yue-Latn",
["sl"] = "yue-Latn",
["poj"] = "nan-Latn",

Wikifresc (talk) 23:47, 8 March 2019 (UTC)

Putting in an edit request for the above edit to be carried out, though it won't fix the issue with |j=. Romanisations should obviously be tagged as Latin script and rendered appropriately. —Nizolan ^(talk) 19:21, 12 July 2019 (UTC)

 Done — xaosflux ^Talk 13:38, 23 July 2019 (UTC)

Jyutping

In addition to Wikifresc's proposed edit, and for the same reason, please edit "yue-jyutping" on line 57 to "yue-Latn-jyutping". This has also been added to the sandbox and fixes the fullwidth character issue Daviddwd identified (see Template:Lang-zh/testcases). —Nizolan ^(talk) 20:37, 12 July 2019 (UTC)

 Done — xaosflux ^Talk 13:38, 23 July 2019 (UTC)

@Xaosflux: Might be missing something but it doesn't look like you made any edits at Module:Zh—guessing this is a mistake. Reopening the requests for now. —Nizolan ^{(talk · c.)} 19:36, 23 July 2019 (UTC)

@Nizolan: very very odd, my commit must have failed, I even had my edit summary saved in my browser's autocomplete. Check now? — xaosflux ^Talk 20:23, 23 July 2019 (UTC)

@Xaosflux: Works great now, thanks. —Nizolan ^{(talk · c.)} 20:56, 23 July 2019 (UTC)

Proposal to add Foochow Romanized (BUC)

Hello all. I am doing some work on the Matsu Islands and the Fuzhou area of Fujian Province, and I was wondering if we could add BUC to the module. Articles like Dongyin, Lienchiang have BUC written on the page with no blue link to the Foochow Romanized page, and I think it looks unprofessional (as well as uninformative). Thanks for any help or suggestions. Geographyinitiative (talk) 06:30, 31 August 2019 (UTC)

(Also, BUC is the form used on the Mìng-dĕ̤ng-ngṳ̄ Wikipedia ( https://cdo.wikipedia.org )- why exclude them?) Geographyinitiative (talk) 06:31, 31 August 2019 (UTC)

Requested move 29 October 2019

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: moved (closed by non-admin page mover) DannyS712 (talk) 06:28, 6 November 2019 (UTC)

---

Module:Zh → Module:Lang-zh – Match name with template * Pppery * _{it has begun...} 22:10, 29 October 2019 (UTC)

• Support per nom. --Gonnym (talk) 14:00, 30 October 2019 (UTC)

---

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Proposal for "first=poj"

The first sentence of Hong-Gah Museum and Tamsui would be made better with 'first=poj'. Geographyinitiative (talk) 10:49, 19 November 2019 (UTC)

The romanization name "Cantonese Yale" is confusing

As someone who has some familiarity with Chinese Romanization systems, upon looking up "New Territories" I was confused by the phrase "Cantonese Yale", generated by the zh template. Upon examining the template definition, I find that "Cantonese Yale" is the phrase used to denote the Yale Romanization system. That phrase looks strange in English as it (1) inverts the usual English adjective-noun order (2) omits the word "Romanization".

Searching the internet outside of Wikipedia, I find that occurrence of the phrase "Cantonese Yale" to be vanishingly rare.

I suggest that the text produced by the zh template in response to "cy" as a template parameter be changed from "Cantonese Yale:" to simply "Yale:" or maybe "Yale romanization:"

I am not implementing this change myself at this time, but I request that someone familiar with the zh template please do so. Dratman (talk) 00:01, 3 February 2020 (UTC)

Template-protected edit request on 24 July 2020

Line 186: please change val = "'" .. val .. "'" to val = "{{'}}" .. val .. "{{'}}".

See Project 523 § Discovery of artemisinin and its derivatives as an example. In that section, placing '' around the template would be unnecessarily italicize the entire template-generated text, instead of just the value in the |l= parameter. As is, the '' in the template combine with the ' from this module to bold the title, which is unexpected behavior. If we could escape that character here, that would solve that problem without changing the behavior of the template elsewhere. Thanks! Rotideypoc41352 (talk · contribs) 22:48, 24 July 2020 (UTC)

To editor Rotideypoc41352:  Not done: put that in the sandbox and all it does is place {{'}} in the template, as in (Chinese: 《肘後備急方》; lit.: {{'}}The Handbook of Prescriptions for Emergencies{{'}}). Not sure how to fix this other than using only one apostrophe in the template, as in (Chinese: 《肘後備急方》; lit.: 'The Handbook of Prescriptions for Emergencies' as I have done at Project 523 § Discovery of artemisinin and its derivatives. I'll keep checking back here to see if you have come up with something else. The sandbox can be used in "preview" to see if it works. P.I. Ellsworth  ed. ^put'r there 00:14, 25 July 2020 (UTC)

To editor Rotideypoc41352: Looking at this more closely, we find that the "literal translation" parameter, |l=, is used in the example you gave as follows:

l=The Handbook of Prescriptions for Emergencies

That is a lower case letter "l", for "literal", not the number "1", by the way. When the |l= parameter is used, this module automatically links to lit. (literal translation) and encloses the text in single quotation marks, as in:

Chinese: 《肘後備急方》; lit. 'The Handbook of Prescriptions for Emergencies'

For the most part, this is adequate to note the translation. As you have seen, problems arise when the translation is the title of a film or book, and it should be in italics. That is easily dealt with by adding a single quote mark (apostrophe) at the beginning and end of the text, as follows:

{{lang-zh|t=《肘後備急方》|l='The Handbook of Prescriptions for Emergencies'}}

and results in:

Chinese: 《肘後備急方》; lit. 'The Handbook of Prescriptions for Emergencies'

That is the only way I know of to deal with such titles without mucking up the works for other uses where italics are not called for. Hope this helps! P.I. Ellsworth  ed. ^put'r there 06:14, 25 July 2020 (UTC)

It does! I was hoping for a less work-aroundy solution, but if that's how the cookie crumbles, that's how the cookie crumbles. Thanks again! Rotideypoc41352 (talk · contribs) 07:51, 27 July 2020 (UTC)

Question about rendering of depreciated zh-t and zh-trad

I realize that the other zh templates have been consolidated into lang-zh, but when zh is still used, it do not seem to render traditional Chinese characters properly. For example, if I want unicode U+4ECA, then zh-t (and zh-trad) give me 今, but it should actually render as 今 (as lang-zh|t= correctly does). Similarly, zh-t incorrectly renders 次 and 骨, whereas lang-zh|t= correctly renders 次 and 骨.

This seems to be a result of Han unification (see the examples), so I was wondering if this is intentional or known behavior. It would make more sense to me, at least for backwards-compatibility, for zh-t to render the same as lang-zh|t=, but it currently does not. ChromeGames923 (talk · contribs) 19:15, 10 September 2020 (UTC)

MOS compliance

Notified: WP:CHINA. — Goszei (talk) 19:00, 14 May 2020 (UTC)

Notified: MOS:LEAD. — Goszei (talk) 03:04, 23 November 2020 (UTC)

The Manual of Style section for foreign-language names (MOS:LEADALT) states:

Relevant foreign-language names, such as in an article on a person who does not themselves write their name in English, are encouraged. Separate languages should be divided by semicolons, and romanizations of non-Latin scripts by commas.

This seems to clearly prescribe changes to this template, which currently looks like this:

simplified Chinese: 中国; traditional Chinese: 中國; Hanyu Pinyin: Zhōngguó; Tongyong Pinyin: Jhongguó

At the least, the pinyin fields should be separated by a comma and not a semicolon, because they are romanizations and not separate languages. In cases like:

Chinese: 最高人民法院; pinyin: Zuìgāo Rénmín Fǎyuàn

The MOS clearly prescribes a comma separator. Comments? — Goszei (talk) 04:39, 14 May 2020 (UTC)

I was actually kind of skeptical at first, but I see your point. I noticed this while looking at Gyirong Town, which lists the name in both Mandarin and Nepali, rendered as (Chinese: 吉隆镇; pinyin: Jílóng zhèn; Nepali:केरुङ). That setup might be confusing for someone unfamiliar with what Chinese or what pinyin means. WhinyTheYounger (talk) 22:37, 21 May 2020 (UTC)

Template-protected edit request on 30 March 2020

literal translations should be labeled "lit." not "literally" for brevity when that parameter is used. Or a translation parameter should be used like Template:Lang-ja

Mualphachi (talk) 17:18, 30 March 2020 (UTC)

• Support, here for the same proposal. I think "lit." is even better. (consistent with other {{Lang-xx}}) -- Akira😼CA 10:25, 8 April 2020 (UTC)

  I've mocked it up, example is in Template:Lang-zh/testcases. @Mualphachi and Akira CA: if it looks good I'll implement. Primefac (talk) 16:31, 18 April 2020 (UTC)

  @Mualphachi and Akira CA: your comments please? — Martin (MSGJ · talk) 07:28, 5 May 2020 (UTC)

 Done No one has said anything about the change, and it's doing what was requested, so in the grand scheme of SILENCE and "why not" I've made the change - no opposition to rolling back if there are serious concerns or bugs. Primefac (talk) 14:07, 15 May 2020 (UTC)

thanks, looks good Mualphachi (talk) 04:14, 18 May 2020 (UTC)

@Primefac, Mualphachi, and Akira CA: I like the change, and would like to suggest two small tweaks (which are not a package, and could be implemented separately).

• the colon in lit.: could be removed, as it simply looks cleaner without, IMO. This would also match with the format of my next suggestion.

• Template:Literal translation (renders as lit.) could be used here, as the tooltip gives the necessary level of info, and the wikilink to literal translation seems like overkill to me. — Goszei (talk) 02:50, 23 November 2020 (UTC)

Addendum: I have found another option. Upon inspecting the other Lang-x templates (French, Spanish, German, etc.), I have found that they all use this format, which utilizes small tags: (French: Marine nationale, lit. 'National Navy'). — Goszei (talk) 03:59, 23 November 2020 (UTC)

Just a quick note to say that I've seen this and it's on my list of things to get to. Primefac (talk) 12:22, 26 November 2020 (UTC)

|l= now shows lit. (small, w/o colon). Primefac (talk) 21:23, 3 December 2020 (UTC)

@Primefac: Whatever you did to the module, it created error messages on pages using {{Lang-zh}}. Red text stating 'Lua error in Module:Lang-zh at line 218: Tried to read nil global part.' appeared on an article I happened to look at. You can see this in the testcases. Cheers, Number 57 21:32, 3 December 2020 (UTC)

Fixed, the second was for when there's no param, so it kind of makes sense that it would throw that error. In the back of my mind I wondered about that (at least it's an easy fix). Primefac (talk) 21:34, 3 December 2020 (UTC)

Request to Add override default ordering option for POJ as the first in the ordering

Hi, I'd like to request if someone could please edit the code so as to add an option to also override the default ordering so as to put Hokkien POJ first before Pinyin and the others, just like how Cantonese Jyutping can already do that. I think maybe the order of 'poj, zhu, w, hp, tp' might do.--Mlgc1998 (talk) 21:07, 7 December 2020 (UTC)

Doesn't the template already allow custom ordering? Primefac (talk) 13:43, 8 December 2020 (UTC)

@Primefac: Hi apologies, I just saw this now lol. If you look at the code, it is only hardcoded to accept 2 inputs in the Ordering field, either "t" or "j" to put either Traditional Chinese first or Cantonese Romanizations first. In order to add the option to place POJ first, I suggest to add the code for the if statements to accept these as well, unless you would like to think up the code that accepts custom ordering based on input.

function p._Zh(args)
	local uselinks = not (args["links"] == "no") -- whether to add links
	local uselabels = not (args["labels"] == "no") -- whether to have labels
	local capfirst = args["scase"] ~= nil
 
	local t1 = false -- whether traditional Chinese characters go first
	local j1 = false -- whether Cantonese Romanisations go first
+	local poj1 = false -- whether Hokkien Romanisations go first
	local testChar
	if (args["first"]) then
	 	 for testChar in mw.ustring.gmatch(args["first"], "%a+") do
			if (testChar == "t") then
				t1 = true
			end
			if (testChar == "j") then
				j1 = true
			end
+			if (testChar == "poj") then
+				poj1 = true
+			end
		end
	end
	if (t1 == false) then
		local title = mw.title.getCurrentTitle()
		t1 = t1st[title.text] == true
	end

	-- based on setting/preference specify order
	local orderlist = {"c", "s", "t", "p", "tp", "w", "j", "cy", "sl", "poj", "zhu", "l"}
	if (t1) then
		orderlist[2] = "t"
		orderlist[3] = "s"
	end
	if (j1) then
		orderlist[4] = "j"
		orderlist[5] = "cy"
		orderlist[6] = "sl"
		orderlist[7] = "p"
		orderlist[8] = "tp"
		orderlist[9] = "w"
	end
+	if (poj1) then
+		orderlist[4] = "poj"
+		orderlist[5] = "zhu"
+		orderlist[6] = "w"
+		orderlist[7] = "p"
+		orderlist[8] = "tp"
+	end

add new translation parameter "tr"

could someone implement these small changes to add a Translation parameter? the concept of literal translation is limiting in use cases for translating texts...

diff --git a/lang-zh.lua b/lang-zh.lua
index 7a8791c..1fe24a5 100644
--- a/lang-zh.lua
+++ b/lang-zh.lua
@@ -29,6 +29,7 @@ local labels = {
 	["poj"] = "Pe̍h-ōe-jī",
 	["zhu"] = "Zhuyin Fuhao",
 	["l"] = "lit.",
+	["tr"] = "trans.",
 }
 
 -- article titles for wikilinks for each part
@@ -115,7 +116,7 @@ function p._Zh(args)
 	end
 
 	-- based on setting/preference specify order
-	local orderlist = {"c", "s", "t", "p", "tp", "w", "j", "cy", "sl", "poj", "zhu", "l"}
+	local orderlist = {"c", "s", "t", "p", "tp", "w", "j", "cy", "sl", "poj", "zhu", "l", "tr"}
 	if (t1) then
 		orderlist[2] = "t"
 		orderlist[3] = "s"
@@ -186,7 +187,7 @@ function p._Zh(args)
 				-- add span for language if needed
 				params = {["lang"] = ISOlang[part]}
 				val = mw.text.tag({name="span",attrs=params, content=val})
-			elseif (part == "l") then
+			elseif ((part == "l") or (part == "tr")) then
 				-- put literals in quotes
 				val = "'" .. val .. "'"
 			end

talk@TRANSviada 01:39, 27 February 2021 (UTC)

@Jonesey95: @Pppery: @Xaosflux: @Firefly: @Earl Andrew: @Tol: help?talk@TRANSviada 22:27, 25 November 2021 (UTC)

@HJ Mitchell: can you have a look at this?talk@TRANSviada 21:13, 25 November 2021 (UTC)

Sorry, I'd have no idea what I was doing. HJ Mitchell | Penny for your thoughts? 21:19, 25 November 2021 (UTC)

@HJ Mitchell:Do you mean back when you created this template? I implemented the above changes in Template:Lang-zh/sandbox/tr pretty much by copying what the already existing l (literal translation), so it works just as that but with different letter and abbreviation, and am using it at Shizuka (band), so you can have a look that it works. Those are really small changes. The only thing that could go wrong is if the elseif was implemented wrong, but it work as expected in Shizuka (band).talk@TRANSviada 21:59, 25 November 2021 (UTC)

Erm, it looks like I just protected it, back in 2014 (seven and a half years ago!), almost certainly from an RfPP request. As far as I know, I've never made a substantive edit to any Lua module. I write articles, block vandals, and sometimes clear admin backlogs but I don't get involved in technical matters. Sorry. Try a different admin. HJ Mitchell | Penny for your thoughts? 22:13, 25 November 2021 (UTC)

cc @Primefac: @Number 57: @Izno: @DannyS712: --talk@TRANSviada 03:16, 25 November 2021 (UTC)

Why is Template:Lang-zh/sandbox/tr being used in mainspace? There are seventeen uses in Shizuka (band); there should be none. --Redrose64 🌹 (talk) 22:29, 12 May 2021 (UTC)

Fixed by Frietjes. --Redrose64 🌹 (talk) 09:41, 5 November 2021 (UTC)

 Not done Please make your edits in the sandbox and test this first. Once sandboxed and validated, feel free to reactivate the edit request. — xaosflux ^Talk 22:38, 25 November 2021 (UTC)

@Xaosflux: I just made it there the sandbox. What do you mean by test? Unit test or use case test? If the latter see https://wiki.riteme.site/wiki/Sandbox/TRANSviada/Lang-zh/tr.talk@TRANSviada 23:37, 25 November 2021 (UTC)

requeued for update. — xaosflux ^Talk 00:26, 26 November 2021 (UTC)

 Done * Pppery * _{it has begun...} 17:09, 5 December 2021 (UTC)

Traditional first, optionally

If you saw the article of the Cantonese movie, Bio Zombie, you'd notice that the simplified Chinese characters are displayed fisrt, even though the title is in Cantonese. There is no way of altering which appears first, since the template mandates simplified characters first then traditional characters. --Mahmudmasri (talk) 16:23, 16 March 2021 (UTC)

You can alter which appears first. Use the parameter |first=t to put the traditional script first. See Template:Lang-zh#Ordering. Rincewind42 (talk) 08:21, 21 February 2022 (UTC)

Link to Wiktionary entry

Would it also be desirable to add an option to link the Chinese text to their respective entries in Wiktionary? Perhaps something like wikt=yes would render a {{Lang-zh|t=中國|s=中国|wikt=yes}} entry as:

simplified Chinese: 中国; Traditional Chinese characters: 中國

This surrounds each entry using {{wikt-lang|zh|...}}. — Umofomia (talk) 19:00, 19 August 2022 (UTC)

I just tried implementing the functionality myself in the sandbox and it appears to work:

simplified Chinese: 中国; traditional Chinese: 中國

I don't currently have template editor privileges to commit this change to the main template but I can look into requesting it. — Umofomia (talk) 21:03, 19 August 2022 (UTC)

Foochow Romanized/Bàng-uâ-cê

Hello, can a parameter for Foochow Romanized be created? --Lousysofa (talk) 17:02, 27 March 2023 (UTC)

Preventing problems with italic and literals

Hi! I noticed a problem when someone wants to use literals with italic next to a bold word. For example the line below...
'''Pak Mong''' ({{zh|t=白芒|l=white ''[[miscanthus]]''}})
will produce something like...
Pak Mong (Chinese: 白芒; lit. 'white miscanthus')
instead of...
Pak Mong (Chinese: 白芒; lit. 'white miscanthus')
In order to solve the problem we could just change the line 193 from...

val = "'" .. val .. "'"

to...

val = "<nowiki>'</nowiki>" .. val .. "<nowiki>'</nowiki>"

What do you think? (@Underwaterbuffalo:) -- Basilicofresco (msg) 17:16, 19 October 2023 (UTC)

Thank you for raising the issue encountered by FrescoBot at Pak Mong article. I don't have any expertise with modules. As long as the fix solves the issue and does not create others, I am all in favor! Underwaterbuffalo (talk) 09:34, 21 October 2023 (UTC)

Yes, the single quotes used to mark literal glosses should not be interpreted as wiki markup. Kanguole 09:42, 21 October 2023 (UTC)

The pending revision I have to the module currently produces an output of

Chinese: 白芒; lit. 'white miscanthus', which i'm noticing isn't entirely correct. i'll fix it asap.

Remsense聊 21:37, 21 October 2023 (UTC)

And there we are! Properly escaping quotes now has

'''Pak Mong''' ({{Lang-zh/sandbox|t=白芒|l=white ''[[miscanthus]]''}})

output

Pak Mong (Chinese: 白芒; lit. 'white miscanthus')

Remsense聊 17:13, 23 October 2023 (UTC)

Template-protected edit request

Allow specifying t variant: zh-Hant-HK vs zh-Hant-TW. See this image for an example of 返 vs 返. NM 02:45, 20 November 2023 (UTC)

I will write a patch for this ASAP. Here's the question: how should it work? I am thinking just additional parameters |tw= and |th=. But how the module presently works, if only one character field is specified, it just gets tagged as zh. But it should be trivial to tweak the code so that the more specific language tag is used when specifying only |t= or |s=, et al.Remsense聊 02:54, 20 November 2023 (UTC)

I don’t think there’s a need to modify the logic for |t= and |s=. Sometimes the region is really irrelevant that you only want to specify the script (for example, in a page that talks about the history of the writing system).

We should also avoid ambiguous abbreviations and just go with a slightly longer format like t_hk and s_sg.

NM 05:08, 26 November 2023 (UTC)

fair—it's really difficult, re: abbreviations, because after the 10th time entering it in an article, you might wish concision was favored over disambiguation, but yeah. I still haven't started on this, but I'll keep this in mind when I get to it shortly. Remsense聊 05:26, 26 November 2023 (UTC)

Template-protected edit request on 14 October 2023

Diff with my sandbox implementation: diff

This does three major things, things that address real perennial limitations with the {{zh}} template:

• It adds a new |out= parameter, allowing one to select one of the terms to place before the rest, which are then put in brackets, an extremely common presentation format when writing Chinese text inline in paragraphs and tables.
• It now uses double quotes for the |tr= parameter, for "full translations" instead of glosses, as is prescribed in MOS:FOREIGN and MOS:ZH.
• It enables the use of multiple, correctly quoted glosses (literal translations, |l=), delineated by commas.

Examples:

{{Lang-zh/sandbox|c=我|p=wǒ|l=I, me|j=ngo<sup>5</sup>|out=j}}

↓

Jyutping: ngo⁵ (Chinese: 我; pinyin: wǒ; lit. 'I', 'me')⸻|out=j puts the value for |j= outside the brackets

---

{{Lang-zh/sandbox|s=中华|t=中華|p=Zhōnghuá|l=China|out=p|labels=no}}

↓

Zhōnghuá (中华; 中華; 'China')

---

{{Lang-zh/sandbox|s=她刚刚离开了|l=she's just left|out=l}}

↓

lit. 'she's just left' (Chinese: 她刚刚离开了)

---

{{Lang-zh/sandbox|s=电脑|t=電腦|tr=computer|p=diànnǎo|l=electric brain|out=tr|labels=no}}

↓

"computer" (电脑; 電腦; diànnǎo; 'electric brain')⸻double quotes now used for |tr=

---

I was apprehensive about patching the template, but I'm pretty sure I haven't broken anything, I'm sure someone more experienced than I will take a look-see before it gets merged. :) Remsense聊 17:20, 14 October 2023 (UTC)

Remsense, would you be so kind in adding testcases for this change at Template:Lang-zh/testcases? SWinxy (talk) 20:36, 14 October 2023 (UTC)

Certainly! I'll try to cover all the edge cases I can think of. Remsense聊 20:37, 14 October 2023 (UTC)

I've gone ahead and added some! if you'd like me to be more thorough/any test cases you need to see, let me know. (Oh, and I found a bug in the process.) Remsense聊 21:17, 14 October 2023 (UTC)

I fixed the (very obvious!) bug, and added the ability to put both simplified and traditional outside the parentheses. hopefully everything is good now! Remsense聊 00:37, 18 October 2023 (UTC)

I have had a look at the testcases, and it's unclear from them what the use case for this is, what articles it would be used in. I mean when you have something like

"computer" (电脑; 電腦; diànnǎo; 'electric brain')

It would be normal to use the template for everything inside the bracket, and normal text for "computer". The ones where that wouldn't work such as:

pinyin: Cài Yīngwén (Chinese: 蔡英文)

I can't see a use for. You would never put pinyin like that in body text, with the Chinese characters in brackets. Generally in an article both the Chinese and Romanisations should go in brackets so as not to upset the flow of the English text, with the Chinese first. When the Chinese is being discussed, such as in an article on the language, this template isn't really suited for it.--2A04:4A43:90AF:FAB6:29E3:5D64:C243:2A6D (talk) 02:08, 15 October 2023 (UTC)

You are able to put any field outside the brackets: gloss, characters, or romanization. There are situations where any of the three are appropriate, usually depending on whether the orthography, semantics, or phonetics are the focus of the prose. I've worked with all of them editing Chinese-related articles. The Tsai Ing-wen example was copied from above, I wouldn't actually write a personal name in such a way in an article. The cases were meant to demonstrate that all the features are working properly.

Here is a tweaked excerpt from Chinese characters where a pinyin-first example is the best-flowing, in my opinion.

The barrier between pronunciation and meaning is never total, however: in the Chinese system, phonetic characters may be deliberately chosen as to create certain connotations. This regularly happens for corporate brand names: for example, 'Coca-Cola' is translated phonetically as Kěkǒu Kělè (可口可乐; 可口可樂), with the characters selected so as to possess an additional meaning of 'delicious and enjoyable'. A more literal translation would be 'the mouth can be happy', though the phrase is technically grammatically sound.

Also, I think it's worth putting non-diacritical pinyin in |lang= tags when you can, because it will still be pronounced better by a screenreader than an English voice selected will attempting to read it aloud, e.g. {{zh|labels=no|c=蔡英文|p=Cai Yingwen|out=p}} is better for screenreaders than just Cai Yingwen ({{zh|labels=no|c=蔡英文}}).

Remsense聊 02:13, 15 October 2023 (UTC)

 Done * Pppery * _{it has begun...} 00:01, 27 October 2023 (UTC)

Pppery, thank you so much! — Remsense聊 00:13, 27 October 2023 (UTC)

Pppery, Actually, I made several revisions to the module from the initial one, making initial fixes. Could you merge the newest revision of the sandbox? — Remsense聊 00:30, 27 October 2023 (UTC)

 Done Those too. * Pppery * _{it has begun...} 00:44, 27 October 2023 (UTC)

@Pppery and Remsense: Was it after these edits that the lead of Prunus kansuensis started to look so bold? 77.223.109.164 (talk) 17:09, 19 December 2023 (UTC)

Yes. I thought I tested adequately for this. It's not a bug that should've been introduced, but also I think there's never a real reason to put bold text inside this template, so it's good to identify when it's happening at least. Remsense留 20:48, 19 December 2023 (UTC)

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 zh-Latn, as the mainland Pinyin wins by a very large margin in users.

I propose the following changes:

--- Module:Lang-zh
+++ Module:Lang-zh
@@ -54,8 +54,8 @@ local ISOlang = {
 	["c"] = "zh",
 	["t"] = "zh-Hant",
 	["s"] = "zh-Hans",
-	["p"] = "zh-Latn-pinyin",
-	["tp"] = "zh-Latn",
+	["p"] = "zh-Latn",
+	["tp"] = "zh-Latn-tongyong",
 	["w"] = "zh-Latn-wadegile",
 	["j"] = "yue-Latn-jyutping",
 	["cy"] = "yue-Latn",

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

--- Module:Lang-zh
+++ Module:Lang-zh
@@ -55,7 +55,7 @@ local ISOlang = {
 	["t"] = "zh-Hant",
 	["s"] = "zh-Hans",
	["p"] = "zh-Latn-pinyin",
-	["tp"] = "zh-Latn",
+	["tp"] = "zh-Latn-tongyong",
 	["w"] = "zh-Latn-wadegile",
 	["j"] = "yue-Latn-jyutping",
 	["cy"] = "yue-Latn",

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

Agree– I double-checked, and IANA added Tongyong as a valid language subtag variant in 2020. Remsense诉 23:20, 10 February 2024 (UTC)

 Done * 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)

 Done * 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)