Re: Bikeshed invitation for nl_langinfo ambiguities

[Rich Felker <dalias@libc.org>]

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.

I think this may be the nicest approach, despite being an incompatible
change from the existing system, which apparently doesn't matter and
isn't being used or people would have noticed that "May" can't be
translated right.

> 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.

As noted before, obviously this isn't acceptable. We could drop a .mo
file blob in the musl langinfo.c, but I think it might make more sense
to just use different code paths for translated vs nontranslated case.
Then we could just synthesize the keys (ABMON_*, MON_*, ABDAY_*,
DAY_*) to pass into LCTRANS() rather than having a table of them all
expanded out. I might change my mind when actually working out how the
code would look, though.

An alternative I thought about would be just having translations for
"ABMON", "MON", etc. that produce nul-delimited multistrings, but then
the data file encodes an assumption that musl will do the O(n) (albeit
small n) multistring scan for the requested item, and I don't think
it's nice encoding assumptions that limit efficiency or force a
particular size/efficiency tradeoff.

Rich