http://cldr.unicode.org/translation/date-time-patterns
How are 'B' values added for languages that do not have them?
I cannot see an option for this in the survey tool which just refers to the
existing list.
On Fri, Aug 31 2018 at 10:27 +0200, Manuel Strehl via Unicode wrote:
> The XML files in these folders:
>
> https://unicode.org/repos/cldr/tags/latest/common/
Thanks for the link.
In the meantime I rediscovered Locale Explorer
http://demo.icu-project.org/icu-bin/locexp
which I used
Janusz S. Bień wrote,
> Thanks for the link. I found especially interesting the Polish section
> in
>
> https://www.unicode.org/cldr/charts/34/subdivisionNames/other_indo_european.html
>
> Looks like a complete rubbish, e.g.
>
> plmp = Federal Capital Territory(???) =
English is given as "Pomeranian
Voivodeship", why is CLDR giving the English as "Federal Capital
Territory"?
The Wikidata page was last edited/updated on 2018-08-25. The CLDR
page doesn't include last updated information. Perhaps it hasn't been
updated in a while.
On Mon, Sep 03, 2018 at 09:45:38AM +0200, Janusz S. Bień via Unicode wrote:
> plmp = Federal Capital Territory(???) = Pomerania (Latin/English name of
> Pomorze) transliterated into the Greek alphabet (and something in
> Arabic).
This must be a mistake (a strange copy-paste side effect?). Feder
On 03/09/18 09:53 Janusz S. Bień via Unicode wrote:
>
> On Fri, Aug 31 2018 at 10:27 +0200, Manuel Strehl via Unicode wrote:
> > The XML files in these folders:
> >
> > https://unicode.org/repos/cldr/tags/latest/common/
>
> Thanks for the link.
>
> In the mea
(This is the response from Janusz S. Bień which was sent to the public list.)
On Mon, Sep 03 2018 at 1:03 -0800, James Kass wrote:
> Janusz S. Bień wrote,
>
>> Thanks for the link. I found especially interesting the Polish section
>> in
>>
>> https://
What is the formal relationship between the Common Locale Data
Repository (CLDR) and International Components for Unicode (ICU)?
I ask for two reasons:
I raised a ticket http://unicode.org/cldr/trac/ticket/5092 on a
proposed clarificatory addition to UTS#35 'Locale Data Markup
Language
f that does not work for you.
If in a particular locale you want to add another skeleton to the existing 5,
please file a ticket:
http://unicode.org/cldr/trac/newticket <http://unicode.org/cldr/trac/newticket>
(we shoud be able to get to that within a few days)
- Peter E
Sorry for not noticing that this thread belongs to CLDR-users, not to Unicode
Public.
Hence I’m taking it off this list, welcoming participants to follow up there:
https://unicode.org/pipermail/cldr-users/2018-September/000833.html
The Unicode Consortium is pleased to announce the release of new versions
of the Common Locale Data Repository (CLDR 1.2) and the Locale Data Markup
Language specification (LDML 1.2).
For more information on the contents of this release, see:
http://www.unicode.org/cldr
On 7/25/2012 5:01 PM, Richard Wordingham wrote:
What is the formal relationship between the Common Locale Data
Repository (CLDR) and International Components for Unicode (ICU)?
...
The ICU implementation of collation tailoring for changed ordering is
bizarre in some complicated cases. (Life
Mark <https://plus.google.com/114199149796022210033>
*
*
*— Il meglio è l’inimico del bene —*
**
On Wed, Jul 25, 2012 at 5:01 PM, Richard Wordingham <
richard.wording...@ntlworld.com> wrote:
> What is the formal relationship between the Common Locale Data
> Repository (CLDR)
mance to Unicode standards.
And yes, I understand that there is limited point in producing
standards no one considers it worth striving to conform to.
> UTS #35 is owned by the CLDR-TC, not the UTC or the Unicode Consortium
> as a whole.
I've dug further into the structure of Unicode, and
On 7/26/2012 1:21 PM, Richard Wordingham wrote:
I thought the Unicode Consortium had a formal policy of forbidding
untrue (or "misleading") claims of conformance to Unicode standards.
No. What would be the point? Voluntary standards organizations have
no mechanism for policing compliance.
Sure
On Thu, 26 Jul 2012 14:33:08 -0700
Ken Whistler wrote:
> On 7/26/2012 1:21 PM, Richard Wordingham wrote:
> > I thought the Unicode Consortium had a formal policy of forbidding
> > untrue (or "misleading") claims of conformance to Unicode standards.
> No. What would be the point? Voluntary stand
w.unicode.org/policies/logo_policy.html . The implication is
> that untrue or misleading claims using the word 'Unicode' are
> contravening the trademark.
>
Richard,
May I ask if you have a specific example in mind? Is the U in ICU
misleading somehow, or CLDR recommending a policy for plain text?
Steven R. "my TTY is 5-bit clean" Loomis
On Thu, 26 Jul 2012 17:01:53 -0700
"Steven R. Loomis" wrote:
> May I ask if you have a specific example in mind? Is the U in ICU
> misleading somehow, or CLDR recommending a policy for plain text?
I had no examples of untrue or misleading statements about Unicode standards
and
On Thu, Jul 26, 2012 at 6:19 PM, Richard Wordingham <
richard.wording...@ntlworld.com> wrote:
> On Thu, 26 Jul 2012 17:01:53 -0700
> "Steven R. Loomis" wrote:
>
> > May I ask if you have a specific example in mind? Is the U in ICU
> > misleading somehow, or
On Thu, 26 Jul 2012 22:52:54 -0700
"Steven R. Loomis" wrote:
> On Thu, Jul 26, 2012 at 6:19 PM, Richard Wordingham <
> richard.wording...@ntlworld.com> wrote:
>
> > On Thu, 26 Jul 2012 17:01:53 -0700
> > "Steven R. Loomis" wrote:
> I suspect it was simply an oversight and not indicative of any
pen interchange, subject to interpretation
by private agreement, noncharacters are permanently reserved (unassigned)
and have no interpretation whatsoever outside of their possible
application-internal private uses."
For CLDR collation data - *not open interchange, but specific to use in
CLDR col
ed (unassigned) and have no interpretation
> whatsoever outside of their possible application-internal private
> uses."
> For CLDR collation data - *not open interchange, but specific to use
> in CLDR collation data* - these characters have specified use as
> sentinel characters,
2012/7/27 Richard Wordingham :
> The restrictions improve legibility. As it is, many of the
> character-level elements in CLDR XML files tend to be unreadable. It
> would be better for them not to require genuinely complex text
> rendering. In a related matter, it was very inconven
On Fri, 27 Jul 2012 14:14:05 -0700
Mark Davis ☕ wrote:
> I disagree. If legibility were an issue, then XML could have still
> allowed NCRs for them.
It wouldn't help if you looked at the text in a browser.
Richard.
That is a complete, utter red herring.
- There are hundreds of default-ignorable code points, valid in
XML, that won't show at all in your browser.
- There are hundreds of thousands of reserved code points, valid in XML,
that won't show anything but a box in your browser.
- Aside f
Hi all, I am trying to find the CLDR collation tailoring and DUCET data
in JSON format. I looked at the CLDR data published for release 22.1 (
http://www.unicode.org/repos/cldr-aux/json/22.1/), but it doesn't seem
to be there. Is this the right place to look for that? (Is it even
converted to
I wonder if there is any interest in adding stop words to CLDR? Stop
words are ignored by natural language processing algorithms, with use
cases like search engines, word clouds and text classification.
There are already existing collections with stop words like [1] or [2]
which could be used
it was added by CLDR. But the best description I
have been able to find is in UTR #35:
The numbers element supplies information for formatting and
parsing
numbers and currencies. It has three sub-elements: ,
, and . The data is based on the
Java/ICU format. The currency IDs are from [ISO4217]. For
The Unicode Consortium is pleased to announce that the alpha version of
the Common Locale Data Repository (CLDR) 1.2 is available for public
review. The contents include:
SPECIFICATION
* Updated Locale Data Markup Language (LDML) specification (UTS #35
draft), and updated DTD.
* Added
CLDR users might be interested to read this ScriptSource blog
entry about the use we make of CLDR data on our ScriptSource
website.
Martin
I think just the main data is converted. If you want to request the other
data you can file a cldr ticket.
Mark <https://plus.google.com/114199149796022210033>
*
*
*— Il meglio è l’inimico del bene —*
**
On Sat, Mar 2, 2013 at 8:35 PM, Edwin Hoogerbeets wrote:
> Hi all, I am tryin
Dear Unicode list members,
The alpha draft version of Unicode CLDR v30 is available for testing. The main
improvements include:
• New format and preference structure has been added to support week
designations such as “the week of August 10” or “week 3 of March”.
• New data items have been
represent those,
> > but to also serve as a resource that vendors can draw on.
>
> Would you say, then, that Marcel's statements:
>
> "Now that CLDR is sorting out how to improve keyboard layouts, hopefully
> something falls off to replace the *legacy* US-Intl."
&
e that CLDR was going to try to influence vendors to retire these
> keyboard layouts and replace them with those. […]
The “replacement” would be on user side, not on vendors side. I was never
thinking that Microsoft could put another layout *in the place of US Intl*
instead of letting users cho
On 2018/01/30 16:18, Philippe Verdy via Unicode wrote:
- Adding Y to the list of allowed letters after the dieresis deadkey to
produce "Ÿ" : the most frequent case is L'HAŸE-LÈS-ROSES, the official name
of a French municipality when written with full capitalisation, almost all
spell checkers o
Indeed.
But "Faÿ-lès-Nemours" / "FAŸ-LÈS-NEMOURS". "lès" in French place names
means "near", typically followed by another city name or a river name.
In the case of "L'Haÿ-les-Roses", it's just that they have a famous rose
garden, so "les".
Eric.
On 1/30/2018 12:06 AM, Martin J. Dürst via
s seems appropriate: Left Option should be Numbers, and Alt should
become Numbers, too, while itself could be mapped to Left Windows or so. See:
https://unicode.org/cldr/trac/ticket/10851#comment:2
Regards,
Marcel
Marcel Schneider wrote:
> That tends to prove that Mac users accept changes, while Windows users
> refuse changes.
I was going to say that was a gross over-generalization, but that didn't
adequately express how gross it was. It's just plain wrong. Pardon my
bluntness.
How about: Windows is often
Marcel Schneider wrote:
>> http://recycledknowledge.blogspot.com/2013/09/us-moby-latin-keyboard-for-windows.html
>
> Sadly the downloads are still unavailable (as formerly discussed). But
> I saved in time, too (June 2015).
Sorry, try this:
http://vrici.lojban.org/~cowan/MobyLatinKeyboard.zip
On Tue, 30 Jan 2018 10:20:46 +, Alastair Houghton wrote:
>
> On 30 Jan 2018, at 05:31, Marcel Schneider via Unicode wrote:
> >
> > OnMon, 29 Jan 2018 11:13:21 -0700, Tom Gewecke wrote:
> >>
[…]
> >>
> >> They are also all on the MacOS "US International PC", provided since 2009
> >> by App
On Tue, 30 Jan 2018 11:34:40 -0700, Doug Ewell via Unicode wrote:
>
> Marcel Schneider wrote:
>
> > That tends to prove that Mac users accept changes, while Windows users
> > refuse changes.
>
> I was going to say that was a gross over-generalization, but that didn't
> adequately express how gro
On Tue, 30 Jan 2018 11:50:49 -0700, Doug Ewell wrote:
>
> Marcel Schneider wrote:
> >
> > http://recycledknowledge.blogspot.com/2013/09/us-moby-latin-keyboard-for-windows.html
> >
> >
> > Sadly the downloads are still unavailable (as formerly discussed). But
> > I saved in time, too (June 2015
noring
a countryʼs policies and not interfering with official work. France is expected
to
fix itself its keyboarding problems and publish a standard, and thatʼs what is
actually happening. See Shawn Steeleʼs blog post about Locale Data in Windows
10 & CLDR:
https://blogs.msdn.microsoft.com/
le in Fɽanƈë are wondering, but it is primarily a matter of
> honoring
> a countryʼs policies and not interfering with official work. France is
> expected to
> fix itself its keyboarding problems and publish a standard, and thatʼs
> what is
> actually happening. See Shawn Steele
On Wed, 31 Jan 2018 19:05:17 +0100, Philippe Verdy wrote:
>
> Another idea: you can already have multiple layouts loaded for the same
> language : For French, nothing prohibits to have a "technical/programmer
> layout", favoring input of ASCII, a "bibliographic/typographical" one with
> improved c
The spell checker I was invoking was to allow fixing basic the typography
(e.g. the ae and oe ligatures contextually, it does not have to be a full
spell checker, but only concentrate on the typography, not the orthography,
most transforms should be limited to one or two characters, so that it is a
Greetings and Happy New Year,
The discussion of CLDR Keyboards and layout is getting lengthy and
it should probably be moved to the CLDR-Users mail list where it is
more appropriate. Especially because it is so technically detailed.
Please see this page for instructions about how to subscribe
ther task
> competing with CLDR survey.
Please elaborate. It's not clear for me what do you mean.
> Reviewing CLDR data is IMO top priority.
> There are many flaws to be fixed in many languages including in English.
> A lot of useful digest charts are extracted from XML there,
W
Could you make a tag in the SVN or create a zip file for emoji 12.0?
My understanding is Unicode emoji 12.0 has been released and I'd like to get
the annotations and the translations.
Previously I could get http://www.unicode.org/repos/cldr/tags/release-34 but
now I don't know which r
links. CLDR 1.1 (due very soon) updates the links. (We should
add documentation in the future so that we don't depend on anything from
Sun.)
BTW, it would probably be better to float your questions on
the CLDR mailing list. There are instructions for joining it on http://www.unicod
should add documentation in the futureÂso
that we don't depend on anything from Sun.)
Or anybody else, and not just because the links are not stable.
Â
BTW, it would probably be better to float your
questions on the CLDR mailing list.
Will do. That's the old unicore vs. unicode, bu
'Rick McGowan' said on Wed, Nov 03, 2004 at 10:08:32AM -0800,:
> Please note that the freeze date for the next version of CLDR is January
> 15, 2004. All new data or defect reports for CLDR 1.3 must be submitted by
In a time wrap, eh?
--
The CLDR Survey Tool is currently open to, among other things, collect
improvements to (emoji) character names and keywords. I don't see it being done
for any language yet, but wouldn't it make sense to add classic emoticons (like
:-) for various smiling emojis), kaomoji (like o/
The XML files in these folders:
https://unicode.org/repos/cldr/tags/latest/common/
But I agree. I spent an extreme amount of time to get somewhat used to
cldr.unicode.org and and the data repo, and still I have no clue,
where to find a concrete piece of information without digging into the
site
. Yet another task
> > competing with CLDR survey.
>
> Please elaborate. It's not clear for me what do you mean.
These comments are designed for the Code Charts and as such must not be
disproportionate in exhaustivity. Eg we have lists of related languages ending
in an ellipsis. Once th
Hi Rick,
On Friday, October 1st, 2004 00:17, Rick McGowan va escriure:
>
> The Unicode Consortium is pleased to announce that the alpha version
> of the Common Locale Data Repository (CLDR) 1.2 is available for
> public review.
Can you please clarify what are the intent with r
The *beta* version of Unicode CLDR 34
<http://cldr.unicode.org/index/downloads/cldr-34> is available for
testing. The final release is expected on October 12.
CLDR 34 provides an update to the key building blocks for software
supporting the world’s languages. This data is used by all
The *beta* version of Unicode CLDR 35
<http://cldr.unicode.org/index/downloads/cldr-35> is available for
testing. The final release is expected on March 27.
Aside from documenting additional structure, there have been important
modifications LDML (scan for the yellow highlighted se
On 7/26/2012 4:20 PM, Richard Wordingham wrote:
Perhaps I've read too much into
http://www.unicode.org/policies/logo_policy.html . The implication is
that untrue or misleading claims using the word 'Unicode' are
contravening the trademark.
That's more on the level of making sure that when you
CLDR v24 is scheduled to be released next week (2013-09-18). While the LDML
specification (http://unicode.org/repos/cldr/trunk/specs/ldml/tr35.html)
and release note (http://cldr.unicode.org/index/downloads/cldr-24) are
still being worked on, we'd welcome feedback on any major problems i
announcements at unicode.org wrote:
> The alpha version of Unicode CLDR 35
> <http://cldr.unicode.org/index/downloads/cldr-35> is available for
> testing.
No downloadable data files in the sense of released builds, correct?
--
Doug Ewell | Thornton, CO, US | ewellic.org
Just via svn checkout for the alpha.
By next time we plan to be on GitHub...
{phone}
On Thu, Feb 28, 2019, 13:07 Doug Ewell via Unicode
wrote:
> announcements at unicode.org wrote:
>
> > The alpha version of Unicode CLDR 35
> > <http://cldr.unicode.org/index/downloads/
<http://unicode.org> wrote:
> The alpha version of Unicode CLDR 35
> <http://cldr.unicode.org/index/downloads/cldr-35> is available for
> testing.
No downloadable data files in the sense of released builds, correct?
--
Doug Ewell | Thornton, CO, US | ewellic.org <http://ewellic.org>
According to many sources, Filipino is the official language of the
Philippins, which has been standardized years after ISO639 had standardized
its 2-letter and 3-letter codes for Filipino, Pilipino, and Tagalog.
The problem is that Filipino should be considered distinct from Pilipino and
Tagal
fied
Chinese and traditional Chinese.
Claire.
On Thu, Jun 7, 2012 at 5:54 PM, Mark Davis ☕ wrote:
> On Thu, Jun 7, 2012 at 4:28 PM, Matt Ma wrote:
>
>> Hi,
>>
>> I have two questions regarding the collation sequence defined in
>> zh.xml, CLDR 21.0
>>
>> 1
issue, different stroke counts, between simplified
> Chinese and traditional Chinese.
>
> Claire.
>
> On Thu, Jun 7, 2012 at 5:54 PM, Mark Davis ☕ wrote:
>
>> On Thu, Jun 7, 2012 at 4:28 PM, Matt Ma wrote:
>>
>>> Hi,
>>>
>>> I have two q
> Claire.
>>
>> On Thu, Jun 7, 2012 at 5:54 PM, Mark Davis ☕ wrote:
>>
>>> On Thu, Jun 7, 2012 at 4:28 PM, Matt Ma wrote:
>>>
>>>> Hi,
>>>>
>>>> I have two questions regarding the collation sequence defined in
>
Thanks all for clarification. Are there any plans to provider the
following collations in CLDR?
1. Simplified Chinese, stroke order, based on 现代汉语通用字笔顺规范 (PRC-China
modern Chinese commonly used characters standard stroke orders,
mentioned in http://en.wikipedia.org/wiki/Stroke_order).
2
There are no current plans to do that. If you want to present a case for
adding additional collation sequences to CLDR, please start the process by
filing a bug at http://unicode.org/cldr/trac/newticket
--
Mark <https://plus.google.com/114199149796022210033>
*
*
Entered ticket #4949 for Simplified Chinese, stroke order.
Thanks,
Matt
On Fri, Jun 22, 2012 at 12:55 PM, Mark Davis ☕ wrote:
> There are no current plans to do that. If you want to present a case for
> adding additional collation sequences to CLDR, please start the process by
> filing
ootwork already?)
Stephan
On 6/22/2012 5:05 PM, Matt Ma wrote:
Entered ticket #4949 for Simplified Chinese, stroke order.
Thanks,
Matt
On Fri, Jun 22, 2012 at 12:55 PM, Mark Davis ☕ wrote:
There are no current plans to do that. If you want to present a case for
adding additional collation sequences
gt; Entered ticket #4949 for Simplified Chinese, stroke order.
>>
>> Thanks,
>> Matt
>>
>> On Fri, Jun 22, 2012 at 12:55 PM, Mark Davis ☕ wrote:
>>>
>>> There are no current plans to do that. If you want to present a case for
>>> addin
Mark Davis ☕ wrote:
There are no current plans to do that. If you want to present a case for
adding additional collation sequences to CLDR, please start the process
by
filing a bug at http://unicode.org/cldr/trac/newticket
Mark
— Il meglio è l’inimico del bene —
On 27 July 2012 00:42, Ken Whistler wrote:
>
> It is a whole nother kettle of fish when somebody says of their product
> "This product conforms to the Unicode Standard, Version 6.2.0." There
> would be nothing misleading about their use of the Unicode Mark in
> such a case -- they are actually ref
You may still use the terms "Universal Character Set". However, claims
of conformance is declarative. It may have unexpected bugs soemwhere
in which cas the claim should come with either a disclaimer of
warranty, or with a reliable contact address for the support to have
these conformance bugs corr
Typo in section 2.3 "Number Symbols", for the new item
"superscriptingExponent" which describes:
"The superscripting can use markup, such as 4 in HTML, (...)"
Of course this is "4"
2013/9/13 John Emmons
> CLDR v24 is scheduled to be releas
perscriptingExponent" which describes:
> "The superscripting can use markup, such as 4 in HTML, (...)"
>
> Of course this is "4"
>
>
> 2013/9/13 John Emmons
>
>> CLDR v24 is scheduled to be released next week (2013-09-18). While the
>> LD
If there is
an existing such list on openi18n.org, it would make sense to
replace it with a unicode.org list given the change in hosts for CLDR
Absent such a pre-existing list, creating it should be driven by
the need for it, and so far all I've seen on this list are the expected
"what exactl
The Unicode® Consortium announced today the release of new versions of the
Common Locale Data Repository (CLDR 1.1) and the Locale Data Markup
Language specification (LDML 1.1), providing key building blocks for
software to support the world's languages. This new release contains data
From: "Philippe Verdy" <[EMAIL PROTECTED]>
Now comes the problem of tagging localized resources for the Philipines:
can we use "ph" today? or must we use only "fil" or "fil-PH"?
I have just been told by a user in the Philipinins that the theorical
distinction between Tagalog and Filipinos is rare
Following draft-langtags (and CLDR usage), it would be "tl-Tglg-PH"
Addison
Addison P. Phillips
Director, Globalization Architecture
http://www.webMethods.com
Chair, W3C Internationalization Working Group
http://www.w3.org/International
Internationalization is an architecture.
I
At 13:28 -0800 2004-12-27, Addison Phillips [wM] wrote:
Following draft-langtags (and CLDR usage), it would be "tl-Tglg-PH"
Of course the Tagalog script, unless it is enjoying a renaissance,
hasn't been used much in centuries.
--
Michael Everson * * Everson Typography * * http://www.evertype.com
Ernest,
I consider the whole "Standardize TimeZone ID" thread to have been
off-topic for the Unicode list. It is not about Unicode. It is about
locales.
--
Michael Everson * * Everson Typography * * http://www.evertype.com
TECTED]>
Sent: Sun, 2004 Apr 25 10:20
Subject: Re: [META] Should there be a separate public list for CLDR?
> Ernest,
>
> I consider the whole "Standardize TimeZone ID" thread to have been
> off-topic for the Unicode list. It is not about Unicode. It is about
> loc
At 11:35 -0700 2004-04-25, Mark Davis wrote:
This is a public, general purpose list.
Decidated to the discussion of the Unicode Standard and its implementation.
There are already many discussions of topics unrelated to the
Unicode standard per se; just look back over your messages sorted by
subj
Michael Everson scripsit:
> Please, Mark. You don't spend as much time on the Unicode list as I
> do. Trust me.
>
> Or trust MichKa.
>
> Either way, please make a new list for this specialized discussion area.
I add my voice to these. Please create a separate list for public
discussion of loc
On 25/04/2004 10:09, Ernest Cline wrote:
...If the need for a separate list exists, it should soon make itself
apparent.
I think this has already made itself apparent, from the 30 or so e-mails
on this topic which I have received in just one day, and not even a
working day for most of us. Thi
From: Peter Kirk <[EMAIL PROTECTED]>
> On 25/04/2004 10:09, Ernest Cline wrote:
>
> >...If the need for a separate list exists, it should soon make itself
> >apparent.
>
> I think this has already made itself apparent, from the 30 or so e-mails
> on this topic which I have received in just one d
On 26/04/2004 10:47, Rick McGowan wrote:
Personally I would strongly oppose making a new public list parallel to
this one for locale discussions.
My experience over several years of maintaining mail lists is that most
new lists have a week or two of postings and then languish. It is not worth
Peter Kirk wrote,
> There has now been nearly a month to gain experience on this issue.
> During this time there have been several hundred postings related to
> locales. In just the last two days there have been more than 100. It is
> very tedious for those of working on character encoding iss
100. It is
very tedious for those of working on character encoding issues to have
to receive all of this irrelevant material.
Note: discussions about the ISO 15924 beta tables are not related to the CLDR
project.
In the last two days, there has been very few messages related to the CLDR.
And
ious for those of working on character encoding issues to have
> to receive all of this irrelevant material.
Note: discussions about the ISO 15924 beta tables are not related to the CLDR
project.
In the last two days, there has been very few messages related to the CLDR.
And the discussions on ISO
At 19:13 + 2004-05-22, James Kass wrote:
Peter Kirk wrote,
There has now been nearly a month to gain experience on this issue.
During this time there have been several hundred postings related to
> locales.
Actually they were related to ISO 15924, which is a different thing
from the locales
At 12:30 -0700 2004-05-22, Peter Kirk wrote:
Well, CLDR and ISO 15924 are both about locales, and not about
character encoding.
ISO 15924 is about script codes. It is not "about locales".
If this discussion does indeed come to an end soon, I will be happy.
But I will continue to be
Peter Kirk wrote:
And in case anyone is thinking of complaining about how much
discussion of Phoenician there has been on this list, I did try to
divert the discussion to the Hebrew list right at the start, but
everyone else wanted to discuss it here.
Maybe "everyone" who doesn't think Phoenici
> [Original Message]
> From: <[EMAIL PROTECTED] (James Kass)>
>
> Peter Kirk wrote,
>
> > There has now been nearly a month to gain experience on this issue.
> > During this time there have been several hundred postings related to
> > locales. In just the last two days there have been more than
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf
> Of Rick McGowan
> The Unicode(r) Consortium announced today the release of new versions
of the
> Common Locale Data Repository (CLDR 1.1) and the Locale Data Markup
> Language specification (LDML 1.1),
I'
The reports page wasn't updated -- sorry.
As to the UTS, when CLDR came into Unicode, we decided to have it and associated
UTS's in a separate committee (LTC), since its scope was sufficiently different
from the UTC's. http://www.unicode.org/reports/about-reports.html was updated
I can't find these that are mentioned in http://cldr.unicode.org/
"For those interested in the source CLDR data, it is available for each
release in the XML format specified by LDML. There are also tools that
will convert to JSON and POSIX format. For more information, see CLDR
From: "Antoine Leca" <[EMAIL PROTECTED]>
> > Never forget that language codes and country/territory codes are
> different...
>
> We were speaking about ccTLD. A different beast. Try to resolve ANYTHING.GB.
> on a root server, or alternatively to seek UK in ISO 3166, to understand
> what I mean.
I'
1 - 100 of 124 matches
Mail list logo
