Korean romanizations (Was: Japanese transliteration: ja-Latn-hepburn)

Kent Karlsson kent.karlsson14 at comhem.se
Sat Sep 12 12:41:10 CEST 2009

See below.

Den 2009-09-12 02.34, skrev "Mark Davis" <mark at macchiato.com>:

> Mark
> On Fri, Sep 11, 2009 at 03:58, Kent Karlsson <kent.karlsson14 at comhem.se>
> wrote:
>> Den 2009-09-11 05.04, skrev "Doug Ewell" <doug at ewellic.org>:
>>> > Geez, all I had in mind for Korean was registering the three most common
>>> > romanizations, which anyone familiar with Korean could name off the top
>>> > of their head.
>> I would suggest that you just submit the appropriate registration forms
>> to the list. I don't think there is the requirement that the submitter
>> promises to "start using the subtag for the submitter's immediate needs",
>> nor that the submitter has been using the variants for which subtags are
>> requested. I think the subtags you allude to here are useful enough to be
>> registered.
> No, but what I'm afraid of is that then someone else will say, well, we might
> as well do Thai romanizations, and then Lao, and then Russian, and then...
> There is a pretty unending supply of these things.

Well, that is what this group is here for... Processing such requests.

> 1. "Are useful enough to be registered"
> 2. "Are useful enough to be registered, and someone has a need for it"
> I'm just saying that as a working process, #2 gets people what they need, and
> is manageable by this group. #1 would completely swamp this group.

"Need" does not necessarily mean "we need this in our system now".
>>     /kent k
>> PS
>> This is in contrast to trying to register a subtag for a lone pronunciation
>> quirk (by itself that hardly makes a dialect) or for using old road/highway
>> names/numbers instead of their newer names/numbers (totally irrelevant for
>> language tagging, methinks).
> Hardly makes a dialect?  If you are referring to the example I gave, of
> en-US-socapgfr, it is probably spoken by as many or more people than speak
> your native language...

Number of speakers does not a dialect make. But I guess this comes down to
where the border between dialect and minor pronunciation quirk(s) goes. And
I'm sure that can be hotly debated. I would still not count highway
reference method (old or new names) as relevant in that regard. Very few
dialects have been registered in LSR. If requests for more of them come in,
I think it would be good to try to align them with how dialectologists
delineate them.

> Of course, I was using an extreme example, but it was to make a point. For
> *somebody* that level of precision might be important, just as for *somebody*
> the distinction between sl-rozaj-biske and sl-rozaj-njiva, or between
> sl-rozaj-biske and sl-rozaj-biske-1994 is important. We can't anticipate all
> the possible differences that people might need, nor can or should we try to
> second guess that in advance, but what we can do is make sure that the right
> tags are at the right levels of breadth when we do get requests.

But it also makes the registry very uneven when it comes to variants. I'm
not sure how great hopes (or worries) one should have for ISO 639-6, I have
seen neither text nor tabular data for it, but maybe it could make for a bit
more "evenness" w.r.t. variants. (One would have to reactivate LTRU for
using  -6 in the LSR...)

And overly specific variants, such as your "socapgfr" example, should not
become registered anyway (IMO), even if someone were to ask for it. This is
what private-use subtags are for.

> And transliterations are notoriously tricky. What we actually use in CLDR for
> Korean, for example, is a "Korean Ministry of Culture & Tourism
> Transliteration with Clause 8 And Further Modifications for Reversibility
> Because the Source is Underspecified".
> (http://cldr.unicode.org/index/cldr-spec/transliteration-guidelines#Korean)
> [Just noticed that we need to fix the links; the Ministry keeps moving the
> pages around -- sigh.]

That would surely be overly narrow for a registered variant subtag. Cmp.
"pinyin", "hepburn", ...
        /kent k

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-languages/attachments/20090912/d138fd6d/attachment.htm 

More information about the Ietf-languages mailing list