From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12136 Path: news.gmane.org!.POSTED!not-for-mail From: "A. Wilcox" Newsgroups: gmane.linux.lib.musl.general Subject: Re: Bikeshed invitation for nl_langinfo ambiguities Date: Sun, 26 Nov 2017 17:19:07 -0600 Organization: =?UTF-8?Q?Ad=c3=a9lie_Linux?= Message-ID: <5A1B4BEB.5030304@adelielinux.org> References: <20171111020612.GV1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1511738362 6267 195.159.176.226 (26 Nov 2017 23:19:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Nov 2017 23:19:22 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 To: musl@lists.openwall.com Original-X-From: musl-return-12152-gllmg-musl=m.gmane.org@lists.openwall.com Mon Nov 27 00:19:18 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1eJ6Cj-0001JC-T7 for gllmg-musl@m.gmane.org; Mon, 27 Nov 2017 00:19:17 +0100 Original-Received: (qmail 15882 invoked by uid 550); 26 Nov 2017 23:19:23 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 15864 invoked from network); 26 Nov 2017 23:19:22 -0000 X-Enigmail-Draft-Status: N1110 In-Reply-To: <20171111020612.GV1627@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:12136 Archived-At: -----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. 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. 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. > So.... it's bikeshed time. > > Rich > Yellow, definitely pastel yellow. It's a nice muted colour that is warm and inviting without being too striking or in-your-face. The perfect colour for any bikeshed! Best, - --arw - -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJaG0vnAAoJEMspy1GSK50UjGsQAKiuZi+AehXhCgZpzM/ZxKP9 UB4UtvnG9u6EyEbEI+2lpUcftoP+gDLMYyiObjIPH8o5/8v0jlQqFzWgd7E9Mdoa fCgicD8iozr5rDPdF8aEpDOlks97leGErXTjVdozH4PRgHdU9XranzCEKD0rpAiI BI0Ti2CaKOADRoqb5+ZCsL+3giljD2I1PTEkahSD4NeOd28NKAAIY1PtvqkOg5JX XR4CyGA/XRUB/bbyGcfD/ASMpUltw1Jc57xXryvfeo5SHkmJ7/e/KCZmIrZZO0sO lmsEU3OqbrE8/1PlDLMRLn9ty/DH241FWxDEsktTjLb09GgNjlv7W3Um2IdXpM/E EkjZiRuudW0Wr6rQamaOpgJTmpDZSd0MrlNDnib8lFNrP6I7AnIserDSeRtUAVGG pqRWtL2QxEnmZVRH24L71Z7g6BNOFmwIBKtQrYzvn4oUwijUnP23ZYJ0l837F6rR VyhgklTReGjknvxDk2lcXvAnyjMRVFGMDFBOmMeVv1StcN0fIiro4CQh3Si8MFqS nn2u0qBiziLx956MpjYJ4WezzesPJYsTBW77nb1YssPm+sP65aZ9hgaJh56jeESC ruPi7wwMoqN9hZldzCWEMao7zOxpq/IX40T2YJtwBXfFdpOU99OS3jr09vQI3xR6 I6U+YiwwcCMFxU4IkjD4 =DwvU -----END PGP SIGNATURE-----