This is the
talk page for discussing improvements to the
Manual of Style/Korea-related articles page. |
|
Archives: 1, 2Auto-archiving period: 180 days |
This project page does not require a rating on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||
|
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)
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:
I sometimes see Template:Linktext used to add a link to each hangul syllable. For example,
{{linktext|국|립|중|앙|도|서|관}}
in
National Library of Korea{{linktext|이|화|여|자|대|학|교}}
in
Ewha Womans University{{Linktext|수|도|권|제|1|순|환|고|속|도|로}}
in
Capital Region First Ring Expressway{{linktext|나|쁜}} {{linktext|영|화}}
in
Bad Movie{{linktext|아|내|가}} {{linktext|결|혼|했|다}}
in
My Wife Got Married{{linktext|간|통|을| 기|다|리|는| 남|자|}}
in
The Scent{{linktext|구|름|은}} {{linktext|흘|러|가|도}}
in
Even the Clouds Are Drifting{{linktext|유|감|스|러|운}} {{linktext|도|시}}
in
City of Damnation{{linktext|새|터|데|이| 나|이|트| 라|이|브| 코|리|아|}}
in
Saturday Night Live Korea{{linktext|윤|석|열}}
in
Yoon Suk Yeol{{linktext|김|하|늘}}
in
Kim Ha-nul (figure skater){{linktext|이|엘|리|야}}
in
Lee ElijahBut this should not be done. Adding a link to each hangul syllable does not help readers. It is sometimes even misleading.
{{linktext|하|늘}}
and clicks the individual links, they might think 하늘 means something like "always the lowest", which is completely wrong. (
하늘 means "sky".)[[나쁘다|나쁜]]
cannot be done by Linktext.가|나|다
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.가|나|다|라
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
[ ]?[0-9가-힣][ ]?
);
{{linktext|국|립|중|앙|도|서|관}}
and becomes 국립중앙도서관
, someone can re-add Linktext (if they want to; re-adding is not a requirement), but it must be {{linktext|국립|중앙|도서관}}
.{{linktext|가|나다}}
)); and===Adding links to hangul text=== When using {{ Linktext}} 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,{{linktext|국립|중앙|도서관}}
, not{{linktext|국|립|중|앙|도|서|관}}
. ** Incorrect links are also not allowed. For example,{{linktext|대학생|선교회}}
, not{{linktext|대학|생선|교회}}
(unless the term really means "college, fish, church"). ** Circumventing this by using other ways of linking (e.g.[[wikt:국|국]][[wikt:립|립]]...
,[[wikt:대학|대학]][[wikt:생선|생선]][[wikt:교회|교회]]
, 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.
{{linktext|국|립|중|앙|도|서|관}}
){{linktext|국립|중앙|도서관}}
)
국립중앙도서관
without Linktext is perfectly fine).172.56.232.205 ( talk) 19:05, 12 January 2024 (UTC)
{{linktext|국립|중앙|도서관}}
), 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.{{
Infobox Chinese}}
etc.
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)
|un|block|ed
, that kind of thing is less likely to get flagged.)We cannot manually check all 6300+ existing casesThat'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)
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)
Did I not say this? Linktext has never been a requirementYes, 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.
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)
there exist cases where single syllables are complete morphemes (even unbound morphemes) and the link would be correctand 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)
It has been two weeks. Any more comments? 172.56.232.84 ( talk) 20:13, 25 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)
{{
lang|ko|...}}
around the Korean characters (as a group, not individually), or {{
lang-ko|...}}
if a "Korean: " introduction is wanted; and {{
lang|ko-Latn|...}}
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 {{
linktext}}
at all in 99.999% of these cases, and it complies with neither MOS:FOREIGN nor
MOS:LINK. PS: We do not need the huge block of
WP:MOSBLOAT drafted about about using {{linktext}}
; just don't use {{linktext}}
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)
About 24 hours left. Nothing unusual happened so far. 172.56.232.125 ( talk) 23:49, 31 January 2024 (UTC)
{{archive top}}
(a.k.a. {{atop}}
) and {{archive bottom}}
; {{hat}}
and {{hab}}
are used to collapse disruptive garbage, not constructive discussions. {{discussion top}}
and {{discussion bottom}}
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)
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#Welcome! just so I know you saw this message? Thanks, Mathglot ( talk) 00:02, 30 January 2024 (UTC)
Hi, I'd like to propose a change to Wikipedia: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)
Example | |
Hangul | 예시 |
---|---|
Hanja | 例示 |
Revised Romanization | this discussion is about |
McCune–Reischauer | these two parameters |
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.
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:
^
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?Therefore, I would like to propose the following:
How does this sound? 172.56.232.186 ( talk) 02:43, 22 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.
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)
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)
_
: adds a space in romanizations only^
: capitalizes the following letterx
: 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))\
):
\한복남
is input, it will be automatically converted to ^한_^복x남
(→ Han Boknam (RR)).
_
or space is inserted between the components (e.g. surname 선우 + given name 진: \선우_진
or \선우 진
(and then automatically converted to ^선우_^진
or ^선우 ^진
respectively)).
\_
(e.g. \_복남
→ ^복x남
).x
in a surname, but add x
between each syllable of a given name (e.g. \남궁_가나다
→ ^남궁_^가x나x다
).x
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, \을지_길동
→ ^을@지_^길@동
→ ^을@지_^길x@동
.@
should be handled correctly. This may be needed when a given name is from a common noun pronounced irregularly (e.g. \김은@빛
→ ^김_^은x@빛
).\
(e.g. 국립 \홍길동\ 기념관
→ 국립 ^홍_^길x@동 기념관
).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
@
takes care of most irregularities, and another symbol for a single irregularity).
@
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.\
.^
._
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.I am thinking about removing Wiktionary links in the following cases. Any comments?
{{linktext|호두과자}}
in the
Hodu-gwaja article). This is like having the
wikt:computer link in the
computer article; not very informative.{{linktext|대한민국| 원}}
in
South Korean won; XX{{linktext|여자|고등학교}}
in the "XX Girls' High School" article)[[Sungkyunkwan|성균관]]
).{{linktext|X}}
means Y; Literal meaning: Y; lit. Y; etc.)The following are my main criteria for the above:
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)
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)
Our MOS currently doesn't handle how to format names in references, particularly names only known in Hangul. I like how MOS:CHINESE#Citation style does it, and propose we could do similar.
My proposal for handling Hangul names is:
|author1-mask
parameter, like |last=Hong |first=Gil-dong |author1-mask=Hong Gil-dong (홍길동)
Reasoning for preferring Latin text:
|last=
parameter, like |last=홍길동
. However, in a precise sense this is an incorrect usage of the parameter. "홍길동" is the full name, not just the last name.|last=홍 |first=길동
it renders it as "홍, 길동", which is annoying because
Korean names in Hangul aren't normally formatted like this.|last=홍 |first=길동 |author1-mask=홍길동
could work, but still runs into the issues with non-Korean speakers I gave.211.43.120.242 ( talk) 01:37, 7 July 2024 (UTC)
|author=홍길동
is better than |last=홍 |first=길동
(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.
|last=홍길동
.
211.43.120.242 (
talk)
03:32, 7 July 2024 (UTC)|last=Hong
|first=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 {{
sfnp|Hong|2024}}
generates "Hong (2024)".|author-link=
. Otherwise, |author-mask=
is a possible solution, and perhaps cleaner than |last=Hong
|first=Gil-dong (홍길동)
. Note that using |last=
and |author=
together will generate an error, as they are synonyms.
Kanguole
08:44, 7 July 2024 (UTC)
|author-link=
should be used instead of |author-mask=
.
Kanguole
11:04, 9 July 2024 (UTC)|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)
|
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)
|trans-title
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. |publisher=안녕 (Annyeong)
, I think it's strictly speaking not a correct usage of the parameter. The publisher is not "안녕 (Annyeong)", it's 안녕.|author1-mask
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 |author1-mask
parameter, as similarly suggested via
MOS:CHINESE#Citation style. For example:Markup | Renders as |
---|---|
|
Hong Yi-Seop 홍이섭 (2011) [1971]. 세종대왕 [Sejong the Great] (in Korean) (9th ed.). 서울 [Seoul]: 세종대왕기념사업회 [Sejong the Great Memorial Society]. ISBN 978-89-8275-660-3. |
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 |script-author1= |script-last1= |script-first1=
Nonabelian (
talk)
10:25, 15 July 2024 (UTC)
Nonabelian ( talk) 18:22, 15 July 2024 (UTC)
|author-mask=Hong Yi-Seop [홍이섭]
or |author-mask=Hong Yi-Seop (홍이섭)
?|trans-title
, e.g. |title=안녕 |trans-title=Hello
displays as 안녕 [Hello]
.|trans-title
, but I don't have a strong preference.
59.5.79.44 (
talk)
06:57, 16 July 2024 (UTC)
|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 ko:
.
Kanguole
07:17, 16 July 2024 (UTC)
|script-title
is preferred for non-Latin titles.trans-title
or orig-date
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.
[1] Therefore it can be argued that, in order for consistency, the preferred formatting of the author-mask
parameter (or indeed other parameters) should in fact be:
|trans-title
. 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?|publisher
and |location
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)
|author-mask1 = Hong Yi-Seop 홍이섭
?
104.232.119.107 (
talk)
11:10, 19 July 2024 (UTC)References
This is the
talk page for discussing improvements to the
Manual of Style/Korea-related articles page. |
|
Archives: 1, 2Auto-archiving period: 180 days |
This project page does not require a rating on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||
|
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)
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:
I sometimes see Template:Linktext used to add a link to each hangul syllable. For example,
{{linktext|국|립|중|앙|도|서|관}}
in
National Library of Korea{{linktext|이|화|여|자|대|학|교}}
in
Ewha Womans University{{Linktext|수|도|권|제|1|순|환|고|속|도|로}}
in
Capital Region First Ring Expressway{{linktext|나|쁜}} {{linktext|영|화}}
in
Bad Movie{{linktext|아|내|가}} {{linktext|결|혼|했|다}}
in
My Wife Got Married{{linktext|간|통|을| 기|다|리|는| 남|자|}}
in
The Scent{{linktext|구|름|은}} {{linktext|흘|러|가|도}}
in
Even the Clouds Are Drifting{{linktext|유|감|스|러|운}} {{linktext|도|시}}
in
City of Damnation{{linktext|새|터|데|이| 나|이|트| 라|이|브| 코|리|아|}}
in
Saturday Night Live Korea{{linktext|윤|석|열}}
in
Yoon Suk Yeol{{linktext|김|하|늘}}
in
Kim Ha-nul (figure skater){{linktext|이|엘|리|야}}
in
Lee ElijahBut this should not be done. Adding a link to each hangul syllable does not help readers. It is sometimes even misleading.
{{linktext|하|늘}}
and clicks the individual links, they might think 하늘 means something like "always the lowest", which is completely wrong. (
하늘 means "sky".)[[나쁘다|나쁜]]
cannot be done by Linktext.가|나|다
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.가|나|다|라
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
[ ]?[0-9가-힣][ ]?
);
{{linktext|국|립|중|앙|도|서|관}}
and becomes 국립중앙도서관
, someone can re-add Linktext (if they want to; re-adding is not a requirement), but it must be {{linktext|국립|중앙|도서관}}
.{{linktext|가|나다}}
)); and===Adding links to hangul text=== When using {{ Linktext}} 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,{{linktext|국립|중앙|도서관}}
, not{{linktext|국|립|중|앙|도|서|관}}
. ** Incorrect links are also not allowed. For example,{{linktext|대학생|선교회}}
, not{{linktext|대학|생선|교회}}
(unless the term really means "college, fish, church"). ** Circumventing this by using other ways of linking (e.g.[[wikt:국|국]][[wikt:립|립]]...
,[[wikt:대학|대학]][[wikt:생선|생선]][[wikt:교회|교회]]
, 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.
{{linktext|국|립|중|앙|도|서|관}}
){{linktext|국립|중앙|도서관}}
)
국립중앙도서관
without Linktext is perfectly fine).172.56.232.205 ( talk) 19:05, 12 January 2024 (UTC)
{{linktext|국립|중앙|도서관}}
), 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.{{
Infobox Chinese}}
etc.
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)
|un|block|ed
, that kind of thing is less likely to get flagged.)We cannot manually check all 6300+ existing casesThat'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)
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)
Did I not say this? Linktext has never been a requirementYes, 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.
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)
there exist cases where single syllables are complete morphemes (even unbound morphemes) and the link would be correctand 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)
It has been two weeks. Any more comments? 172.56.232.84 ( talk) 20:13, 25 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)
{{
lang|ko|...}}
around the Korean characters (as a group, not individually), or {{
lang-ko|...}}
if a "Korean: " introduction is wanted; and {{
lang|ko-Latn|...}}
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 {{
linktext}}
at all in 99.999% of these cases, and it complies with neither MOS:FOREIGN nor
MOS:LINK. PS: We do not need the huge block of
WP:MOSBLOAT drafted about about using {{linktext}}
; just don't use {{linktext}}
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)
About 24 hours left. Nothing unusual happened so far. 172.56.232.125 ( talk) 23:49, 31 January 2024 (UTC)
{{archive top}}
(a.k.a. {{atop}}
) and {{archive bottom}}
; {{hat}}
and {{hab}}
are used to collapse disruptive garbage, not constructive discussions. {{discussion top}}
and {{discussion bottom}}
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)
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#Welcome! just so I know you saw this message? Thanks, Mathglot ( talk) 00:02, 30 January 2024 (UTC)
Hi, I'd like to propose a change to Wikipedia: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)
Example | |
Hangul | 예시 |
---|---|
Hanja | 例示 |
Revised Romanization | this discussion is about |
McCune–Reischauer | these two parameters |
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.
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:
^
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?Therefore, I would like to propose the following:
How does this sound? 172.56.232.186 ( talk) 02:43, 22 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.
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)
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)
_
: adds a space in romanizations only^
: capitalizes the following letterx
: 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))\
):
\한복남
is input, it will be automatically converted to ^한_^복x남
(→ Han Boknam (RR)).
_
or space is inserted between the components (e.g. surname 선우 + given name 진: \선우_진
or \선우 진
(and then automatically converted to ^선우_^진
or ^선우 ^진
respectively)).
\_
(e.g. \_복남
→ ^복x남
).x
in a surname, but add x
between each syllable of a given name (e.g. \남궁_가나다
→ ^남궁_^가x나x다
).x
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, \을지_길동
→ ^을@지_^길@동
→ ^을@지_^길x@동
.@
should be handled correctly. This may be needed when a given name is from a common noun pronounced irregularly (e.g. \김은@빛
→ ^김_^은x@빛
).\
(e.g. 국립 \홍길동\ 기념관
→ 국립 ^홍_^길x@동 기념관
).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
@
takes care of most irregularities, and another symbol for a single irregularity).
@
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.\
.^
._
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.I am thinking about removing Wiktionary links in the following cases. Any comments?
{{linktext|호두과자}}
in the
Hodu-gwaja article). This is like having the
wikt:computer link in the
computer article; not very informative.{{linktext|대한민국| 원}}
in
South Korean won; XX{{linktext|여자|고등학교}}
in the "XX Girls' High School" article)[[Sungkyunkwan|성균관]]
).{{linktext|X}}
means Y; Literal meaning: Y; lit. Y; etc.)The following are my main criteria for the above:
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)
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)
Our MOS currently doesn't handle how to format names in references, particularly names only known in Hangul. I like how MOS:CHINESE#Citation style does it, and propose we could do similar.
My proposal for handling Hangul names is:
|author1-mask
parameter, like |last=Hong |first=Gil-dong |author1-mask=Hong Gil-dong (홍길동)
Reasoning for preferring Latin text:
|last=
parameter, like |last=홍길동
. However, in a precise sense this is an incorrect usage of the parameter. "홍길동" is the full name, not just the last name.|last=홍 |first=길동
it renders it as "홍, 길동", which is annoying because
Korean names in Hangul aren't normally formatted like this.|last=홍 |first=길동 |author1-mask=홍길동
could work, but still runs into the issues with non-Korean speakers I gave.211.43.120.242 ( talk) 01:37, 7 July 2024 (UTC)
|author=홍길동
is better than |last=홍 |first=길동
(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.
|last=홍길동
.
211.43.120.242 (
talk)
03:32, 7 July 2024 (UTC)|last=Hong
|first=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 {{
sfnp|Hong|2024}}
generates "Hong (2024)".|author-link=
. Otherwise, |author-mask=
is a possible solution, and perhaps cleaner than |last=Hong
|first=Gil-dong (홍길동)
. Note that using |last=
and |author=
together will generate an error, as they are synonyms.
Kanguole
08:44, 7 July 2024 (UTC)
|author-link=
should be used instead of |author-mask=
.
Kanguole
11:04, 9 July 2024 (UTC)|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)
|
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)
|trans-title
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. |publisher=안녕 (Annyeong)
, I think it's strictly speaking not a correct usage of the parameter. The publisher is not "안녕 (Annyeong)", it's 안녕.|author1-mask
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 |author1-mask
parameter, as similarly suggested via
MOS:CHINESE#Citation style. For example:Markup | Renders as |
---|---|
|
Hong Yi-Seop 홍이섭 (2011) [1971]. 세종대왕 [Sejong the Great] (in Korean) (9th ed.). 서울 [Seoul]: 세종대왕기념사업회 [Sejong the Great Memorial Society]. ISBN 978-89-8275-660-3. |
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 |script-author1= |script-last1= |script-first1=
Nonabelian (
talk)
10:25, 15 July 2024 (UTC)
Nonabelian ( talk) 18:22, 15 July 2024 (UTC)
|author-mask=Hong Yi-Seop [홍이섭]
or |author-mask=Hong Yi-Seop (홍이섭)
?|trans-title
, e.g. |title=안녕 |trans-title=Hello
displays as 안녕 [Hello]
.|trans-title
, but I don't have a strong preference.
59.5.79.44 (
talk)
06:57, 16 July 2024 (UTC)
|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 ko:
.
Kanguole
07:17, 16 July 2024 (UTC)
|script-title
is preferred for non-Latin titles.trans-title
or orig-date
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.
[1] Therefore it can be argued that, in order for consistency, the preferred formatting of the author-mask
parameter (or indeed other parameters) should in fact be:
|trans-title
. 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?|publisher
and |location
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)
|author-mask1 = Hong Yi-Seop 홍이섭
?
104.232.119.107 (
talk)
11:10, 19 July 2024 (UTC)References