Wikipedia talk:Manual of Style/China- and Chinese-related articles

Template:ill

Template:ill does a reasonable job for most languages at providing sister language links for redlinked terms on en.wp. For Chinese, I find it totally useless, in every case worse than just including the native characters with no link to zh.wp at all. It creates a redlinked romanised term whilst completely hiding the characters: hover or long press displays the zh.wp url with the characters' unicode codepoints escaped for url compatibility, so if I want to know what / whom the redlink is supposed to indicate, I have to leave the website to a different Wikipedia, which feels like very bad design.

My method is usually linking the characters to zh.wp, but I know this isn't shared by everyone. Sometimes alternatively I'll just add the characters in {{lang-zh}} or similar following the transclusion of {{ill}}, although this feels inelegant.

What are people's thoughts on this? Should we provide any MOS guidance about it? Folly Mox (talk) 10:28, 3 July 2024 (UTC)

I know nothing about template design or url compatibility, but this doesn’t seem to happen to me. When I hover over an {{ill}} link to a Chinese page, Wikipedia displays the characters.

Is the issue browser-specific? If so, perhaps there’s a technical fix for this? Personally, I like how using {{ill}} cleans up the running English text. It’d be a shame to have to create call-outs for topics that already have a Chinese-language article. SilverStar54 (talk) 17:08, 3 July 2024 (UTC)

Oh right, I've been meaning to get back to this. It turns out this does seem to be browser specific. Fails in Firefox and DuckDuckGo, but displays in Chrome.

I kind of see the utility of this the other way round, though: a substantially higher proportion of readership is going to be interested in knowing the word for something / name of someone than the proportion who might click through to the sister language project to read about the topic in another language (which is likely a strict subset of the first).

In other words, displaying the graphs for the native name is what I see as the higher priority, and the link to zh.wp I see as a low-priority convenience thing. Folly Mox (talk) 13:43, 6 July 2024 (UTC)

I suppose we could do something like: Lao Laizi ({{ill|Lao Laizi|zh|老萊子|lt=老萊子}})

Which renders as: Lao Laizi (老萊子)

This doesn't feel better than Lao Laizi (老萊子), although the code for that is less clear:

Lao Laizi ({{zhi|[[:zh:老萊子|老萊子]]}})

Folly Mox (talk) 13:54, 6 July 2024 (UTC)

