Re: The Unicode Standard and ISO

From: Steven R. Loomis via Unicode <>
Date: Fri, 8 Jun 2018 09:20:09 -0700


On Fri, Jun 8, 2018 at 6:52 AM, Marcel Schneider via Unicode <> wrote:
> What got me started is that before even I requested a submitter ID (and
> the reason why I’ve requested one),
> "Characters | Category | Label | keycap" remained untranslated, i.e. its
> French translation was "keycap".
> When I proposed "cabochon", the present contributors kindly upvoted or
> proposed "touche" even before I
> launched a forum thread, and when I got aware, I changed my vote and
> posted the rationale on the forum,
> so the upvoting contributor kindly followed so that now we stay united for
> "touche", rather than "keycap".

 But, it sounds like the CLDR process was successful in this case. Thank
you for contributing.

> Please note that I acknowledge everybody and don’t criticize anybody. It
> doesn’t require much imagination
> to figure out that when CLDR was set up, there were so few or even no
> French contributors that translating
> "keycap" either fell out of deadline or was overlooked or whatever, and
> later passed unnoticed. That is a
> tracer detecting that none of the people setting up the French translation
> of the Code Charts were ever on
> the CLDR project. Because if anybody of them had been active on CLDR, no
> English word would have been
> kept in use mistakenly for the French locale.

Actually, I think the particular data item you found is relatively new. The
first values entered for it in any language were May 18th of this year.
Were there votes for "keycap" earlier?
Rather than a tracer finding evidence of neglect, you are at the forefront
of progressing the translated data for French. Congratulations!

> French contributors are not "prevented from cooperating". Where do you
get this from? Who do you mean?

> Historic French contributors are ethically prevented from contributing to
> CLDR, because of a strong commitment to involve ISO/IEC,
> a notion that is very meaningful to Unicode. People relevant to projects
> for French locale do trace the borderline of applicability wider
> than do those people who are closerly tied to Unicode‐related projects.

Which contributors specifically are prevented?

> > There were not "many attempts" at a merger, and Unicode didn't "refuse"
> anything. Who do you think "attempted", and when?
> An influential person consistently campaigned for a merger of CLDR and
> ISO/IEC 15897, but that never succeeded. It’s unlikely to be ignored.

Which person?

> Albeit given the state of ISO/IEC 15897, there was nothing such a merger
> would have contributed anyway.
> I’ve took a glance at the data of ISO/IEC 15897 and cannot figure out that
> there is nothing to pick from. At least they won’t be disposed to
> sell you "keycap" as a French term or as being in any use in that target
> locale. And anyhow, the gesture would be appreciated as a piece
> of good diplomacy. Hopefully a lightweight proceeding could end up in that
> data being transferred to CLDR, and this being cited as sole
> normative reference in ISO/IEC 15897. As a result, everybody’s happy.

 The registry for ISO/IEC 15897 has neither data for French, nor structure
that would translate the term "Characters | Category | Label | keycap". So
there would be nothing to merge with there.

So, historically, CLDR began not a part of Unicode, but as part of Li18nx
under the Free Standards Group. See the bottom of the page "The founding members of the
workgroup were IBM, Sun and". What we were trying to do was
to provide internationalized content for Linux, and also, to resolve the
then-disparity between locale data across platforms. Locale data was very
divergent between platforms - spelling and word choice changes, etc.
Comparisons were done and a Common locale data repository (with its
attendant XML formats) emerged. That's the C in CLDR. Seed data came from
IBM’s ICIR which dates many decades before 15897 (example
- 4th edition published in 1994.) 100 locales we contributed to glibc as

Where there is opportunity for productive sync and merging with is glibc.
We have had some discussions, but more needs to be done- especially a lot
of tooling work. Currently many bug reports are duplicated between glibc
and cldr, a sort of manual synchronization. Help wanted here.

Received on Fri Jun 08 2018 - 11:20:41 CDT

This archive was generated by hypermail 2.2.0 : Fri Jun 08 2018 - 11:20:41 CDT