Re: [gtk-list] imlib and language (was: pixmaps and LANG..)
- From: Steve Hosgood <iisteve iiweeble swan ac uk>
- To: gtk-list redhat com
- Subject: Re: [gtk-list] imlib and language (was: pixmaps and LANG..)
- Date: Fri, 28 Aug 1998 14:43:28 +0100
Michael Lausch <mla@gams.co.at> wrote:
> Floating point values are written using one of the printf functions
> and a format of %f, %g,... The format of the floating point number
> depends on the LANG variable. for english the floating point value is
> written in a format like 99999.999999 (see the point as the decimal
> marker). The whgole german countries are using a comma `,' as the
> decimal marker, therfore the number lokks like 99999,999999 if you
> choose a german locale. Now reading such a file with a different
> locale is a problem
>
> I don't have a solution handy which is clean and not a hack.
>
I can think of two non-hack solutions, one good, one not-so-good.
The not-so-good one is to impose a locale-independent spec for these
~/.imrc files. I consider this a poor solution because I assume you *want*
to let people write them according to their 'natural' habits. But if instead
you consider that the .imrc file should never be human-written, but only ever
machine-written (and read) then you could impose a standard. ( Of course any
program that allows editing of this file can present its contents in a locale-
dependent manner for human consumption. )
But a better solution might be that you specfy the first line of the .imrc
file tells you what locale it was written in. Imlib then temporarily sets itself
with this locale for reading the file, then goes back to the real one.
That's not a hack is it? :-)
This latter solution could fix the troubles in other .rc files where (say)
times and temperatures are stored. US users seem to like 12 hour clocks with
AM/PM indicators, everyone else likes 24 hour clocks. Likewise for
temperatures the 'US' locale assumes Farenheit, everyone else assumes
Celsius (except the 'NASA' locale that assumes Rankine of course!). And of
course there's the famous trouble with dates where the US assumes MM/DD/YYYY,
Europe assumes DD/MM/YYYY and Japan assumes YYYY/MM/DD.
All of this could be fixed with a 'locale=XX' line at the top of the file.
--
Steve | Steve's law of House Rewiring:
S.Hosgood@swansea.ac.uk | "No matter how many power sockets
Phone: +44 1792 297292 + ask for Steve | you fit in a room, you will run
Fax: +44 1792 295811 | out within the first week of use
--------------------------------------------+ even if you took Steve's law of
http://iiit.swan.ac.uk/~iisteve/steve.html | House Rewiring into account"
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]