Új magyar fordítás készül a SquirrelMail-hez

Az 1.4.18-as verzió új magyar fordítást tartalmaz, amely nem csak a törzsmodul 100%-os magyarításából (locale/hu_HU/LC_MESSAGES/squirrelmail.mo) áll, hanem tartalmazza néhány modul fordítását is. Ezek: askuserinfo, check_quota, compatibility, folder_sizes, local_autorespond_forward. A change_pass pluginhez is készült fordítás, de ez modul szerencsétlen módon a saját alkönyvtárában tárolja a lokalizált üzeneteket, így ez a fordítás valószínűleg nem magával a SquirrelMail-lel együtt kerül kiadásra.

A SquirrelMail eddig is kiválóan kezelte a magyar ékezetes karaktereket, bár néhány buktató van az ezzel kapcsolatos konfigurációs opciókban. A config/config.php fájlban található $default_charset változó értékének állítása például tökéletesen hatástalan a magyar nyelven futtatott SquirrelMail esetében, ilyenkor ugyanis a functions/i18n.php fájlban található $languages tömb magyar nyelvre vonatkozó értékei a mérvadóak. A jelenlegi verziókban alapértelmezésként így kerül meghatározásra a magyar nyelv:

$languages['hu_HU']['NAME']    = 'Hungarian';
$languages['hu_HU']['CHARSET'] = 'iso-8859-2';
$languages['hu_HU']['LOCALE']  = array('hu_HU.ISO8859-2','hu_HU.ISO-8859-2','hu_HU');
$languages['hu']['ALIAS']      = 'hu_HU';

Ez legjobb tudomásom szerint (javítson ki, aki szerint tévedek) sorról sorra a következőket jelenti:

• A nyelv neve 'Hungarian'
• A nyelv használatakor a SquirrelMail ISO-8859-2 kódolású HTML oldalakat generál, ami maga után vonja természetesen azt is, hogy a böngészőnek ilyen kódolással kell elküldenie minden form tartalmát (felhasználónév, jelszó, címzett, levél tárgya, levél szövege, vagyis minden).
• A nyelv használatakor a SquirrelMail a locale könyvtár hu_HU.ISO8859-2, hu_HU.ISO-8859-2 és hu_HU alkönyvtáraiban keresi a magyarított üzeneteket tartalmazó .mo fájlokat.
• A nyelv a hu_HU alias névvel is megnevezhető.

Az 1.4.18-as verzióban a functions/i18n.php fájl előreláthatólag valami ilyesmi módon fogja definiálni a magyar nyelvet:

$languages['hu_HU']['NAME']    = 'Hungarian';
$languages['hu_HU']['CHARSET'] = 'utf-8';
$languages['hu_HU']['LOCALE']  = array('hu_HU.UTF-8', 'hu_HU.UTF8', 'hu_HU');
$languages['hu']['ALIAS']      = 'hu_HU';

Vagyis a kódolás UTF-8-ra vált! Ezzel párhuzamosan a magyarított üzenetek .po és .mo fájljainak karakterkészlete is UTF-8-ra változik (ISO-8859-2-ről), ennek azonban SEMMI KÖZE a functions/i18n.php fájl változásaihoz, a .mo fájlokban ugyanis a benne levő üzenetek kódlapjáról is talál információt a program, és az üzenetek megjelenítése előtt elvégzi a szükséges kódlapkonverziót, ha a HTML lapok generálását más kódlap szerint kell végeznie. Ez végül is azt jelenti, hogy ISO-8859-2 kódolással futó SquirrelMail installációba is be lehet másolni az UTF-8 kódolású magyar fordítást, és ehhez még a konfigurációs fájlok szerkesztésére sincs szükség.

A SquirrelMail egyébként is képes akár a kínai írásjelek megjelenítésére még a jelenlegi ISO-8859-2-es módban is, oly módon, hogy az aktuális kódlapban nem szereplő karaktereket &#N; formában szúrta be a generált HTML oldalba. Azonban ha egy UTF-8 kódolású levelet akarunk megválaszolni ISO-8859-2 módban, akkor a szerkesztőablakba már nem képes rendesen beszúrni az idézetet. Egész egyszerűen nem hajlandó elvégezni az UTF-8 szöveg ISO-8859-2-re konvertálását, még akkor sem, ha az UTF-8 szöveg történetesen magyar nyelvű, és a konverzió lehetséges. Ez a probléma is megoldható azonban UTF-8-ra való áttérés nélkül is, mégpedig úgy, hogy a config/config.php fájlban true-ra állítjuk a $lossy_encoding változó értékét.

Ilyenkor minden közép-európai nyelven írt levelet gond nélkül meg tudunk válaszolni, még akkor is, ha az UTF-8 kódolású. Ha viszont pl. héber nyelvű levélre szeretnénk válaszolni, akkor a válaszlevelünk idézet részében a héber betűk helyett csupa kérdőjel szerepel. Ezt a problémát oldja meg az UTF-8 módra történő átállás.

Az UTF-8-ra történő átállás során azonban a következő problémákkal kell szembenézniük a rendszergazdáknak:

A SquirrelMail a felhasználói adatokat (.pref fájlok, .abook fájlok, .sig fájlok, sőt minden valószínűség szerint az SQL-ben tárolt adatok is) ugyanis 8 bites kódolással, az aktuális kódlap szerint tárolja. Így, aki már régóta üzemelő SquirrelMail installációval rendelkezik, és most szerete (verziót és) kódlapot váltani, annak fel kell készülnie arra, hogy az említett adatok kódlapkonverzióját el kell végeznie (pl. iconv paranccsal). Ez még nem is lenne probléma, de a SquirrelMail-be történő belépéskor a webböngésző a SquirrelMail által generált HTML oldal kódlapjának megfelelő kódolással küldi át a jelszót...

Ahol tehát a felhasználók között vannak olyanok, akiknek a jelszavában ékezetes karakter(ek) van(nak), ott kicsit fájdalmas lehet a kódlapváltás. A rendszergazdák tehát a következő lehetőségek közül választhatnak:

• Maradnak az ISO-8859-2 kódolásnál (ez a functions/i18n.php fájl egyetlen sorának szerkesztésével az 1.4.18-as verzióra történő átállás után is lehetséges), és a $lossy_encoding opció segítségével javítnak az ékezetes karakterek kezelésén.
• Átállnak UTF-8 módra, így a világ összes nyelvén írt üzeneteket tökéletesen tudják kezelni, de szembe kell nézniük az adatok kódlapkonverziójának aprócska és a jelszavak kódlapkonverziójának kínos (a felhasználók közreműködését igénylő) feladatával.

UI: Pusztán az UTF-8-ra történő átálláshoz természetesen nem kell verziót frissíteni, elég hozzá a functions/i18n.php fájl egyetlen sorát a fentieknek megfelelő módon átírni.