From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5566 Path: news.gmane.org!not-for-mail From: u-igbb@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: Re: Locale bikeshed time Date: Wed, 23 Jul 2014 11:50:31 +0200 Message-ID: <20140723095031.GE16795@example.net> References: <20140722184932.GA4914@brightrain.aerifal.cx> <20140722201008.GC16795@example.net> <20140722203540.GA11570@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1406109062 28618 80.91.229.3 (23 Jul 2014 09:51:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Jul 2014 09:51:02 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5571-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 23 11:50:56 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1X9tCJ-0002uV-JT for gllmg-musl@plane.gmane.org; Wed, 23 Jul 2014 11:50:55 +0200 Original-Received: (qmail 1947 invoked by uid 550); 23 Jul 2014 09:50:53 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 1921 invoked from network); 23 Jul 2014 09:50:53 -0000 X-T2-Spam-Status: No, hits=0.0 required=5.0 Received-SPF: none receiver=mailfe02.swip.net; client-ip=178.217.187.39; envelope-from=u-igbb@aetey.se Content-Disposition: inline In-Reply-To: <20140722203540.GA11570@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:5566 Archived-At: On Tue, Jul 22, 2014 at 04:35:40PM -0400, Rich Felker wrote: > Having one variable configure multiple things is usually error-prone > and inflexible. +1 > > By the way, please do not follow the way of a single big file. > > For systems which rely on file boundaries to reflect data clustering > I hadn't even considered this aspect, but I think the whole concept of > a single big file is undesirable with data that's naturally subject to > change over time, and where the data comes from multiple sources. So I > wasn't really considering that option anyway. Nice. > > I actually do mix categories from different locales. > > No problem as long as the files are small. > > Note that if you're just mixing "ll_TT" and "C", there wouldn't be any > cost anyway since the C locale (and its aliases) are builtin and never > loaded from a file. Where I was thinking you might see duplication is Sure. This covers certainly most of my preferences but I thought of LANG=l1_T1 and LC_SOMETHING=l2_T2 [and LC_SOMETHINGELSE=l3_T3]. This would result in pulling in two or three locale data files but the overhead is presumably negligible. > for things like: LC_ALL=ll_TT@modifier where modifier is really just > an alternate for one category (e.g. ISO date format for time, alt > collation order, etc.), but the file ends up storing duplicates of all > the data from other categories. However, I think the alternate > preferred usage here would be to provide a file for just the category > being overridden that does not contain the base data and require users > to set the individual categories, like what you're doing, e.g. > LANG=ll_TT LC_TIME=ll_TT@isodate This means that most of the time there will be a single locale file to be opened, sometimes more, in extreme cases up to the number of categories, the files also being of different "completeness". This would certainly contribute to confusion for both the administrators and the users. For the sake of uniformity I would possibly prefer to see only the "thinner" files defining exactly one category, instead of different files having different numbers of included categories. But most of all I'd support your approach of including all information in each file. This is "least confusing" and quite efficient. The overhead is mostly static storage (not noticeable in our setup and probably not much anyway :) and the run time overhead affects just the minority of users who mix locales/categories. (Oh btw as a nice bonus this makes the file boundaries correspond to the data usage patterns). To summarize my view, - a file per locale, with all categories included best - a file per category acceptable - files with differing data subsets please don't > rather than: > > LC_ALL=ll_TT@isodate In a real scenario it would be probably LANG=ll_TT@isodate and this feels OK. > Rich Regards, Rune