Marcel, On Fri, Jun 8, 2018 at 6:52 AM, Marcel Schneider via Unicode < unicode@unicode.org> 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 http://cldr.unicode.org/index/acknowledgments "The founding members of the workgroup were IBM, Sun and OpenOffice.org". 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 http://www.computinghistory.org.uk/det/13342/IBM-National-Language-Support-Reference-Manual-Volume-2/ - 4th edition published in 1994.) 100 locales we contributed to glibc as well. 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. Steven