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@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 > 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. http://www.unicode.org/mail-arch/unicode-ml/y2018-m03/0118.html 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, Marcel