[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140706050612.GA25025@brightrain.aerifal.cx>
Date: Sun, 6 Jul 2014 01:06:12 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Locale is gettext?
While considering implementation for actually-useful aspects of
locale, I had the idea that perhaps the concept of gettext
(translating strings via .mo files) can solve most if not all of the
tasks the locale system might need to do, with a trivial amount of
code. Here are my thoughts on the four categories to consider:
LC_MESSAGES: Obvious, using gettext as intended.
LC_TIME: One step away from obvious: using gettext to map the
day/month names and date format strings to the right values for the
locale.
LC_COLLATE: Non-obvious: using gettext to map collation elements to
their collation keys. This may be prohibitively slow (or may not) if
we just do binary search, but if we support the hash table in .mo
files it may be very practical. I think some additional consideration
might be needed for making primary/secondary/etc. work right, and
(perhaps more importantly) I need to consider how feasible it would be
to translate Unicode-format collation rules into .mo files.
LC_MONETARY: I'm not sure if this one fits the gettext pattern at all,
but maybe there's a way to make it work.
I should clarify that by "gettext" I don't mean the horrible GNU/Sun
API, where text domains and context are global state. I simply mean
the operation of doing lookups in a .mo-format binary file, generated
from a .po file (a well-known and understood text format) based on
binary search and/or hash table present in the .mo file. It should be
possible to implement this lookup in less than 150 bytes of machine
code (not counting dependencies like memcmp or similar), and reuse the
existing __map_file function (used for zoneinfo files) for mapping the
.mo files so this looks like an extremely efficient way, in terms of
code size and simplicity, to do locale.
Of course once we have the .mo file lookup engine, providing the ugly
gettext public API should also be easy, and would enable application
using it to get their message translations without having to link
their own copy of (the much-more-bloated and license-encumbered) GNU
gettext.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
