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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- Fedora-i18n-list mailing list Fedora-i18n-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-i18n-list
