Template talk:Infobox Chinese

Bopomofo and Xiao'erjing

What's wrong with adding Xiao'erjing and Bopomofo? They are Chinese writing methods. 132.205.44.5 21:42, 12 July 2007 (UTC)

We are still in the middle of standardizing templates or trying to here. Please avoid any new parameters and language adding for the time being. Thx. Benjwong 15:21, 13 July 2007 (UTC)

It seems discussions are through? So can these two be added to the template? 132.205.44.5 22:00, 14 August 2007 (UTC)

Do these count as separate languages (blue), not romanizations under Chinese (green)? BTW you can also use Lang1, Lang2, Lang3 without any code added. Benjwong 03:11, 15 August 2007 (UTC)

Bopomofo and xiao-erjing have been added to mandarin. Dungan has been added as a language and to mandarin (dialect of), as it's both, depending on who you ask. Xiao-erjing is also used for Dungan... 70.55.202.250 (talk) —Preceding comment was added at 21:59, 3 April 2008 (UTC)

Order of entries

This is the English Wikipedia, and thus I STRONGLY recommend placing Cantonese under "C" (not Y), Mandarin under "M" (not "G") Hakka under "H" (not K), Shanghainese under "S" (not W), and so on. Maximum usability for everyone in the world is very, very important. Badagnani 04:39, 25 July 2007 (UTC)

No, as this will introduce inconsistency. We are classifying Chinese dialects by their top-level linguistic classification, and not by the common English name for sub-level dialects. For example, Shanghainese is a sub-dialect of Wu, and should not be interpreted as similar. Mandarin and Cantonese in the common sense of the word actually refers to a variant of the Mandarin and Cantonese dialects respectively. Are we going to change "Min" as "Hokkien" next, despite its obvious technical inaccuracies? Since there are only seven entries, I fail to see why users will somehow have major difficulties finding the correct classification, since "Mandarin", "Hakka" and "Cantonese" are also added to aid the English user.--Huaiwei 05:16, 25 July 2007 (UTC)

As per Huaiwei's statement, this template is largely sorted by something like a linguistic classification. But which one, exactly? — Sebastian 19:25, 19 December 2011 (UTC)

Actually, upon further study, I realize that the current arrangement is in fact a mix between linguistic and alphabetic criteria. The latter are of course not well defined, either; sometimes the blue box name has been used for sorting (as in Tagalog, which appears between "Hindi" and "Japanese"), and sometimes the language abbreviation (as e.g. in Burmese, which appears between "mon" and "por"). — Sebastian 19:41, 19 December 2011 (UTC)

OK, here's a table of all languages currently in this template, along with their family (For the purpose is not to assert classification, but merely to make it easier for readers to find simlarities. Therefore, I'm not worried about the current state of classification discussions here.), their current order ("order0"), and the order I would propose ("order1"). I'm sure there are better ways to arrange them; please add them as new columns to this table. — Sebastian 21:08, 19 December 2011 (UTC)

language	code	family	order0	order1
Chinese		Sino-Tibetan	1	1
Tagalog	tgl	Austronesian	2	13
Hindi	hin	Indo-European	3	17
Indonesian	ind	Austronesian	4	12
Japanese	jpn	Japonic	5	10
Korean	kor	Altaic	6	8
Malay	msa	Austronesian	7	11
Manchu	mnc	Tungusic	8	15
Mongolian	mon	Altaic	9	9
Burmese	my	Sino-Tibetan	10	2
Portuguese	por	Indo-European	11	18
Russian	rus	Indo-European	12	19
Tamil	tam	Dravidian	13	16
Thai	tha	Tai–Kadai	14	6
Tibetan	tib	Sino-Tibetan	15	3
Uyghur	uig	Turkic	16	14
Vietnamese	vie	Austro-Asiatic	17	5
Zhuang	zha	Tai–Kadai	18	7
Dunganese	dng	Sino-Tibetan	19	4

Non-Chinese sorting?

In this context, I would like to raise the question what to do in articles that are not primarily Chinese. Malaysian ringgit, e.g., is such a case, where it doesn't seem appropriate to put Chinese first. Then again, in that article, it is questionable if this template is of any use, anyway. Searching further, I didn't actually find many examples; most are geographic terms which at least border present day China, such as Pamir Mountains. Maybe it's better, in the interest of peaceful coexistence, to not start discussing these. But my interest here is from a language point of view, and "帕米尔" clearly is not originally Chinese. — Sebastian 19:25, 19 December 2011 (UTC)

Font size for Chinese characters

When Chinese characters are displayed on Wikipedia article pages using this template, they are just big enough to be read clearly by those not thoroughly familiar an east Asian language - provided one is using a Windows browser. If a Mac browser is used, the Chinese characters are too small. I already corrected this on several Wikipedia article pages, but those corrections were undone when this more sophisticated template was put in place. For the sake of the 5% who use Mac browsers, please consider bumping the font size of just the Chinese characters up one notch. -DoctorW 17:29, 10 August 2007 (UTC)

If one notch means going from the current size of 95% to 100%, it is do-able. Anything higher, is probably a bad idea. Benjwong 03:11, 15 August 2007 (UTC)

Why? What would be wrong with 110% or even 120%? As it is now it is simply too small on Mac browsers. They should be easily readable. -DoctorW 05:52, 27 August 2007 (UTC)

Great work, two suggestions

Wow. This is some fantastic work. The first suggestion is that all of the usage stuff go on the template page, usually talk pages are for discussion, only. The second suggestion is more detailed. It might be nice if alternate romanizations for Japanese were available. There are at least four that are relevant, Revised Hepburn and Traditional Hepburn (both covered at Hepburn romanization), Kunrei-shiki, and Nihon-shiki. Right now, the only field provided is "romaji", which sort of implies there is only one way to romanize a particular Japanese word, and a bunch of other languages have alternate romanization options, so I just thought, for the sake of completeness... Anyway, just a suggestion, thanks, Bradford44 17:13, 14 August 2007 (UTC)

I know the is supposed to separate it. Still I am terrified of having instructions on the same page as the code. Especially when the current talk page calls the function for a demo, which can be modified all you want with no harm. Benjwong 03:11, 15 August 2007 (UTC)

About the extra Japanese romanizations, you might want to break it down real simple on the 4 to be added. Starting with some kind of standard iso codes for each romanization, assuming there is any? Benjwong 03:11, 15 August 2007 (UTC)

• Romaji (iso code = romaji)
• Shūsei Hebon-shiki Rōmaji (iso code = ?)
• Hyōjun-shiki Rōmaji (iso code = ?)
• Kunrei-shiki (iso code = ?)
• Nihon-shiki (iso code = ?)

Ok, I'm not too familiar with iso standards, so I'm not really sure what information you're looking for (that is, your question gives me much more credit for translation/transliteration proficiency than I deserve). According to their respective articles, Traditional Hepburn (Hyōjun-shiki) gained international popularity since its mid-19th century invention, but has never been approved by the ISO. Revised Hepburn (Shūsei Hebon-shiki) is also not approved by the ISO, but has been adopted by the U.S. Library of Congress and is the most widely used in the world. Kunrei-shiki is ISO 3602; Nihon-shiki is ISO 3602 Strict. It should be noted that the significance of those ISO designations are lost on me. If you're asking me what I think the template parameters should be named, I suggest they be the following and in the following order (to replace the current sole parameter, "romaji", and not in addition to it):

• revhep (for Revised Hepburn)
• tradhep (for Traditional Hepburn)
• kunrei (for Kunrei-shiki)
• nihon (for Nihon-shiki)

I hope that provides the information you were looking for. Thanks, Bradford44 04:22, 17 August 2007 (UTC)

And now that I'm thinking about it, a parameter for both "kana" and "hiragana" is redundant as well. Because hiragana is a type of kana, it doesn't make sense to have them both. Perhaps parameters for both "hiragana" and "katakana", instead? Bradford44 17:00, 17 August 2007 (UTC)

Here is a sample article. Maybe you can tell us if that is not hiragana, and is actually using katakana?? Isn't hiragana useful for historic stuff? I don't have a count on how many uses hiragana at the moment. About romaji, we should definitely keep it. It's already been used for hundreds of articles. It will require some hefty language-skills to move existing romaji romanization into revhep, tradhep, kunrei, nihon. Benjwong 17:39, 19 August 2007 (UTC)

