Pseudo-locales for i18n testing by English speakers

[Sean Flanigan]

Ulrich Drepper wrote:
> Sean Flanigan wrote:
>> Would there be any interest in getting something like this into glibc?
> 
> Hell, no.  There is no room for testing code in the runtime.  

I find it hard to believe that there is no testing code in the runtime.
 Even OS kernels have functions for debug messages.

> And I see
> absolutely no need whatsoever to have it there.  It seems to be the
> wrong place altogether.  

Perhaps it is; I'm mostly a Java programmer, but in Java I'd be looking
to hook into the ResourceBundle class, which is responsible for fetching
translated strings.

I'd much prefer to keep my grubby mitts out of glibc, but I was given to
understand that the gettext() calls at runtime are actually implemented
in glibc (rather than say "libgettext").  If that's wrong, please
enlighten me!

> For PO files you create appropriate
> translations.  For the locales themselves you derive a file from the
> existing locales, compile it using localedef, and just use it.
> 
> None of the locale code is hardcoded in glibc.  Why should this?

Is the implementation of "fetch translations from MO files under
/usr/share/locale/" hard-coded?  If there's already a nice programmatic
hook I could use, even better.  If I could register locale-specific
overrides of gettext(), I could add any number of dynamically generated
locales.

A gettext() hook could also be used to fetch translations from other
sources, such as a shared, up-to-date, translation database.  I think
that has the potential to be useful to a lot of people, not just
developers and testers.

It doesn't really make sense to generate thousands of pseudo PO files,
and compile them into static MOs, when all the required data (ie English
text) is available at runtime.

Let me change my question then.  How would people feel about having a
hook to override the behaviour of gettext() in a system-wide fashion?

-- 
Sean Flanigan

Senior Software Engineer
Engineering - Internationalisation
Red Hat

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 551 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20081003/05231840/attachment.bin