The Unicode Standard and ISO
Marcel Schneider via Unicode
unicode at unicode.org
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 unicode.org> 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
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.
More information about the Unicode