From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12576 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: Sat, 3 Mar 2018 00:08:54 -0500 Message-ID: <20180303050854.GD1436@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 1520053629 28405 195.159.176.226 (3 Mar 2018 05:07:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 3 Mar 2018 05:07:09 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12592-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 03 06:07:04 2018 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 1erzNw-0006sh-FW for gllmg-musl@m.gmane.org; Sat, 03 Mar 2018 06:07:04 +0100 Original-Received: (qmail 10042 invoked by uid 550); 3 Mar 2018 05:09:07 -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 10014 invoked from network); 3 Mar 2018 05:09:06 -0000 Content-Disposition: inline In-Reply-To: <5A1B4BEB.5030304@adelielinux.org> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12576 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. 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