[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#376272: libc6: //translit fails with cyrillic and others



reopen 376272
thanks

#include <hallo.h>
* Denis Barbier [Sat, Jul 01 2006, 07:15:37PM]:
> On Sat, Jul 01, 2006 at 03:51:21PM +0200, Eduard Bloch wrote:
> > Package: libc6
> > Version: 2.3.6-15
> > Severity: normal
> > 
> > Hello,
> > 
> > the //translit function seems to be partially broken in the
> > current glibc. I remember it having worked fine some months ago.
> > Demo (with UTF-8 input):
> > 
> > echo Тест | LANG=de_DE.UTF-8 iconv -f UTF-8 -t ascii//translit
> > ????
> > (should be Test)
> > echo Füße | LANG=de_DE.UTF-8 iconv -f UTF-8 -t ascii//translit
> > Fuesse
> > (ok, correct)
> > echo Füße | LANG=ru_RU.UTF-8 iconv -f UTF-8 -t ascii//translit
> > F?sse
> > (Why not the same? Unicode is unicode is unicode... or does iconv try to
> > do some stupid cheating nowadays and assumes that Russian people are not
> > aware of the ä->ae transliteration?)
> > 
> > Whatever the reason behind this changed behaviour is, it is not natural,
> > not userfriendly and therefore not correct.
> 
> No, transliteration is language-dependent, so closing this bug.
> For instance in French,
>   echo Füße | LANG=de_DE.UTF-8 iconv -f UTF-8 -t ascii//translit
>   Fusse
> and this is the expected result.
> The ü -> ue transliteration is defined in /usr/share/i18n/locales/de_DE.

Eh, what? First, you set de_DE.UTF-8 and talk about French (or is your
LC_CTYPE explicitely set to fr_FR...?). Second, Cyrillic is the main
problem (see Subject) and you close the bug report after providing a
hardly sufficient explanation for a secondary problem.

And following your explanation, ru_RU file is still broken and does not
describe the cyrillic->ascii tranliterations. As said before, that
feature has been working fine with previous libc versions.

Eduard.





Reply to: