The Unicode Standard and ISO

[Marcel Schneider via Unicode]

On Fri, 8 Jun 2018 13:06:18 +0200, Mark Davis ☕️ via Unicode wrote:
> 
> Where are you getting your "facts"? Among many unsubstantiated or ambiguous claims in that very long sentence:
>
> > "French locale in CLDR is still surprisingly incomplete". 
>
> For each release, the data collected for the French locale is complete to the bar we have set for Level=Modern.

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".

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.

Beyond what everybody on this List is able to decrypt on his or her own, I’m not in a position to disclose 
any further personal information, for witness protection’s sake.

> What you may mean is that CLDR doesn't support a structure that you think it should.
> For that, you have to make a compelling case that the structure you propose is worth it, worth diverting people from other priorities.

Thank you, that is not a problem and may be resolved after filing a ticket, which would be done for a later release, given that 
top priority tasks require a potentially huge amount of work. First NBSP and NNBSP need to be added to the French charset (see
http://unicode.org/cldr/trac/ticket/11120
). Adding centuries to Date&Time (with French short form "s.") is of interest for any locale, but irrelevant to everyday business practice.

>
> 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.

>
> We have many French contribute data over time.

When finding the word "keycap" as a French translation of "keycap" in my copy of CLDR data at home, I wanted to know who contributed 
that data. I was told that when survey is open, I’ll see who is contributing. I won’t blame those who are helping resolve the issue now.

> Now, it works better when people engage under the umbrella of an organization, but even there that doesn't have to be a company;
> we have liaison relationships with government agencies and NGOs.

That’s fine. But even as a guest I’m well received, and anyhow the point is to bring the arguments. 

My concern is that starting with a good translation from scratch is more efficient than attempting to correct the same error(s) 
across multiple instances via the survey tool, that seems to be designed to fix small errors rather than to redesign entire parts 
of the scheme. 

>
> 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.

>
> 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.

> BTW, your use of the term "refuse" might be a language issue. I don't "refuse" to respond
> to the widow of a Nigerian Prince who wants to give me $1M. Since I don't think it is worth my time,
> or am not willing to upfront the low, low fee of $10K, I might "ignore" the email, or "not respond" to it.
> Or I might "decline" it with a no-thanks or not-interested response. But none of that is to "refuse" it. 

Thanks, I got it (the point, and the e‐mail).

More seriously, to ignore or not to respond to, or even to decline a suggestion made by a well‐known high official is in my opinion as much as 
to refuse that proposition. Beyond that, I think I’d be unable to carve out any common denominator with an unsolicited bulk e‐mail.

Marcel

>
> On Fri, Jun 8, 2018 at 5:32 AM, Marcel Schneider via Unicode  wrote:
>
> > On Thu, 7 Jun 2018 22:46:12 +0300, Erkki I. Kolehmainen via Unicode wrote:
> > 
> > > I cannot but fully agree with Mark and Michael.
> > >
> > > Sincerely
> > 
> >
> >Thank you for confirming. All witnesses concur to invalidate the statement about 
> >uniqueness of ISO/IEC 10646 ‐ Unicode synchrony. — After being invented in its 
> >actual form, sorting was standardized simultaneously in ISO/IEC 14651 and in 
> >Unicode Collation Algorithm, the latter including practice‐oriented extra features. 
> >Since then, these two standards are kept in synchrony uninterruptedly.
> >
> >Getting people to correct the overall response was not really my initial concern, 
> >however. What bothered me before I learned that Unicode refuses to cooperate 
> >with ISO/IEC JTC1 SC22 is that the registration of the French locale in CLDR is 
> >still surprisingly incomplete despite the meritorious efforts made by the actual 
> >contributors, and then after some investigation, that the main part of the potential 
> >French contributors are prevented from cooperating because Unicode refuses to 
> >cooperate with ISO/IEC on locale data while ISO/IEC 15897 predates CLDR, 
> >reportedly after many attempts made to merge both standards, remaining
> >unsuccessful without any striking exposure or friendly agreement to avoid kind of 
> >an impression of unconcerned rebuff.
> > 
> >Best regards,
> >
> >Marcel
> 
>