From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12137 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Bikeshed invitation for nl_langinfo ambiguities Date: Sun, 26 Nov 2017 20:07:00 -0500 Message-ID: <20171127010700.GW1627@brightrain.aerifal.cx> References: <20171111020612.GV1627@brightrain.aerifal.cx> <5A1B4BEB.5030304@adelielinux.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1511744834 31185 195.159.176.226 (27 Nov 2017 01:07:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 27 Nov 2017 01:07:14 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12153-gllmg-musl=m.gmane.org@lists.openwall.com Mon Nov 27 02:07:11 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 1eJ7t6-0007hT-8o for gllmg-musl@m.gmane.org; Mon, 27 Nov 2017 02:07:08 +0100 Original-Received: (qmail 26528 invoked by uid 550); 27 Nov 2017 01:07:12 -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 26508 invoked from network); 27 Nov 2017 01:07:12 -0000 Content-Disposition: inline In-Reply-To: <5A1B4BEB.5030304@adelielinux.org> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12137 Archived-At: 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