[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 26 Nov 2017 20:07:00 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Bikeshed invitation for nl_langinfo ambiguities
On Sun, Nov 26, 2017 at 05:19:07PM -0600, A. Wilcox wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 10/11/17 20:06, Rich Felker wrote:
> > I've found 2 ambiguous-string-to-translate bugs in musl's locale
> > support in nl_langinfo: The pairs ABMON_5 and MON_5 ("May"), and
> > T_FMT and ERA_T_FMT ("%H:%M:%S"), have the same values in the C
> > locale, and thus can't be translated to distinct values like they
> > need to be in other locales.
> >
> > Any opinions on the cleanest way to handle this? There are various
> > hacks I could do at the implementation level, like adding a prefix
> > character to one or the other then applying +1 to the output
> > string, But whatever solution we choose becomes a public interface
> > for translators, so it should be something that's not horribly
> > ugly.
>
> I would personally recommend actually using the enum values as the
> strings to translate. _("MON_5"), _("ABMON_5"), etc; this is
> non-ambiguous, easily understandable and describable for translators,
> and does not require weird hacks at the implementation or ABI level.
This is certainly one possibility, but it does result in embedding a
number of "useless" strings that are never used themselves, only as
translation keys, in the binary. One nice property of it (especially
if we did the same for strerror keys) is that it eliminates the need
for translation files to care about changes in the text in musl.
> Of course, then a "C" / "POSIX" strings file must be present. But
> this is, in my opinion, a very small sacrifice to ensure full purity
> and ease of translation.
This is of course not acceptable. It's solvable just by having the
"translations" embedded (in mo format or otherwise) in the source, but
then it's impossible for __lctrans to be a dummy identity-map in
programs that don't link setlocale/newlocale. I have in mind a way we
could potentially avoid this: passing keys like "ABMON_5" to
__lctrans, and if it returns back the key (which is what happens with
the stub implementation or with no translation present), use the
builtin C locale strings instead.
> A simple " " with a note it is intentional /could/ work, but then
> every locale file has to have an extra " " for those two values. This
> would additionally affect any additional duplicate strings that are
> found when musl is translated to other languages. If there's just ten
> of these, and musl is ported to just 100 languages (glibc has over
> 200), that's already 10 kB wasted on a silly hack. It is also more
> brittle.
I don't follow; there are only two duplicate strings and they are
"May" and "%H:%M:%S". The number does not grow with the number of
translations because it's a property of the untranslated strings not
the translated ones.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
