This page is within the scope of WikiProject Korea, a collaborative effort to build and improve articles related to Korea. All interested editors are invited to join the project and contribute to the discussion. For instructions on how use this banner, please refer to the documentation.KoreaWikipedia:WikiProject KoreaTemplate:WikiProject KoreaKorea-related
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
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.
I made some fixes regarding this issue (example), but what I did is not complete. Sometimes it is difficult to find whether someone legally changed their name or is just going by their stage name while their legal name has not been changed.
This issue does not only exist in articles about people in the entertainment industry. Articles about modern writers who go/went by pen names have this issue as well (e.g. Pak Mok-wol – legal name 박영종, pen name (박)목월).
One of the reasons for this is that there is no parameter specifically for a pen name.
The fundamental issue with this is that the birth name (hangulborn) parameter itself is causing confusion. Probably this parameter should just be entirely removed.
Some people have been putting strange values to the birth name parameter. For example, "왕기, later 왕전" in Gongmin of Goryeo. How does this even make sense?
Agree this is hairy, but I'm skeptical of removing the birth name parameter altogether; it's widely used and it's still useful, just difficult to use with high consistency. Similar can be said of many other parameters in other major infoboxes; ambiguously and inconsistently used but still useful if used well.
This is what I meant: that section should be about any person in any field using any pseudonym, not just about people in the entertainment industry using stage names. 172.56.232.166 (talk) 03:27, 18 June 2025 (UTC)[reply]
Oh, I would like to add one more thing about the birth name parameter.
If the birth name parameter is not going to be removed, I think at least the parameter name should be changed to something that can be unambiguously understood as "former legal name". 172.56.232.166 (talk) 03:38, 18 June 2025 (UTC)[reply]
I made more fixes regarding this issue, but it is so difficult to untangle this inconsistency. The "Birth name" parameter should have never been introduced. 172.56.55.208 (talk) 17:10, 18 August 2025 (UTC)[reply]
It looks like the "birth name" parameter is originally for real names of historical people in royal families (kings, queens, princes, princesses, etc.) who are usually known by their temple names or titles today.
If we are keeping temple names or titles of historical people in the "hangul" parameter, then the parameter for real names of historical people needs to have a better name. An expression like "born" or "birth name" is confusing, and is not really suitable when a historical person changed their real name (e.g. Taejo of Joseon changed his real name from 이성계 to 이단).
Another solution is to always place the real name at the "hangul" parameter, and create a new parameter for temple names and titles of historical people.
I kept thinking about this, and I think always place the real name at the "hangul" parameter, and create a new parameter for temple names and titles of historical people is better. I propose the following for names of people in any time period (02:09, 6 August 2025 (UTC) update – added hangulmyo and made some changes):
hangul: current (or at time of death) legal name (ALWAYS, unless unknown)
hangulmyo (NEW parameter; heading "Temple name"): temple name
hangulrt (NEW parameter; heading "Royal title"): royal names and titles for historical person in royal family
hangulfl (NEW parameter; heading "Former legal name"): any former legal names
hangulpen (NEW parameter; heading "Pen name"): pen name (필명; different from art name (호))
@Paper9oll How do you feel about the above proposal from a South Korean pop culture perspective?
I support the addition of hangulpen; think clearly good distinction.
I cautiously support the addition of hangulfl.
I cautiously support the removal of hangulborn.
I'm a little skeptical of the scoping and naming of hangulrt.
What is a "name" and what is a "title"? Is a temple name a name or title?
Can you classify all the names/titles listed here for Sejong?
Monarchs can have multiple royal names and titles, as given in my Sejong article above. What name goes in? Do we just use hangul1 etc for the other names?
Reading through, the "issue" with hangulborn appears to be mostly limited to historical figures. Since the count for this topic is insignificant on English Wikipedia, I don't see why it can't just be fixed if it hasn't been already, which I believe it has. Regarding hangulpen, since both stage names and pen names are essentially pseudonyms used as alternate names, we could map it to the existing hangulstage using #if and change the label accordingly based on the parameter declared, without introducing another parameter that functions identically. Essentially, if hangulstage has a value, then hangulpen would be ignored or hidden, and vice versa. This approach is already used in {{Infobox person}}, so there is precedent for this coding style from the most commonly used Infobox on English Wikipedia. I have no objection to the addition of hangulmyo and hangulrt. —Paper9oll(🔔 • 📝)14:27, 6 August 2025 (UTC)[reply]
Well, I think it is odd that there is a parameter for pseudonyms for only people in the entertainment industry and not for others. This is why I proposed a parameter for a pen name.
I kept thinking about this, and I started to think that introducing a new parameter hangulps (heading "Pseudonym") for any pseudonym (pen name, stage name, online handle, etc.) is a better idea. Multiple pseudonyms can all go into that parameter. Existing hangulstage can be replaced with hangulps by a bot (and hangulstage will be removed from the template). 172.56.55.222 (talk) 03:12, 17 August 2025 (UTC)[reply]
I believe my original reply already covers this where the only genuinely encyclopedic pseudonym types are stage names (actors, musicians, entertainers) and pen names (writers) in the context of Korean names. However, if there's a reason to cover an broader laundry list, regardless of whether those cases are genuinely encyclopedic, that should still be handled as a template coding change. We should change only the template's coding so it displays "Pseudonym" label whenever any of hangulstage, hangulpen, or hangulps (or any derivative parameter name, since this cosmetic naming keeps changing) is used. That preserves existing pages while giving readers a unified UX labeled under "Pseudonym". I'm opposed to a human using bot-driven migration for a template-level cosmetic changes, the #if conditional is the non-destructive and non-disruptive solution. —Paper9oll(🔔 • 📝)10:49, 17 August 2025 (UTC)[reply]
I would argue that the parameter name and the default heading should be more generic. The pseudonym parameter (hangulps, heading "Pseudonym") I am proposing is meant to cover any pseudonym: not just stage names and pen names, but also online handles or any pseudonym that does not belong to a specific type. For example, in the case of
Maangchi, 망치 is an online handle. This is neither a stage name nor a pen name.
Kim Dal-sam, 김달삼 is a pseudonym that does not belong to a specific type (not a stage name, pen name, online handle, etc.).
So I disagree with using the parameter name hangulstage and the heading "Stage name" as the default.
Disagree. Making disruptive changes to any articles when only a small portion are actually impacted is overkill; in this case, it's 1–2% out of 98–99% being affected. Sorry to say, I also don't understand the recent eagerness for this kind of behaviour, trying to "fix" everything by making sweeping replacements when majority of cases simply don't warrant it. This wasn't an issue previously, and I don't think the numbers are the real problem here, but rather the approach itself. It's like saying to demolish an entire neighborhood just to fix a single broken window. The scale of the response is completely disproportionate to the actual problem, causing needless disruption for everyone. —Paper9oll(🔔 • 📝)17:45, 17 August 2025 (UTC)[reply]
I think you're strongly misinterpreting this. We're saying we want to alter a parameter that affects <500 pages and none of the others. In other words, the vast majority of uses of the template will not be affected.
It's like saying to demolish an entire neighborhood just to fix a single broken window. This metaphor doesn't work. This metaphor would work if we needed to update ALL of the pages in order to fix <500, but that isn't happening. All we need to do is fix the <500. grapesurgeon (seefooddiet) (talk) 17:47, 17 August 2025 (UTC)[reply]
I don't think that I'm misinterpreting this. By saying "<500 pages is not so disruptive", you've implicitly suggested running AWB on those <500 pages, this is based on the assumption of your previous handling of similar situations. Otherwise, I don't see how those pages would be magically "fixed" unless you're referring to changing the template's coding, which would automatically update the <500 pages without any manual intervention. —Paper9oll(🔔 • 📝)17:56, 17 August 2025 (UTC)[reply]
I understand the stated plan is to use a bot request, and I know that filing one isn't difficult. However, my concern comes from what has actually happened in previous cases where AWB runs have still been used, regardless of what was said about bot request. I'm just not seeing consistent follow-through with bot use in practice, which is why I have doubts here and why I strongly object to this approach. This isn't about intent, but about what's actually done and discussed. I've no confidence that this would actually end up being a bot request. —Paper9oll(🔔 • 📝)18:06, 17 August 2025 (UTC)[reply]
Ok you're kinda right about the AWB thing, that was on me. I thought a bot req would be more feasible than it turned out to be for infobox conversions, but turned out there was a lot of manual fiddling that was needed. I should have planned that out better.
I don't think, we actually needed a bot request nor a replacement in this case even if it would be an easy one, maybe you want to refer to my proposal below instead. —Paper9oll(🔔 • 📝)18:35, 17 August 2025 (UTC)[reply]
I'm now wondering why any change is required. The template already provides othername1=–othername3= for custom headings, as well as hangul1=– hangul3= and/or hanja1=–hanja3= for the corresponding Hangul and/or Hanja, which covers the handful of fewer than ten articles that use a pen name or online handle. If a change is still desired, my agree-to-disagree proposal, since this is getting tiring, is a simple compromise as seen in the diff below (ready to implement): add explicit pen name and online handle parameters while leaving the stage name parameters untouched. This would be a small quality-of-life update for editors (if any) who prefer the convenience. I oppose introducing a broad catch-all "etc" parameter since "pseudonym" is broad, vague, and potentially abused. My proposal is intended to narrow the scope to common, well-defined use cases, while fringe cases, which still number fewer than ten after excluding articles that currently use the custom parameters for pen name or online handle, continue to use the existing custom parameters.
Okay, then at this moment, I will not propose something about pseudonyms (hangulstage will stay as-is, and a new parameter for any type of pseudonym will not be added; people should still use hangul[1-3] for pen names, online handles, etc.).
I think "pseudonym" is broad, vague, and potentially abused makes sense.
However, for a specific type of pseudonym (such as a pen name, not a generic one), if I discover that it is needed in 100+ pages, I may (re-)propose adding a parameter for that type of pseudonym in the future.
(By the way, I am not sure if Paper9oll's approach is a good idea because it is not impossible for a single person to go by two or more different types of pseudonyms. For example, you can publish books under the pseudonym A (pen name) and do online activities under the pseudonym B (online handle).) 172.56.55.120 (talk) 19:44, 17 August 2025 (UTC)[reply]
I think hangulstage should be renamed hangulpr ("Professional name" as the infobox header). This proposal is intended to widen the usage to not just entertainers, but also names used by writers and, potentially, online aliases. Instead of relying on hangul1, hangul2, and hangul3, which are voluntary parameters, they could be titled inconsistently by editors. "Professional name" could possibly be an umbrella term for all aforementioned situations. 103.186.160.35 (talk) 09:22, 21 August 2025 (UTC)[reply]
@Paper9oll Are you ok with the above? It'll largely affect historical people articles, although hangulfl and hangulborn will affect modern pop culture. Those we'll likely handle manually instead of with AWB or a bot. grapesurgeon (seefooddiet) (talk) 17:25, 18 August 2025 (UTC)[reply]
For modern people, this is what is going to happen (at least this is what I am planning to do):
hangulborn contains former legal name: the value will be moved to hangulfl.
hangulborn contains current (or at time of death) legal name: the value will be moved to hangul (and the value in the hangul parameter will be moved to a more appropriate parameter like hangulstage).
If it is difficult to determine what hangulborn contains, the value will be removed.
As stated above, I've no objection to the inclusion of hangulmyo and hangulrt, so please proceed with these only. However, I did object to the unnecessary cosmetic replacement from hangulborn to hangulfl. Additionally, I do not believe that there have been any changes to the interpretation discussed at the very beginning of this conversation i.e. to use hangul for the WP:COMMONNAME and use hangulborn for the birth name, which already aligns with MOS:NAME. As a sidenote, I intentionally didn't use the terms "legal" or "legal status" when referring to names since MOS:NAME advise against drawing those conclusions. That said, I can see how the adding hangulfl (rather than replacing hangulborn) could be useful, particularly in the context of MOS:MULTIPLENAMES. As another sidenote, we might want to consider renaming hangulborn to hangulbirth to better align with birth_name found in {{Infobox person}} or other BLP infoboxes, if considered, it would be a proper bot request. —Paper9oll(🔔 • 📝)18:26, 18 August 2025 (UTC)[reply]
I don't think born -> fl is a cosmetic change; it's a semantic one. People have just one birth name, but previous legal names can be multiple, incl. the birth name.
Ironically I'd argue that the born -> birth change is mostly cosmetic, although if we kept hangulborn around I wouldn't be opposed to renaming it to hangulbirth.
Also, I think you're misinterpreting MOS:NAME. It isn't really strongly relevant to this discussion. It's mostly addressing the lead, and not infobox. Also, it's not saying that we should avoid using the term "legal names" altogether, it's saying be precise about sourcing and communicating what is or isn't a legal name.
Thanks for the response. Before I really shutdown my PC and go to sleep, I just want to clarify my reference to MOS:NAME. My point is that since the infobox is functionally and visually connected to the lead, the standards or key principles set out in MOS:NAME should apply to both, not just the prose portion of the lead. If something isn't appropriate in the prose portion of the lead due to policy concerns about clarity, relevance, or sourcing, I don't see why the infobox would be exempt from that. Regarding former legal names, I agree that individuals can have multiple, but MOS:NAME advises against including all former names. This is why I stated that I don't mind addinghangulfl for such cases, but only if there is a strong case (e.g., if it's notably relevant) for its usage in the article(s) concerned. My proposal, as I've stated, is to use hangul for the common name, hangulborn or hangulbirth for the birth name, and hangulfl for a former legal name where it's notably relevant. —Paper9oll(🔔 • 📝)18:53, 18 August 2025 (UTC)[reply]
The problem is that "birth name" caused two different usages of parameters, as stated at the beginning of this discussion topic. This is why I am proposing removing that and introducing an unambiguous one like "former legal name".
By the way, when Grapesurgeon (Seefooddiet at the time) proposed hangul = current legal name, you agreed with this (Support as proposed by seafooddiet.). And after that, this was codified in the MOS and I made fixes regarding this.
But now, you are saying use hangul for the common name, hangulborn or hangulbirth for the birth name. You seem to be contradicting yourself. 172.56.55.104 (talk) 06:46, 19 August 2025 (UTC)[reply]
As stated earlier, I read through what was described as "confusion" and concluded that it affects only a small minority of historical figures' articles, which have already been addressed. I'm also not contradicting myself, by "hangul for common name", I literally meant the current [legal] name, and by "hangulborn or hangulbirth", I meant the [legal] name at birth. As I mentioned earlier, I intentionally omit any wording or terms that imply legal status; that's also why I purposely use brackets to enclose the word "legal" in the preceding sentence. With that in mind, I believe we should adopt a more neutral label without any legal connotations, something like "Former name" instead "Former legal name", using hangulfn= instead of hangulfl=. This would better align with existing headings, which do not imply any legal status or have legal connotations. In addition, this approach would also align with WP:BLP by not implying conclusiveness on legality and by remaining neutral in the presentation of such information. Preemptively, if there are any potential concerns for misuse, we could also restrict this parameter to only one notable usage, specifying this clearly in the documentation and here on the MOS, and monitor it. Based on my observation, any misuse should be picked up quickly (often within minutes or hours) by you or, at times, by Grapesurgeon, so in a best-case scenario, any potential "confusion" shouldn't even have a chance to arise. —Paper9oll(🔔 • 📝)14:16, 19 August 2025 (UTC)[reply]
Okay, if it is desirable to avoid a wording or term that imply legal status, then "former name" would work.
However, at this moment, I decided not to propose a parameter for "former (legal) name". I think I need to first check how many pages actually need this. If I discover that this is needed in 100+ pages, I may repropose this in the future. 172.56.55.85 (talk) 09:49, 20 August 2025 (UTC)[reply]
@Grapesurgeon Read carefully man, you cited MOS:LEGALNAME which is a true that legal name is mentioned however I don't see where is the legal connotations in the examples provided. What y'all are otherwise saying differs i.e. explicitly applying legal connotations. Also, MOS:LEGALNAME is the wrong example for what is being discussed i.e. a person having more than two notable names excluding the stage name, MOS:BIRTHNAME and MOS:MULTIPLENAMES should the correct one instead in which likewise, neither of the two or three has legal connotations. Likewise, none of the BLP infoboxes that this infobox would be combined into as a child module carries any legal connotations pertaining to names. —Paper9oll(🔔 • 📝)06:45, 21 August 2025 (UTC)[reply]
Please keep this polite and be patient. It is normal to disagree. You've pushed over line of rudeness multiple times in this conversation, dial it back; I've never been rude to you here.
I've read all of those policies. What I don't get is your wording of I intentionally omit any wording or terms that imply legal status. Where is this coming from? What if all RS (incl. the person themselves) confirmed that a person had gone by 3 different legal names throughout their lifetime? Would you still try to avoid mentioning legal status of their names? There's no policy reason to do so.
You also mention BLP, but that's not a feature of BLP either. Also what about for deceased people? Would you still try to avoid mentioning legal status of their names for them? grapesurgeon (seefooddiet) (talk) 08:43, 21 August 2025 (UTC)[reply]
MOS:NICKCRUFT This might be the most applicable guideline, but it's not the one you linked. However, in that footnote, it says Avoid clogging the lead with a boldfaced litany of these [variant names]; reserve them for an appropriate place in the body of the article, in an infobox or language sidebar, or in footnotes.grapesurgeon (seefooddiet) (talk) 08:54, 21 August 2025 (UTC)[reply]
Disagree that I'm being rude just being direct and informal which isn't wrong. I don't deli-dali around; if I disagree or am unhappy with something, I simply say it. The entire point that I'm making is that we should use neutral language when categorizing BLP names, not language that assumes or asserts legal connotations of those names, even if it is or could be reliably sourced. Regardless of which policies are cited, they all have one thing in common: they avoid legal connotations in any of their examples and when they mention a "legal name", they're simply using that term as a descriptive label for a type of name, not as a statement of legal fact or with any legal weight. However, literally using "Former legal name" or replacing "Birth name" with "Former legal name" would be assuming or asserting legal connotations of those names, regardless of whether it's sourced or not. While BLP does require reliable sourcing, actually determining a person's legal name typically requires access to legal documents, which we generally don't have, and seeking out such documents if published can run into WP:BLPPRIVACY concerns. Even if reputable sources report that x changed their name from y to z, that information would come from x or its affiliates and not from legal bodies; we can't and shouldn't automatically present that as a legal fact in Wikipedia articles. We can still present the information in the article, but without asserting legal connotation. That's why using neutral language is safer, more conservative, non-assertive, and more in line with policy, which is why "I intentionally omit any wording or terms that imply legal status". —Paper9oll(🔔 • 📝)09:56, 21 August 2025 (UTC)[reply]
Getting excessively informal and impatient with others is generally considered rude. Please don't double down on that; I don't treat you like that on purpose. I could, but don't.
I think all of that is a stretch. No explicit reading of any of those policies leads to that conclusion.
"If a person says 'this is my legal name'", I would say that information would come from that person or its affiliates and not from legal bodies. Even if "a journalist went and confirmed it", in most cases this simply means the subject or their representatives said so, as journalists rarely have direct access to definitive legal documents due to privacy restrictions. Therefore, we should avoid asserting legality unless the information comes from an actual legal record like a court order, deed poll, government record, etc. —Paper9oll(🔔 • 📝)10:12, 21 August 2025 (UTC)[reply]
...? It's quite common to be able to easily find legal names of public figures in many countries. E.g. like looking at a lawsuit or getting tax forms or voter registration records. A lot of those things are publicly available.
The reason I say "what if a person mentioned their legal name" is because it's not a privacy violation then. Then, if a journalist confirms it, the information is almost certainly accurate.
And more importantly, where is this concern stated explicitly in policy? It doesn't come from anywhere, otherwise you'd be able to quote it. grapesurgeon (seefooddiet) (talk) 10:21, 21 August 2025 (UTC)[reply]
I understand that in some countries (such as the US), certain legal records, like court filings or voter registrations, can be accessed by the public and may include their legal name, making this information relatively easy to verify. However in many countries, privacy laws are much stricter, and personal government records are not publicly accessible, even for public figures. Regarding policy, V and BLP both require that any potentially contentious material about living people be sourced and not overstated beyond what sources directly confirm. We can certainly include statements like "Foo announced their name is now Bar" or "it is reported that Foo announced their name to Bar" in the article text, with proper sourcing. However, neither statement confirms the definitive legal status of the name, it simply reports what Foo stated. Likewise, we can certainly include statements like "Foo announced their legal name is now Bar" or "it is reported that Foo announced their legal name to Bar" in the article text, with proper sourcing, but again, neither confirms the definitive legal status of the name. Therefore, summarizing such a name under the infobox label "Former legal name" when legality cannot be definitively confirmed would be factually incorrect, even if the reported information itself is factually accurate, note the distinction. —Paper9oll(🔔 • 📝)10:41, 21 August 2025 (UTC)[reply]
Again, and most importantly, where is "avoid assuming legal names" explicitly stated in policy? You've made a series of inferences to reach this conclusion, and the inferences are problematic.
Legal names are rarely ever considered to be contentious. Similarly, birthdays are not considered contentious. What would be contentious about it, other than like if it was a key factor in a criminal case or something? "My name is Frank Jones" is not a contentious statement; if someone announced their name and a journalist confirmed it somehow that is nowhere near contentious.
At this point, I feel like going to WP:3O or WP:RFC may be appropriate; I feel like most people would side against you on this. It's a fairly niche and imo extreme opinion. grapesurgeon (seefooddiet) (talk) 10:47, 21 August 2025 (UTC)[reply]
I already provided the policies and the principles that the policies is intended to do, I don't find it inferences but intepretation. If a subject or their affiliate claims a legal name change and this is reported in reputable media, that's suitable for inclusion in prose as a claim. However, summarizing it in an infobox under "former legal name" elevates it to a statement of verified fact, implying Wikipedia (and the inline sources) have confirmed the legal status, not just reported the claim. I agree that if the legal name is confirmed by an official source (such as a public court record), it can and should be stated as a legal fact. But in contexts (such as South Korea and many other countries) where that information is not verifiable through official documents, we should exercise the same caution as with any other detail about living people that cannot be independently confirmed. If you feel a broader consensus is needed, go ahead with WP:3O or WP:RFC. I do think, however, that my position is not an "extreme" one but a thoughtful one, and reflects Wikipedia's longstanding approach to verifiability, neutrality, and handling personal details in BLPs. —Paper9oll(🔔 • 📝)10:56, 21 August 2025 (UTC)[reply]
Inferences and interpretations functionally have the same meanings here. I'm saying your inferences/interpretations are not good. There are leaps in logic that I don't agree with. And I don't agree that there's such a severe weight on confirming legal names. Why would that be contentious? We already list birthdates in infoboxes, and those would need to be somehow legally confirmed (but basically never are). Do you have similar complaints about listing birth dates in infoboxes?
And yeah, we should go to 3O/RFC if this continues to be an issue. Again, this is a niche opinion. I have never seen anyone else make this argument. grapesurgeon (seefooddiet) (talk) 10:59, 21 August 2025 (UTC)[reply]
Yeah, okay with 3O/RFC. Inferences and interpretations, or any similar wording, can differ from person to person, and that's fine. My argument is not based on leaps in logic, but on how WP:BLP, WP:V, and WP:BLPPRIVACY work together, which I believe has been made clear. Equating date of birth and legal name is conflating two completely different things; I don't see any basis for a one-to-one comparison here. Even if it's interpreted that they're the same, what I do know that we're not presenting it as "Legal birth date" or "Legal born" or "born legally on" or use similar language here. —Paper9oll(🔔 • 📝)11:12, 21 August 2025 (UTC)[reply]
They're not so different. They're just bits of noncontentious information about people. Again, what would make a legal name a notable point of contention? For 99% of people it is just boring biographical information. grapesurgeon (seefooddiet) (talk) 16:22, 21 August 2025 (UTC)[reply]
Not exactly. Even for seemingly "boring" facts, there can still be contentiousness. Editors don't have a crystal ball. Under BLP policy, virtually any information about a living person falls under WP:CTOPS, so editors should exercise caution and maintain neutrality, even if factual accuracy is guaranteed but contextual accuracy is not. That said, I believe that this have come full circle. —Paper9oll(🔔 • 📝)17:39, 21 August 2025 (UTC)[reply]
You're looking at a 0.1% edge case where names can be contentious and are assuming it'll apply to 100%. And while CTOPs does apply to BLP, we're still allowed to provide coverage that's reasonably likely to be true about people.
If you attempt to argue this in how we regulate infobox params, this will be a 3O/RFC. I don't recommend it; this is a fringe position. grapesurgeon (seefooddiet) (talk) 18:15, 21 August 2025 (UTC)[reply]
What's edge or isn't, is incalculable. CTOPS doesn't stops "coverage that's reasonably likely to be true"; however these coverage are often handled via prose where proper writing allows for nuance and does not imply conclusiveness, rather than in a infobox with a conclusive label and no room to wiggle, it simply isn't a one-size-fits-all. This is what I have been emphasizing many times, and I find it puzzling that there has not been more consideration of the bigger picture or of other perspectives in this discussion. Regardless, my position remains the same and I will continue to do so if necessary. On 3O/RFC, I already addressed it earlier. —Paper9oll(🔔 • 📝)18:35, 21 August 2025 (UTC)[reply]
Just to be clear, I am still proposing the complete removal of hangulborn, because that parameter itself is tempting people to put the most recent (current or at the time of death) legal name there.
Whatever is in hangulborn will be moved or removed. For modern people, this is what is going to happen (at least this is what I am planning to do):
hangulborn contains former legal name: the value will be moved to hangul[1-3] with the heading "Former name".
hangulborn contains most recent legal name: the value will be moved to hangul (and the value in the hangul parameter will be moved to a more appropriate parameter like hangulstage).
If it is difficult to determine what hangulborn contains, the value will be removed.
We recommend you put a modern person's various names in the following parameters:
Current (or at time of death) legal name in |hangul=
Legal name at birth in |hangulborn=
Stage name in |hangulstage=
AFTER (you can make some copyedits if needed):
We recommend you put a person's various names as follows:
When a person's most recent (current or at the time of death) legal name is
known, always put that in |hangul=. Do not use another parameter for this.
unknown, then the common name can be put in |hangul=. When doing this, do not repeat that name elsewhere in the template.
For other names, if there is a designated parameter for a certain type of name, always use that (e.g. always use |hangulstage= for a stage name). If there is no designated parameter (e.g. pen name, online handle, any former names, etc.), use |hangul1=, |hangul2=, or |hangul3= with an appropriate heading.
Do not use "birth name". Historically this resulted in two different usages of parameters, and people had a hard time untangling this inconsistency.
Sorry, I would like to remove hangulmyo (temple name) I originally proposed and introduce hangulmo (heading "Monarch name") instead.
I proposed hangulmyo to cover names of monarchs. However, it looks like not all monarch names are temple names or posthumous names.
In some cases, it is difficult to determine the type of a monarch name. People should not have to spend time on determining this.
If this change causes any inconvenience to anyone, I apologize. I think I should have done more research. I will also make the necessary edits resulting from this change. 172.56.55.198 (talk) 20:32, 22 August 2025 (UTC)[reply]
I think we should just add mo without removing myo. Temple names are a feature of {{Infobox royalty}}. If we know for certain that a name is a temple name, I don't see why we shouldn't indicate in the infobox what their temple name is. Other names that we're less certain of we can just use mo. grapesurgeon (seefooddiet) (talk) 21:13, 22 August 2025 (UTC)[reply]
No, let's just always use a single parameter for any monarch name. As I said, people should not have to spend time determining if a certain monarch name is a temple name, posthumous name, or neither. 172.56.55.198 (talk) 21:15, 22 August 2025 (UTC)[reply]
Imo there's no need to rush. I just need to not reformat more infoboxes until we resolve this.
Per my previous comment, if we already know for certain what a name is I don't see why we shouldn't just indicate it. We know for certain the temple names of all the Joseon kings. If time is needed to determine what another name is, then it can just go in the catch-all mo. None of this requires significant extra time, because mo is a catchall that prevents wasting extra time. grapesurgeon (seefooddiet) (talk) 21:26, 22 August 2025 (UTC)[reply]
Well, this is what can happen if there are separate parameters for a temple name and a monarch name: when inputting the temple name of a monarch, some people may use the temple name parameter while other people may use the monarch name parameter. This is why I oppose the coexistence of both parameters. 172.56.55.198 (talk) 21:32, 22 August 2025 (UTC)[reply]
Imo they should just be corrected as needed. There are only so many monarchs, it's not like there'll be new pages. Once those parameters are in there's basically really little chance they'll change. grapesurgeon (seefooddiet) (talk) 21:33, 22 August 2025 (UTC)[reply]
Also, I want to avoid introducing a parameter that are used on only some tens of pages. Instead of having two separate parameters (hangulmyo and hangulmo in this case) each of which is used on some tens of pages, it is better to use a single parameter (hangulmo in this case) that can be used on 100+ pages. 172.56.55.198 (talk) 21:39, 22 August 2025 (UTC)[reply]
~_~ Imo this can go either way and I don't feel so strongly about it. I'm willing to concede and just follow your ask, but I'm still not really convinced. grapesurgeon (seefooddiet) (talk) 21:43, 22 August 2025 (UTC)[reply]
One thing I'm uncertain about. Couldn't temple names be considered both posthumous names and royal titles at the same time? grapesurgeon (seefooddiet) (talk) 23:06, 22 August 2025 (UTC)[reply]
For a concept like Busan, currently MOS:HANJALEAD is telling us we should show Hanja, as it has been significant before and after 1945. But my gut is telling me that's not necessary or helpful.
Kim Ku was also important before and after the division, and my gut is telling me Hanja is good for his lead.
Think the rule could be adjusted to like "Show Hanja if concept was significant before the division and now no longer exists".
"Show Hanja if a concept was significant before the division. If it is still significant today (for reasons that are not predominantly interest in its historical significance), do not show Hanja".
Examples:
Should show Hanja
Gyeongbokgung is significant before the division. It is still significant today as a tourist destination. However, its current relevance is predominantly due to interest in its historical significance.
Kim Ku is significant before and after the division. He is still significant today as a cultural symbol. However, his significance today is predominantly interest in his historical significance.
Should not show Hanja
Busan is significant before and after division, still significant, and not primarily due to its historical significance.
Seems an improvement if still flexible, although any general rule for people would be overruled if the individual in question prominently used/uses Hanja. CMD (talk) 18:16, 15 June 2025 (UTC)[reply]
Another way of resolving this kind of issue is always only showing hangul (no hanja, RR, or MR in any case) in the lead paragraph. If hanja, RR, or MR is needed, just always let the Infobox Korean name template take care of them.
When people create an article, they usually copy the format that already exists on another page, rather than checking the MOS.
Determining whether hanja is important or significant for a certain subject can be subjective or controversial.
This is too harsh a measure imo; showing these things is almost always helpful and rarely significantly inaccurate to the point of being harmful. Also in general, showing stuff only in infobox and not in article text is discouraged; we're technically in violation of that sometimes but we're in an extreme situation where we have a lot of information. grapesurgeon (seefooddiet) (talk) 11:35, 17 June 2025 (UTC)[reply]
First, [1] see this. In Korean, this film is called "Happy New Year" using a transliteration of the English phrase into Korean: 해피 뉴 이어 (Haepi nyu ieo). However, the Hanja on the article was given as "新年快乐", which is a Chinese-language phrase (not used in Korean) that means "Happy New Year". Think should prohibit doing things like this.
Second, [2] see this. IP user (regular on this talk page; one of the co-authors of the semi-automatic romanization module) deleted the use of several Chinese character phrases here that function similarly to Kun'yomi in Japanese. I think their decision is likely correct here, but wording it in MOS is tricky. I think Hangul/Hanja pairs should tightly correspond, rather than being linked by meaning. grapesurgeon (seefooddiet) (talk) 03:50, 19 June 2025 (UTC)[reply]
What about adding something like this?
The reading of hanja must match the contemporary Korean reading written in hangul.
Will think abt; wording still tricky. Even in your example there's an imprecision, "the contemporary Korean reading" implies a singular reading, but there can be multiple. MOS language difficult grapesurgeon (seefooddiet) (talk) 21:12, 19 June 2025 (UTC)[reply]
I agree that both are unnecessary. I'm not sure if the first one needs more MOS, though. It's fails WP:V as WP:OR. The second is tricky, but removal was justified. As I understand the situation, putting several purported Hanja in the lead when no single one is certain doesn't accurately portray the nuance of the situation. But again, not necessarily a MOS issue, just bad writing. Toadspike[Talk]14:17, 20 June 2025 (UTC)[reply]
I'd say MOS helpful because it's not obvious if/how this is WP:OR; having MOS is shortcut for explanation. Not obvious because one needs to know the relationship between Hanja and Hanzi to know it's OR. grapesurgeon (seefooddiet) (talk) 21:43, 8 July 2025 (UTC)[reply]
2 romanization display rules
Thinking about two changes to guidelines on when to show romanization.
Consider not showing excessively long romanizations in article text (excluding infoboxes; if infobox korean name or similar present, romanizations should always be shown there). They're hardly readable or intelligible to anyone, and they're really bulky. Example: [3] ignoring the egregiously incorrect romanizations, how many people would the long romanizations in the lead be useful for? Really few, and they're bulky.
Do not show romanizations of titles of works in article text (still can show in infobox) if the titles are already reasonably close transliterations of English-language terms. For example, [4]; how many people is "Byutipul Seondei" useful for? I don't think very many. Another example: Blackpink: The Movie; is it helpful to many if we show "Beullaekpingkeu: deo mubi" in the lead? I'd argue it isn't.
I would say that displaying RR and MR itself should be done sparingly. I would like to propose the following:
No RR and MR at all
in the lead paragraph (regardless of the length of the romanization, and regardless of how "unorthodox" or "nonstandard" the common form in English is). If RR and MR are needed, always use Infobox Korean name (or another infobox template).
anywhere (= including both in-line templates and infobox templates) for any word or phrase that is
usually translated (e.g. names of government agencies)
a mere hangul transcription of non-Korean word or phrase (e.g. 뷰티풀 선데이)
I agree that Hangul transcriptions of non-Korean terms are unnecessary in the lead.
I'm not sure about IP's broader attack on RR in the article body and infoboxes; it might stray a little too far from the principle of MOS:INFOBOXPURPOSE that nearly all info should be in the article.
We transliterate Cyrillic nearly everywhere, even when they are basically identical to the article title (see the second footnote after the name at Gorbachev or Stalin, two GAs). Sometimes readers just want to know how a person from that country would say the term, without wanting to learn the alphabet themselves. As a reader, I also find it interesting to know when a subject's Korean name is the transliterated English name; though Beautiful Sunday obviously has bigger problems, there currently wouldn't be any way for a reader who doesn't know Hangul to see this. Toadspike[Talk]14:28, 20 June 2025 (UTC)[reply]
Will respond more in depth later (I agree and disagree with parts of both your and IP's arguments), but noting that since Russian people don't have language infoboxes the romanizations in lead may be more important for them. grapesurgeon (seefooddiet) (talk) 18:43, 20 June 2025 (UTC)[reply]
I agree that Hangul transcriptions of non-Korean terms are unnecessary in the lead.
I did not say this.
Sometimes readers just want to know how a person from that country would say the term, without wanting to learn the alphabet themselves. As a reader, I also find it interesting to know when a subject's Korean name is the transliterated English name
I agree with IP that interestingness isn't adequate motivation for inclusion in first parentheses. The first parentheses should be for vital information, especially for navigation, and continually pushed to be more concise/readable. grapesurgeon (seefooddiet) (talk) 16:36, 4 July 2025 (UTC)[reply]
I agree that we should minimize the impact of excessively long romanizations, especially if there might be multiple of them. For example, in the article for the 2008 Summer Olympics in Beijing does not include the pinyin romanizations of the Chinese name for the Olympics. Alternatively, in the 2020 Summer Olympics in Tokyo, the article uses Explanatory footnotes for both the Japanese text and the Hepburn romanization. I disagree with the notion of not displaying romanizations in the lede paragraph as suggested by the IP. Not only could it possibly violate MOS:INFOBOXPURPOSE as Toadspike suggests, but also some infoboxes are extremely large (ex. Park Chung Hee), and would require some scrolling just to find the romanization. If redundancy is really a concern, it would be more efficient to get rid of the infoboxes rather than the other way around. I personally think keeping both are fine. ⁂CountHacker (talk) 22:17, 27 June 2025 (UTC)[reply]
I disagree with the notion of not displaying romanizations in the lede paragraph as suggested by the IP. & If redundancy is really a concern, it would be more efficient to get rid of the infoboxes rather than the other way around.
I disagree with this. A systematic romanization is not really something important that needs to be shown in the lead paragraph. For Park Chung Hee, what matters is that he is commonly known as "Park Chung Hee" in English and the native name is 박정희; the fact that 박정희 is "Bak Jeonghui" in RR is not really important. So an infobox is more suitable for a systematic romanization such as RR. 172.56.232.109 (talk) 07:32, 29 June 2025 (UTC)[reply]
I agree with CountHacker's point about large infoboxes.
I disagree with IP's point about RR not ever being useful in first parentheses. Imo RR's primary function in first paragraph would be to aid in navigation; making sure you're on the right page within a few seconds.
Sometimes people use significantly unusual romanizations, like Syngman Rhee. Having romanizations there can (but not always) aid in determining if you're on the right page.
For Rhee and Park, I know first hand that Koreans romanize their names in a variety of ways. For them, the WP:COMMONNAME on enwiki could be confusing. COMMONNAMEs aren't necessarily universal spellings, or even widely known in Korea. There are plenty of cases where some spellings are common outside of Korea, while a completely different spelling is common within Korea (e.g. "Hangeul" in SK vs Hangul outside).
I'm currently tempted to word guidance something like this:
Include romanization(s) in the first parentheses only if they are likely notably helpful to readers. For example, if the Korean term is significantly different from the main term, a romanization could aid in quickly helping the reader determine if they're on the right page. Do not include romanizations in the following cases:
1. the main term is already a close, perfect, or adequate match to the romanization. This includes cases where the Korean is itself a transliteration of some English term. For example, the Korean title of Hush (TV series) is 허쉬: Heoswi
2. the romanization is excessively lengthy (footnote: for excessively long romanizations, consider putting them in {{Infobox Korean name/auto}} instead.)
I agree with the first guidance, we don't need to romanize English (or foreign) loanwords back into Roman characters. Exceptions perhaps could be people with non-Korean full names notable for their work in Korea (ex. Ricky Kim/리키 김). For the second guidance, I think romanization should be allowed only if in the footnote. Also, it would be best to define what "excessively lengthy" exactly is to avoid potential headaches in the future. ⁂CountHacker (talk) 21:19, 8 July 2025 (UTC)[reply]
For first guidance, I'd say the exception example you give not so needed. Romanization of "리키 김" is just "Riki Gim"; imo doesn't really help for purpose of navigation to this article.
For second guidance, two thoughts:
I disagree with only show romanizations in footnotes. If a romanization is really short, think there's no reason to add technicality but putting stuff in a footnote (I'm betting many non-Wikipedians don't really know if/how to look in a content footnote; probably just confuse with references and ignore).
Also I'm not sure if/how we should define "excessively lengthy"; I was considering leaving deliberately vague and allowing local consensus to take hold.
Example 1: on a page with a wide infobox (like {{Infobox military conflict}}) that squeezes text, our tolerance for romanization length may be lower.
Example 2: if a romanization is medium length but low information or unhelpful, could argue should exclude. If a movie was called "2000년의 Hello and Goodbye" with English title "2000 Years Hello and Goodbye", I'd argue a romanization here is not helpful and somewhat lengthy. [edit: whoops this is untrue] It still passes condition #1 because it's not strictly identical to English title. But there's only two characters in that that are getting romanized ("년의"). It's not necessarily that long of a string, but it's long enough and low info enough to be not helpful.
Sorry, I should have clarified that for the second guidance I meant that I meant "allowed only if in the footnote" in the lede paragraph and/or infoboxes for specifically "excessively lengthy" romanizations. I'm definitely pro-romanization in the lede paragraph as long as its not too lengthy that it disrupts being able to read the article. I guess it will be better for a consensus to form organically what explain what the gets defined as excessively lengthy. ⁂CountHacker (talk) 02:46, 9 July 2025 (UTC)[reply]
Imo RR's primary function in first paragraph would be to aid in navigation [...] For them, the WP:COMMONNAME on enwiki could be confusing. COMMONNAMEs aren't necessarily universal spellings, or even widely known in Korea.
You do not need RR or MR for this purpose. If Korean speakers not recognizing the common name in English is your concern, then what you need to show in the first parentheses is hangul, not RR or MR. So I am still proposing what I wrote above. 172.56.232.253 (talk) 04:38, 9 July 2025 (UTC)[reply]
Korean speakers are just one example of a potential use case, not a complete list of use cases. For like names of films/television shows where the Korean-language titles are significantly different from the English, it can be helpful for people who can't read Hangul to know what the title roughly sounds like in Korean via the romanization. grapesurgeon (seefooddiet) (talk) 04:53, 9 July 2025 (UTC)[reply]
That kind of information is also just something that some people may find "interesting"; so an infobox is more suitable for RR and MR. 172.56.232.253 (talk) 05:15, 9 July 2025 (UTC)[reply]
Disambiguating films or TV shows can be done by showing/comparing their release dates, casts, etc.; not necessarily by showing how the title roughly sounds like in Korean. (I still don't understand how providing a romanization in the first parentheses can help with disambiguation.) 172.56.232.253 (talk) 06:40, 9 July 2025 (UTC)[reply]
For example, the show Infinite Challenge is sometimes referred to in the press and social media as its romanized title "Muhan Dojeon". The romanization is a significant name for the work, so needs to go in lead somewhere; why not in the first parentheses? The alternative is "Infinite Challenge (Korean: 무한도전), romanized as Muhan Dojeon", but that's just a longer way of doing the same thing. grapesurgeon (seefooddiet) (talk) 21:40, 14 July 2025 (UTC)[reply]
Actually, I think the alternative is better. That can also cover any ad-hoc spellings. For example, if Infinite Challenge were also commonly known as "Moohahn Dohjuhn" (and not as "Muhan Dojeon"), that syntax can cover this too. Strict RR/MR cannot cover cases like this. 172.56.232.109 (talk) 15:33, 15 July 2025 (UTC)[reply]
Well, to do that, editors have to know which spelling corresponds to strict RR/MR and which spelling does not (even with semi-automatic romanizations, you have to check the result that the module generates). I think this just adds an extra step or an unnecessary burden. 172.56.232.109 (talk) 23:16, 23 July 2025 (UTC)[reply]
Note: I am not saying the above because I know Korean and hangul. I know almost nothing about Arabic, but even if Wikipedia articles containing Arabic terms do not provide any systematic romanization for each Arabic term in Arabic-related templates at all, I would not complain. 172.56.232.109 (talk) 07:32, 29 June 2025 (UTC)[reply]
Titles of works: casing
Semi-auto romanization is about a little under halfway done being deployed on enwiki. For romanized titles of works, I've been using sentence case. Almost all South Korean TV series and films now use that casing. However, I'm not sure if this is best practice; before my changes I feel like there was a split between whether articles previously used sentence case or title case, with a leaning towards title case. I should have started this thread earlier, sorry 😓. I'll fix if we decide to change.
In East Asian studies academia, sentence case is widespread for romanized titles of works: WP:ROMANKO#Other style guidelines. My experience aligns with this too.
I'm not sure what is done in journalism on pop media. I suspect title case is popular? But I rarely read journalism on pop media so wouldn't know.
TLDR: based on above, our casing practices should match what is widely done outside Wikipedia. We may need to balance/distinguish between what is done in academia and in journalism.
Think we have two options:
Use sentence case for all romanized titles of works
Use sentence case for academic/historical works, use title case for contemporary pop culture works
If you want #2, you'd need to provide evidence of widespread practice. I'm open to 2, but a little skeptical of it. I think it'll be a little confusing; pop culture people may try to change history article casing, and vice versa. Also, it'd require us going back and changing every SK pop culture article; we're already entirely consistently sentence case rn. grapesurgeon (seefooddiet) (talk) 21:33, 14 July 2025 (UTC)[reply]
Currently, the wording for merging {{Infobox Korean name/auto}} (and eventually {{Infobox Korean name}} after conversion is completed) into broader infoboxes like {{Infobox person}} does not address the duplication that occurs when the Korean name is also filled into the |native_name= parameter. MOS:INFOBOXPURPOSE already addresses that the main function of an infobox is to summarize information, so it would be illogical to present the same information twice.
To address this, I propose changing the following sentence for clarity and consistency:
−
If there is another infobox in the article (e.g. {{tl|Infobox person}}), we recommend you merge the name infobox into the other infobox.
+
If there is another infobox in the article (e.g. {{tl|Infobox person}}), we recommend you merge the name infobox into the other infobox. When doing so, do not duplicate the Korean name by also filling in the <code>|native_name=</code> parameter, as this leads to redundancy and violates [[MOS:INFOBOXPURPOSE]].
I've been bothered by the same issue. I agree with proposal. There's also the issue of people putting in the Korean names in the name parameter, like |name=asdf<br>안녕. Not sure what to do there grapesurgeon (seefooddiet) (talk) 18:51, 10 August 2025 (UTC)[reply]
Thanks, glad to hear you've noticed the same issue. I hadn't personally observed the |name= + Hangul combination myself, so I didn't include it in the original proposal. But your point highlights a similar concern: when {{Infobox Korean name}} is merged into a broader infobox, the Hangul shouldn't be repeated elsewhere, whether it's in |native_name=, |name=, or any other parameter.
I've updated the proposed wording below to cover such cases without listing out a list of parameters:
−
If there is another infobox in the article (e.g. {{tl|Infobox person}}), we recommend you merge the name infobox into the other infobox.
+
If there is another infobox in the article (e.g. {{tl|Infobox person}}), we recommend you merge the name infobox into the other infobox. When doing so, do not duplicate the Korean name elsewhere in the infobox, as this leads to redundancy and violates [[MOS:INFOBOXPURPOSE]].
BOLDly added this section: MOS:KO-SPACE. I figure it's probably uncontroversial, but please speak up if disagree. It's basically just telling people to follow official spacing recommendations and not be sloppy about spacing. Happy to revert and discuss. grapesurgeon (seefooddiet) (talk) 17:37, 14 August 2025 (UTC)[reply]
