mailing list of musl libc
 help / color / mirror / code / Atom feed
* Locale is gettext?
@ 2014-07-06  5:06 Rich Felker
  2014-07-06  9:15 ` u-igbb
  0 siblings, 1 reply; 2+ messages in thread
From: Rich Felker @ 2014-07-06  5:06 UTC (permalink / raw)
  To: musl

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


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Locale is gettext?
  2014-07-06  5:06 Locale is gettext? Rich Felker
@ 2014-07-06  9:15 ` u-igbb
  0 siblings, 0 replies; 2+ messages in thread
From: u-igbb @ 2014-07-06  9:15 UTC (permalink / raw)
  To: musl

On Sun, Jul 06, 2014 at 01:06:12AM -0400, Rich Felker wrote:
> 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

> 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.

+1

Rune



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2014-07-06  9:15 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-06  5:06 Locale is gettext? Rich Felker
2014-07-06  9:15 ` u-igbb

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).