The Unicode Standard and ISO

Marcel Schneider via Unicode unicode at
Sat Jun 9 10:22:53 CDT 2018

On Sat, 9 Jun 2018 09:47:01 +0100, Richard Wordingham via Unicode wrote:
> On Sat, 9 Jun 2018 08:23:33 +0200 (CEST)
> Marcel Schneider via Unicode <unicode at> wrote:
> > > 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.  
> > 
> > Noted. For my part, sadly for C libraries I’m unlikely to be of any
> > help.
> I wonder how much of that comes under the sad category of "better not
> translated". If an English speaker has to resort to search engines to
> understand, let alone fix, a reported problem, it may be better for a
> non-English speaker to search for the error message in English, and then
> with luck he may find a solution he can understand.

Then adding a "Display in English" button in the message box is best practice.
Still I’ve never encountered any yet, and I guess this is because such a facility 
would be understood as an admission that up to now, i18n is partly a failure.

> In a related vein,
> one hears reports of people using English as the interface language,
> because they can't understand the messages allegedly in their native
> language.

If to date, automatic translation of technical English still does not work, then I’d suggest 
that CLDR feature a complete message library allowing to compose any localized piece 
of information. But such an attempt requires that all available human resources really 
focus on the project, instead of being diverted by interpersonal discordances. Sulking 
people around a project are an indicator of poor project management branding dissenters 
as enemies out of an inability to behave in a diplomatic way by lack of social skills.
At least that’s what they’d teach you in any management school.

The way Unicode behaves against William Overington is in my opinion a striking example 
of mismanagement. In one dimension I can see, the "localizable sentences" that 
William invented and that he actively promotes do fit exactly into the scheme of localizable 
information elements suggested in the preceding paragraph. I strongly recommend that 
instead of publicly blacklisting the author in the mailbox of the president and directing 
the List moderation to prohibit the topic as out of scope of Unicode, an extensible and flexible 
framework be designed in urgency under the Unicode‐CLDR umbrella to put an end to the 
pseudo‐localization that Richard pointed above.

OK I’m lacking diplomatic skills too, and this e‐mail is harsh, but I see it as a true echo.
And I apologize for my last reply to William Overington, if I need to.

Beside that, I’d suggest also to add a CLDR library of character name elements allowing 
to compose every existing Unicode character name in all supported locales, for use in 
system character pickers and special character dialogs. This library should then be updated 
at each major release of the UCS. Hopefully this library is then flexible enough to avoid 
any Standardese, be it in English, in French, or in any language aping English Standardese.
E.g. when the ISO/IEC 10646 mirror of Unicode was published in an official French version, 
the official translators felt partly committed to ape English Standardese, of which we know 
that it isn’t due mainly to Unicode, but to the then‐head of ISO/IEC JTC1 SC2 WG2. Not to 
warm up that old grudge, just to show how on‐topic that is. Be it Standardese or pseudo‐
localization, the effect is always to worsen UX by missing the point.

Best regards,


More information about the Unicode mailing list