Jump to content

Module talk:Lang-zh/Archive 2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4Archive 5

Zh-xx consolidation dicussion (copy)

The more I look, the more I feel the mess at Category:Chinese multilingual support templates is out of control. There seems to be a lot of redundancy with all these templates...redundancy in of itself isn't bad, but it causes problems when one template is updated (like I recently did), since there are like a hundred others that need to be updated as well, and it can't necessarily be done with AWB.

So, to that end, I just created User:Rjanag/zh, a template that I believe has the functionality of all of these templates. The only difference is that you have to use named parameters, not numbered...but I think most of these template calls used named parameters anyway (ie, {{zh-cp|c=某|p=something}}, rather than {{zh-cp|某|something}}). When making it, I was careful to make sure that I didn't lose any of the functionalities contained in any of the other templates. Ideally, this template could be moved to {{zh}} and then all articles could just use that one, and display the relevant Chinese and romanizations based on what templates are used (for example, some would use {{zh|c=something|p=something|l=something}}, while others might use {{zh|s=something|t=something|p=something}}, the difference being that the second one gives both simplified and traditional). Currently, though, {{zh}} is a redirect to {{zh icon}} and a lot of pages seem to use it; it might be used in other ways, too, because its WhatLinksHere says it's included in some random pages (for instance, Quiznos) but I can't find it in the wikitext, suggesting that it's a transclusion within a transclusion....

Anyway, I'm thinking that if it's possible some day for me to go through and manually replace the {{zh}}s with {{zh icon}}s, then I can move this new template to there and slowly start replacing specific templates (like {{zh-cp}}) with this one, in all the articles where they're used. Do you have any thoughts on this? rʨanaɢ talk/contribs 06:35, 18 September 2009 (UTC)

