X
Xavier Noria
I was using a field normalizer (for URLs, sorting, etc) that has
Iconv.iconv('ascii//ignore//translit', 'utf-8', s)
as a starting point. Accented characters such as "=E1" are "decomposed" =20=
in my Mac, but the production machine is a Linux and they are ignored =20=
there, so "=E1" becomes the empty string instead of "'a".
In the Mac we have "iconv (GNU libiconv 1.9)", in that linux we have =20
"iconv (GNU libc) 2.3.2". Since the current release of GNU iconv is =20
1.11, I guess those are different libraries with different =20
transliteration tables. Is that right?
I have written a transliteration table as a chain of gsubs as a =20
workaround, but that approach was so good! Can anyone explain what is =20=
actually happening and confirm whether that //TRANSLIT trick is non-=20
portable and thus better avoided?
-- fxn
Iconv.iconv('ascii//ignore//translit', 'utf-8', s)
as a starting point. Accented characters such as "=E1" are "decomposed" =20=
in my Mac, but the production machine is a Linux and they are ignored =20=
there, so "=E1" becomes the empty string instead of "'a".
In the Mac we have "iconv (GNU libiconv 1.9)", in that linux we have =20
"iconv (GNU libc) 2.3.2". Since the current release of GNU iconv is =20
1.11, I guess those are different libraries with different =20
transliteration tables. Is that right?
I have written a transliteration table as a chain of gsubs as a =20
workaround, but that approach was so good! Can anyone explain what is =20=
actually happening and confirm whether that //TRANSLIT trick is non-=20
portable and thus better avoided?
-- fxn