On Jan 8, 2006, at 9:02 AM, Alan Horkan wrote:
I wouldn't be suprised if GTK wasn't very smart about locales like en-CH or other unusual combinations. I'm not sure why but I have a feeling the locales strings are crudely checked against a list of matching strings (xx-XX or xx_XX) rather than broken down into language (xx) and region (XX).
In my experience and testing, they are not just crudely checked. I've done many things, including es_US vs. es_MX, fairly often in testing many things, and GTK+ seems to mirror standard GNU gettext behavior and do the right thing.
In fact, Inkscape (and GTK+) uses standard gettext for it's localization, and thus does things fairly well. (It's Qt, on the other hand, that invented their own method and currently does strange things with custom XML and explicit translator instances needed in the main app...)
(I use en-IE but more often than not I get American spellings even when I'd expect things to fallback to British ones. I know things could/ should be better but I've only ever had the patience to scratch the surface of it. Maybe someday I'll take a proverbial crowbar to glib and see if I can improve the fallbacks.)
That's because there are not really British fallbacks. The base "en" translations are American English, and you need a British specific locale to get non-American (like en_GB or en_IN). In fact, it appears that with Inkscape's base sources there are no other English translations included (although there is 'es' and 'es_MX', for Spanish and Mexican Spanish respectively)
So it's probably not a matter of doing anything to fallbacks, but just adding non-American English locale files to begin with.