Wikipedia talk:Manual of Style/Korea-related articles

Hangeul on media-related pages, such as Dramas for Character names
So I've been struggling with the Reply 1997 article where people keep adding the wrong name back to the article because popular belief is wrong, and I'd like to add hangeul to the page for all characters on the page so the wrong edit doesn't happen. His name is Yoon Yoon Je. I cited it well. I read hangeul.

There's 2 options I propose with this: Either I'm allowed to use hangeul on the page to spell out the names of all of the characters from the official spellings.

OR I'm allowed to add a controversy line to the page about the spelling of the character's name. I've added to the talk page, did citations, but people keep trying to revert the name *despite this* Since there is a clarity issue, I believe something needs to be done to clarify the correct name on the page. Including, but not limited to, calling out the subbers for getting it wrong in the first place.

So I'm asking what's allowed according to the Manual of style. Personally, I'd like the more elegant choice of being able to add the hangeul to character names without a whole section about it. I also believe it would be useful on Japanese and Chinese dramas pages, as often the spellings of the character names and their meanings helps the average consumer understand the media better. (And it takes sometimes forever to find the spelling, having to travel through the language, which may be inaccessible for the average English speaker, but an English speaker may be able to use wikitionary to find it.--KimYunmi (talk) 15:02, 19 July 2023 (UTC)


 * As this is the English Wikipedia, the article should follow the spelling used by independent reliable English-language sources. On the first instance of each name, you should use the {{Korean}} template to indicate the Korean spellings of each name, in addition to the English spelling. Since the name is being disputed, you also need to add a citation to a reliable source (screenshots don't count as subtitles can be inconsistent depending on the streaming platform).
 * For example:
 * Kim Jong Un
 * Moon Jae-in
 * Syngman Rhee
 * Park Chung Hee
 * When discussing disputes on things like names, always be aware of certain Wikipedia policies and procedures, including WP:BRD and WP:EW. There is no deadline for Wikipedia articles to be finished by, so please do discuss any disputed edits with other editors in a civil manner. : 3 F4U (they/it) 17:56, 19 July 2023 (UTC)


 * One thing to note is that in reality there is no strict one-to-one correspondence between a hangul name and a romanized Korean name. For example,
 * Hangul to Latin: 윤 – "yoon" in Chung Yoon-hoi, "yun" in Yunjin Kim
 * Latin to Hangul: "jung" – 중 in Kim Dae-jung, 정 in Youn Yuh-jung
 * So the fact that it is originally 제 in hangul does not necessarily mean that its romanized form must be "je". 2607:FB91:8815:D4B7:E41F:50E2:96CE:EB2A (talk) 06:30, 2 September 2023 (UTC)

About adding a link to each hangul syllable using Template:Linktext
Discussion closed. 172.56.232.167 (talk) 00:10, 2 February 2024 (UTC)

Notice: Unless something unusual happens, this discussion will be closed at 23:59, 1 February 2024 (UTC), and what I wrote below will be added to the MOS page and a bot request will be made. 172.56.232.187 (talk) 03:51, 27 January 2024 (UTC)

Note:
 * Before reading this, having some knowledge of the Korean language would be helpful.
 * This is not to entirely prohibit using Linktext in hangul text.
 * If what I wrote below is too long or unclear, see.

I sometimes see Template:Linktext used to add a link to each hangul syllable. For example,
 * in National Library of Korea
 * in Ewha Womans University
 * in Capital Region First Ring Expressway
 * in Bad Movie
 * in My Wife Got Married
 * in The Scent
 * in Even the Clouds Are Drifting
 * in City of Damnation
 * in Saturday Night Live Korea
 * in Yoon Suk Yeol
 * in Kim Ha-nul (figure skater)
 * in Lee Elijah
 * For more cases, see this (6376 cases as of 03:43, 19 January 2024 (UTC)).

But this should not be done. Adding a link to each hangul syllable does not help readers. It is sometimes even misleading.
 * 1) A word or morpheme in Korean is not always one syllable long. A syllable in Korean is not something special; it is just like a syllable in many other languages. In Korean, like many other languages, there are lots of single words or single morphemes consisting of multiple syllables. For example,
 * 2) * 구름 (cloud) is a two-syllable word consisting of a single morpheme; the individual syllables 구 and 름 do not mean anything. So dividing 구름 into 구 and 름 is meaningless.
 * 3) * 기다리는 is 기다리- (verb stem) + -는 (ending), but 기다리- is a three-syllable single morpheme and cannot be broken further.
 * 4) Blindly adding a link to each syllable in a word can even make readers misunderstand the meaning of the word. For example,
 * 5) * Wiktionary currently gives that 하 is "last, lowest" and 늘 is "always, forever". So if someone encounters  and clicks the individual links, they might think 하늘 means something like "always the lowest", which is completely wrong. (하늘 means "sky".)
 * 6) * The entries 기, 다, and 리 do not give any idea what 기다리- actually means. Readers will be confused. (기다리다 means "to wait for".)
 * 7) Even in a word consisting of multiple morphemes,
 * 8) adding a link to an entire "word" is much more helpful than adding a link to each morpheme in a word. (And it is not Wikipedia's job to break down a word – that is what Wiktionary is for.)
 * 9) * For example, adding a link to 도서관 (library) is more helpful than separately adding links to 도 (picture), 서 (writing), and 관 (building).
 * 10) a morpheme boundary does not always correspond to a syllable boundary. For example,
 * 11) * 나래 (wing (literary); sometimes used as personal names) consists of two morphemes which are not 나 and 래. Instead, it is actually 날- (verb stem) + -애 (suffix), so separating it as 나 and 래 is incorrect.
 * 12) * 나쁜 (bad (modifier form)) is not 나 + 쁜, but 나쁘- (adjective stem) + -ㄴ (ending; yes, a single consonant). So separating it as 나 and 쁜 is incorrect.
 * 13) There are also irregular verbs/adjectives. For example,
 * 14) * 흘러 is not 흘 + 러, but 흐르- (verb stem) + -어 (ending).
 * 15) * -스러운 is not 스 + 러 + 운, but 스럽- (adjective stem) + -은 (ending). (-스럽다 is an adjective-creating suffix; any word that ends in 스럽다 is an adjective irregularly conjugated like this)
 * 16) Korean verbs and adjectives are conjugated.
 * 17) Linktext does not support a piped link. For example, something like   cannot be done by Linktext.
 * 18) Wiktionary sometimes redirects a conjugated form to its basic form, but does not (and very likely will not) have all conjugated forms as redirects.
 * 19) For loanwords or hangul transcriptions of words of non-Korean origin (like 새터데이 나이트 라이브 코리아 and 엘리야 above), it makes no sense at all to separate each hangul syllable.
 * 20) For personal names (including pseudonyms such as pen names, stage names, etc.), no links should be added.
 * 21) * This includes not just  but also other forms of segmentations such as   and , and also the unsegmented  . That is, do not add any kind of link to a personal name.
 * 22) Koreans do not have culturally common names like John or Muhammad. A Korean personal name can literally be a combination of pretty much any hangul and/or hanja (as long as it does not mean/sound something negative). In other words, Korean personal names are usually made-up words and thus semantically opaque.
 * 23) * For example, it is not possible to figure out what the given name 석열 (or the individual syllables 석 and 열) means solely from the hangul spelling. So adding a link to 석열 or 석 or 열 does not give much benefit.
 * 24) Even when the meaning of a personal name is absolutely semantically transparent (i.e. can be clearly understood without any doubt at all), there is still no need for links. The meaning of a personal name could be something that some people may find "interesting", but it is not really something useful or helpful. It does not really have practical value.
 * 25) It does not help understand what kind of person they are.
 * 26) * For example, people named "Jesús" in the Spanish-speaking culture sphere are not actually Jesus. Likewise, people named 하늘 are not actually the sky; people named 나래 are not wings, nor do they have wings.
 * 27) Understanding the meaning of a name is not even necessary.
 * 28) * For example, we do not even have to know what "Jack" means in order to call or mention someone named Jack. Likewise, we do not even have to know what 석열 means in order to call or mention someone named 석열.
 * 29) Wiktionary cannot have entries for all Korean personal names (to reiterate, they are usually made-up words). Even if it can, it usually cannot really give a definition other than "a personal name", which is what readers already know even before clicking a link on Wikipedia. (In other words, readers will not find anything beyond what they can figure out on Wikipedia.)
 * 30) A link to Wiktionary is not a requirement.
 * 31) Wikipedia does not have to provide a link for every single non-English term.
 * 32) If the meaning of a certain Korean term must be explained in a Wikipedia article for some reason (such as for a better understanding of the topic), the explanation can be simply given within that article without Linktext.
 * 33) While it is not a requirement, this does not mean that creating any kind of link is okay. Links should be helpful and not be misleading. Giving misleading or wrong information is worse than not giving any information.
 * 34) Wiktionary is a different website with different policies. It does not have to (and may not always) meet Wikipedia's needs.
 * 35) In fact, Wiktionary used to allow "hangul syllable" entries with no lexical content, but they were deleted in 2021 and are no longer allowed (for the relevant discussion, see wikt:Wiktionary:Beer parlour/2021/August). So, even if Wikipedia keeps having a link for each hangul syllable, it is certain that Wiktionary will not always have an entry for it. For example, Wiktionary will not have entries like 쁜 or 했, which are not lexical units in Korean.
 * 36) Also, terms that are not suitable for dictionary entries (e.g. 새터데이 – merely a transcription of English "Saturday" and is not used as a word in Korean) should not have links. They do not appear in a dictionary, so adding links to such terms is meaningless.
 * 37) * This includes not just  but also other forms of segmentations (,  ,  ,  , etc.), and also the unsegmented  . That is, do not add any kind of link to a term that is not suitable for a dictionary entry.

I propose that
 * 1) existing Linktext templates adding a link to each hangul syllable be removed (this can be done by a bot; each parameter containing nothing more than  );
 * 2) * Note that, as I wrote above, this is not to entirely prohibit using Linktext in hangul text. The Linktext templates removed at this moment can be re-added (except for personal names and terms unsuitable for dictionary entries), but it must be added with the correct or appropriate links. For example, once Linktext is removed from  and becomes , someone can re-add Linktext (if they want to; re-adding is not a requirement), but it must be.
 * 3) existing Linktext templates in personal names and in terms unsuitable for dictionary entries be removed (some of these can be done by a bot, but some of them need to be removed manually (because there are cases in which a single parameter contains two or more hangul syllables, like  )); and
 * 4) the following be added right before Manual of Style/Korea-related articles.

===Adding links to hangul text=== When using to hangul text, do not blindly add a link to each hangul syllable. A word or morpheme in Korean is not always one syllable long (e.g. 기다리다 is a single word, not four words). Also, hangul is not a logographic writing system, so there is no point of emphasizing or focusing on each hangul character. * Add links to meaningful lexical items in Korean. Prioritize words. For example,, not. ** Incorrect links are also not allowed. For example,, not   (unless the term really means "college, fish, church"). ** Circumventing this by using other ways of linking (e.g.,  , etc.) is also not allowed. * For personal names (including pseudonyms such as pen names, stage names, etc.), do not add any links. The meaning of a name does not describe a person, and the definition of a personal name is usually nothing more than "a personal name". * Do not add Linktext to terms that are not suitable for dictionary entries (e.g. 새터데이 – merely a transcription of English "Saturday" and is not used as a word in Korean). * Using Linktext is not a requirement. ** If you do not have enough knowledge of Korean vocabulary to determine meaningful lexical items or whether a term is suitable for a dictionary entry or not, do not add any links. Do not attempt to segment hangul text either (you may end up adding incorrect links). ** If the meaning of a Korean term must be explained in an article, the explanation can be simply given within that article without the Linktext template. ** When there is any dispute about using Linktext, the burden lies with the editor who wants to add/retain the Linktext template. But any instance of the Linktext template should be in compliance with the rule above (i.e. should not add a link to each syllable, should not have incorrect links, etc.). * Note that Linktext does not support a piped link, which means it is not suitable for conjugated forms of verbs/adjectives. For example, it is not possible to create links like  using Linktext. 172.56.232.220 (talk) 17:47, 11 January 2024 (UTC)

If what I wrote above is too long or unclear, here is a summary. 172.56.232.205 (talk) 19:05, 12 January 2024 (UTC)
 * Summary
 * 1) What this is about
 * 2) * This is mainly and basically to ensure that Korean hangul text gets links that actually make sense in Korean. The existing practice—blindly adding a link to each hangul syllable—is unhelpful and misleading. This needs to stop.
 * 3) What this will prohibit
 * 4) * Blindly adding a link to each hangul syllable (e.g. )
 * 5) * Adding links to personal names and to terms not suitable for dictionary entries (e.g. 윤석열, 새터데이)
 * 6) What this will not prohibit
 * 7) * Linktext with correct/appropriate links (e.g. )
 * 8) ** But using Linktext is not a requirement. It is perfectly fine to not add the template (e.g.  without Linktext is perfectly fine).
 * Support I've also noticed this issue and have been bothered by it. You've thought of a lot of edge cases that I hadn't considered before; I've been digesting them since you posted and I think I agree. I'm on the fence about removing all previous linktexts; I don't know the technical details of how using bots to perform this action looks like, but I lean towards support pending other opinions. toobigtokale (talk) 00:34, 13 January 2024 (UTC)
 * Thank you for supporting.
 * I am fine with removing all existing Linktext containing hangul (i.e. even removing Linktext in cases like ), but I did not propose that because that could be perceived as something too extreme. But if others think removing all existing Linktext containing hangul is better, then I will not oppose.
 * For the bot request regarding what I wrote above (removing existing Linktext adding a link to each hangul syllable), I actually asked a question last month and got a reply saying that it is possible. See Bot requests (link as of this writing). 172.56.232.83 (talk) 01:47, 13 January 2024 (UTC)
 * Ah I misspoke, I support removing all single char hangul linktexts, and am more skeptical towards removing all linktexts but also lean support. toobigtokale (talk) 05:38, 13 January 2024 (UTC)
 * 172.56.232.205, In general, I think the mass wiktionary linking of words and glyphs in Korean, Chinese, and Japanese as seen on many articles is indiscriminate and doesn't help the vast majority of readers. I think as a rule, literally all of it should be removed when the passage isn't MOS:WAW, or when the term has its own etc. —  Remsense  诉  22:09, 18 January 2024 (UTC)
 * This discussion is about Linktext being used to create unhelpful and misleading links in Korean hangul text. This is not about the general use of Linktext throughout Wikipedia.
 * Personally, I am even fine with removing every single instance of Linktext regardless of its location (even the ones in infoboxes) and language/script (I would not complain even if the Linktext template itself does not exist, or even if Wikipedia does not provide any link to Wiktionary at all), but I am not proposing that here because that is not specific to Korean and could be way too extreme.
 * If you want to restrict the use of Linktext throughout Wikipedia, then that should be discussed on a different page. 172.56.232.224 (talk) 00:04, 19 January 2024 (UTC)
 * 172.56.232.224, I merely mentioned that it seems to be part of a broader, connected problem with the languages mentioned. — Remsense  诉  01:07, 19 January 2024 (UTC)

It has been a week. Any more comments? It is a bit long, but please give it a read and leave a comment here. 172.56.232.26 (talk) 20:34, 18 January 2024 (UTC)
 * Support MOS changes as sensible. linktext is beneficial if done correctly, but misleading if done incorrectly. Hold off on bot removal of single-syllable linktexts, as there exist cases where single syllables are complete morphemes (even unbound morphemes) and the link would be correct. For now I think it would be helpful to have a bot just list all pages where such links occur (and for the bot to update the list automatically on, e.g. a weekly basis based on the edits in the previous week), so we can assess the scale of the problem and see whether human review is even feasible or whether the best solution is to WP:TNT all the single-syllable links and start over. 59.149.117.119 (talk) 22:47, 18 January 2024 (UTC)
 * (For the benefit of anyone reading this discussion who doesn't know Korean, note that English has the exact same problem where multi-syllable words happen to be formed from single syllables with totally unrelated meanings:, , etc.) 59.149.117.119 (talk) 22:47, 18 January 2024 (UTC)
 * I suspect there are potentially thousands of pages where this occurs; there are around 47,000 pages in WikiProject Korea. Anecdotal, but I've personally reviewed around 10,000 of those pages so far, and in my experience the linktexts are rarely well-done. I think removing single-syllable at the very least is a good move. Rather than making this a multi-step process and creating more work for us to do, wiping the slate clean is better imo. toobigtokale (talk) 23:33, 18 January 2024 (UTC)
 * Well, "there exist cases where single syllables are complete morphemes (even unbound morphemes) and the link would be correct" could be true, but I am still inclined to remove all existing single-syllable Linktext by a bot.
 * We cannot manually check all 6300+ existing cases (if you haven't, click on "this" in "For more cases, see this" above).
 * Don't forget that not everyone on Wikipedia can do this. This can only be done by a small number of people who have enough knowledge of Korean.
 * Linktext has never been a requirement, which means any instance of Linktext does not have to be there in the first place. That is, any existing instance of Linktext does not have to be retained.
 * For "cases where single syllables are complete morphemes (even unbound morphemes)", Linktext can be manually re-added later (after removed by a bot). 172.56.232.224 (talk) 23:39, 18 January 2024 (UTC)
 * Oh the "this" link is nice. Nice regex, didn't even know that was possible on Wiki search.
 * I'm one of the most frequent editors on Korea-related articles, and I just can't manually look through and fix 6,300 instances of this. Scrolling through, few of these seem to be useful anyway. Hanja linktexts are occasionally helpful for me, but even then Wiktionary is missing a lot. toobigtokale (talk) 23:44, 18 January 2024 (UTC)
 * Support MOS changes and would tentatively support bot removal in obvious cases where an editor simply piped each glyph (probably just following examples of other article ledes). However IP58 above makes the better point to run a bot gather data first -- might as well. Regardless, to minimize false positive examples discussed above, a bot could remove linktext and similar from only space-separted strings of at least two words of at least N glyphs. (So if I were showing a linguistics example where I intentionally separate the bound morphemes in English, that kind of thing is less likely to get flagged.)
 * I echo IP172 that this is a concern for any CJK scripts -- and really, any linking done glyph-by-glyph of text of any script (apart from IPA and other such encodings, where it arguably (but not always) makes sense to link each glyph in transcriptions)).) Maybe in parallel take this up to the WikiProjects (WP:LANG seems empty, but WP:LING is active) and Pump? SamuelRiv (talk) 02:36, 19 January 2024 (UTC)
 * If anyone says anything about checking existing cases before removing them by a bot, I will just repeat this.
 * We cannot manually check all 6300+ existing cases (if you haven't, click on "this" in "For more cases, see this" above).
 * Don't forget that not everyone on Wikipedia can do this. This can only be done by a small number of people who have enough knowledge of Korean.
 * Linktext has never been a requirement, which means any instance of Linktext does not have to be there in the first place. That is, any existing instance of Linktext does not have to be retained. 172.56.232.172 (talk) 03:43, 19 January 2024 (UTC)
 * We cannot manually check all 6300+ existing cases That's really not that many, particularly given that WP:THEREISNODEADLINE. Get a bot to make a list of them and section the list into groups of a hundred; sign your name at the top of the section when you start reviewing it; remove the section when it's complete. This kind of simple mechanism has dealt with much bigger problems than 6300 pages. 59.149.117.119 (talk) 05:10, 19 January 2024 (UTC)
 * There's only like 1-3 regular contributors to WPK who can do this work. There really aren't that many regular Korean-speaking editors on WPK; this is even true historically, to my knowledge. In other words, even with "no deadline", given the number of "no deadline" critical projects that have been left undone on WPK, this may just collect dust. And based on what I'm seeing from scrolling through, I think like >90% of cases aren't good uses of linktext. I think I'd be able to get AWB to speed up the review, but I'd be unhappy doing it. The to-do list for WikiProject Korea is very long; this strikes me as mounds of busywork for very little gain. Do you speak Korean and can you help? toobigtokale (talk) 05:19, 19 January 2024 (UTC)
 * Do you speak Korean and can you help? Yes; been working on this problem for years already. The main barrier was never the actual spent time fixing links, but finding instances of the problem in the first place. (I had no idea until this morning that Special:Search supported regexes.) Also, automated removal of linktext from infoboxes of biographies (which I assume is uncontroversial) will significantly cut down that list of 6300 articles. 59.149.117.119 (talk) 08:33, 19 January 2024 (UTC)
 * Ok, if we do automatic removal for all people that'd help a lot. I still don't view the risk of removing all the linktexts on one-char hangul as very significant of a risk though. But I doubt we'll convince each other. If you're volunteering to work on addressing the problem then I'm willing to support your plan. toobigtokale (talk) 10:04, 19 January 2024 (UTC)
 * Well, 59.149.117.119 neither brought any actual examples here, nor showed removing all single-syllable Linktext by a bot can cause a serious problem though. 172.56.232.38 (talk) 15:54, 19 January 2024 (UTC)
 * In the event that they don't reply again, I'd prefer we just delete all single-syllable linktexts. I've been editing lots of pages for mountains that suffer from this issue; people articles aren't the only culprit. toobigtokale (talk) 03:06, 22 January 2024 (UTC)
 * Agree. We should just start with a bot removal. If someone wants to re-add Linktext with correct or appropriate links, they can do that after the bot removal. 172.56.232.24 (talk) 23:24, 22 January 2024 (UTC)
 * We're approaching one week since no reply from 59.149.117.119. Once we pass that mark, I think we're probably good to move forward with your proposed changes. toobigtokale (talk) 18:36, 25 January 2024 (UTC)
 * Agree. The bot removal should not be delayed just because of manual work. 172.56.232.84 (talk) 20:13, 25 January 2024 (UTC)
 * By the way, it looks like this issue is found in various fields. Articles about movies and railway stations are also greatly suffering from this. 172.56.232.113 (talk) 23:27, 29 January 2024 (UTC)
 * Did I not say this?
 * "Linktext has never been a requirement, which means any instance of Linktext does not have to be there in the first place. That is, any existing instance of Linktext does not have to be retained." (bold added)
 * Why should we spend time checking every single instance of something that is not even a requirement?
 * At least I am not going to manually check all those cases. 172.56.232.75 (talk) 05:33, 19 January 2024 (UTC)
 * Did I not say this? Linktext has never been a requirement Yes, but it doesn't become any more convincing by repeating it or by prefixing it with rhetorical questions. The fact that linktext is "not required" does not mean you can go around removing them with no regard for collateral damage such as removal of correct and helpful links, or cases where human review would easily fix the problem. The actual guideline here is WP:SISTER: Wikipedia encourages links from Wikipedia articles to pages on sister projects when such links are likely to be useful to our readers.
 * Automated removal should be restricted to things which clearly violate the proposed guidelines, e.g. automated removal of linktext from infoboxes in biographies (i.e. articles in the Category:People tree), per For personal names (including pseudonyms such as pen names, stage names, etc.), do not add any links. (Worth noting that the overwhelming majority of the 6000 articles in the search link you posted are biographies.) 59.149.117.119 (talk) 08:33, 19 January 2024 (UTC)
 * You said that there exist cases where single syllables are complete morphemes (even unbound morphemes) and the link would be correct and that (there could be) collateral damage such as removal of correct and helpful links (when removing them), but can you bring some actual examples of such cases here? 172.56.232.141 (talk) 08:54, 19 January 2024 (UTC)
 * By the way, "there is no deadline" does not mean you can make others wait. As the person who started this discussion, I do not want this to take longer than a month (and a week has already passed).
 * Unless you can show that removing all single-syllable Linktext by a bot can cause a serious problem, I am not convinced. 172.56.232.38 (talk) 15:54, 19 January 2024 (UTC)
 * The only case in which I could think that someone would linktext individual syllables deliberately (and be ticked off at its removal) is if they were specifically discussing morphology in Korean. So simpler than coding the bot to ignore single short words would be just to review by hand articles the bot finds within and . SamuelRiv (talk) 07:01, 27 January 2024 (UTC)
 * I manually checked instances of Linktext containing only a single syllable, and noted that the following cases may be worth keeping.
 * Chopsticks:
 * List of loanwords in Indonesian:
 * Megalia: 맘
 * But this is not an issue because these can be manually re-added/reverted after a bot runs. 172.56.232.113 (talk) 23:28, 29 January 2024 (UTC)
 * Good catch and due diligence. Agree that that can wait till post-bot run, but since you've already found it, consider adding a &lt;!-- hidden token --> adjacent or nearby to such examples, or maybe better, just keep a list in a centralized location (maybe the bot talk page, or WT:KOREA) listing the examples that need looking at again after the bot runs. Mathglot (talk) 23:41, 29 January 2024 (UTC)
 * In fact, I have been making manual changes to existing instances of Linktext (merged adjacent instances, fixed segmentations, or just removed), and have come to the conclusion above. Since there are only three cases, I don't see the necessity of marking them.
 * Also, people who said something like "hold off on bot removal" or "manually check existing cases" are not bringing any actual examples here, so I don't see the necessity of waiting for more cases either. 172.56.232.152 (talk) 00:57, 30 January 2024 (UTC)

It has been two weeks. Any more comments? 172.56.232.84 (talk) 20:13, 25 January 2024 (UTC)


 * Why is anybody linking like this? It's like writing  or  . It doesn't even make sense for Chinese (except perhaps in a discussion of morphology) where most characters are, at least notionally, a word, but are often not functioning as those individual words but as part of long words consisting of two or more characters. For Hangul it's absurd. Largoplazo (talk) 23:13, 25 January 2024 (UTC)
 * Obviously some people have no idea what they are doing, and that absurd practice is now found in 6300+ pages. It is surprising that no one raised an issue about that before this discussion. 172.56.232.202 (talk) 17:43, 26 January 2024 (UTC)

By the way, I originally thought of waiting for a month, but it looks like I don't even need to wait that long. Unless something unusual happens, on February 1 (that is three weeks since I opened this discussion), I will add what I wrote above to the MOS page and make a bot request. 172.56.232.202 (talk) 17:43, 26 January 2024 (UTC)
 * Correction and clarification: (Unless something unusual happens,) I will close this discussion at 23:59, 1 February 2024 (UTC); the edit and the bot request will be made after that. 172.56.232.216 (talk) 04:36, 27 January 2024 (UTC)


 * Remove it all – linking Hangul syllables is the rough equivalent of linking all legal trigrams in English found at syllabic initial boundaries. In this sentence, it would mean partitioning them like this, and then adding links to every segment: ([In] [thi]s [sen][ten]ce, [it] [wou]ld [mea]n [par][tit]ion[ing] [the]m [lik]e [thi]s, [and] [the]n [add][ing] [lin]ks [to] [eve]ry [seg][men]t). It is is arbitrary and pointless, because the trigrams have no linguistic information other than random phonotactic sequences that convey nothing useful to the reader. And neither do the Hangul links. Dump them.  may have something to add about this. Mathglot (talk) 07:20, 27 January 2024 (UTC)
 * Or like linking all the letters in a Cyrillic name, or the kana of Japanese.
 * If a hangul block is worth linking to at Wk, it's worth linking to directly. The first block I clicked on was 국. But is that 'soup', 'country', or something else? Without a link to the actual lemma, I don't see the point. And none of these are going to be linked to the actual lemma, except accidentally.
 * So it's pointless. Remove.
 * (Also, dividing a string of text into hangul blocks will not generally produce the constituent morphemes in native vocab.) — kwami (talk) 07:53, 27 January 2024 (UTC)


 * Remove them all. Most of these links are pointless and also misleading with native vocabulary where the division into hangul blocks often doesn't match morpheme boundaries. And even if there is a one-to-one match in Sino-Korean words, the Wiktionary entries are often not helpful at all. Try e.g. for the second part of  which appears in a movie title listed above: the correct entry is "Etymology 2 — Korean reading of various Chinese characters". Our readers will be delightedly grateful for this pointer. –Austronesier (talk) 17:49, 28 January 2024 (UTC).
 * Remove all. This is patently overlinking, in any but certain narrow linguistic-analaysis contexts. The proper thing to do is around the Korean characters (as a group, not individually), or  if a "Korean: " introduction is wanted; and  around the transliteration, and a single-quoted 'literal translation' if that's needed. If we're giving an English-language name/term first, then don't single-quote it. This is already covered by MOS:FOREIGN and MOS:SINGLE, and there doesn't appear to be any reason to do anything different/unusual with Korean compared to any other language. There is no reason for any use of  at all in 99.999% of these cases, and it complies with neither MOS:FOREIGN nor MOS:LINK. PS: We do  need the huge block of WP:MOSBLOAT drafted about about using ; just don't use  to do anything like this. It appears to have one some particular editor's obsession, and it was then picked up in monkey-see-monkey-do fashion by some later ones, but is a terrible idea and needs to stop.  — SMcCandlish ☏ ¢ 😼  21:51, 1 February 2024 (UTC)
 * Minor, but I think Template:Korean is lately more commonly preferred over the lang variants. On a personal level, I like its features better. toobigtokale (talk) 21:52, 1 February 2024 (UTC)
 * Since this is now found in 6000+ pages, I think MOS (at least MOS-KO) should directly say something about this.
 * Also (I am just repeating what I already wrote above), this discussion is about Linktext being used to create unhelpful and misleading links in Korean hangul text. This is not about the general use of Linktext throughout Wikipedia.
 * Personally, I am even fine with removing every single instance of Linktext regardless of its location (even the ones in infoboxes) and language/script (I would not complain even if the Linktext template itself does not exist, or even if Wikipedia does not provide any link to Wiktionary at all), but I am not proposing that here because that is not specific to Korean and could be way too extreme.
 * If you want to restrict the use of Linktext throughout Wikipedia, then that should be discussed on a different page. 172.56.232.58 (talk) 22:35, 1 February 2024 (UTC)
 * Agreed, removal of all linktext, even on Hanja, may be too extreme. I use the links for Hanja once in a blue moon but Wiktionary's Hanja dict is still not reliable. Maybe that'll change in future. I often use a separate Hanja dict. toobigtokale (talk) 00:00, 2 February 2024 (UTC)

About 24 hours left. Nothing unusual happened so far. 172.56.232.125 (talk) 23:49, 31 January 2024 (UTC)
 * IP 172, at the very top, you said that after the discussion closes later today, "what I wrote below will be added to the MOS page". Not sure if you meant the main MOS page or some other page, but please don't copy this discussion anywhere else as it's generally not good to fragment conversations as they can begin to diverge with different responders at each. You can briefly summarize it (a sentence or short paragraph) and then just add a link to this conversation for anyone who wants to see the details and the whole course of the conversation. (A valid, non-fragmentation alternative would be to move this whole conversation to the MOS page leaving only a short summary and a link here, but I think that would be a bad idea and wouldn't recommend that approach.) Mathglot (talk) 23:44, 1 February 2024 (UTC)
 * From the very beginning, I wrote "the following be added right before Manual of Style/Korea-related articles". So this has been clear.
 * If I wanted to discuss about the general use of Linktext throughout Wikipedia, then I would have started a discussion on a different page.
 * Also, I did not really copy the discussion. I posted notifications at Wikipedia talk:Manual of Style and Wikipedia talk:WikiProject Korea. However, for some reason, some people decided to start a discussion at Wikipedia talk:Manual of Style. I am not really responsible for the discussion started there. But still, I wrote this there: "if you want to discuss about the general use of Linktext throughout Wikipedia, I recommend that you start a new discussion at Wikipedia talk:Manual of Style/Linking". 172.56.232.167 (talk) 00:07, 2 February 2024 (UTC)
 * Okay, thanks. By the way, if you want to close the discussion in the standard way, have a look at template hat which collapses it with a title bar; alternatives are Discussion top and atop which don't collapse and add bakcground color and a closure message at the top. Mathglot (talk) 00:57, 2 February 2024 (UTC)
 * I put in (a.k.a. ) and ;  and  are used to collapse disruptive garbage, not constructive discussions.  and  explicitly say they are for when there's a summary by the closer, but this lacks one. That said, I don't see the actual point of closing this by an involved party at a particular date in the first place. Not really a normal practice. Could either have been left alone to archive away by the archiver bot, or be formally closed with a summary by an univolved party by request at WP:ANRFC. [shrug]  — SMcCandlish ☏ ¢ 😼  11:02, 2 February 2024 (UTC)

Discussion closed. 172.56.232.167 (talk) 00:10, 2 February 2024 (UTC)

Dynamic IP 172 in previous section: trying to reach you
IP 172 who is responsible for most of the content in the section above about Hangul linktext, I responded to you in a couple of places, but I just realized you have a dynamic IP usually starting 172.56.232 but never or rarely the same one. I was going to respond at your Talk page with a talkback template, but realized you'd never see it as your IP flips over to another one. It would be great if you could WP:REGISTER for a free account, but if you don't wish to do that, can you just pick a Talk page link from any of the previous IPs as a designated spot where we can leave you Talkback or other messages? It doesn't matter if you ever get back to that IP or not, you (and anybody) can write on the chosen user talk page. You can pick any of the Talk pages associated with one of your dynamic IPs.

As an example, I've left you a 'Welcome' message at User talk:172.56.232.187, and you're welcome to choose that page, if you wish, as a stable location for communication, or pick a different one. I'd just ask that once you choose one IP Talk page, and that you use the same one each time, no matter what your newest IP happens to be. Make sense? If you're good with this, can you please reply at User talk:172.56.232.187 just so I know you saw this message? Thanks, Mathglot (talk) 00:02, 30 January 2024 (UTC)


 * I am aware of the inconvenience from using dynamic IP addresses, but I am still not sure about this. I don't come here that often, and I don't want to have a certain username (or a static IP address) associated with me. 172.56.232.152 (talk) 00:57, 30 January 2024 (UTC)
 * Okay. You're doing good work, so I can't complain, but it is somewhat of an inconvenience for other editors who might want to communicate with you. I hope you'll think of some solution that works for you, and let us know. Mathglot (talk) 01:02, 30 January 2024 (UTC)
 * A question about the above discussion: does the same logic apply to hanja syllables the same as hangul ones? ProcrastinatingReader (talk) 12:11, 3 February 2024 (UTC)
 * The above discussion only pertains to Korean hangul text. It is not about any other language/script.
 * Chinese characters are logograms (each character usually represents a certain meaning), and are actively used by the Chinese and Japanese languages. So they should not be affected by the above discussion. 172.56.232.203 (talk) 14:28, 3 February 2024 (UTC)

Crossposting
Hi, I'd like to propose a change to Naming conventions (Korean), and wanted to get more eyes on it. It's related to allowing special characters (namely for McCune–Reischauer) in titles.

See the talk post here. toobigtokale (talk) 07:56, 13 February 2024 (UTC)

Proposal to formally allow removals of unnecessary RR and MR values in various Korean-related templates

 * Korean-related templates: Template:Infobox Korean name, Template:Korean, Template:Infobox Chinese, etc.
 * Note:
 * This is not about one particular template.
 * This is not about article titles, nor about any cases where a spelling is supposed to follow a common form in English.

To find information in Korean, you use the hangul spelling (or hanja in rare cases). To find information in English, you use a common form in English (which is the article title in most cases; this may or may not be in accordance with RR or MR, but that does not matter).

Except in fields that consistently use a systematic romanization rule (such as Korean history), RR and MR forms are not really needed.

So here is a question: Why is Wikipedia including RR and MR spellings in Korean-related templates in almost every article that has a Korean term?

Also, the quality of RR and MR spellings in Wikipedia is not ensured either. I have seen a lot of errors in RR and MR spellings throughout Wikipedia. Here are some issues I noticed: Korean-related templates (especially Template:Infobox Korean name) are found in thousands of pages. It is just not really possible to manually check and fix them all – there are just too many of them, and that can only be done by a very small number of people who have some knowledge of Korean and know how those romanization systems work.
 * For both RR and MR: (1) common spellings in English (such as Lee and Park for surnames 이 and 박) are found; (2) shi is found (시 is si in both systems); (3) two systems mixed up (RR spelling is in MR parameter and MR spelling is in RR parameter); (4) random typos
 * For RR: gg, dd, and bb are used for ㄲ, ㄸ, and ㅃ
 * For MR: (1) k, t, p, and ch are used for ㄱ, ㄷ, ㅂ, and ㅈ even when g, d, b, and j are supposed to be used; (2) apostrophes in random places; (3) carons (ǒ ǔ) instead of breves (ŏ ŭ)
 * etc.

Can a module that automatically generates RR and MR spellings be introduced? That is another possibility (assuming that someone can code and maintain it, of course), but here are some issues that still need to be handled manually:
 * A hangul spelling does not always predict pronunciation. For example, 물고기 and 깻잎 are pronounced [물꼬기] and [깬닙] respectively, but this is not predictable from the spelling. The first case is not reflected in RR (still mulgogi), but is reflected in MR (mulkogi instead of mulgogi; on the other hand, 불고기 (pronounced [불고기]) is pulgogi, not pulkogi).
 * Hyphens and spaces not in the hangul spelling but required in romanizations. This includes separating an administrative division with a hyphen (e.g. 평창군 Pyeongchang-gun) and separting a surname and a given name with a space (e.g. 홍길동 Hong Gildong).
 * In addition, some users want to add hyphens or spaces in other places (e.g. 국립중앙도서관 Gungnip Jungang Doseogwan (instead of Gungnipjungangdoseogwan)), but this is not a requirement.
 * RR is context-sensitive. For example, (1) ㅂㅎ is p by default (e.g. 잡혀 japyeo), but ph in a noun (e.g. 집현전 Jiphyeonjeon); (2) ㄱㄴ is ngn by default (e.g. 마곡나루 Magongnaru), but kn in a given name (e.g. 한복남 Han Boknam).
 * Capitalization for proper nouns.
 * Also, introducing this kind of module requires manual changes to thousands of existing strings in hangul parameters. For example, if  is used for capitalization,   is used for inserting a space, and   is used for converting each syllabic block separately, then the personal name 한복남 should be manually changed to   (the symbols ,  , and   are not displayed in the output of a hangul parameter; it only affects romanizations). Who will make manual changes like this to thousands of pages?
 * More importantly, after those symbols are introduced, can we expect that ordinary people would actually learn about them and properly apply them? Probably not.
 * So, in order to use such a module, a user needs to study a lot about how the module works, and also still needs to have some knowledge of Korean and those two romanization systems. We cannot really expect this from ordinary people.

Therefore, I would like to propose the following:
 * Unless the topic is in a field that consistently uses a systematic romanization rule (such as Korean history), do not add RR and MR spellings in Korean-related templates. (The default is no RR and MR spellings. When there is any dispute about adding/retaining RR and MR spellings, the burden lies with the editor who wants to add/retain them.)

How does this sound? 172.56.232.186 (talk) 02:43, 22 February 2024 (UTC)


 * Leaning oppose but am open to discussion. The reason I lean oppose is because more than a few times the MR/RR in the infobox is what enabled me to find an article that I otherwise would have missed. There are so many possible titles for Korea-related articles because of things like WP:USEENGLISH, the lack of a universal romanization standard for places and people, and sometimes just sloppy titles. While alt titles should ideally be handled by redirs, it seems a tall order given the poor state of many Korea-related articles.
 * On the other hand, I relate to your motivation for the proposal. I've also noticed the incorrect MR/RR issue, and have been considering for months writing a automatic Hangul->MR/RR conversion module. I even regularly use this online automatic conversion tool for convenience's sake, so an in-house conversion tool would be nice. I am a programmer but haven't programmed anything for Wikipedia. I'll look into what making such a module would involve soon. toobigtokale (talk) 05:18, 25 February 2024 (UTC)
 * Additional note, Infobox Korean name is also a nice place to store alternate names of people or things. E.g. art names, pen names, and stage names. toobigtokale (talk) 05:21, 25 February 2024 (UTC)
 * About finding an article by searching an RR/MR form: I'm not sure why this matters. RR and MR parameters are always within a Korean-related template, which also contains the hangul spelling. If you cannot find an article when searching using an RR or MR spelling, you can simply search using the hangul spelling.
 * About introducing a module: I am not against this, but the problem is that some manual handling is still needed. We should not expect too much from people. This may sound funny, but people indeed sometimes don't know what they are doing. The single-syllable linktext disaster was an example of this.
 * About Infobox Korean name: That template is useful. I am only questioning about RR and MR parameters in various (not just that one) Korean-related templates. 172.56.232.65 (talk) 17:08, 25 February 2024 (UTC)
 * I should clarify; I can search the hangul, but others may not be able to because they're not familiar with hangul but may be loosely familiar with one of the systems (likely RR, which may help if the subject of the article uses a non-RR romanization. Still not 100% reliable; South Koreans don't even really fully understand the system and romanize 영 as "Young" instead of the correct "Yeong" all the time).
 * On the usefulness of infobox kor name, my misunderstanding there.
 * I'm still leaning oppose. Even if we put something in the MOS about not using MR/RR, it wouldn't solve the issue about incorrect romanizations being common; the majority of people making those mistakes wouldn't read the MOS anyway.
 * Additional point, I'd argue there's a small value to having some kind of romanization displayed by default, even if slightly incorrect, for non-Korean speakers so they have an idea of how something is supposed to be pronounced. toobigtokale (talk) 19:38, 25 February 2024 (UTC)
 * I wonder how people not familiar with hangul would be able to apply RR (or MR) to hangul text and search using the romanized form.
 * I made it more clear that this is not about one particular template.
 * Having a certain statement in the MOS can be useful, especially when a dispute occurs. In this case, if the MOS says what I proposed above, then the direction is always clear: the person who wants to add/retain RR and MR forms should provide a reason.
 * That romanization does not necessarily have to be an RR or MR form though. When an article title is in accordance with neither RR nor MR but is still based on a Korean term (e.g. mukbang), that can also give some idea about the pronunciation.
 * My main concerns about introducing a module are these:
 * Would people be able to use it correctly?
 * How can we prevent misuses or mistakes?
 * 172.56.232.165 (talk) 07:04, 26 February 2024 (UTC)
 * First point you're right; sorry, brain has been fried lately. I shouldn't have made you point out gaps in my logic twice. However, I still think MR/RR often provides two more opportunities for finding articles, and that having it by default offers some pronunciation help for readers who can't read Hangul.
 * For the module, I'll try to get around to doing some brainstorming for how it could work. I agree that it's not straightforward to make; needs to be done well.
 * I lean neutral now; think others should process the proposal. toobigtokale (talk) 07:41, 26 February 2024 (UTC)
 * By the way, I wonder how important it is to convey pronunciation (using a romanized form).
 * Wikipedia is written, not pronounced. When reading a written language with eyes, you don't really have to know how the text is pronounced.
 * Even when pronouncing a spelling strictly in accordance with a systematic romanization rule, prior knowledge is needed. For example, you have to know that eo is pronounced [ʌ] in RR.
 * One can even argue that instead of learning that eo is pronounced [ʌ], you can just learn that ㅓ is pronounced [ʌ]. There isn't much difference between those two (both are "a certain written shape is pronounced this way").
 * For visually impaired people, a text-to-speech (TTS) system is used. But a TTS system is trained for pronouncing text written in the native script (hangul for Korean), not in a romanized form. For example, a TTS system for Korean would handle 한국어 much better than hangugeo or han'gugŏ.
 * So, I would still say that RR and MR forms in Korean-related templates are not really needed (unless the topic is in a field that consistently uses a systematic romanization rule (such as Korean history)).
 * Note: I am not saying this because I know Korean and hangul. I know almost nothing about Arabic, but even if Wikipedia articles containing Arabic terms do not provide any romanization or pronunciation information for each Arabic term in Arabic-related templates at all, I would not complain. I don't even need to know how they are pronounced anyway. 172.56.232.151 (talk) 07:37, 27 February 2024 (UTC)
 * Hence I say "some" pronunciation help; while people can put things through TTS, having something directly in the article can be easier access for a quick glance (I recall statistics about something like >98% of people leaving articles within several seconds). And while RR/MR require prior knowledge for complete accuracy, an uninformed English speaker has a better shot of pronouncing something using RR/MR than if they had nothing else at all.
 * Actually for Arabic specifically, many times I've looked for the romanization or pronunciation of terms in articles. Having pronunciation on hand sometimes helps while traveling. I've often had to pull up something else to put it into TTS because I couldn't find it. Granted, having romanization on a page is not a large quality of life improvement; if someone's persistent they can get what they're looking for (but I'd argue most aren't persistent). The combination of these small factors is why I'm still leaning neutral. toobigtokale (talk) 08:31, 27 February 2024 (UTC)
 * My point is this: Pronunciation is not really important when reading written text with eyes. So one does not really need to provide RR and MR forms in a Korean-related template if the reason is pronunciation.
 * The reason I mentioned TTS is because someone might ask "what about visually impaired people?". I did not mean that people with normal eyesight should use TTS (they can if they want to, of course).
 * Well, in some cases it could be useful to show pronunciation (whether that is accurate or just a rough approximation), but still, (1) written text does not necessarily have to provide this; (2) learning/speaking a foreign language (this includes communicating while traveling) is not the main/primary purpose of Wikipedia.
 * So, even after a module is successfully introduced, I would still lean towards "no RR and MR spellings in Korean-related templates by default". 172.56.232.215 (talk) 18:13, 28 February 2024 (UTC)

Another problem is that some people mix up a common form in English and the result strictly applying a systematic romanization rule. It looks like they think that the former should apply to the latter.

I guess this explains why in RR and MR parameters in Korean-related templates.
 * 1) common spellings in English like "Lee" and "Park" appear
 * 2) some people think that a hyphen must be used in a given name (RR: no hyphen by default / MR: hyphen not used)

This is another reason that I am proposing removals of unnecessary RR and MR values in various Korean-related templates. 172.56.232.105 (talk) 21:41, 4 March 2024 (UTC)


 * oppose – the appropriate response to incorrect information is to correct it, not delete it. The romanizations are useful for cross-referencing an article against English-language sources. Since this wiki is targeted at English language users, such cross-referencing should be facilitated even for readers who don't know Hangul. Kanguole 14:50, 13 March 2024 (UTC)
 * Disagree.
 * Only a very small number of people have the knowledge to fix incorrect RR and MR spellings.
 * As I said, it is just not really possible to manually check and fix them all – there are just too many of them.
 * Also, new articles are sometimes created. Should the very small number of people always monitor newly created articles?
 * English-language sources that consistently use a systematic romanization rule are usually limited to fields like Korean history. I already stated that such fields are exceptions.
 * 172.56.232.24 (talk) 22:48, 18 March 2024 (UTC)
 * The usefulness of cross-referencing is not limited to sources making consistent or systematic use of romanization. Kanguole 23:48, 18 March 2024 (UTC)
 * In what way are they useful? Also, are you seriously saying that the very small number of people should manually check thousands of pages and fix them? 172.56.232.215 (talk) 20:16, 19 March 2024 (UTC)
 * Please try to be more respectful; I lean agree with Kanguole. MR/RR being incorrect, to my understanding, is not a seriously impactful issue. While you do have a valid point on the small manpower of who's able to copyedit them, I'd argue there's a slightly larger harm to unilateral deletion. In other words, I don't think this is a case where a few bad apples are spoiling the bunch.
 * The real solution to this, again, would be a robust automatic romanization module. But realistically with my schedule I'm unlikely to take this up in the next few months. toobigtokale (talk) 20:38, 19 March 2024 (UTC)
 * I did not mean to be disrespectful. I was merely asking questions.
 * I hope people use the module correctly after it is introduced though. 172.56.232.105 (talk) 22:45, 19 March 2024 (UTC)
 * If one is trying to match names in an English-language text against Wikipedia articles, romanizations can help.
 * Wikipedia has many errors. Each of us fixes what we can. Kanguole 22:09, 19 March 2024 (UTC)
 * RR and MR forms can help only when the English-language text consistently uses either one of the systems. And such a text is usually limited to fields like Korean history.
 * There are just too many cases to manually check and fix.
 * I think I am just repeating myself. 172.56.232.105 (talk) 22:53, 19 March 2024 (UTC)
 * As I said above, the romanizations are useful even when the text does not use them consistently. Just because something is of no use to you does not mean that it does not help someone else. I believe I've already responded to the other point. Kanguole 23:08, 19 March 2024 (UTC)
 * Well, I asked "in what way" they are useful (even when an English-language text follows neither of those systems), but you are just repeating that they are useful. 172.56.232.205 (talk) 05:08, 20 March 2024 (UTC)
 * Suppose someone is reading this or this (neither of which is about history) and wondering if the places named are what they think they are, or where these names came from. Fortunately our articles have romanizations in the infoboxes that answer their questions. Kanguole 14:00, 20 March 2024 (UTC)
 * Agree. These are the kinds of scenarios I had in mind as well. toobigtokale (talk) 17:13, 20 March 2024 (UTC)
 * Then place names can be exceptions too. I did not say that Korean history should be the only exception. 172.56.232.24 (talk) 18:58, 20 March 2024 (UTC)
 * So there would be exceptions for historical topics, places, North Korean topics, and on and on as more examples are produced. At some point the exceptions become the norm and it's just not worth it. Kanguole 19:11, 20 March 2024 (UTC)
 * This applies to more than just placenames. See "Bak Jeonghui's Birthplace" in here: . I've noticed this issue a number of times on this website (Encyclopedia of Korean Local Culture).
 * Concur with Kanguole. I don't think more exceptions will solve the complications we bring up. toobigtokale (talk) 19:12, 20 March 2024 (UTC)

By the way, I was able to create an automatic RR and MR romanization program. It works pretty well. But this is not in Lua, and requires manual changes to existing hangul parameters. @User:Toobigtokale, if you want to see what I made, please let me know. 172.56.232.105 (talk) 02:04, 30 March 2024 (UTC)


 * I'd love to see what you have, please share! toobigtokale (talk) 22:14, 30 March 2024 (UTC)
 * Ah, I have been adding some features and modifying my code to be more efficient, but it looks like they decided to vanish. Sadly, I guess what I made will not be implemented. 172.56.232.165 (talk) 10:32, 4 April 2024 (UTC)
 * I'm still around btw; I'm also not the only person (nor am I the best person; I have no experience in implementing modules like these) you can show this work to. Post around or go to Wikipedia's Discord and ask for help.
 * We need your work. It'd be a shame to have such a module coded but not implemented. 187.190.191.57 (talk) 10:41, 21 April 2024 (UTC)
 * Then, this needs at least three people:
 * A person familiar with implementing Lua modules
 * A programmer who speaks Korean (you)
 * A person who knows Korean pronunciation rules and how the RR and MR systems work (me; I am not really a programmer)
 * Also, I have some additional features in mind (will explain after I can be sure that the module is actually going to be introduced), but I don't have enough knowledge to code them myself.
 * Unless you formally return, I am not planning to share what I made.
 * Note: This does not mean that you should return quickly. Take as much time as you need. Please don't feel pressured by this (even if you decide not to return, that is completely up to you). 172.56.232.24 (talk) 02:01, 23 April 2024 (UTC)
 * I think you are 2 and 3, but I feel I'm unlikely to convince you. I feel you're too modest; even if you don't think of yourself as a programmer, you have programmed something of value. I don't know Lua at all, nor have I programmed anything on Wikipedia besides basic AWB find+replaces. Given the lack of manpower for Korea-related articles on Wikipedia we take what we can get, and you have a lot to offer. 187.190.191.57 (talk) 04:57, 23 April 2024 (UTC)
 * To clarify, I don't mean offense by "we take what we can get"; my sentiment was actually somewhat self-depricating. I have no actual background in Korean history. In fact, until I started editing last year, I knew virtually nothing about (and was arguably actively disinterested in) modern history beyond the big things. I wrote because I knew that if I didn't, few other people would. I've now skimmed/read around 20-40% of all Korea-related articles on Wikipedia personally, and I feel that I am right. Over 10+ years we've had a shortage of serious editors. You're a serious editor, we need everything you can offer. Even if it isn't perfect at first, you have time to refine it and me and a few other people to give feedback. Please take the leap; Korea and Wikipedia need you. 104.232.119.107 (talk) 16:45, 24 April 2024 (UTC)
 * I have a question (I have some additional features in mind, but I don't know if it is possible to implement them), and am thinking about opening another discussion. These will affect what I am making.
 * For these, I need someone like you. But I don't think it is a good idea to post something that needs your reply when you are still formally gone.
 * (Again, please don't feel pressured by this. When to formally return (or even not to return) is completely up to you.) 172.56.232.65 (talk) 10:10, 25 April 2024 (UTC)
 * I'll be formally gone for years at least, although contributing small things pseudoanonymously. Not having an account simply helps me not be on the site quite as much.
 * We would significantly benefit from having your module sooner rather than years later. Please just ask me any questions now; the distinction between me having an account vs not is fairly arbitrary. My IP is fairly fixed so you can post on my talk page too. 104.232.119.107 (talk) 16:35, 25 April 2024 (UTC)
 * Then, I will ask you a question.
 * My program is using some symbols to generate the correct romanizations. Here are some of them:
 * : adds a space in romanizations only
 * : capitalizes the following letter
 * : used for converting each syllabic block separately (needed for a given name in RR; will actually be a symbol, but have not decided what to use)
 * : used for most irregularities (including tensification reflected in MR (e.g.  sontŭng (not sondŭng))
 * For people to use easily, I am thinking about introducing the "personal name" mode (by using ):
 * If  is input, it will be automatically converted to   (→ Han Boknam (RR)).
 * By default, this mode assumes that the first syllable is the surname and the remaining syllables are the given name.
 * To specify a different segmentation,  or space is inserted between the components (e.g. surname 선우 + given name 진:   or   (and then automatically converted to   or   respectively)).
 * For a mononym (personal name that does not have a surname, or any case where only the given name is needed), start the string with  (e.g.   →  ).
 * No  in a surname, but add   between each syllable of a given name (e.g.   →  ).
 * But before inserting  to a given name, if syllable-final ㄹ + syllable-initial ㄷ/ㅅ/ㅈ is found,   should be inserted first (to both a surname and a given name; this is because surnames and most given names are Sino-Korean. I can provide a list of such syllables later). For example,   →   →.
 * In addition, any manually input  should be handled correctly. This may be needed when a given name is from a common noun pronounced irregularly (e.g.   →  ).
 * If a personal name is a part of a longer proper noun, put the personal name between two  (e.g.   →  ).
 * Is this possible to implement? 172.56.232.24 (talk) 19:33, 26 April 2024 (UTC)
 * I think the symbols are too complicated for the average user, whom this module is supposed to be meant for. People who put enough effort into learning this syntax would probably romanize things correctly anyway, which defeats the purpose of it.
 * If it's possible to use yes/no options (e.g. "Person name", "Title case", etc) that'd be better I think. Naturally this would miss nuances, so a manual override option or some alternative to this module where manual override is expected would be nice. 104.232.119.107 (talk) 16:16, 27 April 2024 (UTC)
 * I think the symbols are too complicated for the average user ... People who put enough effort into learning this syntax would probably romanize things correctly anyway
 * Then how should irregular cases be handled? It is not possible to get kkaennip directly from 깻잎. Special symbols are needed to handle cases like this.
 * Also, only two different symbols are needed for irregular pronunciations ( takes care of most irregularities, and another symbol for a single irregularity).
 * There are several different types of irregularities in pronunciation, but most conditions of irregularities do not overlap; so I made  to take care of most of them, and another symbol for the single overlapping condition. So in fact, I made my program as simple as possible to use.
 * Not really. I have seen someone saying that ㄸ is dd in RR (see Talk:Tteokbokki). Introducing a module will get rid of mistakes like this ; a user does not really have to know the rules of a romanization system . (Edit: I should have made this clearer, or should not have said this.)
 * That is why I have the "personal name" mode in mind. If that is introduced, people don't have to input most symbols needed to get the correct result for a personal name; in most cases, a user just needs to prefix the full name by.
 * Manual override should not be allowed. If that is allowed, people can input any random text for an RR or MR spelling, which will not be very different from the current situation.
 * "Title case" is not needed because you can simply use.
 * 172.56.232.205 (talk) 18:56, 27 April 2024 (UTC)
 * I'm on the fence and need to think about this some more.
 * I think in order to use this system users will need to understand the romanization systems. Consider some of your own symbols:
 * _ requires you to have some knowledge of spacing rules for RR/MR (people make frequently mistakes on this; it's not straightforward)
 * ^ requires you to have knowledge of capitalization practices for RR/MR (what even are they? Tbh idk them lol are publications titled in sentence case or title case?)
 * @ requires you understand what is "irregular" for RR/MR in the first place.
 * If we accept the above as true, significantly fewer people would want to use the infobox.
 * We'd be giving them a functionally stiff requirement: they must learn the romanization systems AND the syntax in order to properly use the module. Before, they could get away with just barely knowing the romanization, and even then with leeway for mistakes.
 * I doubt many laypeople would want to deal with this, and will just avoid using the infobox. I'll admit: even I'm not confident in how familiar I am with the edge cases in MR/RR, and would need to learn them before I'd be able to use the module without making mistakes.
 * Speaking of which, mistakes are still possible with this module. However, given that we'd be functionally limiting its use to people who will learn the two systems, we'd see a decrease in both the use of the module and the number of mistakes.
 * I feel we differ philosophically on how much tolerance there is for mistakes. I'm pretty inclusionist and tolerant of these kinds of typos. Will need to think; want to make sure we get this right as it will affect many thousands of pages. 104.232.119.107 (talk) 08:46, 28 April 2024 (UTC)
 * I meant that you don't need to know things like whether ㄸ is dd or tt (because the module will never generate dd). I should have made this clearer, or should not have said that. Yeah, actually, you need to have some knowledge of the romanization system.
 * To add  and   to the correct places, yes, you need to have some knowledge of the Korean language (and the romanization systems). I actually wrote that from the beginning.
 * You don't seem to like this, but the thing is that nothing can be done without any prior knowledge. And I think what I made requires the minimum knowledge.
 * Well, people do not have to use the infobox.
 * If you don't like my approach, then what would be a better way to reflect elements that are required for the correct romanizations but cannot be directly figured out from the hangul text?
 * By the way, if it is okay with you, would you please let me know your email address, or any way that I can contact you directly? If you don't want to reveal what you usually use, you can simply create a new account just for discussing this matter. I can also privately send you what I made.
 * It looks like we two are the only people seriously thinking about this. 172.56.232.165 (talk) 13:57, 28 April 2024 (UTC)
 * To be clear, it's not that I don't like your approach. It's:
 * This is my fault. I'm not familiar enough with MR/RR's edge cases to make a judgement call about if this is the best way to handle this. I need to do some reading and then come back.
 * I think we should strive to develop something that is so robust and easy to use that even the laziest user with a basic knowledge of Korean and little knowledge of MR/RR will be able to use it.
 * I want to emphasize this: it's not straightforward for the average person to learn two romanization systems and your symbol system. You are focused and motivated, but the vast majority of people have short attention spans and don't want to spend effort on this stuff.
 * For product design, we're supposed to design to account for that vast majority as much as possible: after all, they're the majority. While we will need to accept some complication at some point (the reason I'm on the fence is that I think it's possible your system is the simplest possible form of this), your proposal is complicated enough that I want us to be sure it is the simplest possible before we move forward.
 * Email User:J3iodp231i‬. 104.232.119.107 (talk) 16:50, 28 April 2024 (UTC)
 * Ok I'm doing the reading, and I'm more convinced of the viability of your system, but still some questions I want to resolve. Email me at your convenience, and please send over any materials you think would help. 104.232.119.107 (talk) 22:14, 28 April 2024 (UTC)
 * It looks like a logged-in user can send an email to another registered user, but that feature is not available for an IP user.
 * Probably I wasn't very clear; by "a new account", I meant a new email/messenger account (if you don't want to reveal the email address or username you usually use). 172.56.232.186 (talk) 03:37, 29 April 2024 (UTC)

Thinking about removing Wiktionary links in some cases
I am thinking about removing Wiktionary links in the following cases. Any comments?
 * 1) When the article is about the term itself (e.g.  in the Hodu-gwaja article). This is like having the computer link in the computer article; not very informative.
 * 2) When the article title is already descriptive enough (e.g.  in South Korean won; XX in the "XX Girls' High School" article)
 * 3) Place names (e.g. 서울 (Seoul), 부산 (Busan), etc.; this includes names of geographical features (mountains, islands, valleys, rivers, seas, etc.)). Some place names are dictionary entries, but the dictionary definition for a place name is usually nothing more than "a place name (in a certain region)".
 * 4) Generic terms constantly found in multiple articles (e.g 한국/대한민국/조선/조선민주주의인민공화국 (Korea), 고속도로 (expressway), 대학교 (university), etc.)
 * 5) Topics that can be better covered in an encyclopedia than in a dictionary (e.g. Sungkyunkwan is more informative than 성균관). In a case like this, if you want to add a link to the hangul text, it would be better to add a link to the Wikipedia article (e.g.  ).
 * 6) Titles of creative works (books, movies, TV shows, songs, etc.). For these, providing a translation of the entire title is better. And some titles are long (see also the next item).
 * 7) Long phrases/sentences (e.g. 한반도의 평화와 번영, 통일을 위한 판문점 선언 in Panmunjom Declaration). For a long phrase/sentence, providing a translation of the entire phrase/sentence would be much more helpful than several links in a row (and Wikipedia does not have to break down each lexical item in a phrase/sentence).
 * 8) When the article is already explaining the meaning (e.g.  means Y; Literal meaning: Y; lit. Y; etc.)
 * 9) Korean terms written in two or more hanja characters (e.g. 博物館). Wiktionary just gives "Hanja form of hangul" (i.e. a soft redirect to the corresponding hangul entry; see 博物館 for an example). This policy in Wiktionary will highly unlikely be changed in the future, since Korean is almost always written in hangul today.
 * 10) Any other cases where a reader will not find anything beyond what they can figure out on Wikipedia

The following are my main criteria for the above:
 * After clicking a link to Wiktionary, will a reader find anything beyond what they can figure out on Wikipedia?
 * Avoid several links in a row. They can be rather inconvenient.

By the way, in general, I think Wiktionary links should only be added (1) when it can be difficult to understand running text without a Wiktionary link; or (2) in linguistic contexts (e.g. when the topic is about lexical items). It seems that MOS:OVERLINK does not directly say something about Wiktionary links, but I started to think that a lot of (if not most) existing Wiktionary links are actually overlinking (especially when a reader does not find anything beyond from those links). Wikipedia is not a website for language learning; it does not have to provide a link for every single non-English lexical item. 172.56.232.35 (talk) 05:03, 23 March 2024 (UTC)


 * Support; think all of this makes sense. This is toobigtokale btw. 187.147.66.231 (talk) 15:18, 23 April 2024 (UTC)
 * It has been more than a month since I posted this, and no one opposed. I will carry this out someday. 172.56.232.35 (talk) 02:32, 30 April 2024 (UTC)

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

Handling Hangul names in references
Our MOS currently doesn't handle how to format names in references, particularly names only known in Hangul. I like how MOS:CHINESE does it, and propose we could do similar.

My proposal for handling Hangul names is:


 * Always convert them to Latin script (functionally English).
 * This should ideally be done by finding the common spelling for the author's name. Secondary option is using the author's preferred spelling.
 * If no known common or preferred spelling exists, romanize per WP:NCKO guidelines (i.e. MR for pre-1945/NK and RR for post-1945 SK)
 * Optionally display the author's Hangul name by using the  parameter, like
 * Useful if the common/preferred romanization is particularly unusual. Optional unlike in MOS:ZH, because romanized Korean is more easily reversible to Hangul than romanized Chinese is to Chinese characters.

Reasoning for preferring Latin text: 211.43.120.242 (talk) 01:37, 7 July 2024 (UTC)
 * Few people have Hangul keyboards enabled or know how to type in Korean
 * People unfamiliar with Korean will struggle to refer to/differentiate Korean authors' names in discussions, nor can they type them.
 * If names are rendered only in Korean (as I've been doing lately), there's some unhappy compromises that need to be made.
 * Editors on Korea-related articles will often squeeze entire Hangul names into the  parameter, like  . However, in a precise sense this is an incorrect usage of the parameter. "홍길동" is the full name, not just the last name.
 * If you split the Hangul name into  it renders it as "홍, 길동", which is annoying because Korean names in Hangul aren't normally formatted like this.
 * Using  could work, but still runs into the issues with non-Korean speakers I gave.


 * Leaning oppose
 * When the author's name is written in hangul, the reference is written in Korean. Anyone citing or checking a Korean-language source has to know hangul and Korean.
 * Even if someone does not know how to type hangul, they can just copy and paste the hangul text.
 * By the way, when using a citation template, I think  is better than   (and for templates like Template:Sfnp, use "홍길동 (2024)" instead of "홍 (2024)"). 172.56.232.178 (talk) 02:39, 7 July 2024 (UTC)
 * Anyone citing or checking a Korean-language source has to know hangul and Korean. But discussing a source isn't limited to people checking it themselves. They can be asking "what does the source by x say?" While copy+pasting is possible, it's mildly annoying.
 * I thought about the author param, but it's currently not visible in some major citation templates as an argument by default (i.e. you can type it in manually in code, but not select it in visual editor). Maybe could look into having it appear.
 * Even if the romanization proposal is opposed, at the very least I think we could prohibit . 211.43.120.242 (talk) 03:32, 7 July 2024 (UTC)


 * External style guides all say that author names on a non-Latin script should be romanized, so Hong Gil-dong. As 211 says, author names have multiple uses. The parameter names last and first are confusing in this context, so I prefer the synonyms surname and given respectively. Either way, the short reference generates "Hong (2024)".
 * That leaves the problem of recovering the original spelling in cases where the romanization is ambiguous. If the author has a wiki article, which presumably has the hangul (and possibly hanja), we can link to that with author-link. Otherwise, author-mask is a possible solution, and perhaps cleaner than Hong Gil-dong (홍길동). Note that using last and author together will generate an error, as they are synonyms. Kanguole 08:44, 7 July 2024 (UTC)
 * Quick comment: for all non-Latin refs, beest practice is to request all content in non-Lating script (here, Hangul) to be displayed both in Latin and said script. Of course, various versions of non-Latin scripts are moonrunes to most readers here, so translated titles/names/publisher info is needed, but at the same time, we need the original titles and such to locate the works - I've too often seen useless references where only a translated title, inexisten outside Wikipedia, was given, and trying to figure out what was the original work (with no ISBN/URL/etc.) was next to impossible :( Piotr Konieczny aka Prokonsul Piotrus&#124; reply here 09:24, 7 July 2024 (UTC)
 * @Kanguole To clarify, is your comment in support of the change? 211.43.120.242 (talk) 11:00, 9 July 2024 (UTC)
 * Yes it is, with the caveat that if the author has an enwiki article, author-link should be used instead of author-mask. Kanguole 11:04, 9 July 2024 (UTC)
 * @TheLonelyPather Some of the above tips about how to use author-mask, etc. might be useful for your User:TheLonelyPather/Essays/Guide for a translator. I will be adding it to mine, at User:Hanyangprofessor2/Instructions/2 Piotr Konieczny aka Prokonsul Piotrus&#124; reply here 14:11, 9 July 2024 (UTC)
 * Thanks, will do that soon. Feel free to include my essay anywhere you like too. Cheers, -- The Lonely Pather (talk) 16:09, 9 July 2024 (UTC)
 * As this is a significant change, I'll open this to a WP:RFC. 211.43.120.242 (talk) 12:03, 10 July 2024 (UTC)
 * Comment I use the quote parameter sometimes when a specific reference is used for a specific line so reviewers wont have to put the entire source into translate. Would this be a helpful practice to encourage(although we probably shouldn't make it obligatory) in MOS:KO? 00101984hjw (talk) 15:16, 10 July 2024 (UTC)
 * I think so, and agree not obligatory. Think we should make a section in the MOS for referencing practices. We should also point people towards MOS:FOREIGNQUOTE in it; lesser known part of the MOS. These changes are uncontroversial, so I think it'd be safe to WP:BOLD ly make them once my orig proposal is decided on. 211.43.120.242 (talk) 16:01, 10 July 2024 (UTC)

RFC on romanizing author names in refs
See above post. Tl;dr Korea-related articles currently don't have guidance on how to handle Hangul names in reference templates. This has led to a wide variety of practices, with arguable positives/negatives to each of them. I'm proposing we establish a guideline in MOS:KO, in which Hangul names are to be romanized (with nuances). 211.43.120.242 (talk) 12:08, 10 July 2024 (UTC)
 * Per my comment above, best practices for Hangul words (names, titles, publishers) in citations should recommend displaying both Hangul and English translations (or transliterations for given names). --Piotr Konieczny aka Prokonsul Piotrus&#124; reply here 10:37, 11 July 2024 (UTC)
 * I can easily support names (per the masking/linking params) and titles (per the  param). Publisher I'm not aware of a good way to display orig Hangul and Latin text. If there is such a way then I'd support, but if we tried to squeeze everything into the publisher param, e.g. , I think it's strictly speaking not a correct usage of the parameter. The publisher is not "안녕 (Annyeong)", it's 안녕.
 * An alternative is to do what MOS:ZH recommends (last para/example); romanize names without orig Hangul. What are your thoughts? 211.43.120.242 (talk) 13:47, 11 July 2024 (UTC)
 * @Piotrus courtesy tag in case didn't see 211.43.120.242 (talk) 14:43, 13 July 2024 (UTC)
 * If there is no equivalent of author-mask in the template that would display "안녕 (Annyeong)" then we should probably ask for the template to be expanded with such a parameter - that would be a win-win. Piotr Konieczny aka Prokonsul Piotrus&#124; reply here  20:54, 13 July 2024 (UTC)
 * Support - romanize name and provide original Hangul using  Just spotted this thread and it happens to be related to my recent Help Desk post here. In short, my view is that we should always romanize the author and provide the original script via the   parameter, as similarly suggested via MOS:CHINESE. For example:

While there are some cons to this approach, this would be until such time the as the citation template is updated to include additional parameters such as  Nonabelian (talk) 10:25, 15 July 2024 (UTC) Nonabelian (talk) 18:22, 15 July 2024 (UTC)
 * Comment Also...just a note to say that much of this looks to have been discussed in a similar context in the following locations on MOS:CHINESE:


 * This is the OP; thanks for your insights. For showing translations of publisher and loc, I'll lean oppose for now. For publisher, reasoning per my note about ko name + English name not strictly being all part of the publisher's name. Location name I'm opposed because common name is possible to easily establish for locations, so I think no need to show Korean text.
 * In short, for now I only propose guidelines around Latin author name and giving translated title. 106.102.129.92 (talk) 03:26, 16 July 2024 (UTC)
 * Also a minor style thing: do we use square brackets or parentheses? E.g.  or  ?
 * The square brackets match those produced automatically by, e.g.   displays as.
 * However, MOS:ZH recommends parentheses for some reason. I'm tempted to say use square brackets for consistency with, but I don't have a strong preference. 59.5.79.44 (talk) 06:57, 16 July 2024 (UTC)
 * But they wouldn't be consistent: trans-title takes the English translation of the title and puts square brackets around it, whereas here you're talking about the original name in Hangul. By the way, the Hangul title shouldn't go in title: it should be in script-title preceded by . Kanguole 07:17, 16 July 2024 (UTC)
 * I stand corrected. TIL  is preferred for non-Latin titles.
 * Thoughts on parentheses vs square? 59.5.79.44 (talk) 07:35, 16 July 2024 (UTC)
 * Parentheses would be clearer. Square brackets would be confusing since this is the opposite of titles. Kanguole 08:17, 16 July 2024 (UTC)
 * Going through the archives of the CS1 Help Page, it looks like square brackets are used for descriptive or editorial notes that are not part of the original reference but provide additional context or clarification. Thus the   or   parameters are rendered in square brackets for this editorial purpose. This concept seems to align with use of square brackets per WP:MOS and APA recommendations. Therefore it can be argued that, in order for consistency, the preferred formatting of the   parameter (or indeed other parameters) should in fact be:
 * I have amended the above markup to take this into account. Nonabelian (talk) 10:03, 16 July 2024 (UTC)
 * Edit: I need to think about this, but I'm leaning towards parentheses instead of square brackets. I'm a little worried that casuals will find this usage of square brackets unintuitive/uncommon. This usage of brackets comes in the opposite order to . On the other hand, people will already be used to "Hong Gil-dong (홍길동)" because this is already practiced in article bodies. We also wanna align with what other style guidelines are doing on Wikipedia; I've yet to see refs in any language use that format. Although admittedly MOS:ZH is the only MOS I know of that uses parentheses; has anyone seen other practices?
 * Also, what's your thoughts on place name romanization practice? I'm a bit skeptical of the need for "서울 [Seoul]"; "Seoul" is more concise, and the Hangul doesn't add significant understanding. 59.5.79.44 (talk) 10:43, 16 July 2024 (UTC) 59.5.79.44 (talk) 11:20, 16 July 2024 (UTC)
 * I was incorrect about using square brackets around the author's name. The APA convention, when also citing the Hangul, is to give the original terms and present them directly behind the romanized terms without parentheses, brackets, or quotation marks at all. Thus above should be rendered as:
 * Have once again amended markup. With regards to place name and publisher: I currently haven't formed any strong views. I think either hangul, latin text or both is fine. If both, square brackets for translation per reason above. Nonabelian (talk) 14:24, 16 July 2024 (UTC)
 * Now I flip my vote to no parentheses/square brackets. Just looked at various manuals of style for Korean studies journals (Wikipedia category).
 * The Chicago Manual of Style (henceforth "CMOS") seems to be popularly used in Korean studies and is annoyingly paywalled.
 * Yale Library gives this guide for Korean in the CMOS:
 * Seems to validate no parentheses/square brackets
 * Journals:
 * The Journal of Korean Studies (CMOS with modifications):
 * Pages 15–17 relevant, page 17 validates your formatting (no parens or square brackets, non-Latin name after Latin)
 * Place of publication does not provide orig. Hangul, just uses English common name (17)
 * Korea Journal (CMOS more or less):
 * Acta Koreana (CMOS)
 * Can't find any relevant guidance for us here
 * North Korean Review (none?):
 * Seemingly little guidance at all
 * Review of Korean Studies (CMOS):
 * European Journal of Korean Studies (CMOS):
 * Explicitly supports no parentheses/square brackets
 * International Journal of Korean History (CMOS):
 * Seoul Journal of Korean Studies (CMOS):
 * Of these, the Journal of Korean Studies seems to have the most fleshed-out manual; it's also among the most prestigious in the field. I think we could refer to it in future; there's some more things I'd like to hash out after this topic. 59.5.79.44 (talk) 18:39, 16 July 2024 (UTC)
 * Thanks for having a look into this too. In addition, I have found a suitable academic reference which directly addresses formatting of Korean here. It cites the Yale Library ref you found and previously provided APA guidelines. Nonabelian (talk) 04:51, 17 July 2024 (UTC)
 * This is the OP. Summary thus far. I'm proposing we follow the example reference format provided by Nonabelian above, except for the  and   parameters. Those are still uncertain; I oppose providing Hangul for location when WP:COMMONNAME is known, and not sure how to format publisher. 104.232.119.107 (talk) 11:00, 19 July 2024 (UTC)
 * @Kanguole @Piotrus thoughts on conversation just above, where we decided no parentheses/square brackets in author-mask, e.g. ? 104.232.119.107 (talk) 11:10, 19 July 2024 (UTC)
 * This is the OP. Summary thus far. I'm proposing we follow the example reference format provided by Nonabelian above, except for the  and   parameters. Those are still uncertain; I oppose providing Hangul for location when WP:COMMONNAME is known, and not sure how to format publisher. 104.232.119.107 (talk) 11:00, 19 July 2024 (UTC)
 * @Kanguole @Piotrus thoughts on conversation just above, where we decided no parentheses/square brackets in author-mask, e.g. ? 104.232.119.107 (talk) 11:10, 19 July 2024 (UTC)