I remember running some tests a some months ago with gettext and the following code worked perfectly:
putenv(\'LANG=l33t\');
putenv(\'LANGUAGE=l33t\');
putenv
Gettext isn't overly practical for webapps.
So I sort of sometimes wish that PHP module wouldn't exist, and the convenient _()
function name shortcut was available to userland implementations.
(Had my own gettext.php, which worked more reliable.)
Your options:
Anway, according to a few bug reports the Windows port of gettext had some flaws with UTF-8. Maybe your version is affected again. So try bind_textdomain_codeset('default', 'ISO-8859-1');
for starters. Also, it seems to prefer the environment variables on Windows IIRC, so putenv("LC_ALL", "fr_FR");
might work better than setlocale()
. Especially workable if you dl(gettext.dll) later on.
Also give it a chance with including a charset right there LANG=en_GB.ISO-8859-1
. (Since your source text is English anyway, caring about the charset isn't very relavant here; but probably a common case where gettext trips over itself.) Oh and on occasion it's UTF8 not UTF-8; also try ASCII.
Alternatively circumvent gettext. Your domain idea is close, but I'd simply use a pre-defined ./locale/ subdir for languages:
./lang/en/locale/C/LC_MESSAGES/domain.mo
Then just invoke bindtextdomain("default", "./lang/{$APP_LANG}/locale")
without giving gettext room to interpret much. It will always look up /C/, but the correct locale directory has been injected already. But try to have a symlink from the $LANG to /C/ in there anyway.
Bite in the gnu. Give up on gettext. "PhpWiki" had a custom awk conversion script. It transforms .po files into .php array scripts (yeah very oldschool), and just utilizes a __() function instead. Close. And more reliable.
This code won't run perfectly on every system, because every systems locale repository + php version is different, among other things.
If you want consistency you need to use something like Zend_Translate, which if you install Zend on each system ( the same version of it ) they would all be consistent with one another because they're using the same localization data, locale names and codebase.
There are numerous bugs with setlocale
, it's just not reliable. See the comments @ http://php.net/manual/en/function.setlocale.php