Template talk:Infobox Chinese/Archive 4

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Showflag broken

|showflag=p is working |showflag=j is not working, |showflag=pj is partially working. Matthew_hk tc 12:23, 21 October 2018 (UTC)

@Scriptions: Well i saw what you did in Template:Infobox Chinese/doc. Did you sabotaged the code so that according to you version of doc so that both |showflag=pj and |showflag=py are the same outcome, also |showflag=j and |showflag=y? Do i need to report to WP:ANI? Matthew_hk tc 23:32, 22 October 2018 (UTC)

This is a mess. The current behaviour for romanizations of Cantonese, reflected by the documentation, is:

• showflag=pj: this will show pinyin then Yale outside of the hide area.
• showflag=py: this will show pinyin then Yale outside of the hide area.
• showflag=jp: this will show Yale then pinyin outside of the hide area.
• showflag=gdp: this will show Yale then pinyin outside of the hide area.
• showflag=j: this will show Yale outside of the hide area.
• showflag=y: this will show Yale outside of the hide area.
• showflag=jyp: this will show Yale, Jyutping, then pinyin outside of the hide area.
• showflag=yj: this will show Yale, then Jyutping outside of the hide area.
• showflag=jy: this will show Jyutping, then Yale outside of the hide area.

Surely p should stand for pinyin, j for Jyutping and y for Yale. It would be more consistent to revert the some of these (in code and documentation) to:

• showflag=pj: this will show pinyin then Jyutping outside of the hide area.
• showflag=jp: this will show Jyutping then pinyin outside of the hide area.
• showflag=gdp: this will show Guangdong Romanization then pinyin outside of the hide area.
• showflag=j: this will show Jyutping outside of the hide area.
• showflag=jyp: this will show Jyutping, Yale, then pinyin outside of the hide area.

as they were before April 2017, and to add the following:

• showflag=yp: this will show Yale then pinyin outside of the hide area.
• showflag=yjp: this will show Yale, Jyutping, then pinyin outside of the hide area.

Kanguole 00:41, 23 October 2018 (UTC)

@Kanguole: See my thread in User talk:Primefac. It seem Scriptions had sabotage the code in Template:Infobox Chinese/Chinese to make showflag favour Yale than Jyutping. And how the switch on code works, you can view the source code there to figure out. Matthew_hk tc 00:50, 23 October 2018 (UTC)

It may be that the template code was broken accidentally, but then the documentation was changed to match it. In any case, the proper course is to fix the code and document that. Kanguole 01:24, 23 October 2018 (UTC)

The code in Template:Infobox Chinese/Chinese was not accidentally broken but seem meant to be sabotaged that way. I will view the exact diff and file ANI for who exactly did it. Matthew_hk tc 01:37, 23 October 2018 (UTC)

The code was not sabotaged, and it isn't broken. It was simply easier to prefer Yale to Jyutping (for which there are good reasons) by changing the definition of the showflags than by changing j to y in every article. The reason I did it this way was efficiency only, and nobody has complained so far. There is no rule that says j needs to stand for Jyutping, and I myself used j to mean Yale before I added the y showflag. The reason I added the y showflag in addition to the j showflag even though using j to mean Yale created no problems for me, was that it would be easier to remember for other editors.

Anyway, let's drop the ANI nonsense: nothing nefarious has been going on here. Making the edits I made is perfectly legitimate, and before this discussion, I hadn't even considered the idea that someone could see it as illegitimate. Disagreeing and reverting is one thing, but the implication that this way of doing it, so much more efficient than the alternative, is against the rules has no basis. Scriptions (talk) 12:14, 23 October 2018 (UTC)

I have made the above fixes in a sandbox (Special:Diff/827245343/865346050). @Scriptions: Is there any reason not to do this? Kanguole 11:22, 23 October 2018 (UTC)

The reason is the same reason I changed the code in the first place: that Yale is more common than Jyutping in learning materials and therefore better known by non-native speakers of Cantonese, who are the ones who need the transcriptions. If one Cantonese transcription is to be shown outside of the hide area, it should be the one that the most readers will understand. This is the perfectly benign reason for my edits. Scriptions (talk) 12:19, 23 October 2018 (UTC)

Surely the appropriate way to achieve that is not to change the implementation of |showflag=j to be identical to that of |showflag=y, but to change |showflag=j to |showflag=y in the infobox within a particular article, or to argue that |showflag=j should be removed. The way it is now is a confusing mess. Kanguole 12:33, 23 October 2018 (UTC)

It's prohibitively inefficient to change it in every article, which will have to happen even if the j showflag is removed. As I pointed out above, what I originally did was change j to Yale; making a y showflag came later. Anyway, I fail to see how I haven't acted in an appropriate way.

As for confusion, I haven't noticed that anyone actually using the showflags is confused.

I support any solution that will have the same results on the ground, but if someone thinks there are two few showflags that favour Jyutping, the more efficient solution is simply to add a few new showflags. Scriptions (talk) 12:46, 23 October 2018 (UTC)

Summoned by ANI drama I'd suggest that, while accusations of sabotage and vandalism may be over-blown, you should put it back until such time as you are able to add a showflag of y rather than just over-writing the jyutping. Yale was developed for Mandarin AFAIK and will not as accurately represent Cantonese word-sounds as Jyutping. Simonm223 (talk) 13:42, 23 October 2018 (UTC)

@Simonm223:, @Kanguole:, since ANI was closed by the admin, are we on the same page on fixing {{Infobox Chinese/Chinese}} for correct |showflag= functions that j is for j not |showflag=j but pop up |y= data. As well as may be creating real pairs for |y= related showflag code? As well as reverting the changes in the doc? Matthew_hk tc 14:35, 23 October 2018 (UTC)

Yes, usage should be consistent, to make the template accessible to users. If the |showflag= parameter accepts a j parameter, that should display the value of |j=, not |y=. Kanguole 14:59, 23 October 2018 (UTC)

Yes please. Simonm223 (talk) 15:34, 23 October 2018 (UTC)

@Kanguole: Thanks for making edit request at Template talk:Infobox Chinese/Chinese per consensus on j to j and ANI closing comment on revert change by Scriptions (the j to y trigger). Matthew_hk tc 16:06, 23 October 2018 (UTC)

The template is already perfectly accessible to users. No editor should use a template without consulting the doc page anyway, and no user has actually had any problems using the template. This is a classic "throwing the baby out with the bathwater" situation. The only argument for making letters align is to appease some editors' sense of neatness, which is not important. The argument for keeping it the way it is is that otherwise, a less common (and therefore less understood) transcription will be shown – and that is important.

As I said above, I support any solution that will have the same results on the ground, but such a solution needs to be found first. It should be unnecessary to point out that ensuring that the most commonly understood transcription is the one preferred must take precedence over making the code neat. I'm all for making the code neat, but you're putting the cart before the horse here. First a solution needs to be found that doesn't negatively effect countless articles, then we make the code neat. No convincing argument has been made for the need to rush to make the code neat. Scriptions (talk) 07:45, 24 October 2018 (UTC)

