![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 |
|showflag=p
is working |showflag=j
is not working, |showflag=pj
is partially working. Matthew_hk tc 12:23, 21 October 2018 (UTC)
|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:
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:
as they were before April 2017, and to add the following:
Kanguole 00:41, 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)
|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)|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)
|showflag=
parameter accepts a j parameter, that should display the value of |j=
, not |y=
. Kanguole 14:59, 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)
|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)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)
|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|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)|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)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)
|j=
related (j to j; NOT |showflag=j
but triggering Yale)|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|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)|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 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)
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)
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)
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)
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 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)
Imaginatorium | |
---|---|
Japanese name | |
Kanji | 想像館 |
Romanization | Sōzōkan |
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)
|showflag=y
and |showflag=j
are currently showing Cantonese Yale. Matthew hk (talk) 11:59, 29 December 2018 (UTC)|showflag=gdp
Matthew hk (talk) 14:13, 6 January 2019 (UTC)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)
|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
|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)
|showflag=pj
use the label [[Cantonese]] [[Jyutping]]
when all other 'j' labels are [[Jyutping]]
?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:
|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?|data6=
(|showflag=
)
|label7=
and |data7=
: why aren't these listed with the other transliterations that are rendered by the child infobox that feeds main infobox |data9=
?|data9=
looks for |c=
, |t=
, |p=
, |s=
, and |phagspa=
. |phagspa=
is documented but does not exist. Why is it tested here?|data9=
|header20=
looks for |wuu=
, |lmz=
, and |suz=
. |data23=
expects |ouji=
. Why is |ouji=
not part of the test at |header20=
?|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=
?|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)
|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)
[[Cantonese]] [[Jyutping]]
labels to [[Jyutping]]
labels|phagspa=
so there are two options:
((Infobox Chinese))
to restore support for |phagspa=
|phagspa=
has not been supported since 2013, remove it (and probably |phagspa-latin=
) from the template documentation|showflags=
squabble. When you-all resolve that issue, I will make sure that the module reflects your resolution; do not argue your |showflags=
position hererequire ('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.((Infobox Chinese/Korean))
– the most-used sub-template at 13k-ish transclusions.@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:
|_µ=
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 commentAt 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)
|_µ=
(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)
((#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).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)
|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)
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:
|child=yes
then
|chinese_header=<name1> or Chinese name
|c=
, |t=
, or |s=
is present and has a value then
|chinese_header=<name1> or Chinese name
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)
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))} )) )) ))
|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)
((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.|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)
as of timestamp, ((Infobox Chinese))
is using Module:Infobox multi-lingual name.
—Trappist the monk (talk) 17:28, 12 January 2019 (UTC)
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)
((transl))
which wraps its output in <span>...</span>
tags. That decision is probably correct for the preponderance of cases.|plainlist=
and the splats and write:
|h=Tǒi-nǎm ([[Sixian dialect]])<br />Toi-nam ([[Hailu dialect]])
|lang1=[[Sixian dialect]]
|lang1_content= Tǒi-nǎm
|lang2=[[Hailu dialect]]
|lang2_content=Toi-nam
((Infobox Chinese))
also needs |child=yes
because without it ibox zh looks silly floating around inside that other ibox.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)
|th-hdr-color=
, |pt-hdr-color=
, |lang-hdr-colorn=
, etc should be available to override the global |headercolor=
. Opinions?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)
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.|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-hdr-color=
when set, then defaulting to |headercolor=
when set, then defaulting to #b0c4de
as last resort.I have made some changes in Module:Infobox multi-lingual name/sandbox:
|child-hdr-color=
; see Template_talk:Infobox_Chinese#headercolor|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=
|msa=تيمور جاوء <br/> Timur Jauh
|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.|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)
|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.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)
((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.Kuomintang | |||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
![]() "Kuomintang (Guómíndǎng)" in Traditional (top) and Simplified (bottom) Chinese characters | |||||||||||||||||||||||
Traditional Chinese | 中國國民黨 | ||||||||||||||||||||||
Simplified Chinese | 中国国民党 | ||||||||||||||||||||||
Literal meaning | "Nationals’ Party of China" | ||||||||||||||||||||||
|
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)
|mi=
and |ci=
data at ends of transcriptions lists. Is that what you want? Are there objections to this change?Add cantonese pinyin? Ȝeſtikl (talk) 02:24, 14 September 2019 (UTC)