That article was using only hiragana, just two different pronunciations. Hiragana are an inherent part of Japanese writing, but carry no meaning alone. Hiragana represent discrete syllables of sound, while kanji represent ideas, but whose pronunciation and meaning vary depending on context. One common example of the use of hiragana is to indicate the use and meaning of a particular kanji (such as its tense or meaning). Hiragana fulfill other functions as well, such as particles of speech. The only reason this is relevant here, is because writing in hiragana is the most accurate way to represent the pronuciation of a particular word. Katakana is a coextensive set syllables, but used more rarely, such writing foreign loanwords, or for emphasis like bold or italic text in English. I also want to make clear that "romaji" is a generic term. Technically, the four romanization systems I am proposing to be added are all romaji. You are correct however, that it should not be deleted, where so many articles already use it. Nevertheless, the way Korean is currently handled is exactly how I'm proposing Japanese be handled. A parameter for the kanji, a parameter for hiragana, and then a [show/hide] box labeled "transliterations", under which the main romanization styles are listed, in the order I previously indicated. I'll think about simply trying to implement it myself. Bradford44 00:28, 20 August 2007 (UTC)

I went ahead and made the changes myself, as described above, and it appears to be working fine. I did not remove "romaji" as a parameter, but it should considered deprecated for use until it can be phased out. I will start implementing the alternate romanizations on articles which use the template. Bradford44 17:53, 20 August 2007 (UTC)

• Comment - I believe that four romanizations is excessive and confusing. The "standard" romanization for a given word is just fine, and good enough for our users. Badagnani 18:52, 20 August 2007 (UTC)

Well, four is how many major romanization systems there are. Korean is allowed its two, and the Chinese "transliterations" section has seventeen different fields. There is no "standard" romanization system in Japanese, and which one is the best is hotly debated. Revised Hepburn is used by the library of congress, and the one officially preferred by wikipedia, but widely criticized by linguists. Kunrei-shiki is the version propogated by the Japanese government, and adopted by the ISO, but criticized as very poor for practical use because it often utterly fails to reflect actual pronunciation of terms. The other two are variations on Revised hepburn and Kunre-shiki, respectively, and are often relevant for historical or other reasons. Note also that not all four need be listed in instances where multiple systems romanize a word the same way. Compare Qi and Soy sauce. Bradford44 19:47, 20 August 2007 (UTC)

Should Historical kana usage be added as well? There are a few articles that might benefit from its inclusion (East Asian calligraphy, Chinese style name). PC78 08:36, 21 August 2007 (UTC)

For the sake of completeness, I suppose so, but I don't have a deep enough knowledge of the subject to answer authoritatively. You might ask around at WP:JPN, they tend to be very knowledgeable about Japanese. Bradford44 14:21, 21 August 2007 (UTC)

Interference

In Solar terms, this template interferes with {{Template:Solar terms}} which may be a problem with the latter template. However, even when I remove the Solar terms template, this Chinese template still interferes with remaining table—the text from both tables overlay each other transparently, especially when the text size is increased. Although {{-}} prevents the interference, excessive white space is then generated. — Joe Kress 21:23, 14 August 2007 (UTC)

Further experimentation shows that the problem only exists in Firefox 2—no interference exists in IE 7. The two templates don't interfere with each other, but both interfere with the article's table in Firefox. I found that {{clearright}} does separate the two templates from the table with minimal whitespace, provided that {{clearright}} is not used between the templates, forcing them to exist side-by-side. But this also moves the right margin of the table to the left of the Chinese template, squeezing the table's contents. I ultimately decided that {{clear}} offers the best compromise. In summary, experimentation with the various clear templates is needed if interference exists in any browser. — Joe Kress 01:09, 15 August 2007 (UTC)

I want to say solar terms is a unique page. It has two big templates, followed directly by another table. None of them make way for one another. If you try another language template, it'll likely have the same effect. So {{clear}} is a good quick fix. Template:Chinese do stack with most templates. See Shenzhen article for example. I am open to any solution really. Benjwong 03:11, 15 August 2007 (UTC)

Heading

This template looks great - I know people have been working hard on it the last few weeks, and you've all done a fine job. I wonder, though, if there's any option to alter the heading, so it doesn't read "Chinese". Most of the topics I'm working on are not primarily Chinese topics, so it would be great to have a language template where Japanese, Vietnamese, or Okinawan can be the primary language listed, with Chinese coming later - in these cases, having "Chinese" as the header at the top of the template doesn't really work. This template could be quite useful not only for CJKV languages but also for all the world's languages - but in order to be used that way, the "Chinese" heading has to go. Thanks. LordAmeth 13:16, 18 August 2007 (UTC)

Yes, it doesn't make sense. I don't know why it was changed from the template Template:Chinesename, which reads "Chinese name" at the top, which is more logical. The color blue signifies it's a primarily China-related topic, purple is Korean. I believe the Chinese template ought to say "Chinese name" at the top rather than Chinese. Badagnani 14:18, 18 August 2007 (UTC)

Thanks; I agree with you that Chinese name is more logical than just Chinese, I guess. But actually, I was looking for a template which would allow the editor to choose the heading. I've been working on and off on various topics related to the Ryukyu Kingdom; I'd like to be able to represent the Chinese, Japanese, and Okinawan versions of the kingdom's name, but with Okinawan first (and most prominently), not Chinese. Even a neutral heading like "Native name" or "In other languages" would be preferable to "Chinese" or "Chinese name". I understand that this template is originally intended for Chinese usage, and I do not mean to be obnoxious or anything, but I just think it would be useful if the heading were more flexible. Unfortunately, I don't know much at all about template coding syntax, so I won't hazard to "be bold" and change the template myself. LordAmeth 23:07, 18 August 2007 (UTC)

Pretty much, if you are looking for a universal language template, there is none right now. This template displays mostly in alphabetical order. It so happens conveniently that Chinese began with a "C". You can certainly add Ryukyu and other languages using "Lang", though I agree it won't come first. Benjwong 17:54, 19 August 2007 (UTC)

North Korea

I've added a switch to the Korean name fields which can be used to adjust them to a North Korean context. To activate the switch, use northkorea=yes. This feature can be seen in Sino-Korea Friendship Bridge. PC78 03:34, 19 August 2007 (UTC)

Diacritics?

An anon user has removed diacritics from some of the name fields, stating that we "don't use them" in this template. Is this in fact the case? I can't see any discussion above or in the archived talk to support this claim. PC78 10:34, 8 September 2007 (UTC)

The editor also made a whole lot of other edits to the template, as you can see from the template's history. I don't know if there was a previous consensus to not use diacritics, but I assumed he removed it from the singular instance of usage because they were not used anywhere else on the template. Hong Qi Gong (Talk - Contribs) 17:18, 8 September 2007 (UTC)

diacritics are a bad idea, it hurts usability in parameter names. (unless you mean actual text, and not parameters?) 70.55.202.250 (talk) —Preceding comment was added at 22:02, 3 April 2008 (UTC)

Have some people got their priorities completely mixed up?

When I came upon this template at Nanking Massacre I almost balked. This is an infobox intended to present linguistic aspects of the name of the article, yet it takes on the guise of a general infobox in its full splendor! I find this horrible. I urge you to downscale the appearance of this template. I am going to AfD it if something drastic isn't done to accomodate this grievance. __meco (talk)

This template is designed to be both an general way to present the linguistic aspects of the name of the subject as well as take on the form of an infobox. If you wish to change this template, I suggest that you start a civil discussion and refrain from threatening to do this or that or demand that something be done immediately. nat.utoronto 19:18, 24 April 2008 (UTC)

Though I can sympathize with your reaction finding the announcement of an AfD a drastic measure, I am in earnest, and I do not think I am being uncivil. I contend that this infobox, as it takes shape in the article I mentioned, is a monstrosity. I stand aghast at its immodest layout and that it takes on the appearance of regular infoboxes. __meco (talk) 20:42, 24 April 2008 (UTC)

Can someone explain what the user means by downscale the appearance? Like change colors? Benjwong (talk) 19:37, 24 April 2008 (UTC)

The user means particularly the size, that is correct. If that change proves insufficient, I would consider looking at other features of its layout to make it less ostentatious. This may be a little "labour of love" that has gone somewhat amok, and I must hasten to emphasize that I find it very appealing. However, that's the problem. It steals the show, and an infobox outlining various spellings in different scripts should not be an article's main attraction. For one thing, there should be no image option in this template. That is way outside the scope of such a template. __meco (talk) 20:42, 24 April 2008 (UTC)

