Re: [PATCH] Fix decimal_point and thousands_sep in es_MX locale

[Petr Baudis <pasky at ucw dot cz>]

On Fri, Jun 08, 2012 at 12:50:31AM +0200, Keld Simonsen wrote:
> Yes, of cause it should be possible to use UTF-8 characters. 
> 
> But we then may need to have more versions of locales, eg. one with
> utf-8 characters, and one with a more restricted character set.

  Isn't this all solved by localedef? Except where different
transliterations are required in various context, but I don't
know about any case like that.

> >   (In case a locale is generated with more restrictive charset, e.g.
> > ISO-8859-1, the thin space is automatically transliterated to normal
> > space.)
> 
> Is it really transtliterated to a notrmal space? What wonders
> our locales can do:-)

  Yes it is, that's what all the translit* files do. (This one is
handled in translit_compat.)

> A problem with the normal space is that it is difficult to parse.
> A normal space is normally used as a separator. 

  But that's our current situation.

> There is also a question  on what our locales really are aimed at.
> Eg dates, - what we have is partly meant for listing files in long
> format (ls -l) and this indicates that the format needs to be
> constant width.

  This is all very hairy. ls -l in particular does some very special
magic that in part boils down to internally gettexting message formats
and auto-guessing width modifier for %b based on chosen locale (so that
field can be variable-width). The final value printed does not map
easily to any LC_TIME key.

> The same with number formats: There seems to be several schools
> whether to use a space or period/comma as thousands separator in a number of countries.
> EG Norway - the linguists says space, but banks allways use period.
> Spreadsheets use period too, and all financial software likewise.
> For programs where you need to process outputted numbers again, the
> numbers better be parsable - there is then a point in having the locales be
> more computer-oriented than the linguists want them to be. This could lead
> to having more specification possibilities in the locales.

  We have separate thousands separator for normal numbers and monetary
values in locales, so is this really an issue?

> BTW, why thin space? My understanding is that numbers often needs to
> be output very aligned, and thus all digits need to have the same width.
> The space should then have also the same width as a digit.
> (The same goes for comma as  decimal separator)

  In monospace fonts, thin space is as wide as normal space. In other
fonts, digits are variable-width anyway and you will not get alignment.

-- 
				Petr "Pasky" Baudis
	Smart data structures and dumb code works a lot better
	than the other way around.  -- Eric S. Raymond