@Folly Mox I am not sure I follow. I tell my Chinese students (and Koreans) to use ill, see activity here: User:Hanyangprofessor2/Module/MoS (I'll be refining it in the future). Sample article by my students using Ill: Iron flower. What's wrong with it and how would you make it better? Note I tell my students to do a red link and add Chinese charas in the parenthesis if they cannot locate the zh wiki article for the notable concept that should be linked, but if there is one, ill works well enough. Why do we need do display the non-Latin characters for something that has an article? (additionally, today's digital literacy includes machine translating stuff in browsers, so any competent internet user who clicks on ill and goes to zh wiki should be able to read zh article with two mouse clicks). _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 14:21, 9 July 2024 (UTC)

I guess my perspective is that if I'm reading about a Chinese topic, and come across a transliterated name or translated title I'm not familiar with, I want to know its name. That's the basic piece of information I look for to determine whether or not I'm familiar with the topic and whether I want to read more about it.

Being unable to see the names of things in English language topic area sources is something that deeply bothers me, to the point where I'll discontinue reading a book or article if the native terms are not provided, and I don't want that experience for myself or anyone else whilst reading Wikipedia. Granted our case is different, because we can click through to a zh.wp article with {{ill}}, so we're not cutting people off from looking more deeply into a topic should they wish to, but not having the information present on the page is something that upsets my pedagogical sensibilities.

It does look like I hold something of a minority opinion here, and about half my concerns would be alleviated if I switched browsers, so I'm fine with not saying anything in guidance about this. I do think that it should be permitted to retain characters where {{ill}} produces a redlink locally, and people shouldn't remove them just because {{ill}} is present, but no further guidance seems necessary. Folly Mox (talk) 14:16, 11 July 2024 (UTC)

I see. I am not opposed to your example of Lao Laizi (老萊子 [zh]) although I am not sure it is necessary given the link. I most often use this template for Polish Wikipedia, and occasionally Polish words are different and even use diacritics, but unless they have been used in English works, I think we don't need the reader to know them. For Chinese and such, they are even more useless, as readers cannot read (pronouce) or memorize the characters. I certainly see the need to use them when no link is present, to allow people to research them, but otherwise... shrug; as I said, I am not opposing your idea because while I feel displaying the characters when zh link is present is IMHO not needed, WP:NOTPAPER, so why not. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 12:02, 12 July 2024 (UTC)

What about mask (Chinese charas) for publisher?

I was looking at Wikipedia:Manual of Style/China- and Chinese-related articles and I've noticed "publisher=Wenzi gaige chubanshe", with the following MoS note: "For publishing houses without a common name in English, their names are transliterated without tone marks, but not translated. ". Errr. Why? I think we should include original Chinese characters, at min, and why not both the transliterated and translated title? For example, it is important to tell the reader that something may be, for example, a publishing house or an academic journal. There are academic journals with only Chinese names, for example. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 14:17, 9 July 2024 (UTC)

It seems to me Chinese characters are more useful than pinyin for the name of the publishing house. Presumably we mention the publishing house to help interested readers get a copy of the cited source, and I think Chinese characters would help more than pinyin with that. Moreover, pinyin can always be derived from the characters (usually pretty easily), but the reverse is not always true. —Mx. Granger (talk · contribs) 16:07, 9 July 2024 (UTC)

Indeed; most times I search for pinyin I get nothing but Wikipedia, occasionally Google Books (the latter makes it a bit useful, but not as useful as finding info about the original, obviously). _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 06:12, 10 July 2024 (UTC)

This is probably a holdover from academic publishing, which itself is a holdover from days when Chinese characters were not easily included in printed material. Folly Mox (talk) 14:17, 11 July 2024 (UTC)

Infobox Chinese + other infobox redundancies

Many general-use infoboxes have a |native_name= parameter somewhere. Would it be worth specifying that listing the same native forms in both {{Infobox Chinese}} and an article's primary infobox is redundant and usually undesirable?

Moreover, the use of {{Infobox royalty}} in the Chinese context has been killing me: I'm not even sure I would remove the native form conventionally placed right at the top (cf. Kangxi Emperor or any other emperor), but I'm leaning towards that being ideal if we're not even making |native_name= a proper parameter for that one. Remsense诉 23:00, 13 July 2024 (UTC)

Is it redundant and undesirable? I really like the native names of subjects being visible on the first screen, before scrolling down. It makes a lot of sense to have the name at the top of the article, since a lot of people will be looking for that. I'd go as far as saying that if we were to remove either the native name or transliterated name from the header of {{infobox royalty}}, I'd remove the transliterated name, since it already introduces the lead sentence, and leave only the native name, but having both looks correct to me.

{{Infobox Chinese}} is a separate matter entirely. In my experience, it mostly exists to shove diacritic pinyin out of the prose, and then gradually become increasingly bloated with pronunciations. Most of this information seems crufty at first glance, although doubtless it's useful to someone, and removing pronunciations from people's own minority topolect probably feels like a personal affront. Removing the characters from this infobox would leave us without an "index item" (not a good term, sorry about my brain) to compare the pronunciations against. I suppose the characters could be moved to the bottom, if we're concerned about increasing the distance between appearances of the same terms.

I think I'm more pro–"sprinkle 漢字 throughout" than most. Someone in a thread somewhere above called Chinese characters something like unavoidable; I'd call them desirable. Our educational value is significantly enhanced by including them where they're not too obtrusive. Folly Mox (talk) 00:24, 14 July 2024 (UTC)

I really do think the {{Infobox royalty}} case is plausible—I just wish it was its own parameter.

I think the reason my particular opinions are what as strong as they are—maybe "ductile" is a better word? I like having deep justifications for opinions on these things, as long as I'm willing to uproot them and change my mind, as happens often—because I start as an editor with desiring a parsimony of data, i.e. within reason every piece of information appears in the specific place for it. Of course, this doesn't always align with what's good for readers or even other editors, which is why I appreciate the pushback when I lead myself to overly dogmatic positions. Remsense诉 00:56, 14 July 2024 (UTC)

What if we created a wrapper template? And by we I'm not really volunteering myself because I don't have any background coding templates here and am not really sure where to look for guidance, but as a hypothesis:

We could create a template that wrapped {{Infobox royalty}} or {{Infobox officeholder}} and bundled {{Infobox Chinese}} underneath? I'm not sure if that's technically possible or if we'd have to wrap the first template and just output the second based on input parameters.

But the idea would be that the native name goes up top, then the main infobox, then pronunciations at the bottom, without duplicating the native name. Or, if that's impossible to do, create a single template that doesn't wrap anything, but accepts all the parameters of {{Infobox royalty}}, {{Infobox officeholder}}, and {{Infobox Chinese}}, and spits out a single box for every applicable biography? Folly Mox (talk) 11:04, 14 July 2024 (UTC)

I guess before we commit to any such mad undertaking, I'd like to hear from other people active on this talkpage whether the duplication of characters between two infoboxes bothers them.

I definitely used to have a similar idea about how often information should be repeated (never), which came from a background in database programming. That was before the adult-onset ADHD. Now I'm a person who keeps copies of everything important in at least three places, because chances are one is lost and I've probably forgotten another on the way somewhere. I forget what's at the top of the first infobox by the time I've scrolled down to the second paragraph of the lead section.

Mainspace (and projectspace, now that I think of it) hugely duplicate information across a broad array of related pages, and I've come round to a position of inelegant and messy convenience: if someone is looking for information in a place, might as well put it there too, irrespective of wherever else it already is. This is just my opinion as an editor, though, not a firmly held belief. Folly Mox (talk) 11:04, 14 July 2024 (UTC)

Note that {{infobox royalty}} has |module=, which can contain {{infobox Chinese}}, which bundles it at the bottom, whereas |native_lang_name= would go at the top. (e.g: Michael Nylan, with a diffent infobox) Kanguole 11:34, 14 July 2024 (UTC)

Thank you for the technical insights (and for creating that article; I always wanted her to have one, since I cite her all the time, but never got round to it).

Maybe if people are bothered by the duplication of characters, we could either get consensus to add |native_name= to the top of Infoboxen royalty and officeholder, then |module=Infobox Chinese them and remove the |c= from the child templates. Or construct a wrapper that does the same if consensus to change the widely used templates cannot be achieved. Folly Mox (talk) 13:44, 14 July 2024 (UTC)

`Infobox sinogram`?

I've had the idea of creating a derivative of {{Infobox grapheme}} specialized for characters for a while now. Use would likely be relatively niche, i.e. when a character is itself the subject of encyclopedic analysis while not running afoul of WP:NOTADICTIONARY, like on Dao. Any thoughts? Remsense诉 21:44, 30 July 2024 (UTC)

What should generally be included in the articles for emperors?

Also kicking this one off since it's probably of interest to several people floating around lately.

1. We currently use {{Infobox royalty}} for the lead, which has some specific niceties for Chinese emperors built in. I'm not convinced the template really needs changing at this moment, but naturally there's historically been an impulse to stuff these way past the function of an infobox. Specifically, I don't think there's any justification for including the Chinese calendar reckoning for dates of birth etc, as has often been added. Maybe some loose consensus could be made about this?
2. At the bottom of articles, there's usually a fairly bespoke nesting list showing every descendant an Emperor is associated with that someone decided to write down. It seems fairly trivial to me that it's always WP:UNDUE to this degree, and there would be very few cases where non-notable figures with no historiographical content whatsoever should be mentioned even once.

Remsense诉 06:07, 31 July 2024 (UTC)

I think the date reckoning stuff came about because there was a fairly high profile calendar conversion tool active till the end of the 2010s or so, and it was (and, often, still remains) easier to source vital dates and accession dates in Chinese sources then do the conversion, than to find a source that supported the dates using a Western calendar.

Genealogical information has been an area of cruft expansion due in part to the organisational schemata of official histories. The most recent thread on my usertalk, a tangent from an AFD, touches on this as well.

I have to go and don't have time right now to engage on substance, but I did want to provide my impression on where these informal conventions came from. Folly Mox (talk) 11:15, 31 July 2024 (UTC)

Why here "China" not "mainland China"

−

when editing articles concerning China, Taiwan, Hong Kong, Macau

+

when editing articles concerning mainland China, Taiwan, Hong Kong, Macau

(I)t should (only) be used when a distinction with Hong Kong, Macau, or Taiwan is required.

— WP:NC-CN

Donttellu8 (talk) 16:30, 7 September 2024 (UTC)

Because that would sound strange, and we still probably need to specify HK + MO for some. Remsense ‥ 论 20:41, 7 September 2024 (UTC)

Converting full-width punctuation and currency symbols in horizontal text

Greetings! Over the past few years, there have been no objections to converting Latin letters and Arabic numerals to ASCII from their full-width forms when they appear in horizontal Chinese, Korean, or Japanese text. I've raised it on MOS and Wikiproject talk pages and made many cleanup edits to articles. I'm making a push to finish that cleanup, and I've been noticing that punctuation, currency symbols, and spaces have the same problem. It looks weird to have the full-width versions mixed in, and they sometimes leak into English-language text. My plan was to start converting punctuation and currency symbols in horizontal text (except where the characters themselves are being discussed) when the July 1 database dump becomes available in a week or two. If you have any questions, objections, concerns, or suggestions, please let me know! Open-circle full stop is not included; the affected characters are: ＂ ＃ ＄ ％ ＆ ＇ ＊ ＋ － ／ ＠ ＼ ＾ ＿ ｀ ￠ ￥ ￦ ＜ ＝ ＞ ｜ ￤ and the space character. -- Beland (talk) 17:51, 29 June 2024 (UTC)

Will the areas targetted include <blockquote>, |quote=, etc? Or will direct quotes be avoided and only article prose affected? Folly Mox (talk) 21:16, 29 June 2024 (UTC)

I think this advice should be presented with caution, as fullwidth punctuation doesn't fit all the time. Otherwise I don't see the problem.

 Original research from me! Tangentially, I think I'm the only one outside both the W3C and East Asia that knows one can specify CSS lengths in units of ic as well as px and em—with 1ic equal to the width of a fullwidth character for practical purposes, and more technically equal to the used advance measure of the "水" glyph (CJK water ideograph, U+6C34), found in the font used to render it. I think that means it's equal to the height of 水 instead when the text is being rendered vertically, neat. Can't figure out what ic stands for though, other than that i is probably "ideograph". Remsense诉 21:34, 29 June 2024 (UTC)

Did you have specific wording in mind for "with caution"? I'm not sure what you mean by "fullwidth punctuation doesn't fit all the time", as that would be what we are getting rid of. Did you have an example or two in mind? Just trying to make these suggestions actionable. -- Beland (talk) 22:32, 29 June 2024 (UTC)

Oh, I was thinking of Anglo-style halfwidth quote marks “⋯”, which aren't always appropriate to swap out with fullwidth corner brackets 「⋯」. Remsense诉 00:43, 30 June 2024 (UTC)

Curvy quotes like “ and ” are prohibited by MOS:STRAIGHT; both those and full-width ＂ would get converted to ASCII ". Corner brackets don't have a direct ASCII equivalent, so I did not put them on the list of affected characters, and they would be left alone. -- Beland (talk) 00:52, 30 June 2024 (UTC)

This is the only bit that low key concerns me. The glyphs I care most about preserving (，,：,。,「」,、,（）,！,？) are not in the list of affected punctuation. I'm well aware of MOS:CURLY, but I find that the default ascii straight double quote is easily lost in a string of Chinese characters, and does a very poor job of marking out the quoted material.

But, this might be my eyesight, and I suppose if we find ascii-width double quotes getting lost after the punctuation changes, we can replace them with the permissible 「」. Folly Mox (talk) 14:05, 30 June 2024 (UTC)

That sounds like an elegant solution. -- Beland (talk) 19:35, 30 June 2024 (UTC)

My practice has been and would continue to be to change formatting of direct quotations, because MOS:CONFORM says to change quotation marks, dashes, ligatures, etc., to match Wikipedia house style. -- Beland (talk) 22:30, 29 June 2024 (UTC)

@Beland: I've unarchived this—somehow having missed its conclusion for months on end, and that's on me. If this is seen as an exception to WP:CONFORM, then to me it's one with very clear reasoning behind it—the impetus behind MOS:CONFORM doesn't naturally extend to requiring the awkward mingling of full width and half width text. I don't disagree with specifics about curly quotes here, but I must reiterate that generally it is simply a different situation, because we're dealing with snippets of a qualitatively different writing environment than almost all others. Remsense ‥ 论 17:09, 11 March 2025 (UTC)

Hmm, these punctuation characters occur in CJK contexts both inside and outside of quotations. I think it would look typographically sloppy to have the full-width versions inside quotations and the ASCII versions outside quotations. If we decide this is undesirable "awkward mingling" then it would make sense to use fullwidth forms consistently. So far the consensus across Chinese, Japanese, and Koreak WikiProjects seems to have been that the upsides of easier searching and whatnot outweigh the downside of some people not liking the appearance. Using fullwidth-only in CJK contexts would also require not matching quoted and cited sources, as the ASCII characters commonly appear in CJK language text, including in professional publications. -- Beland (talk) 18:00, 11 March 2025 (UTC)

Searching isn't a point I hadn't considered deeply. I should note that much of the time search algorithms in web browsers etc. are smart enough to alias characters together—e.g. Ctrl+F for 。 here in Firefox matches every Unicode full stop code point unless I check a box (that says "match diacritics", a bit silly but understandable why that is). I think it's especially worth considering the incongruence with pre-20th century anything—while I understand Chinese punctuation as we use it is largely a 20th-century invention, it's an invention often adapted to older texts. The use of inverted commas where a Literary Chinese passage may generally be typeset to use 「」 is simply distractingly wrong to me—to the point of seeming unintentionally mangled or sloppy. I don't know, I'm obviously a bit more uptight than most on this, but. (I also need to get some rest, so apologies if you got a particularly disheveled response here.) Remsense ‥ 论 18:10, 11 March 2025 (UTC)

As noted above, 。 and 「」 are not on the conversion list, and other editors support using 「」 where you feel the visual appearance would justify it. -- Beland (talk) 18:19, 11 March 2025 (UTC)