[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug-gnu-libiconv] [bug #56304] Greek, Cyrillic and Armenian translitera
[bug-gnu-libiconv] [bug #56304] Greek, Cyrillic and Armenian transliteration
Fri, 10 May 2019 17:17:24 -0400 (EDT)
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0
Update of bug #56304 (project libiconv):
Status: None => Not a Bug
Assigned to: None => haible
Open/Closed: Open => Closed
Follow-up Comment #1:
Transliteration was, in the years 2000-2010, when many people were still using
an 8-bit character set (most often ISO-8859-1 or ISO-8859-15), the way to
represent text that used characters outside that character set in a lossy
Nowadays, virtually everybody uses Unicode (on Unix, mostly in the UTF-8
encoding). But iconv from UTF-8 to UTF-8 is a no-op.
Therefore, it does not make sense to implement new transliterations in iconv
any more. (Neither in glibc's iconv nor in libiconv.)
The right approach, IMO, is to create a program outside the scope of iconv.
The GNU gettext package has already a filter program for transliterating
Serbian from Cyrillic to Latin script (I'm saying script, not charset). It
would be OK to add Greek, Cyrillic, and Armenian transliterations as separate
programs in there.
For how it's done, please look at the files
gettext-tools/src/filter-sr-latin.c and gettext-tools/src/recode-sr-latin.c in
the GNU gettext package.
If there are different transliteration conventions for, say, Russian,
Ukrainian, and Bulgarian, we can have different programs.
If there are different transliteration conventions for Western Armenian than
for Armenian, it would be OK to have a command-line option to indicate the
dialect of Armenian.
Alternatively, you could submit these transliterations to the Recode project
https://github.com/rrthomas/recode . It's a more generic framework for such
things, but you probably need a certain time in order to understand the
mindset of this framework.
Reply to this item at:
Message sent via Savannah