Good idea, a lot of work. You might want to put your template in mainspace under "zh-testing" or s.t., redirect a common zh-xx template to it, and wait for the complaints to flood in if you've missed s.t., then try another, etc., until you're confident you've got it right, meanwhile migrating from zh to zh icon with AWB (preparse?). Of course, it might not be possible to rd some of the zh-xx templates until the individual articles have named parameters; that could be done with AWB and regex, though I don't know if I'm up to that kind of complexity in regex--I can't get some things to work that look simple on paper. Anyway, no point in editing the individual articles (except for named parameters) until you've redirected all the templates and they're working well. I wouldn't spend my time on it even then; there are bots that can automate the task. kwami (talk) 07:43, 18 September 2009 (UTC)
Impressive, having a template where Cantonese is nor forced to Jyutping would be really good! Akerbeltz (talk) 22:47, 18 September 2009 (UTC)
One comment: first=t puts Tongyong before Hanyu, but since Taiwan's switched to Hanyu, do we want them linked like that? Would it be possible to have a generic n=x, where n is any ordinal, and x is any parameter, and repeatable (1=t, 2=s, 3=p, etc.)? kwami (talk) 06:35, 19 September 2009 (UTC)
Ah, I didn't think about that. I could just get rid of the Tongyong-before-Hanyu bit...the important thing is allowing trad. to go before simp., but I'm not so concerned about the different Pinyin styles. I also considered adding something like first=j to allow Jyutping to go before Pinyin (for Cantonese-related articles), but then again I'm not sure how widely accepted/used Jyutping is as compared to others.
As for an n=x setup, it should be possible, it would just require lots of messy code—as you can see with the trad./simp. characters, the only way I really know to do it so far is to repeat the code over and over again in different parts of the template. Another option would be to divide the templates into core and shell templates...ie, put all the messy code for displaying simplified characters (for example) into {{zh-s}} (after usurping that...or I could just give it a new name), do that for everything, and then make {{zh}} itself be nothing more than a shell template that has a big #switch statement deciding which thing to show and when. It sounds like something I can play around with in my userspace for a while...these things always seem to work out better in my head than they do in actual code!
If enough functionality gets added to that, it might even be better to divide this across two templates, the current {{zh}} template left more or less as-is to be used in most cases (where people aren't concerned about ordering and the current version is sufficient), and something new, like {{zh-full}} or something, which would have extended functionality but also more parameters and more complicated syntax. rʨanaɢ talk/contribs 15:12, 19 September 2009 (UTC)

The people behind Jyutping are just pushy (off Wiki I mean); it has flaws, especially for an English speaking audience, especially the j for [j] and c for [tʃ] thing. Is it not possible to have the ordering flexible, as in, that if you move one above the other manually, they display that way? I must confess to a high degree of ignorance regarding templates. Akerbeltz (talk) 18:02, 19 September 2009 (UTC)

I don't foresee too much need for flexibility apart from traditional before simplified. Actually, I'd think we'd want that as the default, with "first=s" as an option. After all, traditional is the international form, with simplified being restricted to mainland China (and maybe Singapore?). kwami (talk) 19:41, 19 September 2009 (UTC)
Perhaps...although at this point it will be difficult to change. I didn't notice your message before I started replacing, and now I've basically gone through and replaced many of the traditional-first templates with {{zh | ....... | first=t}}, and many of the simplified-first with just {{zh}} (but I haven't done all of them...there are still several thousand more, so rather than trying to do them by hand I'm starting to fiddle with bot stuff). So things that already have first=t won't be changed if I update the template, but things that don't (i.e., any articles about mainland China stuff) will be changed, unless a simple way can be found to go and insert first=s into all of them. rʨanaɢ talk/contribs 00:19, 20 September 2009 (UTC)
AWB can insert first=s into templates which do not contain first=t, and I assume other bots could easily do the same. It should be ignored unless and until it's defined. kwami (talk) 07:02, 20 September 2009 (UTC)
It would have to be done by a bot, since there are over 6,000 articles that would need to be edited.
Also, about the suggetsion above for a template with more flexibility... I threw together a mock-up at User:Rjanag/zh-full (with an example in my sandbox), which gives the user full control (I think) over the order in which they display things. In most cases that much control isn't necessary (and indeed, the vast majority of combinations would be illogical...for instance, you would never put the literal translation or any of the romanizations before the Chinese characters), but after some more tweaks I could probably put it into mainspace in the off-chance that anyone wants more control (over, for example, the order in which various romanizations are displayed in a given article). rʨanaɢ talk/contribs 16:34, 20 September 2009 (UTC)
Well, if it's easy to do and not code intensive, why not. But you might wait until there is an actual demand for a particular option - it might never materialize, or materialize in a way we didn't expect. kwami (talk) 22:37, 20 September 2009 (UTC)


I agree we should not make first=s as the default. Further we should create {{zh-tw}} and {{zh-hk}}, to make first=t default (and Cantonese too for articles related to Hong Kong). 14.0.144.63 (talk) 16:56, 4 April 2013 (UTC)

I do not understand what you're saying. First of all, something has to be the default (unless we give it no default, which means that there will be an error when |first= is not provided, and that would just make it a pain for people to use). So if you're saying the default should not be simplified characters, then I guess you're saying you think traditional should be the default. As far as I have seen, there is no strong argument for or against making either one the default. I happen to be a user of mainland Chinese and thus I made the simplified stuff first, but nevertheless there is no compelling reason to change it.
Regarding your suggestion of making separate templates with different defaults, I must respectfully disagree. The entire purpose of creating this template was to consolidate everything into one template; before I did this, there were scores of different "zh" templates on Wikipedia and they were not internally consistent (i.e., some were no longer maintained, or didn't format in the same way as others). Your suggestion would re-introduce that problem. It's much better to have one template that does everything, and then when changes need to be made they only need to be made here. Furthermore, I don't see what problem your suggestion solves. It lets people not have to type "first=t" to get traditional characters first, but they still have to type that extra "-tw" or "-hk", so really you're only saving them a few characters. In fact you're costing them more characters, since this template has the option of setting a |first= default for the whole page (and thus you can get traditional characters first for the whole page, without having to enter |first=t every time), whereas under your suggestion if someone were writing a long article they'd have to use zh-tw or zh-hk over and over again. Quite simply, the current template is better. rʨanaɢ (talk) 22:13, 4 April 2013 (UTC)

Items should be comma-delimited

Where a term is given in more than one lang, the langs are usually separated by semicolons and items of a particular lang are separated by commas, e.g. <the language>: <the term itself>, <the transliteration>, <the transcription>; <another language>: <the term in that language>, ... . This one's items being comma-separated makes things a little confusing and disorderly. — Lfdder (talk) 19:30, 22 September 2013 (UTC)

I've added a delim param in the sandbox, compare:
Would anyone be against importing it? — Lfdder (talk) 19:39, 22 September 2013 (UTC)
Already discussed at length above. rʨanaɢ (talk) 09:57, 23 September 2013 (UTC)

There doesn't seem to be any opposition to this change. — Lfdder (talk) 11:18, 23 September 2013 (UTC)

 Not done Then you don't seem to have read the discussion. rʨanaɢ (talk) 18:37, 23 September 2013 (UTC)
I've read it. The possibility of an optional param never came up. What's wrong with adding a delim param that'll have no effect on existing transclusions, but will make sense for when there's other langs listed? — Lfdder (talk) 18:47, 23 September 2013 (UTC)
I don't see the point of this, adding extra complexity and unnecessary variation. You write that 'items of a particular lang are separated by commas' but these are not terms in a language, as Chinese is not a single language, which causes particular problems. To illustrate:
  • {{zh | t=香港| s=香港| p=Xiānggǎng| j=Hoeng1gong2}}
    Chinese: 香港; pinyin: Xiānggǎng; Jyutping: Hoeng1gong2
Cantonese (represented by the Jyutping) and Mandarin are two separate languages, but they have the same written form. So they should be separated by semicolons except with 香港 where commas should appear. Which is impossible. And this is a relatively simple example. --JohnBlackburnewordsdeeds 19:37, 23 September 2013 (UTC)
You must be proud for having come up with such a brilliant distraction. Plainly, "Chinese", "pinyin" and "Jyutping" are related; Uyghur is not. Separating them all with semicolons is inappropriate. — Lfdder (talk) 19:58, 23 September 2013 (UTC)
Pinyin and Jyutping are no more related than French and Spanish. Also, as I already pointed out multiple times in the previous discussions, if you absolutely must use commas, {{zh-full}} already allows that. rʨanaɢ (talk) 04:27, 24 September 2013 (UTC)
What about my suggestion from that discussion back in 2011 about using semicolons to delimit within language families ("Chinese", "Japanese", "Mongolian", etc.) in the template while using commas to delimit varieties within those families ("pinyin", "Jyutping", "Peh-oe-ji", etc.)? Maybe that would be an acceptable compromise.  White Whirlwind  咨  06:03, 24 September 2013 (UTC)
Like I said in 2011, {{zh-full}} already allows that. Delimiters between families are usually not part of any template (because the different families are added by separate template), so anyone can use a semicolon there if they want. {{zh-full}} allows you to use commas between Chinese-related things. So I don't really see what the issue is. rʨanaɢ (talk) 08:00, 24 September 2013 (UTC)

Please change the link for "Cantonese Yale" to Yale romanization of Cantonese, as done in the sandbox[1]. Kanguole 22:40, 23 November 2013 (UTC)

Done thank you. Callanecc (talk • contribs • logs) 05:11, 24 November 2013 (UTC)

Using Nihongo template and zh template together

There are some difficulties when trying to use both Nihongo and zh template together. Please see Template talk:Nihongo#Using Nihongo template and zh template together Rincewind42 (talk) 06:45, 1 January 2014 (UTC)

Language tagging for pinyin

It feels odd that, when multiple parameters are supplied (such as simplified Chinese: 优酷; traditional Chinese: 優酷; pinyin: yōukù, that the pinyin isn't tagged with {{lang}}.

Is there a reason why the pinyin isn't output as ''{{lang|zh-Latn|yōukù}}'' or ''{{lang|zh-Latn-pinyin|yōukù}}'' (yōukù) ? — OwenBlacker (Talk) 17:42, 8 April 2014 (UTC)

Agree. The pinyin is still Chinese, not English and so should be tagged as such. Either the using the template:lang and zh-latin / zh-Latn-pinyin as OwenBlacker said or else by using the template:transl such as ''{{transl|zh|yōukù}}''. Both have the same end result in the html code. Not just the pinyin, all the transliterations should be tagged similarly. Rincewind42 (talk) 05:35, 9 April 2014 (UTC)

Abbreviating the writing systems

I've just been looking at the current version of the article Youku and noticed that there is a lot of Chinese text not wrapped in {{zh}}, presumably to allow for abbreviation on repeated use.

I agree that we should spell out the writing system names on first use — such as Youku (simplified Chinese: 优酷; traditional Chinese: 優酷; pinyin: yōukù; lit. 'literally excellent (and) cool') — but it feels like we should allow for subsequent uses to do something more terse, like Victor Koo (S: 古永锵; T: 古永鏘; Gǔ Yǒngqiāng).

This feels like the kind of thing that could [relatively] easily be handled either by Lua templating or by a parameter (such as |terse=yes) that allows us to use the same template, but without having the words "simplified Chinese" and "traditional Chinese" littering articles all over the place. — OwenBlacker (Talk) 17:35, 8 April 2014 (UTC)

That reminds me. A while ago to explore the new scripting system/teach myself Lua I did a Lua version of this template on the test2 wiki,
Looking at it now it's broken: it's working but not displaying any Chinese characters, which is a bit of a problem. It also doesn't implement the Default ordering capability of this template, but I never saw a way to implement that.--JohnBlackburnewordsdeeds 18:45, 8 April 2014 (UTC)


I've tried copying it across, fixing some errors, changing the sandbox to use it, disabling the {{lang}} functionality as that depended on a Module I can't find here, and it otherwise seems to work, e.g.
the Module's at Module:Zh. Far from the most elegant programming but far easier to understand than the parser function.--JohnBlackburnewordsdeeds 19:14, 8 April 2014 (UTC)
I've added back the {{lang}} functionality as a function within the module, which also adds it to the appropriate 'Article containing xxx-language text' category, so it now does everything that {{zh}} does except the Default ordering capability.
My original motivation for this was to experiment with and learn the new Lua interface, but I picked this template as it looked like one that could benefit from a speedup. In my tests it is faster, but on most articles the difference will be negligible as the template is used so little, typically once or a few times. The article I used for testing, Mandarin Chinese profanity (see here for the test version) contains many instances of the template but it's exceptional in that.
So I would not advocate adopting Lua for performance reasons. But it does produce much more readable and maintainable code, with the current template being an especially complex one. This will become more of an issue over time as we switch over to Lua – expertise on and support for parser functions will decline. It's also likely that Lua will improve further, becoming perhaps faster and easier to use. For these reasons I think complex templates will have to switch sooner or later, and if there is good reason to such as to add more functionality then sooner makes the most sense here.--JohnBlackburnewordsdeeds 01:17, 9 April 2014 (UTC)
Regarding abreviations, have a look at Wikipedia talk:Manual of Style/China-related articles#Pinyin in article text where I suggested that deep within the article we need not label the text at all. The exception being in articles where other languages, such as Japanese or Korean, are included, when we should be explicitly clear what is what. I don't think the abbreviations S, T, P mean anything to most readers. For someone who has studied Chinese, they can make an educated guess. However, Wikipedia's target is to be an introduction to a subject. We should assume that readers don't know there is more than one form of Chinese writing or what pinyin or other systems might mean.
While we are on the topic about adding features to a new version, would it be possible to make the template automatically un-link the labels if used more than once on a page. That would save us from having to type links=no repetitively.
Another much more advanced, but I'm sure doable, feature would be to have a database of Chinese script/pinyin such that the editor need only fill in either the traditional or simplified Chinese and the other fields be generated via the database. I know that's a big jump but would fix allot of issues with existing articles where only one form of Chinese text exists and the later editors have to try to work out whither to tag it as t, s or c. -- Rincewind42 (talk) 15:26, 9 April 2014 (UTC)
I'm pretty sure linking only the first instance of the template can't be done: there's no way for templates to query other instances of themselves on the page, or to know if they're first (which might e.g. be different when previewing a section, so you could get the preview looking different to how it looks after being saved).--JohnBlackburnewordsdeeds 16:08, 9 April 2014 (UTC)
Having thought on your last suggestion I don't think it's a good idea. It's up to the editor adding the Chinese text via the template whether or not they specify a writing system or just leave it as 'Chinese'. As in many if not most cases it doesn't matter. In most cases on the English WP a bit of Chinese may be added for completeness, to i.e. provide the original characters of a Romanised word or name. Whether it's Simplified or Traditional is of little interest to the vast majority of readers. Those who know enough Chinese to know the difference between Simplified and Traditional can probably tell which it is, if either, themselves, and also know where to find those articles.
So if you see {{zh|中国}}, which generates Chinese: 中国, it's fine to leave it like that. Readers don't need to be told it's simplified Chinese, either as they don't understand Chinese so don't care, or if they do understand Chinese they can recognise it as simplified themselves so don't need to be told. There are cases where the traditional should be added – in this case in China for one – but it should be an editorial decision, not something the template does.--JohnBlackburnewordsdeeds 14:08, 10 April 2014 (UTC)

I've worked out how to do the default ordering in the module: add the list of articles to the module. This is easily done as there are only a handful of them – see Special:PrefixIndex/Template:Zh/. But even if there were hundreds it would be easily done. See e.g. Module:Check_ISO_639-1 for a table of hundreds of ISO codes which can be checked efficiently. Arguably this is much easier than the current method which puts the files in a hard to find place (took me a minute to find them) and also leaves them open to abuse as it would be easy to modify, add or move any of them without anyone knowing, unless they checked or were watching that particular file. If the module is protected then {{editprotected}} or similar can be used to add articles which means they'll also be checked before being added, to stop abuse/POV changes.

I've gone ahead and added this to Module:Zh. While adding I noticed one distinctly odd one which perhaps illustrates the problem with having these in small files that no-one looks at. One is for Chinese calendar but I can't see why t-first is needed for it. The template is only used once, in Chinese calendar #Cultural issues and I don't any Hong Kong/Taiwan association or other reason for putting traditional first.--JohnBlackburnewordsdeeds 00:59, 11 April 2014 (UTC)

Edit request

Per the above discussion please replace the template Template:Zh with the sandbox version Template:Zh/sandbox, which will in effect replace it with the module implementation. If this is done the Module, Module:Zh, needs template-protecting, because of the large number of transclusions of the template.--JohnBlackburnewordsdeeds 17:13, 3 May 2014 (UTC)

Partly done: I updated the template. If you want Module:Zh template-protected, ask at WP:RPP. Jackmcbarn (talk) 22:32, 3 May 2014 (UTC)
Thanks, and I've put in the request.--JohnBlackburnewordsdeeds 22:39, 3 May 2014 (UTC)
Have you just locked yourself out of your own module? — lfdder 23:29, 3 May 2014 (UTC)
Yep. It needs protecting so it's done. The module is hopefully done for now - I've been checking and every use I've seen looks OK. If anything needs doing to it, whether short term fixes or longer term improvements, I can put in another edit template-protected request. --JohnBlackburnewordsdeeds 23:35, 3 May 2014 (UTC)
I'm sure it needed protecting. There's big bad wolves out there. — lfdder 23:42, 3 May 2014 (UTC)

I don't know if there's a precise transclusion count that warrants protection but the Template's protected and the Module is now used in as many pages. Pages with Chinese language content do sometimes become a focus of dispute; there have been long and contentious disputes over country names and language names for example. Given the focus of these disputes is often language it's perhaps best that participants are unable to use the template, or the module, as part of the dispute.--JohnBlackburnewordsdeeds 00:01, 4 May 2014 (UTC)

Module rewrite

As some may have noticed I've been working on a Lua module implementation of the template. This was initially meant to improve performance, but probably the greater benefit is future development and maintainability: the code is simpler and clearer with almost none of the duplication and complex [parser] constructions seen in the template. The module is here

Module:Zh and {{Zh/sandbox}}

Almost all of the data is exposed in tables at the top. This makes it easy to expand and update, to account for page moves, formatting changes and new fields, with no actual programming. More generally the logic is much simpler so even code changes should be easier to do, while things perhaps previously impossible or impractical will become possible.

One particular change in how it works is given by the very first table, which is the 'traditional first' default ordering override. This is currently done using separate files, as described at Template:Zh/doc#Default ordering, but that is a far from ideal solution. Not only is it a bit of a hack but it's easily misused as files can be created to effect a change on an article, perhaps against consensus or a POV change, without those with the article on their watchlist being aware. The current list is based on the files, as found e.g. here, and at least one, the one for Chinese calendar, would seem to be incorrect and unnecessary (the template only appears once in the article).

Other than that it's meant to reproduce the behaviour of the current template exactly. But I found when testing it there were differences, some of which look like bugs in the current template, others of which look like undocumented behaviours. The tests are all here:

Template:Zh/testcases

I have noted the differences on that page, as notes so they link to the examples, but I include them below

  • The template currently changes simplified and traditional to just Chinese if they are the only Chinese. The module uses simplified or traditional if it is specified. This seems more logical to me: if an editor specifies either simplified or traditional Chinese they probably meant to. But it would easy enough to change this.
  • A bug in the current template, with s and t the same it's inserting a semi-colon.
    • I Note that this was raised here on this page but was not fixed. I agree with the original report that it should be fixed; it may be it was considered too hard to fix, given the already complex parser code at that point of the template.--JohnBlackburnewordsdeeds 21:26, 2 May 2014 (UTC)
  • the template is linking to the redirect Hanyu pinyin here, it should use a direct link (so if e.g. it were used on pinyin it would work properly).
  • The template is using 'Mandarin Pinyin', presumably to disambiguate pinyin but there are no other forms of pinyin, or nothing else I recognise as such. I've never heard it called Mandarin Pinyin before, and that appears nowhere in pinyin (one external link did but on checking the linked page doesn't use 'Mandarin Pinyin').

Also it was suggested at Wikipedia talk:Lua/Archive 2#Odd problem with new template/module that the template might be a wrapper for {{lang}}, but that would only partly work, for Chinese and perhaps its two main writing systems, as most of the things here aren't languages and so aren't I think supported. It would therefore make the module more complex. Converting the Language templates to Lua seems to be a work in progress - see e.g. Module talk:Language – so it's possible it will become clearer how it can be used later.--JohnBlackburnewordsdeeds 16:12, 28 April 2014 (UTC)

Not sure what you mean by "most the things here aren't languages and so aren't I think supported". Pinyin, Wade-giles etc are still the Chinese language, just transliterated into latin script. Thus using the lang template you would mark-up Pinyin as {{lang|zh-latin|Běijīng}} or you could use the {{transl}} template {{transl|zh|Běijīng}} Rincewind42 (talk) 02:27, 29 April 2014 (UTC)
Do note that {{transl}} does nothing other than set the title attribute to "ISO 7098 Chinese", though. You could use both, but wrapping the text inside two spans isn't very elegant. — lfdder 02:37, 29 April 2014 (UTC)
On line 96 you're overwriting c with a nil when both s and t are not set. — lfdder 03:04, 29 April 2014 (UTC)
It's not - it's one of the testcases: {{Zh/sandbox|c=中国}} gives Chinese: 中国. Now you point it out I'd expect it not to work, and it will certainly break with e.g. {{Zh/sandbox|c=中国|s=|t=}} so I'll add an extra check.--JohnBlackburnewordsdeeds 14:30, 29 April 2014 (UTC)
It's still broken in Lua when their value's nil; try
= p._Zh{c="test"}
in the console. The sane way to do it would be to discard empty strings from frame (maybe using Module:Arguments) and check for nils. — lfdder 15:49, 29 April 2014 (UTC)
Console ? (I'm on a Mac, so have a (unix) command line and have a JS console in Safari but don't know if you mean either or something else).--JohnBlackburnewordsdeeds 16:06, 29 April 2014 (UTC)
The Lua console on Module edit pages. It's right underneath the code editor. — lfdder 16:08, 29 April 2014 (UTC)
Never noticed that before and this is the third module I've worked on. It could be more prominently placed and/or documented! --JohnBlackburnewordsdeeds 16:20, 29 April 2014 (UTC)
I've added Module:Arguments and simplified the checks; it all seems to work at least with the testcases (I'll keep adding tests as I think of them but think I've covered all the cases that might arise in articles). This does mean that calls from other modules will need to be better behaved than invocations from articles, but that shouldn't be a problem; module programmers should be better able to identify and deal with any problems in module-module code.--JohnBlackburnewordsdeeds 21:25, 29 April 2014 (UTC)

On using language templates the first version [2] of the module on test2 did use the language module, but on porting it to en.wp that didn't exist so I reimplemented it first as a function then inline. I haven't tagged the pinyin or any other transliterations but then nor does the current template and my goal was first to get them working identically (except for the issues identified above). It's unclear in this case which of lang and trans is best: both produce quite different output while lang looks distinctly odd: on my system this [Běijīng] Error: {{Lang}}: unrecognized variant: latin (help) is rendered using Heiti SC font, which looks something like Helvetica Neue.--JohnBlackburnewordsdeeds 14:53, 29 April 2014 (UTC)

I've changed the module to use only 'Chinese:' when there's only one of them, like the template. An easy fix and on reflection doing otherwise would cause far too many problems, where the template's been used already. Editors may have used the template with just one of s=, t= to get the link to the relevant writing system, or to get the HTML for simplified or traditional, or just as they copied and pasted the template not realising how the parameters worked. In each case changing how it looks with much longer and more descriptive labels would neither be expected nor desired. The testcases and notes above have been updated accordingly.--JohnBlackburnewordsdeeds 10:44, 30 April 2014 (UTC)

I've added a new option to disable labels, 'labels=no', to the module. See the testcases for the full set of examples, but a simple example looks something like this

  • {{Zh/sandbox|s=中国|p= zhōngguó}} gives
  • {{Zh/sandbox|s=中国|p= zhōngguó |labels=no}} gives
    • 中国; zhōngguó

Obviously this defaults to off, i.e. it defaults to show labels, so matching the current template. Disabling labels also disables wikilinks.--JohnBlackburnewordsdeeds 18:19, 30 April 2014 (UTC)

I've updated the module to properly escape colons: see #Does not work in description lists on this page. If there are any other potential issues or usage cases that should be checked please post them here or to the testcases. I think I've covered everything there but the template is used on thousands of pages so there are bound to be others.--JohnBlackburnewordsdeeds 00:42, 2 May 2014 (UTC)

@JohnBlackburne: Hi John, thanks for adding the "labels=no" functionality, although when that is the case I think there is a need for the subscripted question mark at the end of the strings linking to Chinese characters or something. I'd also like to ask when you anticipate completion of the Lua module such that it duplicates all existing {{zh}} functionality. In particular, the test cases do not show all the tone marks for pinyin, which is a key requirement. I am assuming that the Lua module is going to replace {{zh}} at some stage, so there is no point in discussing changes to the old template per the thread above until the new version is settled in. Is that correct?  Philg88 ♦talk 06:43, 2 May 2014 (UTC)

Pinyin tone marks work fine; they're just latin characters as far as the template's concerned. I didn't use any when creating the tests (I wrote out the Chinese and pinyin myself before copying the rest of the fields from the template documentation). I've added them now, to the testpage and examples above.

I've tested all the usage cases I can think of, having looked through articles and these talk pages for ideas, and checking the tests with alternate skins, i.e. cologne blue, modern, monobook and (the default) vector. The module is done, as far as I can tell. The next thing is to get it out there in articles.

As for a subscripted question mark, per {{nihongo}} I think we need more discussion to come to consensus on how to proceed, both over how to introduce any change to the template's default behaviour, and how exactly it will look. It's probably worth continuing discussion at the Wikiproject. The module certainly facilitates this with the 'labels=no' option, but until there's a consensus to change it should default to working the way the template now does.--JohnBlackburnewordsdeeds 16:52, 2 May 2014 (UTC)

Thanks for all your work on this John. I agree that more discussion is needed if we are to add the superscripted question mark. On further thought, now that we have the "labels = no" functionality, I don't think it's a pressing requirement - if labels are used with the first instance of the template readers should get the idea when Chinese appears the next time without them. The best thing about the new module is that it removes the need to use {{lang}} when labels aren't required.  Philg88 ♦talk 12:20, 4 May 2014 (UTC)

Add lead = yes parameter?

At the moment, there is no way to hide the text headers from {{zh}}, only to disable them using links=no. This leads to unnecessary clutter where there are multiple Chinese words and phrases in the article. This is currently solved by using {{lang}} when {{zh}} does not provide the required functionality.

The alternative, use of {{lang}} with Chinese variants, cannot cope where the traditional and simplified characters are the same, because there is no ISO language code for zh-han, only zh-hans and zh-hant. This means that categorisation of Chinese language text using {{lang}} can only span the three possible variants if zh is used as the language code, which is non-intuitive and potentially confusing. The ability to use {{zh}} throughout an article containing Chinese characters would be more desirable than switching to {{lang}} when header suppression is required.

As a potential solution to the issue, the {{Nihongo}} template has the parameter lead = yes to override the default suppression of text headers, which would be a much better way for {{zh}} to function. Because {{zh}} supports the c= parameter where the traditional and simplified characters are the same, the necessity to switch to {{lang}} is obviated.

Comments please.

 Philg88 ♦talk 08:26, 27 April 2014 (UTC)

Philg88 has asked me to comment here. This seems like a reasonable suggestion to me, and I can't see any particular technical barriers to it. The final decision, though, should rest with the editors who use this template regularly. I don't think I have ever had the opportunity to use it myself, so I can't say first-hand how convenient (or not) the current setup is. — Mr. Stradivarius ♪ talk ♪ 07:47, 28 April 2014 (UTC)
Thank you for that. I will post a note on the Wikiproject China talk page asking for input.  Philg88 ♦talk 13:23, 28 April 2014 (UTC)
Ah, I just realised something important that should have been obvious to me before - if you are planning on switching the labels from on by default to off by default, you'll need to update all the transclusions to make sure that the articles that need labels have them. This will probably require a bot to change all the {{zh}} invocations that appear in the lead section of the transcluded articles. (There are 29,000 transclusions of the template, so too many to check by hand.) If you wanted to add "lead=no" instead of "lead=yes", then you could do that just from the template code - but would that be as intuitive for editors to use? — Mr. Stradivarius ♪ talk ♪ 14:36, 28 April 2014 (UTC)
Hmm ... that's an interesting point. My suspicion is that if it is on by default, editors used to the old format will see no difference in functionality and remain unaware of the change. Conversely, forcing people to switch it on should ensure more apposite use. And yes, I think it is more intuitive on the basis "if you want to use it switch it on". Hopefully, we will get some more input from other editors.  Philg88 ♦talk 15:13, 28 April 2014 (UTC)
I agree, it would be problematic to have it changed to default 'no', and so change all those uses of the template already in articles. It's not as if editors have no option now if they want Chinese without the prefix 'Chinese:', so many if not most people using the template did so because it added the names and links to their text, with the other features such as adding a span lang="zh" tag and adding it to categories being largely invisible and probably not something most editors are aware of (if how rarely {{lang}} is used for foreign text is anything to go by). Other than that though it seems a useful change.--JohnBlackburnewordsdeeds 15:29, 28 April 2014 (UTC)
  • Question: When you say you would like to have headers changed, what exactly do you mean? That by default, there are no links, and there is only a tiny link to a help page (just like with the nihongo template)? The thing is, Japanese doesn't have two kinds of writing systems used in the modern day since there is only one way to write Japanese, and in many many cases, the {{zh}} template contains content for both simplified and traditional, in addition to the romanization that the {{nihongo}} template also manages. If the headers were stripped by default, this may prove a problem with 90% of pages which already use the {{zh}} template. Japanese doesn't need a distinction between two widely used writing systems, whilst Chinese does, which means that in the case of {{nihongo}} people don't actually have to guess between what is used; the {{zh}} template also supports parameters for regional romanizations such as Pe̍h-oē-jī, and in various Taiwan-related pages, both pinyin and POJ romanizations are used within the template.

    Currently many pages out there with this template rely on it to make a T/S distinction, or some other kind of distinction, which means that each page that has a necessary requirement for the headers needs to be manually adjusted one by one to display the headers if a significant change to the template is made in regards to default header visibility. What do you think should be done to mitigate this problem? Would you rather—instead of stripping—simply have the header made very condensed, e.g. (s. 测试; t. 測試)? Or would you prefer that the template's default value is lead=yes, so that the template displays headers by default and needs to be manually changed in order to hide them (by optionally changing it to lead=no on the page where the template is used), which is completely converse to how {{nihongo}} currently stands? --benlisquareT•C•E 15:14, 28 April 2014 (UTC)

I am in favour of having a toggle for the lead. I think it would be best to default to lead=on/yes for several reasons. First off, that existing templates are unaffected by the change. I know a bot could change them all quickly but it's better to not fix something that isn't broken. Also existing editors are familiar with the current behaviour and may not be watching this talk page. They would be confused by a sudden change in behaviour and insert the template incorrectly. Further, new editors might incorrectly assume that the default behaviour is the preferred/recommended behaviour and not enable the lead when it should be enabled. Temporarily having extra words until an experienced editor comes and tidies the page is less of an issue than temporarily having words omitted that are required to understand the article. Omitting the leads should be the considered exception used in a few articles that have multiple zh templates. Care should be taken to chose where and when omitting the lead is valid.

I dislike using abbreviations like s: t: p: as they are not intuitive to anyone other than experienced Chinese students. Omitting the lead as suggested above is only for cases where multiple zh templates are used on one page and the pattern of simplified; traditional; pinyin has been established and is to be used consistently throughout. Where other transliterations/scripts/languages exist on the same page, the lead always be visible to avoid confusion.

The nihongo template uses the word "lead" but I would like to suggest we use a different world. The word "lead" can also be spelled "lede" which could result in many typos by some users. Also the term "lead" is used to describe the introduction of an article. Using the term in the template may give the impression that lead=on/yes is to be always used within the lead section of the article or always disabled outside the lead section. Can I suggest we use the words label=on/yes and label=off/no.

-- Rincewind42 (talk) 15:53, 28 April 2014 (UTC)

Comment: Thanks to everyone for their input so far. I have summarised below where I think we are based on that and some further thoughts:

1. In theory, according to the Chinese style guide, no more than one {{zh}} parameter should appear in the first sentence of the lead. [If there is] "more than one parameter in use in a given article, prefer using a {{Chinese}} box instead of {{zh}}" This needs to be rewritten as it doesn't make sense - one parameter is clearly not enough (I think it is supposed to mean "if there is more than one Romanization"). In my experience, as a minimum, the first sentence of the lead should show Chinese characters (traditional ('t') and simplified ('s') or a single iteration if they are identical ('c')) [reversed if required e.g. t=first], the associated Romanization and on occasions the literal meaning ('l'). [Note editor discretion will be required here if such a construct creates an overly long definition that trips up the reader]. The Romanization flags 'p' or 'hp' 'tp', 'w', 'j', 'cy', 'poj' and 'zhu' should be mutually exclusive and if more than one is required the labels/text should go into a {{Chinese}} box. Note that although pinyin is the preferred Romanization per the style guide, there are instances—in Hong Kong-centric articles for example—where an alternative is used.
2. My proposal that 'lead=no' [hereinafter amended to 'labels=no' per Rincewind42's suggestion] as the default is based on the premise that once editors get used to the new template parameters, it will be much easier to use as it is more intuitive. In my experience, Chinese text does not suddenly popup in the middle of an article but is shown first in the lead. Where to switch labels=on then becomes logical, as by default labels will be off in the article body. I realise that a bot will be needed to make some initial changes—29,000 transclusions according to Mr. Stradivarius—based on labels needing to be switched on in the lead, but this should not be hard to code. If we don't do it this way around, editors who don't know there is a labels=no parameter will end up scattering labelled instances of {{zh}} throughout the article body which damages readability. Note that the functionality of 'links=no' would probably be removed as surplus to requirements - there will be no need for it in the lead and links would be handled in the body as proposed below.
3. As Benlisquare rightly points out, handling {{nihongo}} is more straightforward as it uses a single character set. Where {{zh}} labels=no (i.e. in the article body), there needs to be some sort of separator between the traditional and simplified characters to improve readability, I agree with Rincewind42 that using a subscripted s:t:p system is non-inuitive to the majority of readers as well as potentially confusing. As an alternative: (撫吧? 抚吧? fǔba?) follows the same help principle as {{nihongo}} and scans more easily. Someone else might have an alternative proposal.
4. Based on JohnBlackburne's Module Rewrite thread below, this might be a good opportunity to test the new functionality using the Lua module with a view to using it as a replacement for the current {{zh}} after testing. That would also provide the time necessary to get a bot ready to perform any updates required based on the new functionality.

 Philg88 ♦talk 07:43, 29 April 2014 (UTC)

With a view to point No.2: There are a significant number of articles where the zh template is not used in the first sentence. For example, Beijing (where Chinese script first appears in the Etymology section) or in Mao Zedong (where Chinese doesn't show up until well down the article in the "Leadership of China" section). This occurrence will increase as more articles start to use {{chinese}} instead of the zh template in the lead section.
Looking at No.3: I don't like the question marks used by the nihongo template. I feel they make a visual clutter, especially when the text is linked to wiktionary. It might be suitable to just have one at the end linked to a help page such as (撫吧/抚吧; fǔba?) but even then I'd like a flag to turn it off as it would only be needed once per article, not on every. Or how about with tooltips. For example mouse over these (撫吧/抚吧; fǔba) or combined with a tooltip only on the question mark (撫吧/抚吧; fǔba?). -- Rincewind42 (talk) 08:39, 29 April 2014 (UTC)
@Rincewind42: My responses to your points. If a bot is set the task of switching labels=yes, it will do so for the first occurence of the {{zh}} template in the article, so it doesn't matter whether it's in the lead or half way down. Tooltips might be a problem if people have hovercards swiched on in Beta preferences, or are using another script that creates mouseover popups. Your alternative suggestion of a single superscripted question mark at the end is a good one. A flag to switch it off (e.g. linked question mark shown if labels true, not shown if help=no) should be straightforward.  Philg88 ♦talk 11:47, 29 April 2014 (UTC)
Philg: you can see the transclusion count using this tool. (It's linked from the "what links here" page for the template.) — Mr. Stradivarius ♪ talk ♪ 14:47, 29 April 2014 (UTC)
Thanks, Mr. Strad.  Philg88 ♦talk 15:36, 29 April 2014 (UTC)
  • Comment – Repetitive display (with or without links) of "Chinese", "pinyin", etc., is visually intrusive and not very helpful. This newly tweaked template should solve our problem. I'm not competent enough to help with the technical issues, but I will fully support this initiative once they're ironed out! Madalibi (talk) 01:59, 30 April 2014 (UTC)

Re Point 4 I've added it to the module; see the section below. It defaults to not disabling labels, the current behaviour which I think is the sensible thing for a template with many thousands of transclusions. In particular it would be a very bad idea to roll out the module at the same time as changing fundamentally how the template works - it would become impossible to sort actual bugs from complaints about how its behaviour changed. But with the code in place it's at least means the behaviour could be modified, to e.g. disable labels by default, if there is a decision to do so.--JohnBlackburnewordsdeeds 18:27, 30 April 2014 (UTC)

The new Lua module is now operational with support for "labels=no" where required. If anyone feels that we should move forward with a discussion of adding the superscripted question mark as a help device, or indeed has any other suggested enhancements, please start a new thread at Wikipedia talk:WikiProject China where it will have higher visibilty.  Philg88 ♦talk 12:26, 4 May 2014 (UTC)

MfD the old format subpages

I have nominated the formatting subpages used by the previous version of the template for deletion; see the page here:

Wikipedia:Miscellany for deletion/Unused Template Zh template subpages

I think these are pretty noncontroversial but chances are anyone who can think of any problems, or simply wants to make note of them before they're deleted, is reading this talk page.

I notice though that one has been added to the list since I created the module, for Yellow River Map. I should in theory get this added to the module but it won't make any difference as none of the instances of the template in the article show both traditional and simplified. The instance with both, {{zh|t=大洪水|s=大洪水|p=Dà Hóngshuǐ}}, gives Chinese: 大洪水; pinyin: Dà Hóngshuǐ as the simplified and traditional are the same.--JohnBlackburnewordsdeeds 21:53, 4 May 2014 (UTC)

I've addressed the later problem by noting there's no need to set the default ordering for that article on its talk page, so there's no need to add it to the module's list either. I've also updated the notice, Template:Zh/notice, to reflect the recent changes.--JohnBlackburnewordsdeeds 01:30, 5 May 2014 (UTC)

Edit request 2

Please remove the following line from the module 

 ["Bao'an County"] = true,

As per this change to the sandbox. The reason is that article Bao'an County, is a mainland topic so should have simplified first. The format file Template:Zh/format/Bao'an County specifies this but I did not notice it when compiling the list for the module.

(the good news is the list approach works, it is setting traditional first in this article based on the list, but it should not be doing so in this article)--JohnBlackburnewordsdeeds 01:48, 5 May 2014 (UTC)

Done Jackmcbarn (talk) 01:55, 5 May 2014 (UTC)

Bug for shorthand version

Some articles use this template in a shorthand form. When adding the "labels=no" code to the shorthand version, the result still displays the labels. For example {{zh|物理|labels=no}} results in: 物理 -- Rincewind42 (talk) 16:04, 5 May 2014 (UTC)

I didn't add that as I assumed that the only use for that would when no parameters are named, just a string is passed, e.g. {{zh|物理}}. As noted in note 1 of the testcases a workaround is to use c=, e.g. {{zh|c=物理|labels=no}}, while {{lang|zh|物理}} also works. It's a straightforward fix though; I'll look at adding it to the sandbox.--JohnBlackburnewordsdeeds 16:25, 5 May 2014 (UTC)
Done. Have a look at Template:Zh/testcases which I've expanded to show labels=no for both the current and sandbox version, it's the only difference between them (or should be).--JohnBlackburnewordsdeeds 16:41, 5 May 2014 (UTC)
Rincewind42 or anyone else able to look at this to confirm it fixes the problem? It's on the Template:Zh/testcases or here:
  • {{zh|物理|labels=no}}
    • 物理
  • {{zh/sandbox|物理|labels=no}}
    • 物理

--JohnBlackburnewordsdeeds 23:14, 6 May 2014 (UTC)

Looks OK. Rincewind42 (talk) 13:28, 7 May 2014 (UTC)

Edit request 3

Please update the module from its sandbox with the above change, a fix to make the flags behaviour consistent across all usage cases, even the 'default with no named parameters' case, as described in #Bug for shorthand version immediately above.--JohnBlackburnewordsdeeds 13:43, 7 May 2014 (UTC)

Done Jackmcbarn (talk) 15:34, 7 May 2014 (UTC)

Other Chinese scripts

If you look at a Chinese bank note, on the obverse you have 中国人民银行 and on the back the pinyin "Zhonggou Renmin Yinhang" but below that there are four more scripts: Uyghur, Tibetan, Mongolian and Zhuang. Since these are commonly used in articles along side Chinese script it would be useful to include them as fields in this template. It may also be useful to be able to prioritise in the same ways as s/t or t/s. This would be useful for articles such as Shenyang where currently we have {{Lang-mnc}} {{lang-mn}} and {{MongolUnicode}} where I'm rather doubtful about marking up Manchu script as Mongolia. I'm also doubtful if the script is Manchu at all. The page for Ulan Hot is also a mess of confused templates including a Russian Cyrillic transliteration. The Kashgar article has to use {{lang-ug}} and Tibet has {{bo}} {{IPA-bo}} {{lang-mn}}. The addition of these extra Chinese scripts into {{zh}} would simplify such pages considerably. I know {{Chinese}} has these scripts but in the cases above, the other scripts are used within the body text of the article multiple times so an inline template is required rather than an infobox. Rincewind42 (talk) 09:20, 8 May 2014 (UTC)

Just a note that I started looking at this but have put it to one side while sorting out the language tags for the current supported fields. Not only is it easier to do them one at a time but I think sorting out the current set will give us a better idea how to proceed with other languages and scripts.--JohnBlackburnewordsdeeds 14:39, 13 May 2014 (UTC)

Edit request 4

Again please update the Module from its sandbox. The changes this time add language tags to the fields other than those already with them (the Chinese character fields) and the literal ones. See #Language tagging for pinyin again and in particular #Languages for details.

This change is a little different from those before, which introduced the module, and fixed minor issues. This changes how the template works, in theory quite significantly, though in practice it should be invisible to the vast majority of readers; the only way I can see it's working without looking at the HTML output is with custom CSS. It's very unlikely to break anything though; if anyone else notices a difference it should be an improvement, as whatever software they're using does something useful with the new language tags.--JohnBlackburnewordsdeeds 17:39, 14 May 2014 (UTC)

 Done – Paine Ellsworth CLIMAX! 03:09, 15 May 2014 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Module_talk:Lang-zh/Archive_2&oldid=1255210439"