From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5641 Path: news.gmane.org!not-for-mail From: u-igbb@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: Re: Locale bikeshed time Date: Sun, 27 Jul 2014 09:28:55 +0200 Message-ID: <20140727072855.GA16795@example.net> References: <20140724220228.GB4038@brightrain.aerifal.cx> <20140725090649.GN16795@example.net> <20140725201551.GQ16795@example.net> <20140725223239.GG4038@brightrain.aerifal.cx> <20140726072502.GR16795@example.net> <20140726080327.GJ4038@brightrain.aerifal.cx> <20140726093805.GS16795@example.net> <20140726174706.GF10402@port70.net> <20140726185613.GY16795@example.net> <20140726193015.GQ4038@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1406446167 29380 80.91.229.3 (27 Jul 2014 07:29:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Jul 2014 07:29:27 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5646-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jul 27 09:29:20 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 1XBItU-0002fJ-F4 for gllmg-musl@plane.gmane.org; Sun, 27 Jul 2014 09:29:20 +0200 Original-Received: (qmail 24117 invoked by uid 550); 27 Jul 2014 07:29:17 -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 24102 invoked from network); 27 Jul 2014 07:29:15 -0000 X-T2-Spam-Status: No, hits=0.0 required=5.0 Received-SPF: none receiver=mailfe07.swip.net; client-ip=31.172.30.3; envelope-from=u-igbb@aetey.se Content-Disposition: inline In-Reply-To: <20140726193015.GQ4038@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:5641 Archived-At: On Sat, Jul 26, 2014 at 03:30:15PM -0400, Rich Felker wrote: > The original locale plan was based on the principle that the whole > locale system in C/POSIX is poorly designed, but that it's still the Sure. > basis for supporting native-language interfaces in software, and thus > that musl should eventually have the minimal locale support necessary > for enabling such usage. Using the locale system as a means for > arbitrary non-essential customization, support for legacy character > encodings, etc. is outside the scope of that. Sounds pretty reasonable. > > If anybody else feels for using "," than so be it in the corresponding > > locale, as the default or as a variant - how much would it cost? This (the cost) is as I see it the main consideration. > > Actually I very much dislike software which expects that it knows my > > situation better than myself and prevents me from doing what I need. > > And what about character encoding? Should we also support Latin-1? Or This is a different matter, not exactly about cost against perceived benefit. You _do_ offer a means to represent the user's data by unicode/utf-8, so the desired function (e.g. to represent åäöü) is available. It is different with the radix point as there is hardly another means for helping the user to handle her grandmother's favourite radix character. There is a difference between computing-related preferences like "I like Latin-1 and refuse to recode my data to utf-8" and the real life ones like "I grew up in Germany and despite 20 years in USA still confuse 24 and 42 in English". What you call "a single pixel" makes for some people the difference between apparent legibility and gibberish. Note, one e.g. can be very much used to interpreting '.' as a thousand delimiter and will be utterly confused by 3.142 . > ISO-2022? One thing I don't like about how the whole locale discussion > has gone is that, once one one thing is added, demands for more and > more things that have much higher implementation and maintenance I do not demand for more things, I just want to go after cost vs benefit. If the cost is high we may have to drop even very useful features. Without analysing the code I can not say how dangerous / bothersome / complex it would be to support one alternative character as radix dot and weight this against making about half the human population 1% happier. :) (A third character for radix dot would certainly affect much less than half the population). It is you who have a say about the balance, I just call for objective reasoning. Being generally upset about "feature proliferation" does not help, features is what any software is about. Do not doubt, in my eyes compactness and simplicity => robustness and safety are extremely important features, as they are for you. > practical benefit, keep popping up. Radix points is definitely such an > item where the cost (in terms of bug/security risks, code size, making > state-free code stateful, maintenance, and just plain being ugly, ...) > is relatively high It is your competence area. > and the benefits are near-zero. But this one is possibly to some degree outside of your personal experience and you may _possibly_ have a biased impression. That's why I dare to spend the precious time of yours and of mine for this discussion. Thanks for listening and of course for musl as it is - clean and useful. Yours, Rune