[fpc-pascal] locale solution for unix systems
idokan at gmail.com
Thu Mar 19 09:55:11 CET 2009
The locale itself is not just ascii based files, there are compiled
files, so you will require to re-implement the way of reading the data
inside the compiled files.
If you wish to make rules on your own, well it's way too much
information to add to RTL.
For example here in Israel our first work day in the week is Sunday
and not Monday, so you will need to work with it. Also our date format
is dd/mm/yyyy and not mm/dd/yyyy or yyyy/mm/dd
etc.. Currency separator is comma, the actual names of things are in
Hebrew, so for each locale you will require to re-implement all of
this rules. That's why using the libc functions is better.
Or am I missing here something in what you are saying ?
On Thu, Mar 19, 2009 at 10:44 AM, Graeme Geldenhuys
<graemeg.lists at gmail.com> wrote:
> On Thu, Mar 19, 2009 at 10:17 AM, ik <idokan at gmail.com> wrote:
>> In order to know what is the active local in Unix/Linux you should
>> check the environment variables.
>> If it was not defined or it stand on "C", then en_US is inplace.
> Currently FPC doesn't populate the locale variable on unix systems (if
> you don't compile your application with the libc related units).
> $> locale
> Yet if I create a simple console application the date formats etc are
> all en_US. I want to write a new unit that doesn't rely on libc
> (seeing that it isn't available on all UNIX-style platforms) that will
> parse the correct locale text files (base on LC_xxx environment
> variables) and populate the locale variables in the RTL.
> It's on my todo list, but I have a few more things to finish before I
> can start this project.
> - Graeme -
> fpGUI - a cross-platform Free Pascal GUI toolkit
> fpc-pascal maillist - fpc-pascal at lists.freepascal.org
More information about the fpc-pascal