Template talk:ko-usex
Optional feature request
[edit]@Wyang Great stuff! Do you think you can imitate the Japanese equivalent and allow capitalisation with ^ symbol and insert "-" to separate particles with no effect on the Korean script.? E.g.
{{ko-usex|^서울-에 가요|(I am, you are, he is, etc.) going to Soul}}
and display 서울에 가요 (Sour-e gayo)? --Anatoli (обсудить/вклад) 00:38, 14 April 2014 (UTC)
- Hi, I think it's done.
{{ko-usex|^'''서울'''-에 가요|(I am, you are, he is, etc.) going to Seoul}}
- 서울에 가요
- seour-e gayo
- (I am, you are, he is, etc.) going to Seoul
Wyang (talk) 01:28, 14 April 2014 (UTC)
- Seems to break if "-" is inserted before 이... Monni95 (talk) 10:22, 27 July 2014 (UTC)
- Do you mean 사람은 짐승이 아니다. in 아니다? Sorry, it was my mistake. You don't need additional "-", if it's already inserted automatically. --Anatoli T. (обсудить/вклад) 11:02, 27 July 2014 (UTC)
inline parameter
[edit]Perhaps it should have a parameter inline=1 to show a one-line example? E.g. @ 있다, the 2nd sense? They are not really citations, no need to hide them. --Anatoli (обсудить/вклад) 01:58, 14 April 2014 (UTC)
- Yes. I have added |inline=, |ref=, |noenum= from
{{usex}}
. The inline parameter is non-empty if there is no '.?!' in parameter 1. Wyang (talk) 02:11, 14 April 2014 (UTC)
Additional parameters
[edit](Notifying TAKASUGI Shinji, HappyMidnight, LoutK, Karaeng Matoaya, B2V22BHARAT, Quadmix77): Hi. It would be great to enhance this with regular parameters, which are available in {{ux}}
such as |lit=
for literal meanings and |q=
(qualifier) e.g. for marking speech styles (I think that's essential). Also calling for assistance with @Suzukaze-c, Benwing2. --Anatoli T. (обсудить/вклад) 00:55, 22 January 2021 (UTC)
- @Atitarev: In my honest opinion, I think this template in its current state could just be deprecated and all its uses bot-changed to
{{usex|ko}}
, given that all it currently does differently is create a background color for the bolded word, which is superfluous. In general I feel it's best to minimize the use of language-specific templates when there's no language-specific need for it. But if this template is kept or bot-switching proves too difficult, then yes, all the{{ux}}
parameters should definitely be included.---Karaeng Matoaya (talk) 01:22, 22 January 2021 (UTC)- @Karaeng Matoaya: Thanks but I disagree on minimising the use of language-specific templates, not at the moment. The Korean templates are perhaps the least impressive language-specific templates but I find the background colour of
{{ko-usex}}
and the ability of adding hanja to{{ko-l}}
is also important. (You can explore Chinese, Thai, Khmer and Japanese language-specific templates, which are ahead of generic templates but in different ways but may also lack features). If generic templates are made to be able to do what language-specific templates can do, the latter could be abandoned, IMO but I doubt it will happen soon. - Another thing that's missing in this template is controlling inline/multiline, which is currently automatic. --Anatoli T. (обсудить/вклад) 02:11, 22 January 2021 (UTC)
- @Atitarev, for
{{ko-l}}
, @Suzukaze-c was looking into adding the functionality for hanja into the generic linking templates, which should make{{ko-l}}
unnecessary. In the case of{{ko-usex}}
, I personally like the aesthetic of the background color myself, but currently there are some issues with visual consistency that comes from using this template. For example,{{ko-usex}}
doesn’t support quotes, which have to be inputted through generic templates like{{quote-book}}
which don’t have the background color—so usage examples have the fancy background and actual quotes don’t, which could be confusing for readers. In any case there is nothing beyond aesthetics that would be lost from switching over fully to{{usex|ko}}
.--Karaeng Matoaya (talk) 02:32, 22 January 2021 (UTC) - @Karaeng Matoaya, Suzukaze-c: We need to add the ability to add hanja for Korean terms, trad./simpl. for Chinese terms with a semi-automated conversion from trad. to simpl. and a way to phonetically respell (partial translit) for languages such as Chinese, Japanese, Thai and Khmer. These (excluding Japanese and Korean) also automatically provide links to individual words, which I find helpful for such languages.
- Imagine using the generic
{{t}}
for adding transliterations only in the native script for these examples: - 你住在哪兒?/你住在哪儿? ― Nǐ zhù zài nǎr? ― (please add an English translation of this usage example)
- คุณอยู่ที่ไหน(kun yùu tîi-nǎi)
- Lua error in Module:km at line 263: attempt to concatenate local 'translation' (a nil value)
- --Anatoli T. (обсудить/вклад) 02:48, 22 January 2021 (UTC)
- @Atitarev, for
- Frankly, colored backgrounds could easily be applied with a simple CSS rule for any language: for bold Korean text of an HTML element designated as a "usex", make that text yellow.
.e-example:lang(ko) b { background: yellow;
} - But why do we make an exception for Korean? Why don't we give English usexes yellow backgrounds?
- As for hanja, besides an additional Hanja parameter, we could also try an approach where hanja in parentheses is stripped from links just like Arabic vocalization. This seems to be something that Module:ko-translit already does.
- (The hanja parameter is probably a better idea, but it's a second idea.) —Suzukaze-c (talk) 05:34, 22 January 2021 (UTC)
- @Karaeng Matoaya: Thanks but I disagree on minimising the use of language-specific templates, not at the moment. The Korean templates are perhaps the least impressive language-specific templates but I find the background colour of