Re: Bikeshed invitation for nl_langinfo ambiguities

["A. Wilcox" <awilfox@adelielinux.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 26/11/17 19:07, Rich Felker wrote:
>> 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.


That was the idea, yes.  This would work for *all* translatable
strings, not just the nl_langinfo ones.


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


"Of course"?  Why not?  The reason this wouldn't be acceptable is not
obvious to me.


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


That would work.


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



If you are returning (string+1), then all strings need to have the " "
at the beginning, or else you are going to return "ai" instead of
"mai" for French and so on.


Best,
- --arw
- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJaG38SAAoJEMspy1GSK50UblkQAMqHOuqFTrgbV6k5+6scBc2y
a6IcldAupt6swk1b/+Bzro7n3DVcVhoBOV97ofyPSlwT1OOzFCoc6ljeqR1+TUgZ
ZaFyOPICpS/1xnBqiipiQgQjn0a9/ZH7fDeb54aP3F0Jp18hrjwpvFduWcNItx/D
AonDoUGecrahwwBYUYjk7GJ6Hp2hqeVGPLTpNWKwDkXTvN1CQ9HTCTRsBdaBkuFh
CevzYbt4m+BQblcr4IdCHlKr5Yenb8s5aHCvV8ag/PhC1uFD6/MFu6kgKQbyqjfr
ji9mD4xoX/l0rrUXqPGpdLRs5OwCpda42lGxUu9gGIUDrMt3v3YAPXTbsePTa6H6
+9cPNd562OqTqoCDiG6V7pWSapyDK+eR7swwnqNDe1Z8AyHZN3/2tJ3Gr/jH98Ko
Vvjyv4sybiAgqdiu5Q/v1kKX0hVafOz7KNRKQuFt9kiUG8bj6S714CYg3WCFW7uk
30KdhI02Iy888y/nZIn6ApzmCsmx42ZZeG16CqgsbizXuyZK1kndXSaPuE7TG7Ot
0vxiz5B1Zv0ftqgEMaFeG1yqNpCPINhyYRjWMMohfrm9hi7gXQEtYWb4o+ibmb52
I/iCYdvRCcfPll48p3MNIc3w8zUDVs2vF86WQhX0nrWNnwI6urTmOdnC3L5fM4zz
CzCoHkaHJIj2HEPE0V2o
=MtiD
-----END PGP SIGNATURE-----