What a Locale is.... (Re: [Fwd]: Response to Mark's message])
mark.davis at jtcsv.com
Tue Apr 15 08:25:11 CEST 2003
Ἀς φαρ ἀς μοστ πεοπλε ἀρε κογκερνεδ, স্চ্রিপ্ত্ ইস্ নোত্ অন্ ইন্চিদেংতল্
ফ়েঅতুরে ওফ়্ থে ব্রিত্তেন্ লন্গুঅগে. Ит ис ас импортант, ор море импортант,
트한 옱혹랖힟 페아투렛 숯흐 앗 위헽헤르 토 스펠르 아 위올드 트헤앝레" 오르 "트헤아테르". テヘセ オルテホグラプヒク
ディスティンクティオンス アレ カプテゥレデ イン ルフク 3066, անդ տհերե իս լիտտլե րեասոն նոտ տո
ծապտուրե սծրիպտ աս ւելլ. இப் யொஉ வஂத் புரெல்ய் திஸ்திந்ச்திஒஂஸ் இந் ஸ்பெஎச்,
ஸ்திச்க் தொ இஸொ 639!
mark.davis at jtcsv.com
IBM, MS 50-2/B11, 5600 Cottle Rd, SJ CA 95193
fax: (408) 256-0799
----- Original Message -----
From: "Jon Hanna" <jon at spin.ie>
To: "Ietf-languages" <Ietf-languages at alvestrand.no>
Sent: Tuesday, April 15, 2003 04:12
Subject: RE: What a Locale is.... (Re: [Fwd]: Response to Mark's message])
> > I think this provides a basis on an answer for Jon Hanna's question: why
> > combine script IDs into the middle of language tags.
> Given that there are
> > existing implementations of language tags in which a single
> > tagging system
> > is used for both non-textual and textual distinctions, I think the onus
> > should be on those who think we should have distinct systems to
> > make their
> > case.
> A few points for our case.
> 1. If you can reasonably avoid changing a current standard then leave it
> it is.
> 2. The separation between script and language is very "real".
> This is true both in terms of how humans and programs view such data.
> a. There are systems that only care about one of these two facets
> or script). We can also have systems that change one while retaining the
> other. Even with systems that deal with both there is likely to be much
> internal that only cares about one of the two. Reflecting this change is
> likely to benefit both human and electronic users.
> b. Amongst systems that do care about both the necessity of explicit
> for each can vary. In cases were we have the text we can deduce the
> often with a 100% degree of accuracy.
> c. User-selection is likely to often separate language and script. Partly
> because this is how we normally talk about these in natural language, and
> partly because many users would have one of these "fixed" (e.g. there are
> many people who use several Western European languages that all use Latin
> script, there are many people who use only Chinese but in a variety of
> 3. Systems that do require both pieces of information may have to
> interoperate with systems that, for one reason or another, only supply
> It will be easier to indicate which piece of information is missing (or
> where an assumption has been made) if the format used separates them.
> 4. The two, while separate, can easily be combined. Conversion between a
> format along the lines of zh-HK;Hant and something that treats the
> and script as a single atomic "locale" is trivial. Those that require such
> combined "locale" (for want of a better word) haven't demonstrated why
> is of less use than the proposed zh-Hant-HK format.
> 5. The little-endian/big-endian debate about where the script code should
> in a language code will be pre-empted if there was separation.
> 6. While questions about other i18n issues (date formats, currency
> placement, decimal separators etc.) have justifiably been dismissed from
> this discussion I think it is inevitable that they will be raised again. A
> format that contains both language and script information, but with a
> separation between each, could, with a little foresight, give us a
> for dealing with these issues.
> 7. The issues for the continuing administration of language and script
> are likely to differ. The degree of interest that leads to people getting
> involved in such work may also vary amongst many individuals. The external
> changes (such as ISO activity) that will need to be reacted to will
> These differences will more easily be dealt with if they can be dealt with
> with a strong degree of autonomy between the two. That autonomy will more
> easily be provided by a format that clearly defines the separation between
> the two.
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
More information about the Ietf-languages