 |
|
Donations News About Support Security Screen shots Download Plugins Documentation Sponsors Bounties 
Junk Email Filter |
Using gettext is the preferred method for translations. It is much faster and more efficient. To get it going, you need to compile PHP with the option --with-gettext. Further, it has been reported that in some circumstances, you must provide the path to gettext, for example --with-gettext=/usr/bin. Please don't blindly assume this is the correct path for your configuration. If either one is successful, a phpinfo() will let you know that gettext is enabled. Also, read about gettext at the [PHP web site]. If PHP has --with-gettext enabled and you only get English no matter what language you try (please try them all), then something on your system is broken. Often this has to do with gettext not liking your system's kernel or maybe PHP not being able to mesh correctly with gettext. Either way, you need to check your system's and PHP's documentation for further answers. If PHP has --with-gettext=shared and it still doesn't work, then you might not be loading the shared module. If this is the case, you probably need to uncomment ;extension=php_gettext.so in php.ini. You may also have to specify the correct path to the module on that line. If you are running PHP in safe_mode, try set up following in php.ini:\n safe_mode_allowed_env_vars = LC_ALL,LANG,LANGUAGE,PHP_ / Desi Petrovic <[email protected]>
In the file /usr/share/locale/locale.alias, add a line like (example for Finnish):\n fi fi_FI.ISO-8859-1 The reason is that SquirrelMail thinks "fi" is correct argument for setlocale, when it should set "fi_FI".
After upgrading to Apache 1.3.28 and PHP 4.3.3, translation no longer worked. I tried updating gettext to the latest version (trough rpmbuild --rebuild using the package included in Red Hat 9.0) with no results. As glibc includes some of the translation functions, I tried updating the glibc packages. After updating glibc and restarting the Apache process, the translation worked perfectly. / Xavier Arino
If there are no locales installed, the system administrator can add them by typing the following at the promt (example for Finnsih):\n # localedef -ci fi_FI -f ISO_8859-1:1987 fi_FI Lithuanians: baltic instead of ISO_8859-1:1987 / Titus
Using the SquirrelMail CVS as of 2004-07-15 on a cPanel Red Hat 9.0 server, I was unable to get the Arabic translation to work. Selecting it in SquirrelMail showed everything in English. I don't really understand this stuff, but doing the following fixed it for me:\n localedef ar -i ar_SA -f ISO-8859-6 cd [path_to_squirrelmail]/po ./compilepo ar cd ../locale/ar/LC_MESSAGES/ msgfmt -cvo squirrelmail.mo squirrelmail.po apachectl graceful / Mhtawfiq
If you running a SUSE 7.3 with PHP, gettext and Apache from the RPMs and the translation doesn't work, comment the extension=php_gettext.so entry in php.ini out. / Lago
I had problems getting gettext to work with SUSE 8.0 after doing a minimal installation. The problem is that YAST does not install glibc_locale when installing gettext. Install glibc_locale and the traslations are there. Not really a SquirrelMail problem but a SUSE one. After running SquirrelMail for half a year in English, I am happy to see it in my native language! / Jörg
With a minimal SUSE 8.1 installed from the network, I have the same problem: glibc_locale must be installed because the installation program doesn't install it. / Jordi
Add the path /usr/bin/ in /etc/php5/conf.d/gettext.ini.
I have a Gentoo compiled system. I compiled my system with the following support:\n $ locale -a $ en_US, en_US.utf8, es, es.iso885915, es_ES, es_ES.utf8, es_ES@euro This does not match the charset and locale for Spanish in functions/i18n.php. To get my installation to work, I had to change the values of:\n $languages['es_ES']['CHARSET'] = 'iso-8859-1'; $languages['es_ES']['LOCALE'] = 'es_ES.ISO8859-1'; to:\n $languages['es_ES']['CHARSET'] = 'iso-8859-15'; $languages['es_ES']['LOCALE'] = 'es_ES.ISO8859-15'; I do believe -15 is the norm for Spanish? Am I wrong? Edit: Both -1 and -15 are correct. Spanish is not the only language that can be either or.... So, either have the correct local installed, both or simply modify i18n.php as I did. / Juan G.
In Debian, I have to run "locale-gen" every time I upgrade libc or the translation stops working and everything shows in English. Make sure that at least one of the lines starting with es_ in /etc/locale.gen is not commented before running locale-gen. I don't understand completely how this works, but this solves the problem for me. I hope it helps you. Using dpkg-reconfigure locales is the "Right Way" of doing ANY locale maps (?!) changes in Debian, as of Debian Woody. It will present a list of availiable maps and ask you to select the ones desired. Once you do this, you won't have to re-genarate them on glib/whatever update - debconf will do it for you. Please Note: if you don't select the locale map for the language you want SquirrelMail translated to, you won't get SquirrelMail translated at all! I guess this is a gettext thing, e.g. if you want pt_BR translation of SquirrelMail, you MUST select the pt_BR.ISO8859-1 locale map to be generated - and this is not a Debian-only issue / Tiago Macambira, http://www.c9-komput3r.org/maca, m a c a .-=@AT@+=-. c 9 - k o m p u t 3 r . o r g << what we have to do to avoid spams.... dpkg-reconfigure locales, selecting the desired locales and restarting the Apache did the trick on Debian Woody. Tiago Macambira's statements have thus proven valid for me. / Dietmar Lang On a related subject. I was translating squirrelmail.po to Portugues (pt_PT) and I noticed that sometimes after I run msgfmt to generate the squirrelmail.mo file, the translation stopped working also. I found out that restarting Apache makes the translation work again. Maybe this info is useful for someone. / Ruben Leote Mendes
Another Debian user reported problems with Progeny. His solution was to simply downgrade to Potato. Apparently, glibc 2.2 was to blame (Potato uses glibc 2.1).
I've got a Debian Sid/Woody, which uses glibc 2.2, and I now sucessfully use SquirrelMail with translations. You need to edit locale.gen and (because SquirrelMail uses "hu" instead of more standard "hu_HU") you have to put a hu hu_HU.ISO-8859-2 line the /etc/locale.alias. This is for Hungarian translations, but it may also be true for the other languages. / RISKO Gergely
No entries in php.ini are needed (gettext is enabled by default). Run dpkg-reconfigure locales and select the wanted locales. Refresh the SquirrelMail page. / f_x
No entries in php.ini are needed (gettext is enabled by default).\n apt-get install localeconf dpkg-reconfigure locales Download the SquirrelMail locales needed (they are not included in the SquirrelMail apt package 1.5.x). Restart Apache, just in case. / monosabio
Remember to reload your Apache server each time you modify a mo-file. That'll clear the gettext cache and avoid erratic behaviors. After generating the locales with dpkg-reconfigure locales nothing may happen, but after restarting Apache it works.
If all else fails, make sure that the aliases for your language (located in functions/i18n.php) are configured properly. For example, in the case of Polish, the $languages['pl_PL']['LOCALE'] array should contain an additional element 'pl_PL.UTF-8', for (at least) some new versions of Debian and Ubuntu. Specifically, the aforementioned addition solved the problem on Debian Etch and Kubuntu Feisty. Comment : And for me with Ubuntu 8.10 x_64 server. Thank you.
Oh yes, the latest suggestion worked for me also on Debian Etch when trying to use the Italian localization: I added an it_IT.UTF-8 element in the array and the translated strings appeared right away. Thanks. / starless
Holy shit, yes! /usr/share/squirrelmail/functions/i18n.php has to be changed: $languages['de_DE']['LOCALE'] = array('de_DE.ISO8859-1','de_DE.ISO-8859-1','de_DE','de_DE.UTF-8'); That's a bothersome bug. netAction
Had to run this to get it to work:
Probably valid for any language too. The output of locale -a has to show the language AND encoding you need. I had the right language but wrong encoding and dpkg-reconfigure did't give me any choices, even with -plow. lmunro |