This page falls within the scope of the Wikipedia:Manual of Style, a collaborative effort focused on enhancing clarity, consistency, and cohesiveness across the
Manual of Style (MoS) guidelines by addressing inconsistencies, refining language, and integrating guidance effectively.Manual of StyleWikipedia:WikiProject Manual of StyleTemplate:WikiProject Manual of StyleManual of Style articles
This page falls under the
contentious topics procedure and is given additional attention, as it closely associated to the English Wikipedia
Manual of Style, and the
article titles policy. Both areas are subjects of debate. Contributors are urged to review the
awareness criteria carefully and exercise caution when editing.
This page is within the scope of WikiProject Asia, a collaborative effort to improve the coverage of
Asia on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.AsiaWikipedia:WikiProject AsiaTemplate:WikiProject AsiaAsia articles
This page is within the scope of WikiProject China, a collaborative effort to improve the coverage of
China related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.ChinaWikipedia:WikiProject ChinaTemplate:WikiProject ChinaChina-related articles
This page is within the scope of WikiProject Hong Kong, a project to coordinate efforts in improving all
Hong Kong-related articles. If you would like to help improve this and other Hong Kong-related articles, you are invited to
join this project.Hong KongWikipedia:WikiProject Hong KongTemplate:WikiProject Hong KongHong Kong articles
This page is within the scope of WikiProject Macau, an attempt to better organize and improve articles related to
Macau.MacauWikipedia:WikiProject MacauTemplate:WikiProject MacauMacau articles
This page is within the scope of WikiProject Malaysia, a collaborative effort to improve the coverage of
Malaysia and
Malaysia-related topics on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.MalaysiaWikipedia:WikiProject MalaysiaTemplate:WikiProject MalaysiaMalaysia articles
This page is within the scope of WikiProject Singapore, a collaborative effort to improve the coverage of articles related to
Singapore on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.SingaporeWikipedia:WikiProject SingaporeTemplate:WikiProject SingaporeSingapore articles
This page is within the scope of WikiProject Taiwan, a collaborative effort to improve the coverage of
Taiwan on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.TaiwanWikipedia:WikiProject TaiwanTemplate:WikiProject TaiwanTaiwan articles
This page has archives. Sections older than 180 days may be automatically archived by Lowercase sigmabot III when more than 6 sections are present.
Pinyin usage in topics related to the late Qing Dynasty and Republican Eras on the Mainland
Hi! A user argued in
WP:PINYIN for usage of pinyin. This makes sense with post-1949 articles about Mainland China and/or general about individuals loyal to the CCP. However, I think both Pinyin and old postal system names/other romanizations of cities should be used in late Qing Dynasty and Republican Era-related articles, as those spellings were used at the time. Also, IMO individuals who died in the Republican Era and/or were loyal to the KMT should likely use the non-standard romanizations.
WhisperToMe (
talk)
03:31, 16 January 2024 (UTC)reply
This has been discussed before; see
Wikipedia talk:Naming conventions (Chinese)/Archive 14#Historical names of Chinese places for a recent discussion of a similar topic. Most modern sources use pinyin as the standard transliteration of Chinese terms from all periods of Chinese history. It's sometimes useful to provide another transliteration in parentheses to help readers who may be using older sources, but our default should be pinyin. There are exceptions for the unusual cases (e.g. Sun Yat-sen and Hong Kong) where a different transliteration is clearly more common in modern reliable sources. —
Mx. Granger (
talk·contribs)
13:47, 16 January 2024 (UTC)reply
Mx. Granger said it better than I could. It would be really confusing to readers if we changed romanization systems based on the historical time period. We should keep things as straightforward as possible.
SilverStar54 (
talk)
19:03, 16 January 2024 (UTC)reply
I posted responses to
Talk:Kweilin_incident. Based on the discussion, I felt the outcome would be to retain pinyin for Mainland Chinese cities, but I indicated the old spellings in parenthenses because one key source (Gregory Crouch's book) uses the old spellings. I indicated aspects about the particular people on the discussion page, with at least one using a particular non-standard romanization of his name during his lifetime.
WhisperToMe (
talk)
22:06, 16 January 2024 (UTC)reply
Infobox Chinese works for introducing various romanizations of the main article's subject. But when introducing multiple romanizations of a time period (for example, looking at an article subject set in the late Qing/Republican eras, when relevant documents and even some modern secondary sources use extensive Postal System romanization), one can't put all of the romanizations of each term used in a single template. Also expecting a reader to click-click-click multiple articles to see multiple romanizations of each term isn't ideal because many readers don't want to do that work. Now, footnoting them might be a possibility.
WhisperToMe (
talk)
23:21, 17 January 2024 (UTC)reply
I like the footnoting approach
WhisperToMe took in the
Kweilin Incident article, and I agree with @
Remsense that it's superior to putting the alternate romanizations in paranetheses, which interrupts the flow of the text. I would support recommending this as part of the guide if it's supported by other users as well.
SilverStar54 (
talk)
17:02, 19 January 2024 (UTC)reply
Suggested reworking of "Romanisation" section
What does everyone think of this as a reworking of the "Romanisation" section? Hopefully there's nothing controversial here. My main goal was to add clarifying details and improve the overall flow. I also replaced guidance that already exists more extensively at
WP:NCZH with references to that page, to minimize duplication.
===Romanisation===
There are a
number of systems used to romanise Chinese characters. English Wikipedia uses
Hanyu Pinyin, with some minor exceptions outlined below. When using pinyin:
Follow the established conventions for hyphens, spacing, apostrophes, and other parts of pinyin orthography (see
WP:NCZH#Orthography)
Follow
MOS:FOREIGNITALIC for when to use italics. In general, use italics for terms that have not been assimilated into English, but do not use italics for the names of people, places, or groups.
See below for where and how to use tone marks
If a source uses a non-pinyin or non-standard spelling, it should be converted into pinyin. Consider also providing the source's spelling to ease
verification by other users.
Even where the title of an article uses a non-pinyin romanisation, romanisations of other Chinese words within the article should still be in pinyin. For example,
Tsingtao Brewery is a trademark which uses a non-pinyin romanisation, but an article talking about Tsingtao Brewery should still use the pinyin spelling when talking about Qingdao city:
Correct: Tsingtao Brewery Co., Ltd. is located in Qingdao city, Shandong.
Incorrect: Tsingtao Brewery Co., Ltd. is located in Tsingtao city, Shan-tung.
or Tsingtao Brewery Co., Ltd. is located in Tsingtao city, Shandong.
====When to use romanisations other than pinyin====
Articles should use a non-pinyin spelling of a term if that spelling is used by the clear majority of modern,
reliable,
secondary sources (see
WP:NC-ZH for examples). If the term does not have its own article, the pinyin romanisation should be given in a parenthetical. For example,
The
Hung Ga style Ng Ying Hung Kuen (
Chinese: 五形洪拳;
pinyin: Wǔxíng Hóngquán) traces its ancestry to
Ng Mui.
When to include characters — I think it may be worthwhile and not
CREEP-y to explicate that characters for a term may be included if the prose is specifically talking about the graphical form of the character, or is comparing characters.
Almost all methods of emphasis are
bad emphasis, but it's hard to know what to do with characters sometimes—in general, I think double-underlining as facilitated by {{
uuline}} is likely the best technique we have when we would like to emphasize a character:
Posthumous name Emperor Qintian Lüdao Yingyi Shengshen Xuanwen Guangwu Hongren Daxiao Su 欽天履道英毅聖神宣文廣武洪仁大孝肅皇帝
Logical exception to "don't include characters/romanizations for linked terms"
During the GAN for
Chinese characters, @
Kusma pointed out sections that really should include the characters and romanization for certain terms, even though they're linked—e.g.
regular script in the the § History section. I agree: perhaps some class of exception to this guideline should be mentioned, while always being mindful of
WP:CREEP. I'm not sure exactly what that class should be—perhaps "within a broad article, while summary style–ing what could be considered its subarticles", or "when omission would be conspicuous or confusing in light of other terms that are linked within an article"
Remsense诉02:39, 13 April 2024 (UTC)reply
I've been meaning to bring up here that the "don't include characters if a link exists" should make reasonable exceptions for tabular data (which is already common practice in many articles like e.g.
13th Politburo of the Chinese Communist Party and all in that series). I'm especially interested in adding characters to terms where translations vary, and no common name has been rigorously established at the target article, which is relatively common for literary titles.I also think I agree with Kusma's comment referred to above, which I have not read in the original, in that for certain topics, including the native name of a concept in prose should not be prohibited. If you're ever talking Chinese calligraphy with someone irl, the term they'll employ in an English sentence will be kaishu, not "regular script" (which I literally had to click through to in order to ascertain that 楷書 was indeed the topic).
Folly Mox (
talk)
13:55, 11 June 2024 (UTC)reply
Yes. Having really immersed myself in writing a topic including a lot of native vocabulary from top to bottom, it now seems pretty common sense that this should be a class of exceptions to not including characters.
Remsense诉14:00, 11 June 2024 (UTC)reply
I think it makes sense to modify the guideline to explicitly allow for more flexibility. For instance, maybe we should add a sentence to the paragraph in question saying something like "Reasonable exceptions can be made when important for consistency or clarity." —
Mx. Granger (
talk·contribs)
14:06, 11 June 2024 (UTC)reply
Foreign terms within the article body do not need native spellings if they can be specified as title terms in separate articles; just link to the appropriate article on first occurrence.
The difference is that Chinese is the only major non-phonetic writing system, so it's reasonable that there would be a distinction on this point.
Remsense诉01:16, 3 July 2024 (UTC)reply
Japanese is also a bit major. But it's not clear that this argues for an exception for repeating the characters. It certainly doesn't justify repeating the pinyin.
Kanguole21:41, 3 July 2024 (UTC)reply
I think it does simply because articles are meant to be internally complete, not relying on other pages to adequately explain its subject. If I were on a desert island and I only had the one article, in many cases I would like to have the characters of certain key terms included in that article. I think the distinction requires careful thought though.
Remsense诉01:23, 4 July 2024 (UTC)reply
By the way, I've been pondering the viability of, say, {{Infobox sinogram}} or something like that, intended either for articles specifically about lexemes, or maybe even to provide an unobtrusive, modular explanation of a lexeme in other articles where its lexical properties are important.
Remsense诉01:25, 4 July 2024 (UTC)reply
There's a lot of boilerplate etymological prose in many articles which cannot simply be outsourced to wiktionary. It's possible that it could be better presented this way.
WP:SUMMARY
My distinction is that characters should be included when not doing so leaves other information in the article underexplained. One should not have to reference other articles to fill in specific details that are necessary to understand those already presented, which is what WP:SUMMARY also says. This is of course distinct from having other articles for a generally more detailed treatment. I stress that I think there's a distinction to be made between logographic and phonetic languages here also.
Remsense诉20:00, 4 July 2024 (UTC)reply
If you want to discuss the graphical structure of a particular character, then certainly it needs to be included. I think you want a bigger exception than that though, and it sounds like special pleading.
Kanguole20:50, 4 July 2024 (UTC)reply
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)reply
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)reply
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 technicallyequal 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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
Odd passage?
Where "China" or the "People's Republic of China" is used, it should not be changed arbitrarily. In many contexts, the terms are interchangeable: if China and People's Republic of China both seem appropriate, editors should use their own discretion.
Idk how I feel about this. On the one hand, I don’t know if it’s worth encouraging edit wars by allowing mass changes of PRC —> China, but on the other hand maybe it would be better for stylistic consistency.
If we were to change this policy, I think we should give some examples of where it’s necessary to make a distinction versus where it’s not.
SilverStar54 (
talk)
06:17, 3 July 2024 (UTC)reply
I'm all for pragmatism in our operations, but I hope it makes sense when I say that "implementing what is clearly site policy (assuming momentarily that this is the case) would lead to prohibitive levels of disruption" seems to necessarily require admitting "local consensus in this area inevitably trumps global consensus", which isn't a position you or I would find viable, of course
I think it'd be fine just removing this passage, as it just reads like a permission slip to ignore
WP:COMMONNAME if one fancies. I don't think it really needs to be replaced with anything to the opposite effect.
Remsense诉07:03, 3 July 2024 (UTC)reply
Pinyin with and without tone marks
I think we should encourage articles to list pinyin with tone marks in parentheses even if the term itself is just pinyin without tone marks. It might seem redundant, but we can't just ditch showing the tone marks. They're essential to knowing how the term is pronounced in Chinese.
SilverStar54 (
talk)
07:36, 3 July 2024 (UTC)reply
To me, it's a fairly reasonable deduction from
WP:LEADLANG that it's a superfluous term to include in a lexemic call-out, especially as it will be present in the {{
Infobox Chinese}} if the term is the article's subject. Including characters is justified because it's necessary for disambiguation, even if they are not useful to most readers. Including identical pinyin but with tone marks is additionally useful to almost no one, as readers will either not find their meaning to have much utility, or they will already be able to read the characters and in all likelihood derive the tones from them. The sliver in between has to be very small.
Perhaps overly blunt, but surely Wikipedia is explicitly not a dictionary? We generally provide lexical and linguistic information in proportion to its relevance for the article, not for its own sake. {{
Infobox Chinese}} is a general compromise that helps a lot to address a particularly needful case.
Remsense诉07:49, 3 July 2024 (UTC)reply
There have been a lot of recent edits to this MOS guidance. Am I correct in understanding that the question here is whether or not to include romanised terms used in running text should omit [tone marks] after Tone marks should only appear within templates, parentheticals, or infoboxes?To me, using pinyin without diacritics inside the |py= parameter of {{lang-zh}} and its aliases seems fully incorrect, and seeing pinyin with tone marks in running prose feels a bit jarring, but it's not something I ever copyedit out.What are some examples that have led us to this thread? It's been a busy couple weeks and I'm not really looped in.
Folly Mox (
talk)
10:08, 3 July 2024 (UTC)reply
Apologies for the confusion. The question is whether diacritical pinyin should be included in the brackets for terms that are themselves identically spelled but undiacritical pinyin.
No apologies necessary: I'm confused about everything all the time, straight e.g. wandering around grocery stores in a daze like "what is this place??"If that's the question, then yes I think we should include tone marks in the |py= parameter as stated above include the |py= parameter with tone marks, unless the second example is going to be rewritten "Zēng Guófān (
traditional Chinese: 曾國藩;
simplified Chinese: 曾国藩;
Wade–Giles: Tseng1 Kuo2-fan1)", which seems less better. Of course, ideally this would all be relegated to {{Infobox Chinese}}, but if no infobox is present, we should include the pronunciation somehow.
Folly Mox (
talk)
10:39, 3 July 2024 (UTC)edited 10:58, 3 July 2024 (UTC)reply
I agree, the second form is preferable, as the tone marks are essential pronunciation information. I would guess our articles about China-related topics get a significant number of readers who know enough Chinese to read pinyin but not enough to pronounce all the characters that an educated native speaker knows. Tone marks are even more valuable for topics that include uncommon characters or characters with multiple pronunciations. —
Mx. Granger (
talk·contribs)
17:17, 3 July 2024 (UTC)reply
Understanding that generally infoboxes are meant to summarize and not stand alone, though {{
Infobox Chinese}} is a clear common-sense exception to that much of the time—the primary situation in my head is for the article subject itself, where the diacritical pinyin is assuredly listed. Is this a meaningful distinction for those concerned?
Remsense诉17:48, 3 July 2024 (UTC)reply
Are you suggesting including hanzi in the lead but putting the pinyin with tones in the infobox? That might be alright, but I think in that case I'd prefer to relegate both hanzi and pinyin to the infobox. I worry it might be confusing to have some of the extra details about the name in one place and some in a different place. I'm not sure. —
Mx. Granger (
talk·contribs)
18:31, 3 July 2024 (UTC)reply
In the absence of {{Infobox Chinese}}, the first form seems most readable. Combining tone marks with bolding can be harder to read in some environments. It's true that the way {{zh}} is commonly used stretches LEADLANG quite a bit. Perhaps there should be a preference for using {{Infobox Chinese}} instead if there are more than a couple of items. Despite its name, {{Infobox Chinese}} isn't an infobox presenting key facts about the article topic, but rather a box of a different sort, devoted to the name of the topic.
Kanguole21:37, 3 July 2024 (UTC)reply
Ruby characters
I think I've never seen these on en.wp (only on zh.wp and ja.wp), and the guidance ruby is not used for body text on Wikipedia seems accurate and appropriate. The explanation that follows, as it would display at too small a size, may be outdated. Maybe this was true for older skins, but in Minerva and Vector 2022, the text is no smaller than the text of a footnote or citation. Maybe we could trim that bit, or use an alternative explanation like as it disrupts line spacing?
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.
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)reply
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)reply
I suppose we could do something like: Lao Laizi ({{ill|Lao Laizi|zh|老萊子|lt=老萊子}})
@
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 here14:21, 9 July 2024 (UTC)reply
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)reply
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 here12:02, 12 July 2024 (UTC)reply
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 here14:17, 9 July 2024 (UTC)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply