Wiktionary talk:About Korean

Latest comment: 6 months ago by Apisite in topic Middle Korean Readings

Problems about alternative forms edit

(Notifying TAKASUGI Shinji, Atitarev, HappyMidnight, LoutK, Karaeng Matoaya, B2V22BHARAT, Quadmix77): also @Atitarev, @Suzukaze-c, @Eirikr, @Solarkoid, I am trying to revamp this outdated page according to modern standards. Some questions about alternative forms:

  • Should alternative spellings that vary only in the highly ad hoc presence of an orthographic space be hard-redirected or soft-redirected? e.g. 정신 승리 (jeongsin seungni) for 정신승리 (jeongsinseungni), or 라이트노벨 (raiteunobel) for 라이트 노벨 (raiteu nobel). I currently support a hard redirect, given again the ad hoc nature of the spacing.
  • How should NK terms be formatted: with {{lb|ko|North Korea}} followed by a definition identical to the South Korean entry, or with {{standard form of|ko|from=North Korea}}? I think the latter is better to reduce duplication.
  • When should {{lb|ko|South Korea}} be used? The standard in Wiktionary is South Korean, and it seems absurd to label e.g. everything in Category:Korean internet slang with {{lb|ko|South Korea}} just because North Korea doesn't really have Internet. IMO {{lb|ko|South Korea}} should be reserved for the standardized forms of proper nouns of countries, cities, etc., such as 루마니아 (Rumania).

Cheers,--Tibidibi (talk) 04:35, 10 February 2021 (UTC)Reply

@Tibidibi I agree with all of these, thanks for bringing these up.

  • I definitely support a hard redirect for spacing variations. They are quite a hassle to add, and in my opinion, do not add any additional information other than telling the fact that the main information is at the other spaced or non-spaced version. A hard redirect would essentially remove that middle man and lead readers directly to what they were looking for.
  • The latter is more concise and aesthetically pleasing.
  • Honestly, I'm not sure if the SK label is even that useful, as categorization could be done without the label. Besides, The information is better conveyed and presented through the new S/N template anyways.

LoutK (talk) 06:12, 10 February 2021 (UTC)Reply

@Tibidibi Honestly, just like LoutK, I agree with 1st one. A hard redirect is the best solution. No need for another page creation. I think it's also necessary that the most common form be the main page? I feel like that's good. There is one situation, where the nonstandard spelling is the most common. In such cases, I recommend going with the standard spelling and in alternative form header mentioning that the nonstandard form is much more common. As for 2nd, I have no preference on that. I like both of them. For the 3rd one, I'm sharing LoutK's words here. It's currently unnecessary, because people can understand it in any other way. If the word is not marked with North Korea or a dialect, then it's obviously 표준어 (pyojuneo). -Solarkoid (talk) 08:40, 10 February 2021 (UTC)Reply

I support hard redirects. Also, even though I find it useful to label {{lb|ko|South Korea}} in some rare cases, I rather want to remove it completely. We usually don’t label {{lb|ja|Tokyo}} for Japanese. — TAKASUGI Shinji (talk) 12:46, 10 February 2021 (UTC)Reply

Presentation of hanja in links edit

Suzukaze-c (talk) 06:24, 1 December 2021 (UTC)Reply

Discussion moved from Talk:영검하다.

@Suzukaze-c, Tibidibi. Hi. I meant to say this awhile ago when I first noticed this new practice. It's my personal opinion but putting hanja in the middle of a word looks esthetically ugly. It's okay to mix with brackets when the full word can be written in hanja but not like this: 령검(靈驗)하다. Naver provides this format - 공부하다 (工夫하다) (gongbuhada), never uses 공부(工夫)하다 (gongbuhada). Daum gives 공부하다 (工夫— —) (gongbuhada) (hyphens are removed, using m-dashes instead). Is that right? I also think that a space before the first bracket looks better and correct than no space.

  • 령검하다 (靈驗하다) (ryeonggeomhada) looks better and matches the standard practice than
  • 령검(靈驗)하다 (ryeonggeomhada).
  • The third option is 령검하다 (靈驗--) (used by Daum dictionary, I think) to show just hanja AFTER the term and replace remaining hangeul with '--'. (Not able to do with templates as hyphens are removed automatically by the module.)

Again, only voicing my opinion. Please consider. --Anatoli T. (обсудить/вклад) 06:10, 1 December 2021 (UTC)Reply

It seems to exist: google:"공(空)하다".
I also support a specialized "hanja" parameter in {{l}} and other linking templates, but the problem is that a name like |hanja= is incredibly specific for something that can be used by other languages (Vietnamese, etc), and I worry about alternative names. In the Discord server, @Tibidibi proposed |alt-scr=, and @AG202 proposed |alt-tr=, which are reasonable, but I worry about these because of potential confusion with |sc= (and |alt=) — we provide one script (|sc=) and then provide another (???)
I implemented the current thing at Module:languages/data2. The benefit is that we don't need to worry about a parameter name or updating templates. The downside is that the hanja isn't a link on its own, and (as you mentioned) it's aesthetically questionable.
Suzukaze-c (talk) 06:34, 1 December 2021 (UTC)Reply
(For the record, I had originally planned to put off the reformatting of {{t|ko}} until this was decided, but it totally slipped my mind until halfway through the execution. —Suzukaze-c (talk) 06:39, 1 December 2021 (UTC))Reply
@Atitarev Hello, it's nice to see you back.
Spaces are not supposed to be used before parantheses in Korean. This is an English spelling rule, not Korean, and applying spaces around them looks off (suggestive of non-native usage) to a Korean. Subjectively, I think it also looks much worse aesthetically.
In the case of putting hanja in the middle of words, this is how more Koreans do it. "공부(工夫)하다" has 470 Google hits, versus 230 for "공부하다(工夫하다)". It is also more concise and contains less redundant information.--Tibidibi (talk) 06:41, 1 December 2021 (UTC)Reply
@Atitarev
However, I agree with @Suzukaze-c that a separate hanja parameter would be for the best. It could also be used for Vietnamese, and maybe for other languages that have switched between scripts recently (like ex-Soviet Turkic languages).--Tibidibi (talk) 06:42, 1 December 2021 (UTC)Reply
OK, no problem. Let it be so, if it's decided and is common. Something |alt-scr= seems very appropriate especially for translations, templates like {{t+}}.
The usage would be enormous for a few languages. Japanese could use all the respellings, like ^, %, ., -, etc. on kana spellings to produce transliterations without any romaji and both plain kana and romaji would be exposed to the user. Thai and Khmer could also use phonetic respellings, again without the necessity to provide romanised transiterations in many cases, especially on multiword translations. E.g.
คุณอยู่ที่ไหน
kun yùu tîi nǎi
where do you live?
The French Wiktionary uses "Écriture traditionnelle" parameter for traditional Chinese (looks like this: 中国 (zh) (中國) Zhōngguó) in the output), the wikicode: {{trad+|zh|中国|tr=Zhōngguó|tradi=中國}}. {{t+}} should be able to do the same (as a minimum) as {{zh-l}}, e.g. compare the wikicode on 中國中国 (zh) (Zhōngguó), 中国 (zh) (Zhōngguó) with 中國中国 (Zhōngguó). --Anatoli T. (обсудить/вклад) 07:02, 1 December 2021 (UTC)Reply
For Japanese and Thai, really I would prefer to put respellings in |tr=, while our theoretical parameter could be for kanji spellings of 和語. Currently, {{t}} just has a special hack for making Cantonese tones superscript, which is somewhat of a precedent for doing things to |tr=, if mild. —Suzukaze-c (talk) 07:39, 1 December 2021 (UTC)Reply
Re: |tr= - sure, if the same result can be achieved. Alt |alt-scr=- could also be used for Serbo-Croatian, Mongolian, etc. {{t}} et al are too limited. -Anatoli T. (обсудить/вклад) 08:02, 1 December 2021 (UTC)Reply

hyphens edit

Fish bowl (talk) 23:57, 24 February 2023 (UTC)Reply

Middle Korean Readings edit

When it comes to the requests for Middle Korean readings at Category:Requests for etymologies in Korean entries, where could any references with Middle Korean readings be found? -- Apisite (talk) 22:22, 17 October 2023 (UTC)Reply

Return to the project page "About Korean".