The box works well at articles for subjects such as Tofu, with similar names among many Asian languages. However, the colors are horrible and the fact that the romanizations are hidden is unnecessary and problematic. Badagnani (talk) 23:30, 24 April 2008 (UTC)

Actually, that example makes me even more convinced that this template is a bastard that needs to go unless the changes I have demanded are put into effect. This is not Wiktionary, and making an article present the spelling of the name the most prominently featured aspect of the article is significantly lowering its quality. __meco (talk) 03:30, 25 April 2008 (UTC)

TfD nomination of Template:Chinese

Template:Chinese has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for Deletion page. Thank you. — meco (talk) 13:42, 27 April 2008 (UTC)

Template was speedy kept. 70.55.84.13 (talk) 06:17, 28 April 2008 (UTC)

Hopefully you are going to do something about the issue which was the reason for my nominating the template. __meco (talk) 06:26, 28 April 2008 (UTC)

I have no problem with the template the way it is. Your suggestion would be that we create a wiktionary entry for every article, is it not? Personally, I think that _every_ article on Wikipedia should have a section listing what the topic is called in other languages. (And interlang links don't cut it, since those articles need not be equivalent, nor would they exist in every alternate wikipedia) Wiktionary won't accept such information for every article, since they're not always words. Such information is important, and encyclopedic, and will help people using Wikipedia for school work, or to look up references in foreign languages if they know what its called. 70.55.84.13 (talk) 06:41, 28 April 2008 (UTC)

If you'd actually be very clear and specific about which things you'd like to be changed (other than deleting the template), that would be great, because it would allow us to consider and make those changes. Badagnani (talk) 06:49, 28 April 2008 (UTC)

If you read my argument, you see that I do not object to any of the information being presented. I propose that this template is presented as collapsible auto-hide except for a title heading. __meco (talk) 07:03, 28 April 2008 (UTC)

I would have to oppose this, as the Asian names (as well as photo and caption) are crucial to the Asian-themed articles in which the names appear. Badagnani (talk) 08:05, 28 April 2008 (UTC)

What do general images related to the subject have to do in a linguistics infobox in the first place? __meco (talk) 08:40, 28 April 2008 (UTC)

I'm beginning to see that you have difficulty dealing with what you perceive to be irreconcilable items: in this case, a photograph and various names. That's fine; we all deal with our data in different manners. However, as you've seen from the discussion earlier today, other editors do not. In my opinion, at Chopsticks or Tofu I do want to know, in a single box, what the item looks like and how it is called in the nation that invented it (in this case, China), and the nations nearby that have related, or different languages (in this case, Japan, Korea, Vietnam, etc.). Badagnani (talk) 08:46, 28 April 2008 (UTC)

And as I've attempted to relay a couple of times already I do not (at least not for the time being, although I might want to take issue with that aspect as well) protest the availability of this information. It is the way in which is being presented that I so strongly object to. Anyway, I have invoked the attention of et wikiEn-L mailing list on this, so we'll see if some people who aren't completely entrenched can provide some fresh perspectives. __meco (talk) 09:48, 28 April 2008 (UTC)

I honestly don't understand what the fuss is about. I honestly don't really care, either. Johnleemk | Talk 10:03, 28 April 2008 (UTC)

I came to take a look after seeing the post on wikiEn-L, and I too honestly don't understand what the fuss is about. --Stormie (talk) 00:45, 2 May 2008 (UTC)

Question about showflag command

I like the template - it declutters things a lot but I have a question: if I get this right, showflag= will add a transliteration to the automatically displayed section. So showflag=p adds Pinyin, showflag=pj adds Pinyin and Jyutping. But for some reason I cannot get showflag=y to work to display Yale rather than Jyutping. Can anyone tell me what I'm doing wrong please? Thanks! Akerbeltz (talk) 14:39, 2 June 2008 (UTC)

The feature was hardcode added for a few of the commonly used flags. It cannot do all romanizations. Unless we find someone who can do it dynamically (if that is the word?) Benjwong (talk) 04:38, 9 July 2008 (UTC)

Adding MPS2

I would like to add MPS2 to the template section for Mandarin romanisations - this was the official romanisation in Taiwan from 1986 until the implementation of Tongyong Pinyin in 2000. It's still used in Taiwan from time to time and is also found in reference to events during the period of its official use. As an example, the government website of Jhonghe City, an article I am working on at the moment, is www.junghe.tpc.gov.tw - the spelling of the name is in MPS2.

Any thoughts/objections? Taffy U|T|E 11:20, 8 July 2008 (UTC)

Feel free. Please make sure it shows up in the document as well as under altname. Benjwong (talk) 04:38, 9 July 2008 (UTC)

Done. Thanks! Taffy U|T|E 04:46, 10 July 2008 (UTC)

This should be renamed

This template is terrific. But it is weird to have it be called Chinese when it is sometimes being used for showing the Korean and Japanese versions of a name. It should be renamed to Template:Multi-language name. 70.17.185.94 (talk) 18:27, 14 July 2008 (UTC)

Chinese is the primary name. It's not "multi-language" because the other languages are languages that are also from East Asia, many having some relationship with Chinese. Badagnani (talk) 18:37, 14 July 2008 (UTC)

POJ

The listings for "Min Nan POJ" should really be changed to "Hokkien POJ" as peh-oe-ji is only used for Hokkien (including Amoy, Taiwanes, etc.) and not for other forms of Min Nan. The romanisation for Teochew is listed under that name, although it is also a form of Min Nan - the same should be done for POJ. —Preceding unsigned comment added by 122.109.170.213 (talk) 00:44, 23 August 2008 (UTC)

Hindi

I tried to edit 'Indian name' to 'Hindi name', as several other Indian languages are also used with the template (like Tamil, Urdu used at Aksai Chin). I did an edit ([1]), but it still appears as 'Indian name' at Aksai Chin. How to do? --Soman (talk) 13:00, 10 September 2008 (UTC)

It appears as Hindi name ok. Your changes did work. Benjwong (talk) 04:47, 13 September 2008 (UTC)

Combined templates broken

Templates such as {{zh-stp}} do not work. They insert the three templates literally so that it reads simplified Chinese: {{{s}}}; traditional Chinese: {{{t}}}; pinyin: {{{p}}}. Please could someone have a look at this? Thanks, JRawle (Talk) 22:23, 14 February 2009 (UTC)

The template works fine. you just need to specify the character yourself when you use the template. if you just type {{zh-stp}} you'll see the variable tags, like {{{s}}}, come through. instead, you need to type something like {{zh-stp|s=简化字|t=簡化字|p=Jiǎnhuàzì}}, where the 's=', 't=', and 'p=' parts assign the correct character to the variable. wikipedia templates aren't smart enough to know which chinese character goes where on their own. --Ludwigs2 22:45, 14 February 2009 (UTC)

Thanks for the explanation. Now I see what I was doing wrong. I hadn't included the variable names. Is it now standard/preferred on Wikipedia to use variables in this way, rather than having arguments in a set order, e.g. {{zh-stp|简化字|簡化字|Jiǎnhuàzì}}? JRawle (Talk) 02:52, 15 February 2009 (UTC)

don't know if it's standard and preferred... using named variables has some advantages over positional variables, but there are times and places where positional variables are better. some templates even allow both. --Ludwigs2 04:15, 15 February 2009 (UTC)

Please fix this template

OK, I see that there's some history here. I've just wasted a good hour attempting to investigate exactly what's going on with this template, but honestly I don't really care. I see the nomination for TfD, which seems to be an attempt (misguided?) to address what I'm about to bring up here.

I don't have an issue with the purpose or the existence of this template. I can see it's usefulness, regardless of whether or not I personally find it useful. The problem is that the template takes over the entire article, in every article that it is included in!

I find it hard to believe that the authors of this template didn't/don't see the problem with it in it's current form. It seem blatantly obvious to me that there is an issue with it, but assuming that some people will not understand what the issue is please see the article Tiananmen Square protests of 1989. Compare that article prior to and after my simple edit commenting out the use of this template, please.

Ohms law (talk) 06:17, 12 June 2009 (UTC)

I simply reverted the last change made to the template and it seems to be fixed now. Incidentally the TfD you mentioned looks to well predate the current issue. -Amake (talk) 06:42, 12 June 2009 (UTC)

I also left a warning on the guilty editor's talk page. -Amake (talk) 06:48, 12 June 2009 (UTC)

Ah, I see... Thanks for clearing up the issue so quickly. Now I need to fix the Tiananmen article that I "fixed" previously (oops!) I think that the whole TfD "incident" caused me some confusion here. I hadn't really had any exposure to this template prior to tonight (that I know of, at least), so coming here and seeing that whole mess seems to have created some misconceptions on my part as to what was occurring here. Anyway, Thanks for correcting the problem. Ohms law (talk) 06:57, 12 June 2009 (UTC)

Move Gan and Hakka

I would like to propose that the romanizations for Gan and Hakka are placed later, below Mandarin. Reason due to standardization; the "most significant" or "largest", so to speak, should come first. Suggestions/comments? -- 李博杰  | —Talk contribs email 09:31, 23 August 2009 (UTC)

This is alphabetical order according to archived discussion. Someone just moved Yue to Cantonese so it does not appear to be in order anymore. Benjwong (talk) 17:29, 23 August 2009 (UTC)

I second the call for ordering the languages by "most significant" or by number of native speakers. Ordering alphabetically is counterintuitive and varies from one language to the next. This is compounded by the different dialects, names and spellings for each language (i.e. Mandarin/Putongua/Guoyu/Kuoyu/Beijingese/standard Chinese; Wu/Shanghainese; Yue/Cantonese; Min Nan/Hokkien/Taiwanese).

A proposed order by number of native speakers (grouped by language family) is: Mandarin, Wu/Shanghainese, Yue/Cantonese, Min Nan/Hokkien, Min Bei, Min Dong, Xiang, Hakka, Gan, Dungan, Burmese, Tibetan; followed by Engish, German; then Spanish, Portuguese, French, Italian; Arabic; Hindi, Bengali, Marathi, W. Panjabi, Urdu, Gujarati, Nepali; Russian; Japanese, Korean, Turkish, Uyghur, Mongolian, Xibe/Manchu; Javanese, Malay/Indonesian, Filipino/Tagalog; Telugu, Tamil; Vietnamese; Thai, Zhuang. This covers languages with over 50 million speakers, and some additional Chinese and southeast Asian languages. 75.150.168.6 (talk) 16:07, 9 July 2010 (UTC)

Protect this template

Administrator, please protect this template because the template is very difficult.

Triwikanto (talk) 00:37, 13 September 2009 (UTC)

Pre-emptive protection is a bad idea. The template is fine as it is. Chris Cunningham (not at work) - talk 01:39, 13 September 2009 (UTC)

Transliterations

There seems to be a problem where a transliteration will appear under the wrong heading. For instance, on the article on the Fuzhou dialect, the alternative name given in Min-Dong BUC appears under Mandarin instead of Min. For some reason, this problem disappears when the Hokkien POJ transliteration is also given, and doesn't affect Cantonese Jyutping. --Freelance Intellectual (talk) 18:09, 20 December 2009 (UTC)

 Done I think I fixed it. check a few other pages to make sure nothing else got goofed up in the process, please.

Alt text

I don't think it's currently possible to add alt text to images contained within this template. Would it be possible to add such a feature? —tktktk 01:33, 25 December 2009 (UTC)

can you explain what you mean by 'alt text', and what that might look like in the template? --Ludwigs2 01:36, 25 December 2009 (UTC)

Sorry, I should have elaborated a bit. I have no idea what the code would look like, but the result would be two parameters (something like |picalt= and |picalt2=), one for each of the two images that can be displayed with this template. They would simply allow alternative text to display when the cursor hovers over the images. —tktktk 06:44, 25 December 2009 (UTC)

so, for a transclusion on a page like Fish sauce which has a picture in it, you want to be able to add a tooltip? tooltips are what show when you hover the mouse over the picture (they go in the picture's 'title' key); alt text is what shows on non-graphical browsers in place of the image.

assuming that's the case, it shouldn't be too difficult to do - I'd just want to make sure that it could be done without mucking up the very large number of pages this template transcludes onto. let me take a look at it. --Ludwigs2 08:05, 25 December 2009 (UTC)

The reason I asked was that the featured article criteria asks for "brief and useful alt text when feasible". So I meant alt text, but since alt text apparently displays as a tooltip in some browsers I didn't realize the distinction between the two. Currently what's in the "|pictooltip=" parameter also seems to be the alt text (at least it shows up under "Alternate text" when I click on an image's "Properties" in Firefox), so evidently your change did what I wanted it to anyway. Thanks for your help. —tktktk 04:44, 26 December 2009 (UTC)

cool. glad I could help, even if it was a bit random. --Ludwigs2 04:51, 26 December 2009 (UTC)

labeling problem

At Zhou Dynasty, the IPA for the Mandarin is used. However, it appears under Cantonese, despite no Cantonese transcription being given. Is there no way to distinguish which language the "i" parameter encodes? — kwami (talk) 23:50, 21 September 2010 (UTC)

Zhuang name

I request that since we now have a Zhuang Wikipedia that the option to move Zhuang under the Chinese transliterations for non-Guangxi areas be allowed. The current format, which forces Zhuang outside of Chinese, is great for Guangxi, but if added to articles dealing with non-Guangxi areas, gives an implication that Zhuang is spoken in those areas. Yet I see few strong reasons not to include a Zhuang transcription. --HXL's Roundtable, and Record 01:11, 30 November 2010 (UTC)

Other than misleading people into thinking that Zhuang is Chinese? — kwami (talk) 07:17, 30 November 2010 (UTC)

well the flip side is that we would be misleading people into thinking that Zhuang is spoken in a particular area. I mean if people wish to seek further information then they should look into the Zhuang Language article... --HXL's Roundtable, and Record 11:28, 30 November 2010 (UTC)

Collapse feature and navboxes

This puzzled me: at the bottom of these two pages[2][3] we find the same navigation box on its own, but in the first one it's expanded and in the second it's collapsed. Why? Surprisingly, it's because the second one has this infobox at the top of the page.

Navigation boxes built with {{navbox}} default to showing the navbox if it is the only one on the page and collapsing it if there are more than one. However because this infobox is (optionally) collapsible, a navbox at the bottom of a page with this infobox at the top will be collapsed, which is surprising and, I think, unfortunate. Kanguole 23:26, 29 January 2011 (UTC)

Correcting the template's code (1 variable {{{my}}} for Mandarin Yale and Burmese)

This template's code needs to be updated to reflect that the variables for the Burmese name and the Mandarin Yale romanization are different, as they are currently one and the same ({{{my}}}). And all of the articles that use this template need to be updated to reflect this.--Hintha(t) 23:12, 30 June 2011 (UTC)

Get rid of fields under Japanese name

The current layout looks like this. It's bloated. Parameter bloat considered harmful.

 Japanese name
 Kanji	{{{kanji}}}
 Kana	{{{kana}}}
 Hiragana	{{{hiragana}}}
 Kyūjitai	{{{kyujitai}}}
 Shinjitai	{{{shinjitai}}}
 Transcriptions
 - Romaji	{{{romaji}}}
 - Revised Hepburn	{{{revhep}}}
 - Traditional Hepburn	{{{tradhep}}}
 - Kunrei-shiki	{{{kunrei}}}
 - Nihon-shiki	{{{nihon}}}

We don't need every field under the sun here. For example, the oft-used nihongo template only has English name, kanji, and romaji. No one ever uses multiple romanization fields, because that would be pointless. We can get rid of that show/hide control and the Transcriptions header row for a group of fields that are never going to be more than one. On top of that, per Wikipedia:Manual of Style/Japan-related articles, we only use Revised Hepburn. Keep the romaji field (the one people actually use), and get rid of all the other romaji fields. Remove the show/hide control which adds to bloat and clutter, and requires unnecessary user interaction. I don't see the need for a hiragana parameter either when we already have a kana parameter. That just leads to unwanted parameter bloat. Arguably we could get rid of both hiragana and kana, but since we have a tabular structure, we can afford extra space.

Proposed new structure (version 1):

 Japanese name
 Kanji	{{{kanji}}}
 Kana	{{{kana}}}
 Hiragana	{{{hiragana}}} <!-- deprecated -->
 Kyūjitai	{{{kyujitai}}}
 Shinjitai	{{{shinjitai}}}
 Romaji	{{{romaji}}} <!-- assumed to be Revised hepburn without stating so, per WP:MJ -->

Version 2. This would require a bot to convert hiragana fields to kana fields:

 Japanese name
 Kanji	{{{kanji}}}
 Kana	{{{kana}}}
 Kyūjitai	{{{kyujitai}}}
 Shinjitai	{{{shinjitai}}}
 Romaji	{{{romaji}}}

For the set of parameters, I realize that the ver. 1 set and ver. 2 set both appeared in July 2007. Of course we want the newer style and template programming (except for the unnecessary transcription hiding), but revert to the more reasonable set of parameters.

Alternate Proposal (Version 0). This is a bare minimum effort approach to improving the Japanese name section. Deprecate multiple fields and disable transcription hiding for Japanese (what is being hidden takes up the same amount of screen real estate as the show/hide control itself).

 Japanese name
 Kanji	{{{kanji}}}
 Kana	{{{kana}}}
 Hiragana	{{{hiragana}}} <!--deprecated. use kana instead. -->
 Kyūjitai	{{{kyujitai}}}
 Shinjitai	{{{shinjitai}}}
 Romaji	{{{romaji}}}<!--use Revised Hepburn romanization here. -->
 Revised Hepburn	{{{revhep}}} <!--deprecated. use romaji instead. -->
 Traditional Hepburn	{{{tradhep}}}<!--deprecated. use romaji instead. -->
 Kunrei-shiki	{{{kunrei}}}<!--deprecated. use romaji instead. -->
 Nihon-shiki	{{{nihon}}}<!--deprecated. use romaji instead. -->

Aside: is there a way to annotate parameters as deprecated? If not, it would be a nice feature request to make. --Bxj (talk) 08:48, 13 September 2011 (UTC)

That was too hard hitting as plenty of it is used and that MoS stated that there are exceptions. By default all romanizations and transcriptions are hidden, unless it's specified with a flag in the code per case basis. People should follow the MoS when applicable, but those are hardly deprecated. Anyway, put a comment at the documentation referring to the MoS. Cold Season (talk) 18:54, 29 October 2011 (UTC)

I strongly disagree. There should be only one romaji field. You didn't touch on most of the reasons for applying the changes, however I do appreciate you expressing your suggestions. One problem with having multiple fields when one suffices is that it adds unnecessary clutter and complication for both the editor and reader. Modified Hepburn romanization can cover 99.99999999% of the cases for use in Infobox Chinese, however it should be possible to note exceptional cases with one romaji field even when there are needs to mention other romanizations. We don't need every field under the sun here. For example, the oft-used nihongo template only has English name, kanji, and romaji. No one ever uses multiple romanization fields, because that would be pointless. We can get rid of that show/hide control and the Transcriptions header row for a group of fields that are never going to be more than one. On top of that, per Wikipedia:Manual of Style/Japan-related articles, we only use Revised Hepburn. Keep the romaji field (the one people actually use), and get rid of all the other romaji fields. Remove the show/hide control which adds to bloat and clutter, and requires unnecessary user interaction. I don't see the need for a hiragana parameter either when we already have a kana parameter. That just leads to unwanted parameter bloat. Arguably we could get rid of both hiragana and kana, but since we have a tabular structure, we can afford extra space. Please consider discussion before changes as a matter of practicality. --Bxj (talk) 20:40, 29 October 2011 (UTC)

I see that you have reverted it placed your changes in again. I should note that this template is in use on many pages and the statement: "If your edit causes unexpected problems, please undo it quickly, as this template may appear on a large number of pages." Thus, I was not wrong to undo it quickly, since your changes had affect on many inputted info. It is not up to you to decide what transcription or script gets used, what is deprecated, and whatever transcription should be unhid over others. Rather strange to state that "we can afford extra space", are you selective on what it applies to? If you seriously plan to defend your changes I or, better yet, you will notify the WikiProjects involved, as this widely-used template is watched by only a minor fraction of people, as this chunk of code removal is definitely not minor. Which I also rather find quite contradictory to what you are saying, since you didn't consider discussion before huge changes as as you didn't notify anyone also involved. I wonder why with such huge changes and 30 or less active watchers. Cold Season (talk) 20:56, 29 October 2011 (UTC)

I placed a message to the talkpages of the first few of those involved projects by now. Cold Season (talk) 22:35, 29 October 2011 (UTC)

Some obvious observations that I can make: "I see that you have reverted it again." Actually, there is no "again" on my part. Please don't mistake me for you. I only reverted your edit once, which you did so without any prior discussion (and adding something to the talk page, not waiting for a reply, and proceeding to make that edit on the same day doesn't count as prior discussion -- that's just insincere).

An idea is bots. We can fix the template usage as needed by tasking a bot to batch modify the parameters in the articles. In the multi-step changes that I propose, we're still working towards version 1 now. If you care for the reasonings behind this proposal or are otherwise interested, we could discuss bot application as the next logical step... --Bxj (talk) 22:54, 29 October 2011 (UTC)

Some more replies to your comments:

Rather strange to state that "we can afford extra space", are you selective on what it applies to?

I am saying that the status quo (which you seem to prefer) is taking up wasted space, but we can afford to keep taking up that extra space, at least in version 1 as a means of compromise. I'm sure you understood the context in which I used this phrase since I stated it very clearly, however I'm no sure what you are objecting to here. If we were to actually touch upon the reasonings for the proposed cleanup for a second here, don't you think it's rather redundant for us to have BOTH kana and hiragana parameters? When would simply having kana not suffice? This clutter doesn't sound like a good idea.

If you seriously plan to defend your changes I or, better yet, you will notify the WikiProjects involved, as this widely-used template is watched by only a minor fraction of people, as this chunk of code removal is definitely not minor.

I guess I need to seriously defend if there are people who are seriously attacking, and extra seriously defend if there are people who are extra seriously attacking and so on... However, keep in mind that the status quo sucks, and we wouldn't have the status quo if it weren't just slipped into the template without proper deliberation. I gave more than a month for feedback, so that's not nothing. But yes, I am interested in hearing opinions from more than one other user.

Which I also rather find quite contradictory to what you are saying, since you didn't consider discussion before huge changes as as you didn't notify anyone also involved. I wonder why with such huge changes and 30 or less active watchers.

Again, you're just blocking something from your mind that's obvious, and I'm not impressed with that. The is the fact that I waited for more than a month after my edit proposal before proceeding, as you can see in this discussion section. Unlike your repetitive reverts, or the author who added the bloat in the first place, I've waited more than a month. Just saying, for the sake of perspective.--Bxj (talk) 23:22, 29 October 2011 (UTC)

Sorry for your displease or frustration at my wording, no, I'm clear in mind. I don't agree with unhiding or removal of transcriptions. And what if the bot stumbles on several transcriptions? It's per case basis. --Cold Season (talk) 00:40, 30 October 2011 (UTC)

I see no advantage to the changes, and great loss of flexibility with it. The fields are hidden. If you don't like it, they don't appear anyways. 65.94.77.11 (talk) 06:13, 30 October 2011 (UTC)

Isn't this a template where there might be additional benefits to having extra Japanese fields for cross-culture items. Even if the fields are not used in Japan today, isn't the more parameters better? Pinyin and Jyutping covers 99.99% of the scenarios. But extra fields supporting that .001% make this template helpful. Benjwong (talk) 18:30, 30 October 2011 (UTC)

@65.94... Depends. Is this flexibility that is useful for any legitimate use cases? The hidden issue makes it a bad user experience. You have to click through to view just one additional line. The show/hide interface takes up additional line, thus not saving screen real estate, just requiring a click-through. @Benjwong if it requires a show/hide widget, then it's not that great, and it's stuff that could be said in "romaji=" anyway. E.g. "romaji=(Nihon-shiki) Kaibutu" although I can't really think of a common or uncommon reason why this would be needed. Unlike other languages, there is very little that could be lost by going with the standardized Modified Hepburn romanization. Heck, we even throw in kana / hiragana, which is more than the commonly used Template:Nihongo offers. --Bxj (talk)

I can see how the "Transcriptions [show/hide]" widget can come in handy. For example, for Hong Kong, we have:

   Transcriptions    [hide]
   Hakka
   - Romanization	Hiông-kóng
   Mandarin
   - Hanyu Pinyin	Xiānggǎng
   - Wade–Giles	Hsiang1-kang3
   - IPA	[ɕjáŋkàŋ]
   Min
   - Hokkien POJ	Hiong-kang
   Wu
   - Romanization	shian平kaon上
   Cantonese
   - Jyutping	Hoeng1gong2
   - IPA	[hœ̂ːŋkɔ̌ːŋ]
   - Yale Romanization	Hēunggóng

This makes sense for Chinese, since it's a very large and diverse country. However, let's consider Japan, to see if the same hammer is really appropriate for applying everywhere. How many ethnicities are there? One. How many governments are there? One. How many languages are there? One. (I'm simplifying here a bit. There is Ainu language, which has less than 15 people.) So, the same needs doesn't exist. To have a laundry list of parameters. Definitely not long enough to necessitate a show/hide widget either. And the fact that this is Template:Infobox Chinese makes parameter bloat for Japanese even more ridiculous. --Bxj (talk) 01:37, 2 November 2011 (UTC)

It is consistent, if someone wants to show a transcription and it's really needed (can't think why), they should use the flag for that option. Neither are they unhidden when it's just one filled in. And those parameters are precise, same could be said about removing pinyin and wade-giles and just put "Mandarin romanization" for simplification (since Romanji is Japanese romanization) and let people figure it out themselves. --Cold Season (talk) 02:27, 2 November 2011 (UTC)

So you're suggesting that we should take up article real estate with a show/hide control and hassle the user for one row of romanization "just because?" To quote what you said: "And those parameters are precise, same could be said about removing pinyin and wade-giles and just put "Mandarin romanization" for simplification" I think you missed the point here. Your devil's advocate example is problematic because there are two separate political entities called PRC and ROC, and they use different currencies, historical developments, Chinese characters, and romanization systems. Japan has one political entity. I'm amazed that you missed this argument that I mentioned in the very comment to which you responded to. --Bxj (talk) 14:09, 8 November 2011 (UTC)

No, not just because, I've given the reason... / I haven't missed it. This romanization use is not restricted to Japan, and other romanizations can and are commonly used in English, and can be romanized with different systems in different literature. Cold Season (talk) 00:54, 9 November 2011 (UTC)

Actually, I'm speaking about Modified Hepburn romanization which is used exclusively for Japanese. The modification I am proposing is restricted to Japanese. Sorry if I confused you into thinking this was about changes that could affect documentation of Chinese words.--Bxj (talk) 01:48, 9 November 2011 (UTC)

That narrows it down to the use of one target group on a widely-used template, against what is or are possibly commonly used romanizations. Cold Season (talk) 02:42, 9 November 2011 (UTC)

Look at articles like Qiang an old weapon. It uses two romanizations that would have been considered to be deprecated according to Bxj. So is it really not in use? It looks in use to me?? Like someone researching from colonial documents for example will be using wade giles, yale without knowing it. Could it be that 1% is looking up traditional hepburn and not know it. Benjwong (talk) 06:24, 2 November 2011 (UTC)

You're really determined, aren't you? Look, you can throw examples to death. I've already explained what we could do with edge cases, which is to add additional explanation. This is pretty true with any template for anything anywhere ever. And I really don't see why we can't just have one romaji field for Infobox Chinese Japanese in the one specific example that you gave, Qiang. Theoretically, exceptions can exist where additional explanation is needed as a result of field consolidation, but Qiang is not that example. So, I don't get what the strong opposition is about yet.--Bxj (talk) 14:09, 8 November 2011 (UTC)

Romanization is like a pronunciation guide in a dictionary. It's a nice-to-have, but you don't need multiple of them. Chinese is an exception because China+Taiwan is multi-ethnic, multi-lingual, and multi-political resulting in hard-core differences, requiring multiple romanizations. Japan is homogenous in comparison. They're apples and oranges.--Bxj (talk) 14:23, 8 November 2011 (UTC)

A "pronunciation guide" that is written in Latin letters. Historical accepted spelling differ at times and there can also other preferences in spelling. Cold Season (talk) 00:54, 9 November 2011 (UTC)

This wasn't a reply to your comment, but I'm sorry you didn't like my analogy. I thought it was reasonable, anyway. Wiktionary, for example, has IPA for pronunciation guide of English words. It doesn't incorporate various incompatible pronunciation guides used in various dictionaries, because that would be pointless. Do you even work on Japan-related articles much? Does this even matter to you? I don't get it. I'm going to look for input from editors who actually make major contributions to Japan-related topics. After all this section discussion is about Japanese. --Bxj (talk) 01:48, 9 November 2011 (UTC)

You're on Template:Chinese, not Template:Nihongo. This template is to aid in including MORE information than the inline transcription templates provide. 70.24.248.23 (talk) 05:58, 11 November 2011 (UTC)

Indeed. The Nihongo template is the most common language template used on Japanese articles, which is why I provided as an example. Wikipedia articles specializing in Japanese culture do not mention multiple romaji, and neither does Wiktionary, e.g. http://en.wiktionary.org/wiki/槍 However, as a middle ground I concede that a good example and/or argument for having multiple romaji fields can "theoretically" exist, I just haven't seen one yet. By the perceived rarity, handling those rare "theoretically existing" ones by tacking on additional notes in the article should suffice, while the general structure of the template could cater to the average use (i.e. by only having one romaji field). Note that multiple romaji fields were originally tacked on without any deliberation, so it shouldn't be surprising that a well-rounded consideration wasn't made. In addition, you shouldn't require users to show/hide transcriptions for languages that provide only one transcription. There is literally no benefit given to the user, while at the same time requiring the user to click and expand on something that did not have to be hidden in the first place. I'm looking at current Korean and future Japanese sections.--Bxj (talk) 16:43, 12 November 2011 (UTC)

User:Bxj would do well to keep his comments more professional. Not doing so tends to engender acrimony, not cooperation. That being said, I support his proposal to remove the deprecated fields. The multiple romaji fields seem particularly unnecessary. Someone gave the example Qiang (spear) - the Japanese usage there is redundant given the wikilink to Yari.  White Whirlwind  咨  07:51, 11 November 2011 (UTC)

This discussion seems to have died down. I haven't seen any good counter-arguments despite calling for them. Applying the recommended changes could be postponed as homework for the future, once we feel like being productive again. --Bxj (talk) 16:26, 24 December 2011 (UTC)

{{{i}}}

Quite a few articles were using {{{i}}} for any ol' IPA, often for Mandarin. Since it's just a historical leftover, I changed it to {{{ci}}} (parallel to {{{mi}}}), and also changed Burmese from {{{IPA}}} to {{{bi}}}. {{{i}}} is no longer supported; I'm switching the articles over now. — kwami (talk) 03:06, 25 January 2012 (UTC)

It would be nice to have multiple fields for Mandarin IPA just as Cantonese IPA does. Shrigley (talk) 19:29, 17 February 2012 (UTC)

"Favored Romanization"

I disagree with the addition of a required "Favored Romanization" field so prominently in the infobox.[4] First of all, the capitalization implies that "Favored Romanization" is some type of romanization scheme that we can use on all Chinese characters, when it is not. AlanbirdVIEW added this for Jeremy Lin, who apparently uses some ad-hoc romanization for his Chinese name. He asserts that "Most of time, romanized names differ from their original pinyin or WG or Jyutping", but in my experience, Lin is the exception rather than the rule. If the subject of an article "favors" some arbitrary romanization other than the overwhelmingly common international standard or the old common standard, then that romanization already appears prominently in the title and article. (It could also be entered in the "title" parameter of this infobox) This is a infobox for Chinese-language terms — not English — and for the Chinese characters' clearly defined, consistent, and duplicatable romanization systems. It does not usually serve as an infobox for the subjects, which are {{Infobox Person}}, etc. Shrigley (talk) 19:29, 17 February 2012 (UTC)

I, myself, have added this "Favored Romanization" with the all critical reasons for it:

1. Better connection between original Chinese name and English used by such person
2. Among all types of phonetic systems (Mandarin, Cantonese, Min,...) pronouced,a highlighted "Favored Romanization" (not sure if use this title) give the clear idea which type of romanization is selected and used formally in his/her daily life
3. The function of the Infobox Chinese is mainly for Western readers to gain deeper meaning of Chinese, in conjunction of such written form in English, I think this is a nice and the best way to do so
4. Put respect and accuracy to the persons and the articles: * Such as: Jeremy Lin (Shu-How) 林書豪 using "How" in lieu of "Hao", Chien-Ming Wang 王建民 replaces "Min" with "Ming"...and many you can tell as well, some of them use alternative words for original ones (the rules, the standards), but still all of them are recognizable and fully legal.
5. Add it only if you need it: Since this additive function will appear only if you make this newly-defined {{{e}}} active by adding it with text. This means one more option available without making structural damage!

My final suggestions are:

• Leave this [Favored Romanization] alive and ask for more talks
• The title, for not to confuse, is so welcome to change as another more suitable one,

such as: [Favored romanization], [Favored in English], [Personal romanized],...

• No hard feeling, revision/removal are expected, all of us are committed to a better Wikiplace, aren't we?

Thanks for your dedication and time!! I like the way YOU are ^^

alanbird (talk) 21:14, 17 February 2012 (UTC)

Regarding your points,

1. If a person uses some nonstandard romanization for their Chinese name in English, then it will already appear, repeatedly, in the title and text of the English-language article. The purpose of the {{Chinese}} template is to render a Chinese-language term, which means Chinese characters and some auxiliary systems to aid in pronunciation. The purpose of this template is not to show some person's English-language name, which is already accomplished with {{Infobox Person}} and other more appropriate templates.
2. See above. We don't need to "give the clear idea which type of romanization is... used formally in his/her daily life" because any romanization that the person uses will appear in the title and repeatedly in the article text.
3. It doesn't help anyone to get a "deeper meaning of Chinese" to promote arbitrary transcriptions to the level of well-known and standardized ones. With some study, anyone can learn how to pronounce "Shūháo", but "Shu-How" is a complete black box.
4. See above.
5. You didn't make the "e" option "add it only if you need it". The articles that I pointed out, such as tofu and Yellow River output "Favored Romanization: {{{e}}}" even though there was no change to those articles since your edit.

Please read {{Intricate template}}, which appears on the main template page. This template affects a large number of pages, and it caused unexpected problems, so you should be undoing it, conducting tests, and asking for help instead of fighting to keep this controversial change. Shrigley (talk) 21:59, 17 February 2012 (UTC)

User:ASDFGH has hidden the option where it is not used, which is progress. However, I am not convinced that we need this option at all. You are mistaken that Cantonese, Min, etc. cannot appear prominently with the current template. The "showflags" option allows you to put established romanizations on top: see how the infobox on Guangdong elevates Jyutping, Cantonese Yale, and pinyin. This is about adding English language renderings, not Chinese romanization to a Chinese language template. Shrigley (talk) 22:23, 17 February 2012 (UTC)

Thanks for your comprehensive explanation and examples given herein!

Before make it concluded, I'd like to stress the following:

• I only made one-time revision [18:47 17 February 2012] (51,647 bytes)

  It's my first time & only revision I've ever made, the rest of followed-by revisions were actually only "undo" from your reverts. Before submitting it, I've done all necessary tests and checks for each alternations. I found nothing to do with the conflict you mentioned above so-called "Favored Romanization: {{{e}}}"

• However, I DID observed a couple of similar situations occurred on Tofu, this Template:Infobox Chinese page while User:ASDFGH were doing continuous updates afterwords; but returned normal later.
• I'd believe neither ASDFGH nor myself screwed it up, instead, a temporary inconsistency between template database change (it happened before) caused this issue, I guessed.
• Understood all your points, but I do believe, on the other hand, the way I created is acceptable and complied with all wiki standards and guidelines.
• I DID read and understand the "showflags" function as an alternative to so, but I had strong belief that such personal used romanization shall be classified as a unique field as well

Since no further users have given their comments, while the current hidden option, harmless revision has made (thanks to ASDFGH), I think it's better to keep it there and stay where we are unless more ideas to come.

alanbird (talk) 01:47, 18 February 2012 (UTC)

DO NOT CHANGE WITHOUT TALKS!

Unfortunately, Shrigley, you DID reverted it into a negative term "nonstandard romanization" by your own will/without further notice/compromise. Can you image that how bad it looks like? (see pic)

Why "nonstandard" has to be associated with Jeremy Shu-How Lin 林書豪? He has nothing to do with your so-called "nonstandard romanization"!! "Shu-How" has been part ot Lin's full legal name in the U.S. as long as he was born to honoring God! It is not consistent wtih standard romanied systems, while pinyin/Wade–Giles' spell "Shu-Hao", but doesn't mean it has to be entitled "nonstandard"!!

To better settle down:

• I have switched back the original term I first uesd, but de-capitalized as "favored romanization", which I agree with you to avoid any mislead. And it is the only one I will accept before further agreement.
• "favored romanization" is re-linked to Romanization of Chinese's sub title: Other transcriptions, and I may add more content on it to approve these personal/custom needs.
• Some other alternative terms, such as: personal romanization, custom romanization, personal romanized use... I'd consider more suitable to replace with if more people come for the discussion.
• I will invite others to talk and make it done! Before this, no one ought to do any further revision since this added {{e}} parameter has not harmed to or changed Infobox Chinese template's versatility/flexibility or affect to other linked articles. (actually it gives more clear idea how "standard" unable to apply to all)
• Respect others and self!

alanbird (talk) 05:06, 1 March 2012 (UTC)

Agree with Shrigley on all the points. Alan you seem to have a lot to learn about what Wikipedia is and isn't. (And you have to earn your respect.) Your edits to Jeremy Lin has turned in into WP:FAN. "Favored romanization" has no place in Wikipedia, especially the fact that one who is given at birth is no romanization at all. HkCaGu (talk) 17:26, 1 March 2012 (UTC)

"Tang reconstruction"

Readers may have noticed User:Dcattell's recent adds of "Tang reconstruction" across various China articles, and I'd like to give him a chance to explain his reasoning and the sources he is relying on. I am highly suspicious of these changes, and I think I know which sources he's citing, but I think he deserves a shot at explaining his methodology for distinguishing Tang reconstructions from EMC. I of course WP:Assume good faith here.

Personally, I think the distinction between Tang and EMC is artificial in most reconstructions, as there's so little data to rely on in the first place. I almost never give even Early Middle Chinese and Late Middle Chinese distinctions here on Wikipedia, since the most obvious differences are simply the merger of the zhuang 莊 and zhang 章 initial series into the zhao 照 and the labiodental developments in the 3rd division hekou rhymes. There are more distinctions, to be sure, but they're not mentioned nearly as often, as far as I've ever learned.  White Whirlwind  咨  23:08, 1 June 2012 (UTC)

Unrelated, but I wanted to note this. Whether it this distinction will be kept or not, 'Tang reconstruction' does not appear under the 'Middle Chinese' section as seen here [5] and should be corrected. --Cold Season (talk) 00:25, 2 June 2012 (UTC)

The basic problem which I think needs addressing is that according to our (that is, en.Wikipedia's) article Middle Chinese:

Middle Chinese can be divided into an early period, generally called Early Middle Chinese (EMC, c. 5th–7th century AD), and a later period, Late Middle Chinese (LMC, c. 10th–12th century AD). EMC is usually connected with the Sui dynasty and early Tang dynasty rime dictionaries, especially the Qieyun (601 AD), while LMC is usually connected with Song dynasty rime tables, especially the Yunjing (c. 1150 AD).

This leaves a major gap from 601 AD to 1150 AD (basically covering almost the entirety of the Tang dynasty and its immediate aftermath). This gap is not resolved by just calling reconstructions "Middle Chinese", because we have three categories: EMC, LMC, and "Middle Chinese" -- but "Middle Chinese" in this case can refer to EMC, LMC, and the gap in between, a rather ambiguous situation. Of course, maybe I give to much weight to consistency on Wikipedia, but there does not seem to be a consistency between sources on the definition of "Middle Chinese" is problematic. For example, I believe that Karlgren would considered what we are calling "EMC" here to be part of "Ancient Chinese", and "Middle Chinese" to only properly begin with the Song rhyme tables. "Tang reconstruction" as a category may well not be the best solution, but would fill a gap between "EMC" and "LMC" in terms of chronology, although not necessarily of much phonological value. I think the big phonological issue here is the major change in terms of distinctions based upon syllabic medial glides and final consonants versus the phonology of tones in the modern sense. Although the actual time and geographic framework of this seems to be currently rather uncertain, using "Middle Chinese" to cover both the former and the latter phonological systems under one umbrella (and then to label one "EMC" and one "LMC" with a big gap in the middle) seems especially problematic. I think a general solution might be found with a bit of work, for example by clear reference citations in relevant articles, for example Middle Chinese, Mandarin Chinese#Old Mandarin, and so on (maybe Historical Chinese phonology best to start with?), and then making the template categories consistent with whatever terminology this process supports. Dcattell (talk) 01:48, 2 June 2012 (UTC)

I'd advise against necessarily looking at what Wikipedia currently has for guidance on these matters, as it can be misleading, especially where articles aren't fully fleshed out yet (as is the case in a number of Chinese historical phonology articles). EMC is basically a term that encompasses Qieyun-Guangyun Middle Chinese, which covers just about all of the Tang. LMC is basically rhyme table (Yunjing, etc.) Chinese, which is Late Tang and Song. Baxter (1992) 1.2.5 gives a brief synopsis and is pretty tame. Remember, descriptions of EMC as 5th–7th century AD and LMC as 10th–12th century AD are not saying that the 7th-10th centuries were unknown, they are simply describing the general time periods where differences are apparent. The distinction of Middle Chinese into only two parts (an overly simplistic view that was basically introduced by Karlgren's groundbreaking but flawed work) is extremely problematic in practice – it persists just because it makes things easier to think about.

Your term "Tang reconstruction" is embraced in the term EMC for non-technical purposes (a.k.a. Wikipedia). A separate designation is not needed and would simply clutter things up; additionally, current scholarship sticks to the previously mentioned terms. If anything needs to be changed, it is the time references in the Middle Chinese article, which, as we have seen, are currently misleading lay readers.  White Whirlwind  咨  02:55, 2 June 2012 (UTC)

Yes, often less is more: just adding another category to the template is not per se helpful, and indeed may increase the cruft/clutter. The question of chronological categories from what I can tell remains open: do they have merit or not? Avoiding "what Wikipedia currently has for guidance on these matters, as it can be misleading" seems to be a major problem here, one which I have perhaps been doing. In regard to, "the time references in the Middle Chinese article, which, as we have seen, are currently misleading lay readers", I'm sorry that this would take some time for me to figure out on my own; but, which time references seem to be misleading lay readers? Dynastic? Common Era? All? How are they misleading? Is it because there was a continuum of phonological processes punctuated by a few surviving rhyme books, inconveniently located in terms of other timelines? Dcattell (talk) 05:25, 2 June 2012 (UTC)

As White whirlwind says, EMC essentially designates the system of the Qieyun dictionary and its redactions, while LMC refers to the system of rhyme tables like the Yunjing. As you suggest, the gaps in the periodization are gaps between the materials available to us. Chinese is obviously not like say Greek where you have a long continuous record of alphabetic writing with spellings varying as pronunciations gradually evolve, and division of that continuity into periods is somewhat arbitrary. Between these comprehensive descriptions of Chinese pronunciation, there is only fragmentary evidence (foreign transcriptions, rhyming practice, etc).

Both of these systems seem to be artificial constructs rather than descriptions of the speech of some community. Karlgren thought the Qieyun (EMC) reflected a Tang standard, but it is now believed to reflect a compromise between northern and southern practice in reading the classics in the late Northern and Southern dynasties. Its distinctions were doubtless real, but not all made by any single speaker. The rhyme table system (LMC) reflects sound change, but also the Qieyun tradition, and it's difficult to disentangle the two.

There are several romanizations of what we call EMC, and this "Tang reconstruction" seems to be one of them. Despite the superficial differences, they all reflect the same data. "Ljɨ Bɐk" looks very different from "Lǐ Bhæk", but they're different spellings for the same pronunciations of the characters 李白 given non-alphabetically in the Qieyun. The "Tang reconstruction" seems to use the same diacritics as modern pinyin for the rising and departing tones, and "bh" etc for voiced initials, reserving "b" for unaspirated voiceless initials (as modern pinyin does), and there are different notations for the vowels. That's perfectly reasonable, but a surface difference only. "Tang" is a bit of a misnomer in light of the current view of the Qieyun system, though it's undoubtedly close.

For the same reason, the |mc=, |emc= and |lmc= fields ought to state which of the many transcriptions they're using. Kanguole 09:06, 2 June 2012 (UTC)

I am not an expert on the linguistic reconstruction of the historical phonology of Chinese language, and only have limited reference resources in this regard. However, even if I were a world class expert with a huge collection of specialized journals, I doubt that the EMC-LMC distinction is particular useful for this template, or Wikipedia in general. In fact, the EMC and LMC terms do not appear as major distinctions in the references which I have consulted. The distinction between the Qieyun and the Yunjing (and Qiyinlue) seems to be one largely of format (rhyme table) and better presentation of information based on a more sophisticated understanding of linguistics (although acknowledging the existence of an important dialectical shift occurring in late Tang): however, linguistic study of these works does not seem to have given rise to any more than minor dialectical differences as indicated by those two sources. I have not seen a reference source with a thorough presentation of EMC or LMC reconstructions, only Middle Chinese, with a few notes on minor changes or variants within Middle Chinese . The term "Tang reconstruction" can be better defended: it seems that the Qieyun is "the primary source for Middle Chinese" (Jerry Norman:1988, Chinese, page 41). The oldest surviving copy of Qieyun seems to be Wang Renxu's, from the Tang dynasty. Thus, to put it perhaps over-simplistically, Middle Chinese = Qieyun = "Tang reconstruction". Thus, it would seem that the template code for "Tang reconstruction" is redundant (though accurate enough). However, the equation that Middle Chinese = EMC + LMC seems to be misleading, and poorly and vaguely defined. So, I'm eliminating the "trc" code, and may address the issues raised here through fixes in the Middle Chinese article. Dcattell (talk) 17:43, 2 June 2012 (UTC)

If you're looking at Norman, the second half of page 24 relates the current consensus I mentioned, with more detail on the next page. Karlgren's view that the Qieyun describes the standard speech of the Sui-Tang capital Chang'an, which can therefore be reconstructed from it, is no longer seriously entertained. Not only is it not Tang (or Sui), but it doesn't describe a single variety to be reconstructed. Hence Baxter insists that his transcription for MC is not a reconstruction but a convenient notation for the Qieyun categories. Kanguole 00:02, 3 June 2012 (UTC)

You're correct in saying that Early Middle Chinese is probably more accurately termed "Tang Dynasty Chinese", but unfortunately that isn't the common practice in the reliable sources. And, again, you have be careful with just going off of the Qieyun and Wang Renxu Tang dynasty connection – the text of the Qieyun has only partially survived, and 99% of the citing of it is actually just the later Guangyun, and the earliest extant edition of that dates to about 1000. The whole business is a mess. As far as I know, Stimson and Pulleyblank are the only scholars that would dare to explicitly use the term "Tang Chinese" in their reconstructions. I think User:Kanguole's idea is a nice one – maybe fields could be added under Middle Chinese for particular reconstructions? The main ones in use in English sources are, as far as I know, Baxter, Li Fang-kuei, and Pulleyblank. In Chinese I think it's mostly still Wang Li but increasingly Baxter and Zhengzhang Shangfang.  White Whirlwind  咨  20:50, 2 June 2012 (UTC)

Note that Pulleyblank asserts that LMC represents the standard variety of the High Tang. He has produced a dictionary of both EMC and LMC transcriptions, which is as usual for his work highly influential but not widely accepted in detail, so not very suitable for our purposes. Kanguole 10:45, 3 June 2012 (UTC)

Vietnamese

There have been three scripts used in Vietnam:

• Chinese characters (chữ Hán or Hán tự), recording Literary Chinese (chữ nho) for administration scholarship and formal literature up to the early 20th century.
• a script (chữ nôm) combining Chinese characters and local creations, used for folk literature in Vietnamese up to the early 20th century.
• the Vietnamese alphabet (quốc ngữ), the standard script for Vietnamese since the early 20th century, and now used for everything.

So why do we have five fields? In particular, |vie= and |qn= seem to be the same thing, and |hn= (Hán–Nôm) seems to be a conflation of |hantu= and |chunom=. Kanguole 00:27, 30 May 2013 (UTC)

I have reverted the deletion of |hantu=, which is used on dozens of articles (though maybe it should have been called chuhan). I think the parameter that should be removed is |hn=, which mixes two scripts, losing information. Further, it's inappropriate to apply {{vi-nom}}, described as "for the markup of text written in Nôm, a Chinese-style script formerly used to write Vietnamese", to names taken from texts written (in Vietnam) in Literary Chinese. Kanguole 09:40, 30 May 2013 (UTC)

I suggest unifying |vie= and |qn=, and replacing |hantu= and |hn= with |chuhan=, for chữ Hán. Most of the entries currently labelled with |hn= are actually chữ Hán, being the names of figures known from histories written (in Vietnam) in Chinese. Kanguole 01:32, 1 June 2013 (UTC)