This page is within the scope ofWikiProject China, a collaborative effort to improve the coverage ofChina related articles on Wikipedia. If you would like to participate, please visit the project page, where you can jointhe discussion and see a list of open tasks.ChinaWikipedia:WikiProject ChinaTemplate:WikiProject ChinaChina-related
Hi there — I’m seeking guidance on an unanswered COI edit request.
On the article’s Talk page, I submitted a request using {edit COI} proposing limited changes to address accuracy/clarity and to add citations from independent sources. The request has been pending without response for two weeks. I made a follow up but received no answers.
Would someone be willing to take a look and let me know whether the request is suitable as written or how I should improve it? Here is the link to the Talk page request:https://en.wikipedia.org/wiki/Talk:Huagong_Tech
Many pages forcommanderies in Chinese history are currently written in anUpperCase format (i.e.HenanCommandery). However, it is stated inMOS: Dynasties that specific dynasties are not to follow such format as it is not actually part of the dynastic name (i.e. Ming dynasty, notMingDynasty).
Similarly, I think commanderies should follow suit as well as prefectures for consistency. However, since commanderies are much fewer in number and less controversial, I suggest we start with it first.Asieon『✉』17:48, 25 December 2025 (UTC)[reply]
A commandery was a division of land; it's not obvious that it should be capitalized the same way as a historical period or ruling dynasty. For comparison, American counties are typically written with the word "county" capitalized:Cook County, notCook county. What do English-language reliable sources do when talking about Chinese commanderies? —Mx. Granger (talk·contribs)19:40, 25 December 2025 (UTC)[reply]
I don't think the guidance at MOS:Dynasties applies here, since the type of subdivisionwas part of the name of these subdivisions. In your example, it was 河南郡, not just 河南. However, if you find evidence that sources do not consistently capitalize the word "commandery", we could lowercase them perWP:NCCAPS andWP:COMMONNAME.Toadspike[Talk]19:47, 25 December 2025 (UTC)[reply]
They are frequently interchanged depending on the source.
A lot of the commanderies don't have much papers written about them, but more relevant ones such as theLelang commandery don't use upper casings.
I'm also a little skeptical as to deeming "commandery" as part of a particular name. Names such as theJapanese archipelago, written as 日本列島 (Nihon Retto/にほんれっと) is not capitalized despite being part of a specific placename.Asieon『✉』19:58, 25 December 2025 (UTC)[reply]
I threw "Lelang (C/c)ommandery" into Ngrams[1]. Surprisingly, the result there is not as clear as your evidence. I will do some more digging...
Looking elsewhere in Asia on wiki currently, the Russian oblasts, Myanmar states, Nepal provinces, Kazakh regions, Afghan provinces, and Mongolian provinces are capitalized. Thai, Lao, and Vietnamese provinces are not. The Phillipines drops the word province but then uses Province of (X) in text.
Well, I guess Wikipedia has not yet provided a clear standard for placenames such as this. With that being said, I believe leaving them as is for now is the best decision.Asieon『✉』05:30, 26 December 2025 (UTC)[reply]
A topic that recurs is how to characterise birth/death locations in the Biography infoboxes for modern Chinese figures whose lives spanned multiple sovereignties. Obviously there are a huge number of such articles. Although there are various permutations of these edits, often an editor is wanting to make the infobox indicate that someone was born during the era of the Qing Dynasty (some of these are more objectionable like replacing "China" with "Qing Dynasty", others are less objectionable like retaining "China" and wikilinking to something Qing era-related, but there are many variations).
I am under the impression that our consensus for several years has been to simply state "China" in the infobox, and leave the sovereignty to the body (for example,Mao Zedong page does this). This is what I favor. Following a discussion raised by @RegularboyA, however, I have been unable to find the earlier discussion or style guide direction I thought I remembered on this. I am also becoming more oriented to this issue and seeing that our modern Chinese bios are not as uniform as I thought they were.
Am I wrong about the consensus? And what should our approach be to become more consistent? Although it is not strictly necessary for articles to be consistent, it would be nice if there is a clear consensus and we could move in a consistent direction.
I seem to remember @The Account 2 addressing this issue recently so ping that editor as well in addition to RegularboyA.
To give a bit more elaboration on my own view and rationale, I think what the infobox is really asking iswhere a person was born or died, notwhat the sovereign was, and I think the latter point is for the article body not the brith/death infobox fields. I would simply say "China".JArthur1984 (talk)18:22, 4 January 2026 (UTC)[reply]
I think stating that someone is born in "Qing dynasty" is incorrect, but I think "Qing China", "Ming China", "Republic of China" etc. is good context for them (we often refer to figures by what dynasty/ies they lived in, and this could be unclear as you go further back in time. Additionally, China as a region might not necessarily line up with the borders of the Chinese state at any given time.
There seems to be a mismatch between the articleShuishiying on the English Wikipedia and the corresponding articles in other languages.
The English-language article which describes it as a name for Qing-era naval camps (according to Google, "水师营" translates as "naval camp") has a single source, a book excerpt pasted to a apparently defunct Chinese-language Internet forum that is now only available on archive.is.
According to machine translation:
The Chinese Wikipedia appears to describe a specific place in Liaoning Province, China.
The Japanese Wikipedia article appears to be about Qing dynasty naval bases.
The Bahasa Indonesia article appears to describe one specific Qing dynasty naval base in Liaoning Province.
Is this a failure of disambiguation, a hoax, or (as I suspect) just a case of a kind of thing and one specific example of it, or someting named after it, being conflated?
The enwiki article forLüshunkou, Dalian has a red link for a subdivision Shuishiying Subdistrict (水师营街道), which would seem to correspond to the zhwiki article, and confirm your suspicion.Kanguole09:42, 5 January 2026 (UTC)[reply]
I don't see a proposal anywhere. The Korean templates perform romanizations of the Hangul alphabet. Is your plan to generate Wade-Giles, Bopomofo and Gwoyeu Romatzyh from pinyin?Kanguole08:56, 7 January 2026 (UTC)[reply]
Postal romanization is not systematic enough to be automatically derived. Jyutping and Cantonese Yale are for Cantonese, and cannot be derived from pinyin. Deriving Wade–Giles, Bopomofo and Gwoyeu Romatzyh from pinyin is certainly possible, but it's not clear that running that code all the time is a good idea. Maybe a subst'ed template would be sufficient, if needed.Kanguole23:57, 7 January 2026 (UTC)[reply]
Apologies, I may have misunderstood your point. You want an editor to input Pinyin, which the module would convert to other romanization formats? That makes more sense, but as Kanguole pointed out it would really only work between three romanization systems, one of which (Gwoyeu Romatzyh) is completely obsolete and the other of which (Wade–Giles) is on its way out. If someone wants to put in the effort to code a module that turns Pinyin into Wade–Giles and vice-versa, I wouldn't stop them, but it seems like a waste of time. This would also only be useful forTM:Infobox Chinese, notTM:Pinyin – we shouldn't really have more than one romanization inline (in article text).Toadspike[Talk]16:24, 8 January 2026 (UTC)[reply]
Indeed what would really be valuable is automation to convert characters to pinyin (with a way to specify when characters have multiple readings). There is tech for this at Wiktionary; I don't know if we have any similar things here at English Wikipedia. On Wiktionary you can write{{zh-l|中國}} to get '中國/中国 (Zhōngguó)'. (Observe that the same template also has automation for traditional/simplified conversion. Again, with a way to specify when it's not 1-to-1.) Seewikt:Template:zh-x orwikt:Template:zh-l orwikt:Module:zh. Internally, there's abig, centralized lookup table, as you might expect.In my estimation, the greatest hurdle isn't "can it work" or "is it a good idea" but the implementation. The implementation takes someone with the effort and time and skill in hooking up templates and modules, a software system which is rather arcane for most editors. Once done, though, it would be easier to use and easier to maintain than the manually entered transliterations spread across tens of thousands of articles.Adumbrativus (talk)04:22, 8 January 2026 (UTC)[reply]
I think "can it work" and "is it a good idea"are hurdles. I didn't even have to open that table to see a critical flaw: it only produces one reading forhomographs (多音字) like 长, which is only listed as "cháng" and not "zhǎng". That table also only contains eleven thousand entries, which is lots, but probably not sufficient for Wikipedia, where we often deal with archaic characters. Further, Chinese characters are used by a huge variety of languages and dialects, such that Mandarin pronunciation is often completely irrelevant. I don't want to create a mindless tool that causes editors to think they can simply plug and chug without verifying the output.
The Hangul tool is far more accurate than the average Wikipedian. In addition to the fact that Hangul is phonetic and Chinese characters are not, this is due firstly to the extraordinary efforts of those who built it and secondly to the arcane and complicated rules of Korean romanization. I cannot see a Pinyin tool (aside from, perhaps, an LLM) reaching similar levels of accuracy and I expect such a tool to cause more harm than good.Toadspike[Talk]16:05, 8 January 2026 (UTC)[reply]
Like I said, Wiktionary's templates already provide a way to specify the reading. For instance,{{zh-x|长{zhǎng}长了|grew long}} produces '长长了 ―zhǎngchángle ― grew long'. And, though Pinyin is a sensible default as it is by far the most-used, common case here on Wikipedia, the template documentation shows there are options to specify other transcriptions, e.g. Jyutping for Cantonese. Of course, nothing absolves editors of due diligence like checking the preview of rendered output and understanding the content of their own edits.You originally asked, "how would this work?". I had the same skepticism in my mind too, and looking into this helped broaden my perspective. What I found was news to me, and I think it'll be news to some other editors reading this too. Of course if one were to begin with the premise that Hangul romanization is the benchmark and nothing short of that level of phoneticness is acceptable, then there would be no question left in their mind in the first place. Otherwise, the good news I can share is, there is a project which shows how to do it.Adumbrativus (talk)20:20, 8 January 2026 (UTC)[reply]
Thank you, this is very reassuring. I withdraw my opposition on technical grounds. I remain concerned that editors will not be careful enough when using such a tool, but as long as it'spossible to generate a correct output in all cases, that becomes a behavioral issue and not a technical one, which means we can deal with it on a case-by-case basis.Toadspike[Talk]20:26, 8 January 2026 (UTC)[reply]
I still think it's wasteful to run this code repeatedly, when it always gives the same result. And if it doesn't give the same result, because someone has updated the table to change which of the alternative readings is assigned to some character, that will silently change what could be many pages to an incorrect form. It wouldn't be enough to check the output when the template was first added.
But to take a step back, what problem would this template solve? It couldn't be safely used by people who don't know what the pinyin should be, because they need to check that the output is correct and whether they need to manually supply the correction. And if it does have a use, is that not served at least as well by asubst'ed template (which would avoid the issues above).Kanguole00:01, 9 January 2026 (UTC)[reply]
Perhaps all this talk about customizations is distracting from the common case, which is that most characters have only one reading, and even among characters with multiple readings, most of them have one reading which is much more common than the others. So for instance, let's say you're writing an article aboutXi'an Museum, which is 西安博物院. If you're an editor who doesn't know the characters, then you'll have to fret about it just as much as you do today. But if you're an editor familiar with these characters, then to you it'll be obvious that they're pronounced the familiar way and not with some alternative reading. An auto-conversion template saves the trouble of inputting the pinyin and tones manually.If the value of this sounds like a convenience we can live without, rather than a burning problem – yeah. A great many templates are merely conveniences, and yet they are valuable.For the performance concern about running code repeatedly, I'm not sure if that concern comes from technical expertise (which I'd love to hear more about – I'm no expert) or from technical naivety (e.g. not knowing about caching, or ignoringWikipedia:Don't worry about performance and prematurely optimizing). As for table updates, they are rarely needed; and, among the rare updates, even fewer are "primary reading swaps" rather than additions or unambiguous error corrections. In any case I wouldn't mind a subst template which would be useful too.Lastly, I'm sorry to Absolutiva for side-tracking their topic which was really about something different.Adumbrativus (talk)10:26, 9 January 2026 (UTC)[reply]
OK, the use case is an editor who knows both the characters and their SC pronunciations, to save them from typing the pinyin. Would that not also be achieved by subst'ing the template? That would also produce a result that is easier to maintain.
The performance concern is not based on measurement but general principles. I am not proposing an optimization, just objecting to adding useless repetitive work.Kanguole11:54, 9 January 2026 (UTC)[reply]
On your example: If you don't know what the characters mean, you shouldn't be using this hypothetical automatic romanization template. (This is also true for the automatic Hangul template.) For the Xi'an Museum, you'd have to know that Xī'ān is capitalized and needs an apostrophe, and that Bówùguǎn is a separate word and also needs to be capitalized. So, the hypothetical "editor who doesn't know the characters" should consult a dictionary or, better, another editor who does know the characters, regardless of whether we have an automated tool.Toadspike[Talk]12:24, 9 January 2026 (UTC)[reply]
but just because a tool does not do everything is not reason to not have it. Stoplights do not prevent all people from running reds but they mostly do. This would be useful in the vast majority of cases for modern chinese language.Czarking0 (talk)00:34, 10 January 2026 (UTC)[reply]
Well, in fact, in most cases showing the romanization of a Chinese term is not really necessary.
Those who know Chinese can pronounce a Chinese term correctly even without any romanization.
Those who don't know Chinese do not necessarily need to know how a Chinese term is pronounced (and won't be able to pronounce it correctly anyway).
Using 西安博物院 as an example:
Those who know Chinese can pronounce this correctly as "Xī'ān Bówùyuàn" even without any romanization.
Those who don't know Chinese do not necessarily need to know how this is pronounced (and even when they see the romanization "Xī'ān Bówùyuàn", they won't be able to pronounce this correctly anyway).
Sorry, I don't agree with your arguments. First off, there isno Chinese speaker who can "correctly" pronounce every single one of the 100,000+ Chinese characters in existence, insofar as there even is a "correct" pronunciation for archaic and obsolete characters. Sure, the vast majority can read "西安博物院", but most would struggle to get throughthis list without making a few mistakes. Second, it is absolutely imperative that an English-speaker can read foreign-language terms appearing on the English Wikipedia in some way, even if their pronunciation is poor. (Not to mention that most Chinese speakers don't have impeccableStandard Chinese pronunciation either.) This is so important that it is required byour manual of style. Third, there are many folks at intermediate levels of Chinese fluency who benefit greatly from romanization, even of simple terms. While teaching Chinese is not our primary goal, if we can help readers learn new languages while following good encyclopedic practices, there is no reason to avoid doing so.Toadspike[Talk]14:59, 18 January 2026 (UTC)[reply]
In fact, showing pronunciation (whether accurate or approximate) itself is not really important to begin with. Wikipedia is written, not pronounced. When reading a written language with eyes, you don't really need to know how the text is pronounced.
What I wrote is about the romanization that is shown right next to Chinese hanzi text (like the "Xī'ān Bówùyuàn" in theXi'an Museum article). It is not about English-language use (article titles, running text, etc.).
Since teaching Chinese is not Wikipedia's primary goal, editors do not need to put extra effort on showing romanizations. Readers who want to improve their levels of Chinese fluency should use something else.
You are welcome to raise this issue at a wider venue, like theVillage Pump. We cannot form consensus to change encyclopedia-wide practice here. But I assure you that would be a waste of your time.Toadspike[Talk]09:54, 19 January 2026 (UTC)[reply]
I'm not saying that showing romanization should be prohibited altogether; I'm just saying that it should be done sparingly (such as in contexts where pronunciation in the original language does matter – e.g. when explaining a pun based on the pronunciation(s) of Chinese terms).~2026-42255-4 (talk)09:39, 20 January 2026 (UTC)[reply]
Hello! I came across theMacanese cuisine (Q1045260) andMacau's cuisine (Q77983315) Wikidata items which appear to be for the same topic: thecuisine of Macau. Both of these Wikidata items have articles in Chinese (although I'm unsure which variety of Chinese is used on the zh.wikipedia), and am wondering if any Chinese speakers could help me understand the difference (if any) between the two separate articles:澳門土生葡菜 [zh] in Macanese cuisine (Q1045260) and澳門菜 [zh] in Macau's cuisine (Q77983315). The second article is much shorter so I assume the first one should take precedence, but I wanted to make sure.BaduFerreira (talk)05:07, 9 January 2026 (UTC)[reply]
@BaduFerreira The first article is specifically for food of theMacanese people, which are a specific ethnic group from Macao. The second article is probably supposed to be about food in/from Macao more broadly, though it's too short to really do that.Toadspike[Talk]12:16, 9 January 2026 (UTC)[reply]
"Cuisine": the question about Inner Mongolia (Tibet).
Just Yakutia natural gas , - via the Mongolian government.
Please be advised thatThe Bund was moved without discussion toThe Bund (Shanghai). I have reverted the move for now, given that the article has been considered the primary topic for over a decade, but should there be disagreement over its status please discuss on the talk page. — Chris Woodrich (talk)17:54, 31 January 2026 (UTC)[reply]
Tagged as Unreferenced for 2 years. No other language has a reliably sourced article from which to translate. I conducted several researches online in English, and found no reliable sources.
You may prevent the proposed deletion by removing the{{proposed deletion/dated}} notice, but please explain why in youredit summary or onthe article's talk page.
Hello. Can you help verify a brief, English-to-Chinese translation in a welcome template?
Template:Welcome-foreign is a bilingual welcome template used to welcome new users who have written content in some other language besides English. The template welcomes them first in English, then in their own language, as long as it is one of the three dozen languages it can handle. New languages areeasily added. I have added support for Chinese, but I don't know Chinese so I used automatic translation to createTemplate:Welcome-foreign/Chinese from the original atTemplate:Welcome-foreign/English. I'd appreciate it if a native Chinese speaker could verify or improve the translation. Feel free to edit it directly, or paste a better translation below, if you prefer not to edit a template. Thanks!Mathglot (talk)01:31, 9 February 2026 (UTC)[reply]