Sergey Vlasov, Freitag, 1. März 2002 15:26: > On Fri, 1 Mar 2002 14:12:21 +0100 > > I'd just like to ask, whether it would be a problem to use > > UFT8 encoding for the backend translations? > > Reason: > > The KDE i18n framework has been switched to UTF8; .mo files > > generated from .po files encoded e.g. in iso-8859-1 are not > > displayed correctly (missing "Umlaute"/vowel mutations). > > As far as I know, this wouldn't affect xsane (Oliver?), but > > would make access to the backend translations much easier for > > KDE applications. > > The recent GNU gettext (starting with 0.10.36, released in March > 2001) has the ability to reencode translations on the fly. By > default it reencodes to the current locale encoding, but you can > use bind_textdomain_codeset() to select any other encoding > (including UTF-8). > > The question is: how many people still have old gettext? If we > will use UTF8 in backend translations, people using old gettext > will have problems with non-KDE apps. If we rely on the GNU > gettext reencoding capabilities, this will be the problem for > people which use old gettext and KDE apps. > > Also, many programs still cannot work with UTF-8 - this may be a > problem for translators. (I guess, this should have gone to the list ?)
I'm no i18n expert and my suggestion was only based on my own tests. I recoded the translations included in SANE-1.0.7 to utf8, and couldn't see any problems with xsane, although it seems to use gettext 0.10.35. Nevertheless, what's the solution? Is it possible, to add a configure option like "--enable-utf8-encoding" and then use a script, which runs "recode" on the .po files? Or should I just ask people to recode it themselves (not so nice)? Michael