Please stop your disruptive editing. The template was coded this way. pinyin data stored in |p= Cantonese Yale in |y=, Cantonese Jyutping in |j=. The |showflag= was intended to trigger what the code in |showflag= to show which data from hidden collapsible list. Thus |showflag=p was working was as intended to show pinyin. Same logic applies to |showflag=j and |showflag=y. If you want every Cantonese article to show |showflag=y instead of |showflag=j , you change the {{Infobox Chinese}} template in the articles one by one, as well as fixing the backend code of the template by adding the codes for |showflag=y (and other combination involving |y=). Not sabotage the template codes for |showflag=j and |showflag=gd (Guangdong Romanization). Matthew_hk tc 13:04, 24 October 2018 (UTC)

As has already been pointed out by the closing admin at ANI, no disruptive editing or sabotage has taken place. The closing admin concluded that your reporting me was in bad faith. There is no reason why the less efficient alternative should be preferred.

If you'd bother to read what I wrote above, you'd find that I have nothing against making the code comply with your ideas of neatness. But before that can happen, a solution needs to be found so that articles don't suddenly start showing less commonly understood transcriptions instead of the most commonly understood one. Scriptions (talk) 13:56, 24 October 2018 (UTC)

So far it appears that consensus on this page is against making that change to the tool; an edit doesn't have to be vandalism or sabotage for people to disagree with it. That goes doubly for changes to templates that are widely viewed. Simonm223 (talk) 14:04, 24 October 2018 (UTC)

The change was made (with an informative edit summary) back in December 2016, and no one has protested until now, so if the template is to be changed back, a consensus for that is necessary. Note also that everyone is in agreement that the template should eventually be changed back, but that my point is that there's no rush, seeing as it has been this way for close to two years. We can definitely take the time before we change the template back to ensure that the most commonly understood transcription system will still be the one preferred. Changing the template back now will only have objectively negative consequences. Scriptions (talk) 14:18, 24 October 2018 (UTC)

Please read the closing ANI on strongly suggest to revert your edit. Also, in this thread only you disagree on reverting your edit, and you are not the majority. Matthew_hk tc 14:22, 24 October 2018 (UTC)

He suggested I revert my edit simply to show good faith, not because there was anything wrong with it. He had, however, forgotten that he had protected the template, thus making it impossible for me to do that.

I don't disagree on reverting my edit, only on doing it before the underlying problem has been solved. Changing the template back after all this time will disrupt a lot of articles, and that problem needs to be dealt with first. Scriptions (talk) 14:29, 24 October 2018 (UTC)

The reverting would only affect those misfilled |showflag=. Yes the |showflag=y was added after your edit, so reverting would delete the |showflag=y code added by goodfaith by Littlepenny413. But the reverting would also fix those broken code such as in Walter Kwok, as only |j= data was digged out and filled, |y= is empty and |showflag=j is not working for calling out |j= (Jyutping) data

Also, i don't mind adding a lump sum show option for all Cantonese data, which unlike pinyin as official romanization in Mainland China, someone preferred Jyutping (|j= due to availability of online free convertor ), someone Sidney Lau |sl=, someone Cantonese Yale |y= someone Guangdong Romanization |gd= and may be someone in fact using "Hong Kong Government Cantonese Romanisation" |hk=. Which some Hong Kong people, their common name in English media, was in fact one of the romanization mentioned above (or none, such as Tung Chee-hwa who came from Shanghai). I can't agree on your alteration on code which you resist to revert back, that only show Yale and disable other from showing. Matthew_hk tc 15:25, 24 October 2018 (UTC)

For example, the article Mid-Levels use Sidney Lau only (using {{zh}}) Also The Standard (Hong Kong) (i think it was changed by Sirlanz). Matthew_hk tc 20:45, 24 October 2018 (UTC)

Further to "breaking" the existing article. It only break if we reverting your (Scriptions) edit AND purge the good faith |showflag=y code all together. For example, some editor preferred Yale in Hong Kong article (as shown in the third line of the head "title" parameter of the infobox.) and he correctly filled |showflag=y instead of j. Matthew hk (talk) 00:14, 25 October 2018 (UTC)

Revised proposal and voting

I am not meant to be canvassing, but since @Kanguole:, @Simonm223: @Scriptions: were involved in the discussion, i broken the steps to fix the code: (see also the different of the code since broken and current version)

• Step 1: revert the change to the version by White whirlwind, date 2016-12-04T14:14:55 ver number 752982678 . to restore the function of showing |j= related (j to j; NOT |showflag=j but triggering Yale)

