This is the mail archive of the
libc-locales@sourceware.org
mailing list for the GNU libc locales project.
[Bug localedata/2872] Transliteration Cyrillic -> ASCII fails
- From: "edi at gmx dot de" <sourceware-bugzilla at sourceware dot org>
- To: libc-locales at sources dot redhat dot com
- Date: 17 Feb 2007 22:17:06 -0000
- Subject: [Bug localedata/2872] Transliteration Cyrillic -> ASCII fails
- References: <20060702083101.2872.edi@gmx.de>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From edi at gmx dot de 2007-02-17 22:17 -------
"WORKSFORME" implies that you cannot reproduce the problem, but... does
transliterating Горбачов work with English or not? (see below) If not, how can
it be "resolved"?
Or what are you trying to say with "provide the data"? That there is no data
yet? I have seen it working some years ago. With correct US-style
transliterations. If it is broken now or data has been lost, then TRANSLIT maybe
should be disabled and throw an error immediately. Currently it produces crap
and AFAICS there is no proper documentation explaining why.
The crap it creates is not even consistent within the same language/country
pair, without .UTF-8 suffix it produces more funny non-sense.
echo Горбачов | LANG=de_DE.UTF-8 iconv -t ASCII//TRANSLIT
????????
echo Горбачов | LANG=de_DE.UTF-8 iconv -t ASCII//TRANSLIT
????????
echo Горбачов | LANG=de_DE iconv -t ASCII//TRANSLIT
??? 3/4 N?????N?? 3/4 ??
echo Горбачов | LANG=en_US iconv -t ASCII//TRANSLIT
iconv: illegal input sequence at position 0
--
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|WORKSFORME |
http://sourceware.org/bugzilla/show_bug.cgi?id=2872
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.