From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77903 invoked by alias); 23 Apr 2016 12:01:35 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 77885 invoked by uid 89); 23 Apr 2016 12:01:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,T_FILL_THIS_FORM_SHORT autolearn=ham version=3.3.2 spammy=COUNTRY, justify, POSTAL, de_DE X-HELO: albireo.enyo.de From: Florian Weimer To: libc-alpha@sourceware.org Cc: pander@users.sourceforge.net Subject: Re: mix/match lang/territory References: <1461298610-19221-1-git-send-email-vapier@gentoo.org> <87a8klk4jp.fsf@mid.deneb.enyo.de> <20160422190728.GC5369@vapier.lan> Date: Sat, 23 Apr 2016 12:01:00 -0000 In-Reply-To: <20160422190728.GC5369@vapier.lan> (Mike Frysinger's message of "Fri, 22 Apr 2016 15:07:28 -0400") Message-ID: <871t5wlejq.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2016-04/txt/msg00579.txt.bz2 * Mike Frysinger: > which leaves us with the ones that are actually defined in this locale: > LC_TIME > - day/month fields are def language specific. > - all the other fields are largely territory specific (the way date & > time are displayed locally). But you use ISO 8601, not the local conventions. I'm not saying this is wrong, my hunch is that most en_NL users could live with that (it would definitely work for me with a hypothetical en_DE locale). We already have a request for ISO 8601 variants of locales. It is not clear if this affects date_fmt or just d_fmt (we probably have requests for both). I think adding these variants would make more sense, and then users can pick that locale along with nl_NL. > LC_ADDRESS > - country_name & lang_* are def language specific. > - all the other fields are territory specific. geocode/geoclue uses _NL_ADDRESS_POSTAL_FMT to determine the ordering of street name and street number. evolution-data-server uses _NL_ADDRESS_COUNTRY_AB2. I can't find any other users. So in practice, it should be fine to use nl_NL here. Unless there are other ways to access this information besides _NL_ADDRESS_.* and nl_langinfo_l.*(POSTAL|COUNTRY|LANG). (Without any users, we can't justify a decision which language to use for the translatable fields. Users may prefer either variant.) > LC_IDENTIFICATION > - clearly includes both lang & territory details, but not nearly as > important as the categories above. could just be lived with. _NL_IDENTIFICATION_TERRITORY is used by LightDM, but it assumes that it is in English (which matches what glibc currently does for nl_NL, fr_FR and de_DE at least). > this one can be a bit murky, so i guess > LC_MONETARY > - currency fields are def territory related. > - the others are semi-lang dependent/personal preference (digit spacing > and such), but there's no way to customize on a sub-category basis. Hmm. I think the main obstacle here is that we want the numbering format to match LC_NUMERIC, and you assume that users want en_GB there. This is probably the right choice. So the question is: What programs actually rely on LC_MONETARY? If there is a body of software which uses LC_MONETARY, we need a compelling solution for this aspect of the problem. As far as I can see, it is the only one which is really not addressable with LC_* settings. > so the question before us is how do we want to proceed ? telling users > "that sucks but that's just how it goes" doesn't seems like the right path > to me long term. exploding combinations of lang/territories also sucks, > but it's the only way today to accomplish this. Agreed. > maybe we could spec out a new format for the env vars that'd allow people > to mix & match lang & territory themselves ? POSIX leaves the format of > locale names up to the implementation after all, as well as the output of > the localedef tool. we could do something like: > LANG=[lang]:[territory] > LANG=en_US:nl_NL > and we'd take care of filling in lang fields using en_US and territory > fields using nl_NL. this would go beyond just category selection since > as i described above. Do we need anything besides an override for the currency symbols in LC_MONETARY?