From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12141 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: Mon, 27 Nov 2017 00:09:34 -0500 Message-ID: <20171127050934.GX1627@brightrain.aerifal.cx> References: <20171111020612.GV1627@brightrain.aerifal.cx> <5A1B4BEB.5030304@adelielinux.org> <20171127010700.GW1627@brightrain.aerifal.cx> <5A1B7F15.4050808@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 1511759388 13777 195.159.176.226 (27 Nov 2017 05:09:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 27 Nov 2017 05:09:48 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12157-gllmg-musl=m.gmane.org@lists.openwall.com Mon Nov 27 06:09:45 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 1eJBfp-00030G-5L for gllmg-musl@m.gmane.org; Mon, 27 Nov 2017 06:09:41 +0100 Original-Received: (qmail 18084 invoked by uid 550); 27 Nov 2017 05:09:46 -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 18066 invoked from network); 27 Nov 2017 05:09:46 -0000 Content-Disposition: inline In-Reply-To: <5A1B7F15.4050808@adelielinux.org> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12141 Archived-At: On Sun, Nov 26, 2017 at 08:57:25PM -0600, A. Wilcox wrote: > -----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. It basically means there's no such thing as "truely static linked" binaries anymore, and all programs need to search for and open the "C locale translation file" at program startup time, resulting a number of syscalls. None of this would be remotely acceptable to a large portion of musl's userbase, including myself. If it's not clear why, just observe that functions like nl_langinfo, strftime, etc. have no way to fail for arbitrary reasons when the input is valid. The only way to ensure that they can't fail is to have the data they need already loaded at the time the locale is set, which for the default C locale is program start time. Normally/currently this is achieved just by having the strings in the program text segment. > > 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. I see. I was not intending to include the prefix in the translated strings, just in the key. Rich