Jump to content

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

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia


Kangxi radical template/gloss[edit]

Another template that might tread on toes style-guide-wise, but I think is probably really worthwhile in some form? I wrote {{kxr}} this morning. I want to tweak it a bit more, but it only works by number right now, because by label will take a bit longer.

{{kxr|120}}'SILK'

{{kxr|54|l=yes}}'LONG STRIDE'

It uses small caps and boldface, but I really do think it's fine here, to distinguish from both regular texts and regular glosses. It uses the Unicode gloss for each Kangxi radical, but I also want to add positioned variants like ⺼, 爫, and 歺, etc. etc. But! I wanted to make sure people would find this useful before I put another few hours into it, and moreover don't actively hate it! Remsense 17:00, 11 October 2023 (UTC)[reply]

I can't see any purpose to either the bolding or the all-caps, most especially the all-caps. It appears to me (based on MOS:FOREIGN and MOS:SINGLE) that this should emit the character wrapped {{lang|zh}} (or equivalent bare HTML markup, like <span language="zh">...</span>), followed by the gloss in 'single quotes': 'long stride'.  — SMcCandlish ¢ 😼  17:46, 11 October 2023 (UTC)[reply]
I suppose I was drawing from templates more oriented towards character encoding, like {{unichar}}U+2F35 KANGXI RADICAL LONG STRIDE. It's almost a less-glossed gloss? Since the semantic meanings of the radicals are so broad and reified, it feels appropriate to potentially mark them up differently/make them appear as part of a set. But maybe I'm overfixated on the distinction?
Also, the character is tagged with lang="Und-Hani", since they are radicals and not characters assigned to phonetic language use per se.
Remsense 17:58, 11 October 2023 (UTC)[reply]
{{Unichar}} uses that format because it is conventional (not just within Wikipedia) to render the official names of Unicode code points that way. This is not true of glosses of Chinese radicals. It's kind of like deciding to render all names of video game characters in italics because you saw that italics were used for book titles. There's no connection between the subjects. Re: Und-Hani – sure, that makes sense.  — SMcCandlish ¢ 😼  18:57, 11 October 2023 (UTC)[reply]
It's an oblique connection, but I figured it was worth trying out. I'll look at giving it a more canonical gloss style. Remsense 19:23, 11 October 2023 (UTC)[reply]
@Remsense: It's still rendering all-caps. This has been open a long time and people are already using this template "in the wild", so this needs to be fixed.  — SMcCandlish ¢ 😼  18:43, 12 January 2024 (UTC)[reply]
I have at least one book where radical names are rendered this way: in all caps, single quotes.[1] I am pretty sure it's used in a couple of my books, but I will have to check. It is certainly not the majority style, however. If presence in a couple relevant books is categorically not enough justification for the template's style, I will just change it.

References

  1. ^ Handel, Zev (2019). Sinography: The Borrowing and Adaptation of the Chinese Script. Brill. ISBN 978-9-004-35222-3. S2CID 189494805. Retrieved 2023-11-01.

Remsense 22:02, 12 January 2024 (UTC)[reply]

When to include both character sets[edit]

I'm not sure whether my feeling is very rigorous, but it does seem there are instances where both simplified and traditional characters are supplied where the forms are similar enough that it does little but take up extra space. I do not know exactly how universal the knowledge of basic forms of both sets is, but it seems like it could be worthwhile to investigate a nuance in style policy here. For example, it seems potentially very wasteful when both forms of a word are given, but the only graphical distinction is the systematic simplification of a radical. Remsense 08:02, 29 December 2023 (UTC)[reply]