• Step 2 add back showing |y= related edit for showing Cantonese Yale (|showflag=y), such as Special:Diff/773048904 by Littlepenny413 (more diff to be discover, such as for |showflag=py in the current code, as well as Sidney Lau (Special:Diff/793650818, this edit had other fix BTW), as well as those related to |showflag=bp (starting from this edit Special:Diff/794648594 by Sunshine567), as well as |showflag=wp (Wade–Giles, then pinyin ) |showflag=yj (Yale, then Jyutping), |showflag=pwuu (pinyin, then Wu), |showflag=phsn (pinyin, then Xiang), |showflag=xejp (Xiao'erjing, then pinyin) by unknown
• Please proposal more |showflag= option if needed if it is not in the current code. Current code had |showflag=y, |showflag=py, |showflag=jyp, |showflag=jy, |showflag=yj, so pretty much still have some combination not stated, but related to |y= Matthew_hk tc 17:01, 24 October 2018 (UTC)

---

• Support 1, 2 Matthew_hk tc 17:01, 24 October 2018 (UTC) (Also by implementation of step 1 2 and 3, support Kanguole's code in sandbox. Matthew_hk tc 20:44, 24 October 2018 (UTC))
• There have been several unrelated changes in the interim, which would be lost in this plan. That approach seems unwieldy. I have already sandboxed a change (Special:Diff/827245343/865346050) that restores the previous meanings of |showflag= values of j, pj, jp, jyp and gdp, and adds the missing values of yp and yjp. Kanguole 17:17, 24 October 2018 (UTC)

I just want to show consensus to closing admin more clearly, but any way your code is fine. Matthew_hk tc 17:19, 24 October 2018 (UTC)

• Support 1, 2 with additional support for Kanguole's proposed code. Simonm223 (talk) 18:01, 24 October 2018 (UTC)
• Support using Kanguole's version, assuming it works properly. Making small changes to lots of articles is a small price to pay for sensible coding.  White Whirlwind  咨  19:13, 27 October 2018 (UTC)

use Module:Lang

I recently wrote Module:ISO 639 name with the intent of obsoleting the 1100-ish {{ISO 639 name xx}} templates infavor of a single data set strictly derived from the ISO 639 custodians. The documentation for {{Infobox Chinese/Blank}} is vague (contradictory) with regard to what values should be assigned to |lang=; in one place it says that |lang= gets Two- or three-letter ISO 639 code of the language of the translation and in another says: ISO 639 code for the language of the description; Example zh-Hant (zh-Hant is not an ISO 639 code but is an IETF language tag).

{{Infobox Chinese/Blank}} used a mixture of {{ISO 639 name xx}} and {{lang}} templates so I have replaced the calls to {{ISO 639 name xx}} with calls into Module:lang which understands IETF language tags and is aware of en.wiki's language name overrides.

—Trappist the monk (talk) 12:25, 28 October 2018 (UTC)

Cantonese ordering

Can a template editor or admin please edit the Chinese sub-template so that the |ci= field displays last in the Cantonese box? I'd do it myself, but the page has been template protected since I last made an edit.  White Whirlwind  咨  21:32, 18 September 2018 (UTC)

That would not be a good idea. It seems that most infoboxes Romanise Cantonese only in Yale and Jyut6ping3, and having the IPA between them allows for easy comparison of either Romanisation with the IPA. The situation is different with the Standard Mandarin box, which often includes several transcriptions, so that it makes sense to have the IPA at one end. Scriptions (talk) 14:47, 12 November 2018 (UTC)

Reversing the order of Mandarin, Cantonese, and Hakka in the case of Hong Kong and Macau articles?

Already there is a showflag option to show Cantonese (Yale or Jyupting) as the primary form of Chinese in the collapsed form of the infobox, but I also wonder if there's a way to reverse the order of Cantonese, Hakka, and Mandarin when the infobox is shown in the uncollapsed/expanded form. The idea is that for Hong Kong and Macau articles the Cantonese form is shown first. WhisperToMe (talk) 13:50, 29 July 2018 (UTC)

@WhisperToMe: This is controlled by {{Infobox Chinese/Chinese}}, which currently has about 50 romanization options. I think the best way to do this would be to convert the whole template to Lua (you might want to ask at WT:Lua). Jc86035 (talk) 13:47, 30 July 2018 (UTC)

@Jc86035: Thanks for the suggestion! Asked at Wikipedia_talk:Lua#Convert_Infobox_Chinese/Chinese WhisperToMe (talk) 13:57, 30 July 2018 (UTC)

I would like to know if there's been any progress made on this. I would like to be able to reverse the order of Cantonese and Mandarin for Hong Kong topics. Mandarin is important to HK topics for historiographical reasons and for learning about its relationships with the ROC and PRC, but I would like to insist that Cantonese displays first. WhisperToMe (talk) 07:47, 23 November 2018 (UTC)

Renaming

Not starting a move discussion until this is discussed further. A lot of editors on this discussion (Amys eye, PC78, Inter&anthro, Tom (LT), M.R.Forrester, and Rickinasia) are concerned with this template being called {{Infobox Chinese}} as it incorporates a large amount (over twenty, by my count) of non-Chinese languages. Would people support this being renamed {{Infobox romanized name}} as this appears to be whole function and purpose of this template? DanielleTH ^{(Say hi!)} 15:38, 26 December 2018 (UTC)

I would, since people have started to change the 'Korean name' template on Korean pages to 'Chinese' which doesn't seem appropriate. I actually wasn't aware of the state of the template before I saw the edits and it especially doesn't seem appropriate to have all of these languages under Chinese. Either rename it or have a separate one for each. LONEDIREWOLF 15:51, 26 December 2018 (UTC)

@DanielleTH: I think something more general would be more apt, since some non-transliteration things (e.g. IPA) are also in the template. I have no problem with it ending up being "Infobox romanization" or "Infobox transliteration", though. Jc86035 (talk) 17:51, 26 December 2018 (UTC)

Strongly support a move, but not sure to what. The most clear move would be to {{Infobox name}} which is essentially what this is about, but that is a very broad title. "Infobox transliteration" and "Infobox romanisation would be wrong, because lots of the names are in the original languages.--Tom (LT) (talk) 00:10, 27 December 2018 (UTC)

Possibly, as that addresses one of my concerns, but my other big concern is "why?". Why should we have one utterly massive Template for all Asian language pages? This is getting too unwieldy and still hasn't added in lines for a number of other Korean-related entries, ex: hangulstage or hangulborn. I don't see an upside to making one massive template but do see downsides as a ton of pages need to be updated and seeing such a massive list of options will make new (and some current) editors hesitant to edit as the list feels overwhelming. ₪RicknAsia₪ 01:45, 27 December 2018 (UTC)

@Rickinasia: That can be discussed separately, this template already has Korean and over twenty languages on it, so even if those other parameters aren't added later, these template still isn't just Chinese. Personally for me, the biggest advantage to having a single large template is that one template, of note to multiple WikiProjects, is much more likely to be maintained than a collection of smaller ones of note to one WikiProject with a smaller editor base. But that is not a debate I'd like to have here, since this thread is mostly just for renaming this one template as opposed to debating about whether one large template is a good idea or not. DanielleTH ^{(Say hi!)} 02:31, 27 December 2018 (UTC)

It is obvious that any thought about merging is illusionary, given the current naming. So the fiction of independent decisions is also illusionary. Claiming advantages based on a large userbase may be perceived as subduing a minority userbase. Maybe a small userbase is more flexible to implement desired features? May I suggest "subsidiarity"? Suppressing caveats for fencing in the discussion is inappropriate, anyways. Purgy (talk) 07:29, 27 December 2018 (UTC)

If you're talking about my comment that I'd personally prefer to hold off on discussion whether a larger template is good or not until this template is renamed--I'm attempting to suppress no discussion, Purgy Purgatorio, moreso express a personal feeling. Of course I support discussion, but this is a makeshift discussion to see if people even support a rename in the first place, given this template is used on 10,000 articles, and this rename affects every single one of those. DanielleTH ^{(Say hi!)} 16:01, 27 December 2018 (UTC)

Agree with Rickinasia that I'm not sure a giant merged template is really helping editors here. HOWEVER, this discussion is targeted around what the template's current name should be. Infobox Chinese is clearly not the best title given the 19+ other languages it covers. @Purgy Purgatorio I have no idea what you're talking about (at all) I'm afraid, what do you think about renaming this tempate? --Tom (LT) (talk) 01:29, 29 December 2018 (UTC)

@Tom (LT), I do not care (at all) about the name of this template. I uttered my reservations to keeping discussions apart, where one triggered the other, and to unconditionally preferring larger userbases, as I perceived. You can safely ignore my utterances about preferring smaller units. Purgy (talk) 11:30, 29 December 2018 (UTC)

Support this provided we can find something more appropriate to name it. Especially since, as has been pointed out, the name 'Chinese' no longer applies with so many other languages already included. Kdm852 (talk) 06:57, 29 December 2018 (UTC)

I don;t think Korean user would use this template primary for their articles, but something that had bilingual Chinese-Korean name. (See also Kanji for Chinese character that were imported by Japanese culture and language) Matthew hk (talk) 10:35, 29 December 2018 (UTC)

I think that before considering changing the name, it's rather important to decide the function of the template. It seems overwhelmingly likely that the motivation was to be able to represent names in Han ideographs, with their various readings, variants, etc across the Sinosphere. (I don't know how to examine the earliest versions of the template itself, but I'm guessing a lot from old talk pages.) The common factor, and textually shortest way of referring to the bold terms has to be "China" or "Chinese". Of course, in at least one ideal world the name of the template would just be 漢字, since that's exactly what (I think) we are talking about. Otherwise the template is just a ragbag of languages, which is clearly unreasonable, calling for a replacement by lang. Can I get some feedback here: are we all on the same page??? Imaginatorium (talk) 13:34, 29 December 2018 (UTC)

I oppose renaming. The great majority of the parameters are for varieties of Chinese, and the other language parameters have been added over time as incidental to their use on Chinese-related pages. The infobox's motivation has always been primarily Chinese in nature, as evidenced by the fact that support for alternative names 2–4 is currently limited to Chinese (at least as far as the documentation says).  White Whirlwind  咨  20:14, 29 December 2018 (UTC)

Imaginatorium
Japanese name
Kanji	想像館
Romanization	Sōzōkan

I'm not particularly advocating renaming or not renaming. I'm advocating sorting out the purpose of the template, before considering its name. Your comment (plainly well intended) unfortunately leaves me wanting to ask, "What do you mean by Chinese?" I used template:Infobox Chinese (which I hope amounts to the same thing we are talking about) on my user page (as shown on the right) to display my Han ideograph calque of my (mock-Latin) name. I used the label "Japanese name", because I use this to function in Japanese. I don't have a functional command of Chinese, but I would expect this to be used in Chinese too, short of a surprising explanation from a Chinese speaker that I should call it something else. Do you think this is a reasonable use of the template? At the same time, the ragbag of "other languages" includes Thai and Tagalog, both from outside the sinosphere (that's why in Thailand and the Philippines they give you a fork and spoon instead of chopsticks), and use exclusively scripts imported or adapted from elsewhere (Europe and the Indian subcontinent). I suggest it would be a very good idea to remove this ragbag, but I don't know how to look for statistics on the use of these parameters. Imaginatorium (talk) 05:01, 30 December 2018 (UTC)

Following up this discussion, after spending a while looking up the use of Infobox Chinese in Vietnamese-related (and some Japanese-related that I know of) articles, I think I support White_whirlwind's opinion. It seems to me that Infobox Chinese is mostly used in Chinese-related articles where a famous name/character is translated/transliterated into different languages (see Sun Wukong for example). None of the Vietnamese-related article I have looked up uses this template. The way you (Imaginatorium) use this template is somewhat a niche, I think. Faragona (talk) 05:06, 1 January 2019 (UTC)

Actually I Oppose the proposal to rename as something completely generic ("Romanisation" or whatever), since this is meaningless. I agree that my personal use of "Chinese" might be idiosyncratic, but I am claiming that it is still related to Chinese (in the sense of the Han ideographs). Your example of Sun Wukong is an excellent example where the CJKV readings are helpful. (But the trail from Son Gokū is a tortured mess.) I think there are many aspects of this template which could be improved, but perhaps that should be a separate thread. Imaginatorium (talk) 05:00, 2 January 2019 (UTC)

Rfc on fixing the template showflag

Rfc on fixing the showflag function.

Please see Template talk:Infobox Chinese/Archive 4#Showflag broken and Template talk:Infobox Chinese/Chinese#Template-protected edit request on 23 October 2018. Feel free to ask question if you don't know what is going on. Matthew hk (talk) 10:38, 29 December 2018 (UTC)

As well as Wikipedia:Administrators' noticeboard/IncidentArchive994#User:Scriptions and Wikipedia:Administrators' noticeboard/IncidentArchive995#User:Scriptions disruptive editing Matthew hk (talk) 14:16, 6 January 2019 (UTC)

Survey

• Yes as nominator and the guy that can't show the consensus to the admin in the last thread. Matthew hk (talk) 10:39, 29 December 2018 (UTC)
• I can't follow the discussion, so I won't refer to it. The showflag values should match the other parameters, and the template should be converted to Lua so that the showflag can be interpreted automatically (this does not mean I'm signing up to convert it myself). Jc86035 (talk) 11:40, 29 December 2018 (UTC)

@Jc86035: The current code is edited by Scriptions so that j, stand for Jyutping, y stand for Cantonese Yale, are not working as intended. I really not sure why what consensus needed. If both |showflag=y and |showflag=j are currently showing Cantonese Yale. Matthew hk (talk) 11:59, 29 December 2018 (UTC)

After the opening the RfC, the code was fixed by Jabo-er. I also fixed the |showflag=gdp Matthew hk (talk) 14:13, 6 January 2019 (UTC)

Discussion

Well, the template protection level was stealthy lowered from admin and template editor to extended confirmed user. RfC and consensus should still require for all potentially controversial edits, which the agenda should be: should new pair of code be added to the template for combination |showflag=jyp, |showflag=yp, |showflag=yjp, |showflag=jy, |showflag=yj etc (all commonly combination that added by someone else on changing the function of j related code) Matthew hk (talk) 13:58, 6 January 2019 (UTC)

Now the template have these showflag code

• |showflag=jp
• |showflag=jyp
• |showflag=pj
• |showflag=py
• |showflag=gdp
• |showflag=toip
• |showflag=p
• |showflag=wp
• |showflag=j
• |showflag=jy
• |showflag=yj
• |showflag=h
• |showflag=phfs
• |showflag=gan
• |showflag=wuu
• |showflag=pwuu

....omitted

Thus the RfC should now cover, should |showflag=yp, |showflag=yjp and other combination that involve parameter value y}} be added to the code. Matthew hk (talk) 14:11, 6 January 2019 (UTC)

Why does the 'j' in |showflag=pj use the label [[Cantonese]] [[Jyutping]] when all other 'j' labels are [[Jyutping]]?

—Trappist the monk (talk) 00:30, 11 January 2019 (UTC)

It seem I missed that one to delete it. As I said in below section Jyutping is for Cantonese only, according to zh-wiki and en-wiki. Some labelled there is "Taishanese Jyutping" but no trace of it when I search the term in Chinese in the web (台山 + 粵拼), nor it was written in the zh-wiki. Matthew hk (talk) 01:24, 11 January 2019 (UTC)

While "Taishanese Jyutping", generated wiki echo only. Looking back to the page history in Jyutping, it seem someone placed unrelated romanization method for a not so related dialect Taishanese (Cantonese and Taishanese sounds much different), into the Jyutping article. And may be yes, is that really need to add prefix language/dialect to every entries of the showflag. e.g. Standard Chinese (Mandarin) pinyin, Cantonese Jyutping , Cantonese Yale (one of the few romanization system that also expands to Korean and Japanese), Cantonese Guangdong Romanization . Matthew hk (talk) 01:59, 11 January 2019 (UTC)

Side-related to this issue, I'd like to point out that having any content auto hide is against community guidelines (MOS:DONTHIDE). --Gonnym (talk) 08:17, 11 January 2019 (UTC)

But the infobox with more than 5 entries and did not have hide function, would be very very very long. Matthew hk (talk) 13:05, 11 January 2019 (UTC)

lua conversion

At Module:Sandbox/trappist the monk/Ibox zh I have hacked an implementation of {{Infobox Chinese/Chinese}}. You can compare its output to the current live output at Template:Infobox Chinese/testcases. This implementation ignores the |showflag= dispute and only seeks to produce output identical to the current live template.

I have some questions:

1. main infobox template |data5= expects |phagspa=. This parameter is documented to exist but does not exist in {{infobox Chinese}} so is not / cannot be passed to {{infobox Chinese/Chinese}}. Why?
2. main infobox template |data6= (|showflag=)
   1. what is the distinction between the labels Cantonese Jyutping (|showflag=jyp) and Jyutping (|showflag=jy, |showflag=yj)?
3. main infobox template |label7= and |data7=: why aren't these listed with the other transliterations that are rendered by the child infobox that feeds main infobox |data9=?
4. main infobox template |data9= looks for |c=, |t=, |p=, |s=, and |phagspa=. |phagspa= is documented but does not exist. Why is it tested here?
5. in the live version, child infobox that feeds main infobox |data9=
   1. |header20= looks for |wuu=, |lmz=, and |suz=. |data23= expects |ouji=. Why is |ouji= not part of the test at |header20=?
   2. |header50= tests for |j=, |ci=, |y=, and |gd=. |data54= expects |sl=, |data56= expects |hk=, |data57= expects |mo=. Why are |sl=, |hk=, and |sl= not part of the test at |header50=?
   3. |header60= looks for |poj=, |tl=, |teo=, and |hain=. |data63= expects |bp=. Why is |bp= not part of the test at |header60=?

—Trappist the monk (talk) 12:38, 1 January 2019 (UTC)

@Trappist the monk: 'Phags-pa was removed by Underlying lk in this 2013 edit. Possibly it was unintentional, or the parameter wasn't used.

(My edit to the module didn't work because it introduced nesting issues, and I have no idea why. It may be worth investigating; but anyway, the point was that frame:expandTemplate() might not be necessary for Module:Infobox.) Jc86035 (talk) 19:36, 1 January 2019 (UTC)

@Trappist the monk:, Jyutping roughly means Yue-ping, Yue means Guangdong . Despite Yue languages is a big family of language and dialect, but Jyutping was design for Cantonese only (unlike Yale romanization had standard Mandarin Chinese and Cantonese versions), so "Cantonese Jyutping" is redundant (and the code was altered by User:Scriptions, which probably the label was Cantonese Yale originally). Also, |showflag=jyp means display Jyutping, and then Cantonese Yale and Pin-yin, but the current code is sabotaged which the order is not following the input parameter due to coding in the backend. As a historical error, as Yale can refer to both Mandarin Chinese and Cantonese , {{zh}} use |cy= for Cantonese Yale, but |y= for {{Infobox Chinese}}. Matthew hk (talk) 20:39, 1 January 2019 (UTC)

Thanks. If and when a decision is taken to update the templates to a module, these things:

1. change [[Cantonese]] [[Jyutping]] labels to [[Jyutping]] labels
2. the module already has some support for |phagspa= so there are two options:
   1. update {{Infobox Chinese}} to restore support for |phagspa=
   2. since |phagspa= has not been supported since 2013, remove it (and probably |phagspa-latin=) from the template documentation

As I said in my opening post here, I am not interested in the |showflags= squabble. When you-all resolve that issue, I will make sure that the module reflects your resolution; do not argue your |showflags= position here

I suppose that it would be nice to require ('Module:Infobox') but it is not required so I'm not going to bother trying to figure out how to make it work – if I get to the point where I have absolutely nothing better to do ... If you figure it out, let me know.

I have added support to the module for {{Infobox Chinese/Korean}} – the most-used sub-template at 13k-ish transclusions.

—Trappist the monk (talk) 23:15, 1 January 2019 (UTC)

In theory 'Phags-pa script is related to Tibet, thus it may have potential to use this template (also it still shown in the Template:Infobox Chinese/doc). But in practice, i am not sure how many Tibetan expert in en-wiki and using the template. Matthew hk (talk) 15:17, 2 January 2019 (UTC)

Please do not insert comments inside another editor's comments. I have moved you comment outside of mine.

—Trappist the monk (talk) 15:22, 2 January 2019 (UTC)

@Trappist the monk: Sorry too many layer of : and i missed the end of your comment. Matthew hk (talk) 15:26, 2 January 2019 (UTC)

I've got all of the various language subtemplates working, I think. I haven't started {{Infobox Chinese/Header}}. I am perplexed by {{Infobox Chinese/Footer}}. What is the purpose of |_µ=child? It is used in this call from {{infobox Chinese}}:

{{Infobox Chinese/Footer|_µ=child
  |footnote          = {{{footnote|}}}
}}

In {{Infobox Chinese/Footer}} it is used in this bit of wikitext:

{{
  #ifeq: {{{child<includeonly>|yes</includeonly>}}}{{{_µ|}}} | yes | </table>
}}

I think that I understand that thing to mean:

If the value assigned to |_µ= or the value assigned to |child= or when |child= is empty or missing its default value 'yes' is equal to 'yes' then return the string </table>. Right?

A hastemplate:"Template:Infobox Chinese/Footer" insource:"_µ" search finds only two uses of |_µ=. A similar search for hastemplate:"Template:Infobox Chinese/Header" insource:"_µ" finds the same two results.

Ping Editor Jc86035. You added |_µ= to:

{{Infobox Chinese}} with this edit with the comment prevent orphan categorization of Module:Infobox

{{Infobox Chinese/Footer}} with this edit without comment

{{Infobox Chinese/Header}} with this edit without comment

At about the same time you were involved in this conversation at WT:LUA though that doesn't seem to be related to categorization. So, why |_µ= and why only in these three templates?

—Trappist the monk (talk) 18:09, 4 January 2019 (UTC)

@Trappist the monk: In my initial merge from the module sandbox to Module:Infobox, which Frietjes reverted in less than an hour, I added a tracking category. The reason I added |_µ= (between the two edits) was because the tracking category was showing up in lots of articles due to the template's modular structure, and I didn't know that the issue was happening with other templates (I think). This is probably no longer necessary. Jc86035 (talk) 18:29, 4 January 2019 (UTC)

Good, thank you, I won't support it in the module; likely won't support the rest of that {{#ifeq:}} thing either because I think that it is a documentation something or other that will become meaningless when this module is implemented (the lua version of {{Infobox Chinese}} will not be calling individual sub-templates so the documentation code present in some of them won't be necessary).

—Trappist the monk (talk) 18:52, 4 January 2019 (UTC)

Here is one of the calls to {{Infobox Chinese/Korean}} in {{Infobox Chinese}}:

{{ {{{|safesubst:}}}#if:{{{hanja|}}}{{{hangul|}}} | {{Infobox Chinese/Korean
  |korean_header     = {{ {{{|safesubst:}}}#if:{{{hanja|}}}{{{hangul|}}} | Korean name }}
  |headercolor       = {{{headercolor|#b0c4de}}}
  |hide              = {{{hide|}}}
  |hangul            = {{{hangul|}}}
  |hanja             = {{{hanja|}}}
  |rr                = {{{rr|}}}
  |mr                = {{{mr|}}}
  |northkorea        = {{{northkorea|}}}
  |lk                = {{{lk|}}}
  }}
}}

This call is more or less typical of the many calls to the various sub-templates. In order for that {{Infobox Chinese/Korean}} to be called, either of |hanja= or |hangul= must be present and have a value. Why then, is the same test applied to the value to be assigned to |korean_header=? I can see no reason for the double test.

In {{Infobox Chinese/Korean}} is this:

| header1 = {{#ifeq:{{{header|{{{korean_header|}}}}}}|none||{{{header|{{{korean_header|Korean name}}}}}}}}

which is typical of all of the other named (not Blank) sub-templates. Why then, is it necessary in the call to {{Infobox Chinese/Korean}} to set |korean_header=Korean name? Why doesn't {{Infobox Chinese}} accept and support |korean_header= and similar parameters for the other named sub-templates? I can see no reason why the default header name provided by the sub-template should be overridden by the same name in {{Infobox Chinese}}. Nor can I see a reason why {{Infobox Chinese}} should not support |<lang name>_header= parameters.

A similar thing exists for the {{Infobox Chinese/Korean}} |headercolor= parameter:

|headerstyle  = background-color: {{#if: {{{headercolor|}}} | {{{headercolor|}}} | #b0c4de }};

though in this case, {{Infobox Chinese}} does support |headercolor=. As above, I can see no reason why the default header color provided by the sub-template should be overridden by the same color in {{Infobox Chinese}}.

Is {{Infobox Chinese}} really intended to be substed? Doing so in its current state produces a readable template but also includes many lines of hidden newlines:

...<!--
--><!--
--><!--
...
--><!--
-->...

Why would we want to subst this template?

—Trappist the monk (talk) 15:14, 5 January 2019 (UTC)

Sorry to jump in, Trappist the monk, but is there a particular reason {{Infobox Chinese/Korean}} exists when the near-identical {{Infobox Korean name}} appears to be maintained more by WikiProject Korea? I noticed you were working on Lua support for it so I figured I would ask. DanielleTH ^{(Say hi!)} 17:47, 5 January 2019 (UTC)

@DanielleTH: {{Infobox Chinese/Korean}} is used directly by {{Infobox Korean name}}, as are {{Infobox Chinese/Header}} and {{Infobox Chinese/Footer}}. Jc86035 (talk) 18:14, 5 January 2019 (UTC)

(edit conflict)Some sort of support for Korean been in this template since at least this 2006 edit by an editor who is no longer with us. It is there so I have included it in the module I'm working on. Someone must have found it useful because you can see it in use at Far East.

—Trappist the monk (talk) 18:15, 5 January 2019 (UTC)

Thank you for the clarification. DanielleTH ^{(Say hi!)} 20:19, 6 January 2019 (UTC)

Happy to see you tackle this Trappist. I've been looking this over on and off but couldn't bring myself to start this. Not sure if you know, but both Template:Infobox East Asian name and Template:Infobox name module are meant to be merged together, so if this something you can also look at, that would be great. I have one comment, if we are already making a better lua version of these templates, the parameter names should change. There is absolutely no reason for parameter names like |c=, |t=, |s=, etc. As these modules leave the single-language or area and become global, "c" can mean "Catalan" as much as it can mean "Chinese". --Gonnym (talk) 22:17, 6 January 2019 (UTC)

I can't say that I disagree about parameter names but making that change will be a huge pain and I suspect that part of that will be a substantial push-back from those who are content with the way things are. But fist, I have to noodle out the existing templates and make a module that give the same or acceptably similar results.

—Trappist the monk (talk) 23:43, 6 January 2019 (UTC)

I'm sure there might be a pushback, but those concerns shouldn't have really any weight when the question of readability and conflicting parameter names arise. Also, seeing as how the result is "merge", any conflicting names that arise from that merge must be changes, regardless of personal tastes. But I agree, that should be for the end. --Gonnym (talk) 07:45, 7 January 2019 (UTC)

Here's another question: in {{Infobox Chinese}}, the first call to {{Infobox Chinese/Chinese}} sets |chinese_header= with this thing:

|chinese_header    = {{#ifeq: {{{child|}}} | yes | {{{name1|Chinese name}}} | {{ {{{|safesubst:}}}#if:{{{hangul|}}}{{{hanja|}}}{{{kana|}}}{{{kanji|}}}{{{hiragana|}}}{{{katakana|}}}{{{kyujitai|}}}{{{shinjitai|}}}{{{tam|}}}{{{hin|}}}{{{san|}}}{{{pli|}}}{{{tgl|}}}{{{msa|}}}{{{mnc|}}}{{{mon|}}}{{{mong|}}}{{{por|}}}{{{rus|}}}{{{tha|}}}{{{tib|}}}{{{qn|}}}{{{uig|}}}{{{vie|}}}{{{chuhan|}}}{{{chunom|}}}{{{hn|}}}{{{zha|}}}{{{dungan-xej|}}}{{{dungan|}}}{{{lao|}}}{{{khm|}}}{{{tet|}}}{{{lang1|}}}{{{lang2|}}}{{{lang3|}}}{{{lang4|}}}{{{lang5|}}}{{{lang6|}}}{{{lang7|}}}{{{lang8|}}}{{{lang9|}}}{{{lang10|}}}{{{lang11|}}}| {{ {{{|safesubst:}}}#if:{{{c|}}}{{{t|}}}{{{s|}}} | {{{name1|Chinese name}}} }} }} }}

I think that this mess decodes to something more-or-less like this:

if |child=yes then

|chinese_header=<name1> or Chinese name

elseif one or more of 44 parameters is present and has a value then

if any of |c=, |t=, or |s= is present and has a value then

|chinese_header=<name1> or Chinese name

end

end

Why? None of those 44-ish parameters except for |lao=, |khm=, and |tet= are passed to {{Infobox Chinese/Chinese}} which doesn't use them. None of the other five calls to {{Infobox Chinese/Chinese}} do this. Besides being the first, what is different about this one? Why is it that when it is not a child it must have at least one of the forty-four in order to assign a value to |chinese_header=?

The |c=, |t=, |s= test is redundant because {{Infobox Chinese/Chinese}} is not called unless one or more of |c=, |t=, |p=, or |s= is present and has a value (yeah, there is another discrepancy: |p= is missing from the |chinese_header= mess; why?).

—Trappist the monk (talk) 23:43, 6 January 2019 (UTC)

From how I interpret that, it sounds like "use a header if this is a nested infobox; else if non of the non-Chinese parameters are used, don't use a header; If they are used, but none of the Chinese parameters are used, don't set the header to "Chinese name" (i.e. don't use a header here)". --Gonnym (talk) 07:42, 7 January 2019 (UTC)

• We have here several examples of a classical recipe for failure: discussing how to implement something before discussing what is to be implemented. From the discussion at Wikipedia:Templates_for_discussion/Log/2018_December_23#Template:Infobox_Korean_name, it is cristal clear that the consensus is not for merging {{Infobox Korean name}} into {{Infobox Chinese}}. And therefore, {{Infobox Chinese}} is not to be rewritten to implement the false opinion that East Asian languages are not so different from each other. This implies that the sub-template dealing here with Korean language has not to be implemented as a monster pursuing two different aims: being the core of an infobox about Korean matters, or being an additional part of an infobox about Chinese matters, when the topic has a so large notoriety that it deserves a list of translations in various languages, including Korean. The implication of the do not merge consensus is to use two separate copies of {{Infobox Korea/Both_Koreas}} and {{Infobox Chinese/Korean}}, each of them evolving according to the needs of the two main templates {{Infobox Korea}} and {{Infobox Chinese}}... as well as the editorial decisions of the two communities of writers. This would oversimplify the discussion about:

|chinese_header    = {{#ifeq: {{{child|}}} | yes | {{{name1|Chinese name}}} | {{ {{{|safesubst:}}}#if:{{{hangul|}}}{{{hanja|}}}{{{kana|}}}{{{kanji|}}}{{{hiragana|}}}{{{katakana|}}}{{{kyujitai|}}}{{{shinjitai|}}}{{{tam|}}}{{{hin|}}}{{{san|}}}{{{pli|}}}{{{tgl|}}}{{{msa|}}}{{{mnc|}}}{{{mon|}}}{{{mong|}}}{{{por|}}}{{{rus|}}}{{{tha|}}}{{{tib|}}}{{{qn|}}}{{{uig|}}}{{{vie|}}}{{{chuhan|}}}{{{chunom|}}}{{{hn|}}}{{{zha|}}}{{{dungan-xej|}}}{{{dungan|}}}{{{lao|}}}{{{khm|}}}{{{tet|}}}{{{lang1|}}}{{{lang2|}}}{{{lang3|}}}{{{lang4|}}}{{{lang5|}}}{{{lang6|}}}{{{lang7|}}}{{{lang8|}}}{{{lang9|}}}{{{lang10|}}}{{{lang11|}}}| {{ {{{|safesubst:}}}#if:{{{c|}}}{{{t|}}}{{{s|}}} | {{{name1|Chinese name}}} }} }} }}

inside of an English article about Chinese matters, no need to say (by default) that what appears first is the Chinese name. While the default behavior of the other sub-boxes should be the name of the additional language... obviously leaving the <name1> accessible for specific editorial decisions taken in a specific article. Pldx1 (talk) 12:57, 9 January 2019 (UTC)

I think it would involve the basic function of the template. I had del all other foreign name in Jin Yong in the past, as this is English wiki, and it is not encyclopedic to list all of his name transliteration in all foreign language. Use Jin Yong as example, the only language and dialect that may worth to list, may be pin yin (standard transliteration , use by many library as standard for all Chinese source, e.g. Library of Congress), his native Shanghaiese, and Cantonese where he became famous and publishes his work. The Korean support only worth for people and stuff with bilingual Korean-Chinese origins. For the source code /back end code, keeping only one set of code in the template name {{Infobox Korea}}/ may be good for maintenance, but in case {{Infobox Korea}} and {{Infobox Chinese}} had grow to "re-written" level, then may be worth to split the code and maintenance the back end codes separately. Lua conversion may be a good chance to split the code to their respectively template sub-pages. Matthew hk (talk) 13:11, 9 January 2019 (UTC)

As a side-remark, {{Infobox Chinese}} uses the non documented parameters: cnhangul, skhangul, nkhangul. Pldx1 (talk) 15:08, 9 January 2019 (UTC)

There is many bold edit in the past, also after i fixed |showflag=gdp for showing "gd" and "p" romanizations, i haven't fix the /doc yet. And yes, the /doc itself need to be inspect to match all the previous bold edits, as well as stated above, some code (romanization) was removed from the template, but still existed in the /doc. Matthew hk (talk) 15:15, 9 January 2019 (UTC)

@Trappist the monk: The Korean header parameters are used by {{Infobox Chinese}} for "Chinese Korean name", "North Korean name" and "South Korean name"; and by {{Infobox Korean name}} for about ten different preset headers and three custom headers. I don't know if it was ever planned to implement them otherwise. Jc86035 (talk) 12:34, 10 January 2019 (UTC)

Not exactly sure that I understand the purpose of your post. I don't think that I've asked any questions explicitly about the Korean parameter set though I did use a Korean infobox call as an example because it is typical of many of the various sub-template calls.

Out of curiosity I replaced the calls to {{Infobox Chinese/Korean}} in {{Infobox Korean name}} with the appropriate {{#invoke:}} into Module:Sandbox/trappist the monk/Ibox_zh (ibox_zh_ko()) and previewed the {{Infobox Korean name}} testcases page using the modified template. Not conclusive proof, but no glaring errors occurred suggesting that the module in its current state appears to be working correctly. I have similarly visited the first 200ish pages listed at Special:WhatLinksHere/Template:Infobox_Chinese and , at each page, replaced {{Infobox Chinese}} with {{Infobox Chinese/sandbox}} and previewed the page. No glaring faults found. Others are encouraged to do similar experimentation to see if flaws can be found.

—Trappist the monk (talk) 16:04, 10 January 2019 (UTC)

@Trappist the monk: Sorry, I missed that you wrote "Why then, is the same test applied to the value to be assigned to |korean_header=?", and assumed you were asking about something else. (I don't know, and I think it would be safe to remove the test.) Jc86035 (talk) 16:59, 10 January 2019 (UTC)

I think that I have a working module that can replace the content of {{Infobox Chinese}} and the subsidiary templates that it uses. Today I intend to move the module out of my sandbox into main module space (perhaps Module:Infobox multi-lingual name to get it away from being strictly Chinese. I will then update {{Infobox Chinese}} to use this module. This change does not disturb templates that use the {{Infobox Chinese/...}} subsidiary templates ({{Infobox Chinese/Korean}} for example). I don't expect any calamities, but I have been wrong before. If you notice something wrong, post here.

—Trappist the monk (talk) 12:13, 12 January 2019 (UTC)

Is the module able to support {{Infobox East Asian name}} and {{Infobox name module}} or did you not look into those mergers yet? --Gonnym (talk) 12:29, 12 January 2019 (UTC)

One thing at a time.

—Trappist the monk (talk) 12:35, 12 January 2019 (UTC)

as of timestamp, {{Infobox Chinese}} is using Module:Infobox multi-lingual name.

—Trappist the monk (talk) 17:28, 12 January 2019 (UTC)

Great idea --Tom (LT) (talk) 01:09, 13 January 2019 (UTC)

Linter errors caused by this template update?

I can't be sure, but it appears that recent changes to this template have introduced Linter div-span flip errors (a div tag inside of a span tag, which is invalid HTML). A simplified example, taken from a real article, is as follows:

{{Infobox Chinese
  | title           = Tainan
  | t               = 台南
  | bpmf            = ㄊㄞˊ ㄋㄢˊ
  | p               = Táinán
  | tl              = Tâi-lâm
  | h               = {{Plainlist|
* Tǒi-nǎm ([[Sixian dialect]])
* Toi-nam ([[Hailu dialect]])}}
}}

The plainlist template creates a div, which the infobox wraps in span tags. My usual way of fixing this, which I have deployed in many infoboxen to resolve this problem, is to change span into div style="display:inline;". Given the amount of work that went into this change and my lack of Lua chops, however, I figured that I would post here before trying to monkey with the code. – Jonesey95 (talk) 19:21, 15 January 2019 (UTC)

For certain it would go crazy when there is box in a box in a box. It seem need to discuss should the template even allow multiple value in a parameter. For example, the tone of Cantonese in Guangzhou, Hong Kong and Macau, is that notable to list all if the values were backed by publication from the three cities. For Hakka, the cultural group is too wide spread, it is not encyclopedic if listing 10 variants. e.g. Hakka of Hong Kong, Hakka of Taiwan, Hakka of Burma, Hakka of Guangdong, Hakka of Fujian. Matthew hk (talk) 19:46, 15 January 2019 (UTC)

The linter error occurs because the content of all transliteration parameters are now passed through {{transl}} which wraps its output in <span>...</span> tags. That decision is probably correct for the preponderance of cases.

Maybe not the best solution because it may run afoul of accessibility rules is to remove |plainlist= and the splats and write:

|h=Tǒi-nǎm ([[Sixian dialect]])<br />Toi-nam ([[Hailu dialect]])

I'm not sure that dialects qualify as transcriptions except in this case the dialect text is romanized to an undefined standard; it all seems sort of fuzzy. One might use the undefined language parameters:

|lang1=[[Sixian dialect]]
|lang1_content= Tǒi-nǎm
|lang2=[[Hailu dialect]]
|lang2_content=Toi-nam

I've been spending a bit of time thinking about the parameter set and how it ought to be made better. I'll add this issue of dialects to my list of things to think about.

At Tainan railway station and Tainan HSR station, {{Infobox Chinese}} also needs |child=yes because without it ibox zh looks silly floating around inside that other ibox.

—Trappist the monk (talk) 20:30, 15 January 2019 (UTC)

headercolor

This parameter no longer works, because although both ibox_mln_header() and ibox_boilerplate() test args.headercolor, this parameter has not been copied into the args that they have been passed (hdr_args in ibox_mln() and ibox_args in the various language functions respectively). Kanguole 13:08, 5 February 2019 (UTC)

Yeah, I'm aware of this. There is a partial fix in the sandbox as can be seen in the Template:Infobox Chinese/testcases page. For the various language sub-iboxen I've been thinking that something like |th-hdr-color=, |pt-hdr-color=, |lang-hdr-colorn=, etc should be available to override the global |headercolor=. Opinions?

—Trappist the monk (talk) 15:05, 5 February 2019 (UTC)

OK, I see it's fixed in the sandbox for ibox_mln_header() but not ibox_boilerplate(). I'm not sure that it would be very useful to have lots of parameters to give different colours for different languages in the same box, as boxes are neater and easier to understand if all the headers at the same level of the hierarchy within a given box are formatted consistently. It might make sense for the top-level header of a non-child box to be different from the language subheaders, though. Kanguole 15:22, 5 February 2019 (UTC)

I did say that what was there was a partial fix. I've created |child-hdr-color= that applies to the child infoboxen. See the Template:Infobox Chinese/testcases page where |child-hdr-color=#FF0000 at the right but not set in any of the other infoboxen on that page so they all render the default header colors.

—Trappist the monk (talk) 18:47, 5 February 2019 (UTC)

Could you make |child-hdr-color= default to |header-color= if that is set? That would be backward-compatible, and consistent colours is a reasonable default. Kanguole 22:04, 5 February 2019 (UTC)

Child infoboxen header color is |child-hdr-color= when set, then defaulting to |headercolor= when set, then defaulting to #b0c4de as last resort.

—Trappist the monk (talk) 22:53, 5 February 2019 (UTC)

changes in the module

I have made some changes in Module:Infobox multi-lingual name/sandbox:

• added |child-hdr-color=; see Template_talk:Infobox_Chinese#headercolor
• removed the artificial limit of 11 (why eleven?) 'blank' child infoboxen; see the top right infobox at Template:Infobox Chinese/testcases
• added support for:
  • |lang-ipan= – International Phonetic Alphabet rendering
  • |lang-litn= – literal meaning
  • |lang-romn= – generic romanization; renders label/data pair where label is 'Romanization' and data is the content of |lang-romn=
  • |lang-stdn= – name of a romanization standard; renders label/data pair where label is value assigned to this parameter and data is the content of |lang-romn=

  The reason for these derives from malformed constructs like:

  |msa=تيمور جاوء <br/> Timur Jauh

  The value assigned to |msa= is passed to {{lang|msa|...}}. In this example, the Arabic script should be the only text that is wrapped by {{lang}}; the remainder of the |msa= parameter value is a transliteration that Module:Infobox multi-lingual name should wrap with {{transl}}. Additionally, accessibility requirements prohibit line-break-defined lists (<br />); see MOS:NOBR.

• added support for ISO 639-1 (two-character) language codes for those embedded child infoboxen languages that also have ISO 639-2, -3, -5 language codes; this is in keeping with the common practice set out by IANA and IETF
• added |ibox-order= which accepts a comma-delimited list of language codes; child infoboxen are rendered in the order specified in the list; when omitted or blank, the module renders child infoboxen in the same order as the legacy wikitext template; 'blank' child infoboxen are always rendered in numerical order following the embedded child infoboxen; c.f. the Kuomintang infoboxen on the ~/testcases page which uses:

  |ibox-order=bo, mn, mnc, ug, za, zh

Without objection I shall update the live module to implement these changes.

—Trappist the monk (talk) 14:36, 6 February 2019 (UTC)

Only comment I have is that the module should really have a consistent style of parameters, some are a-b while others are a_b, so if you're going with a-b, just make sure that any future parameters you add are also in that style. --Gonnym (talk) 15:15, 6 February 2019 (UTC)

Yeah, I'm aware of the inconsistencies that already exist (|zh-dungan=, |mnc_rom=, etc). My preference is hyphens because they allow for line-wrapping in wikitext (not so much of an issue here because infoboxen, in general, are written vertically). I had composed a long list of other changes I want to make to this template/module for the purposes of standardization and consistency but have suffered a catastrophic computer failure and may have lost that list; I won't know until I can examine the various drives on that now dead computer.

—Trappist the monk (talk) 15:28, 6 February 2019 (UTC)

Bopomofo language markup

The bpmf parameter sets the HTML tag lang="zh-Latn", when zh-Bopo, zh-Hant or similar would be more appropriate. This would enable applying a matching full-width Chinese font to the tone marks as well (many systems do this by default). Wikifresc (talk) 20:10, 8 March 2019 (UTC)

This happens because transcription renderings use Module:Lang and specifically that portion that handles the rendering of {{transl}}. Because this is the English Wikipedia, {{transl}} was designed to handle transliterations from non-Latin character sets to Latin character sets. To handle |bpmf=text properly so that {{transl}} returns <span style="font-style:normal" lang="zh-Bopo" title="Chinese-language transliteration">text</span> will require some work at Module:lang and some work at Module:Infobox multi-lingual name.

—Trappist the monk (talk) 11:59, 18 April 2019 (UTC)

Quick edit

Kuomintang
"Kuomintang (Guómíndǎng)" in Traditional (top) and Simplified (bottom) Chinese characters
Traditional Chinese	中國國民黨
Simplified Chinese	中国国民党
Literal meaning	"Nationals’ Party of China"
Transcriptions Standard Mandarin Hanyu Pinyin Zhōngguó Guómín Dǎng Bopomofo [ㄓㄨㄥ ㄍㄨㄛˊ ㄍㄨㄛˊ ㄇㄧㄣˊ ㄉㄤˇ] Error: {{Transliteration}}: transliteration text not Latin script (help) Gwoyeu Romatzyh Jong'gwo Gwomin Daang Wade–Giles Chung¹-kuo² Kuo²-min² Tang³ IPA [ʈʂʊ́ŋkwǒ kwǒmǐn tàŋ] Yue: Cantonese Yale Romanization Jūnggwok Gwokmàhn Dóng Jyutping zung1gwok3 gwok3man4 dong2 IPA [tsʊŋ˥kʷɔk̚˧ kʷɔk̚˧mɐn˩ tɔŋ˧˥]

Can a template editor please edit the Chinese subpage so that the Cantonese IPA appears last in its grouping like the Mandarin does? I think it looks cleaner that way. Thanks.  White Whirlwind  咨  03:34, 18 April 2019 (UTC)

If the change required is what I think it is, it is simple. Sandbox rendering at right should show |mi= and |ci= data at ends of transcriptions lists. Is that what you want? Are there objections to this change?

—Trappist the monk (talk) 11:43, 18 April 2019 (UTC)

Yep, that's it, very simple. I'd do it myself except the template is protected. Thanks.  White Whirlwind  咨  17:00, 18 April 2019 (UTC)

Cantonese Pinyin

Add cantonese pinyin? Ȝeſtikl (talk) 02:24, 14 September 2019 (UTC)