I have the same feeling about cases where the difference is very slight, like 没 vs. 沒. For a case like 饭/飯 I'm inclined to err on the side of including both, as some of our readers will have very basic Chinese ability and may not know about systematic simplifications like those. I'm more inclined to include both forms in an infobox as opposed to a lead-sentence parenthetical, because I think long parentheticals can disrupt the flow of the lead. Also, I'm more inclined to include both forms, even if the differences are slight, when the article or term has strong ties to places that use different character sets (for instance, with topics related to cross-strait relations). The current guideline allows for case-by-case discretion, which might be better than trying to list all the relevant considerations, but I'm open to discussion. —Mx. Granger (talk · contribs) 21:04, 29 December 2023 (UTC)[reply]
I agree with Mx. Granger that we shouldn't drop one of the character sets just because the relationship can be guessed if you know about systematic simplications. But as suggested, I would support recommending infoboxes over long parentheticals, especially when the article needs to give both character sets and multiple romanizations. SilverStar54 (talk) 20:04, 16 January 2024 (UTC)[reply]

Pinyin usage in topics related to the late Qing Dynasty and Republican Eras on the Mainland[edit]

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]
WhisperToMe, parenthetically including alternate romanizations is overly clunky in the vast majority of cases. There's a reason {{Infobox Chinese}} exists. — Remsense 23:17, 17 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]
WhisperToMe, I think in this specific case, since both characters and an alternate transliteration may be provided, footnoting is the best option. — Remsense 23:41, 17 January 2024 (UTC)[reply]
I went ahead and footnoted them! WhisperToMe (talk) 00:04, 18 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[edit]

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.

Relatedly, note that systems of Chinese language romanization in Taiwan (the Republic of China) are far less standardized than in mainland China. Hanyu Pinyin has been the official standard since 2009, but systems such Wade–Giles, Gwoyeu Romatzyh, Tongyong Pinyin, and Chinese postal romanization remain in use for both personal and place names. In Taiwan, place names derived from Hanyu Pinyin rarely use the syllable-dividing apostrophe. For example, write Daan District, Taipei City, not Da'an District, Taipei City. SilverStar54 (talk) 19:59, 16 January 2024 (UTC)[reply]

SilverStar54, I think it's a good reorganization. — Remsense 23:15, 17 January 2024 (UTC)[reply]
@Remsense I see you've already added this to the article. Can you remove it? I'd like to get feedback from more users before adding it to the article. SilverStar54 (talk) 17:10, 18 January 2024 (UTC)[reply]

A few suggestions (Mar 2024)[edit]

  • 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
    欽天履道英毅聖神宣文廣武洪仁大孝肅皇帝

    This should be a logical last resort, though.

Remsense 04:21, 4 March 2024 (UTC)[reply]

Logical exception to "don't include characters/romanizations for linked terms"[edit]

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]
This all sounds very reasonable. I support modifying the guideline as well. SilverStar54 (talk) 17:43, 11 June 2024 (UTC)[reply]
The existing wording is broadly in line with the main MOS, Wikipedia:Manual of Style/Text formatting § Non-English language terms:
Use non-English vocabulary sparingly; for more information, see Wikipedia:Writing better articles § Use other languages sparingly.
The latter link says:
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.
Kanguole 14:33, 11 June 2024 (UTC)[reply]
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. Kanguole 21: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, Template: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]

Converting full-width punctuation and currency symbols in horizontal text[edit]

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 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)[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]
That sounds like an elegant solution. -- Beland (talk) 19:35, 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?[edit]

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.

This seems to be wrong. China is the WP:COMMONNAME, so it should be used unless there's a good reason not to. Remsense 01:19, 3 July 2024 (UTC)[reply]

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[edit]

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.
That is, is the ideal form
Zeng Guofan (traditional Chinese: 曾國藩; simplified Chinese: 曾国藩; pinyin: Zēng Guófān; Wade–Giles: Tseng1 Kuo2-fan1)
Zeng Guofan (traditional Chinese: 曾國藩; simplified Chinese: 曾国藩; Wade–Giles: Tseng1 Kuo2-fan1)
That's all. Remsense 10:13, 3 July 2024 (UTC)[reply]
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]
As one of those readers, I second this. SilverStar54 (talk) 17:19, 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. Kanguole 21:37, 3 July 2024 (UTC)[reply]

Ruby characters[edit]

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?

Or, maybe it's my device, and it actually does display super teeny tiny for other people. Folly Mox (talk) 10:19, 3 July 2024 (UTC)[reply]

Template:ill[edit]

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)[reply]

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]