Gettext 関数

_ — のエイリアス gettext
bind_textdomain_codeset — DOMAIN メッセージカタログから返されるメッセージの文字エンコーディングを設定/取得する
bindtextdomain — ドメインのパスを取得/設定する
dcgettext — 単一の参照に関するドメインを上書きする
dcngettext — dcgettext の複数形版
dgettext — 現在のドメインを上書きする
dngettext — dgettext の複数形版
gettext — 現在のドメインのメッセージを参照する
ngettext — gettext の複数形版
textdomain — デフォルトドメインを設定する

Improve This Page

Learn How To Improve This Page • Submit a Pull Request • Report a Bug

User Contributed Notes 37 notes

down

jeremy at jeremy dot se dot nospam ¶

17 years ago

As some of you have mentioned, you must have the locales compiled on your system first. How this is done is depending on your system/distribution *sigh*

In every case you need to have gettext installed on your system. Users running a Linux with a recent version of libc will have gettext in libc already.

Here's an example for those of you running Ubuntu Edgy.

First of all, have a look in /usr/share/i18n/SUPPORTED, here are the locales that are supported on your system. To compile a locale we will use the command "locale-gen". ("man 8 locale-gen" is good reading)

This command reads configuration from files in the folder /var/lib/locales/supported.d/ In these files the locales and charsets are defined.

If we take swedish as an example, start by creating a file called "sv" in /var/lib/locales/supported.d/ and then put in something like "sv_SE.UTF8 UTF8" (without the " ") This says that we want the locale sv_SE to be built with charmap UTF-8. Check the file /usr/share/i18n/SUPPORTED for other alternatives.

Now we run "locale-gen" which will compile all locales defined in /var/lib/locales/supported.d/ and put them in /usr/lib/locales (yes that's a lot of locations...)

Now you're ready to go...

Create a php-file (e.g. hello.php) where all strings you want to translate are surrounded with _("string here");

next run "xgettext hello.php", this creates a file called messages.po, which is you translation-file (pot). Change the "Content-Type: text/plain; charset=CHARSET\n" in this file and replace CHARSET with UTF-8 in this case. Next translate all strings like this.

#: hello.php:3
msgid "hello!"
msgstr "hej!"

Save and use the command "msgfmt -o hello.mo messages.po" which will create a compiled .mo file called hello.mo

This file is then placed in a directory structure somewhere your Apache can read it. The structure looks like this:

"locale/sv/LC_MESSAGES/hello.mo"

Next, let php know what we're doing. We point to where we have our translations. Add the following at the top of hello.php

bindtextdomain('hello','/somepath/locale');

This binds the file hello.mo to the locale/ directory you created.
Then set the locale. LC_ALL tells that we want everything translated. Might not be good at all times, as another person here suggested.

setlocale(LC_ALL, "sv_SE.UTF-8");

Finally select the that we want to use hello.mo 

textdomain('hello');

That should be it! Try it out..

If you get any problems try restarting Apache as it seems to cache the locales.

If you are running command line you might have to set the environment variable LANGUAGE to your locale as well. I didn't have to do that to get it working in apache though, but you might...

putenv("LANGUAGE=sv_SE.UTF-8");

down

C Snover ¶

18 years ago

I think that it bears mentioning that most documentation and tutorials you will find say that you should setenv(LC_ALL, $locale), but this only works IF THE LOCALE IS VALID ON THE LOCAL MACHINE. If you are using a locale that does not exist on the system or is not valid (like something returned from the HTTP Accept-Language header, such as 'ja', which is never a valid locale because it does not include the country code JP), you will probably be pulling your hair out for HOURS trying to figure out why the damn thing isn't working.

What I have found is that setting the LANGUAGE variable (eg. setenv("LANGUAGE=$locale")) will allow gettext to search inside your locale directories, even if the locale is not actually valid on the local system.

So, to summarize:

This will work:
<?php
$locale = 'ja'; // Pretend this came from the Accept-Language header
$locale_dir = './locale'; // your .po and .mo files should be at $locale_dir/$locale/LC_MESSAGES/messages.{po,mo}

putenv("LANGUAGE=$locale");
bindtextdomain('messages', $locale_dir);
textdomain('messages');
?>

This will not work:
<?php
$locale = 'ja';
$locale_dir = './locale';

putenv("LC_ALL=$locale");
bindtextdomain('messages', $locale_dir);
textdomain('messages');
?>

This will also not work:
<?php
$locale = 'ja';
$locale_dir = './locale';

setlocale(LC_ALL, $locale);
bindtextdomain('messages', $locale_dir);
textdomain('messages');
?>

Nor will this work:
<?php
$locale = 'ja';
$locale_dir = './locale';

setlocale(LC_MESSAGES, $locale);
bindtextdomain('messages', $locale_dir);
textdomain('messages');
?>

For reference, this was tested on PHP 5.1.2 + LigHTTPd 1.4.11 + gettext 0.14.5 on Ubuntu Dapper 6.06. It should be true for any variant of Linux, however, as well as older versions of these software packages.

down

analpaper{gmail} ¶

16 years ago

in response to richard:
i was using the wildcard * for sometime ago without problem, until today.

i used:
<?php bindtextdomain( '*', './locale' ); ?>
but it seems to fail under some environments (i dont know why, but in diff machines with same software the result is not always as expected)..

then, with:
<?php bindtextdomain( "*", './locale' ); ?>
all is nicely translated again.

i use single quotes always if possible, now there are another think to remember.
---
live2code

down

djogopatrao at gmail dot com ¶

18 years ago

Juan Liska, I found an alternative. Instead of renaming or adding a alias to the locale, I simply changed 

$language = 'pt_BR';

to

$language = 'pt_BR.UTF-8';
putenv("LANG=$language"); 
setlocale(LC_ALL, $language)

and it did work fine!

down

konrads/smelkovs/gmail/com ¶

18 years ago

re LC_MESSAGES for windows users, LC_MESSAGES should be defi0ned as 5

down

Maxwel Leite -maxwelleite at gmail com- ¶

19 years ago

PHP-gettext is developed to be able to read gettext MO files directly, without requiring anything other than PHP:
https://savannah.nongnu.org/projects/php-gettext/

down

kocio at irc dot pl ¶

20 years ago

Following three lines take about 0.5 second to execute (Debian, Celeron 2GHz, 256MB RAM):

setlocale(LC_ALL, 'pl_PL'); 
bindtextdomain('my_domain', '../dir/' . 'locale'); 
textdomain('my_domain'); 

I think that such delay is important enough to be mentioned in the documentation. In my particular case, it means more than doubled execution time for the entire script.

down

dev.php at tfelber.net ¶

21 years ago

Check your 

/etc/locales.aliases for "english en_GB.ISO-8859-1" (mentioned before) 

and your

/etc/locales.gen for en_GB.ISO-8859-15 ISO-8859-15 

I'm not sure if only this entry solved the problem. In my case this entry was made by an dpkg-reconfigure locales (debian), where i created the locales.

Translation only works with de_GE@euro and  en_GB.ISO-8859-15 (first column in you locales.gen)

down

anim8 ¶

21 years ago

Even though in some cases setlocale() may require a country code in addition to the language code this does not mean that it is required for gettext. 

If setlocale() is set to either es_ES or es_MX gettext() will still get the text from a po file in the 'es' folder.

It probably is not a good idea to go changing a systems alias file(s) just to avoid the verbosity of the ISO standard because:
  a) you might break something 
  b) your code just lost it's portability

.

down

richard at hirner dot at ¶

18 years ago

the * wildcard doesn't work for me (php 5)... I have to use bindtextdomain for each textdomain

down

webmaster [at] ttw [dash] tool [dot] de ¶

18 years ago

If you want to use messages from multiple domains with .mo-files residing in non-standard locations remember to place a bindtextdomain()-call for each domain as "unbound" domains will be looked for in the standard location (usually "/usr/share/locale" on *nix)

<?php

    bindtextdomain('foo','/some/dir/with/mo_files');
    bindtextdomain('bar','/another/mo_file/dir');

    echo dgettext('foo','Text to be translated using the foo-catalog.');
    echo dgettext('bar','Text from a different catalog named bar.');

?>

If all the .mo-files you are using reside in one and the same directory, you may use the "*"-wildcard like this:

<?php

    bindtextdomain('*','/directory/with/all/mo_files');

?>

This code was tested on PHP 5.1.4

down

info at adaniels dot nl ¶

18 years ago

As stated by robert at klugher dot com:
The environment setting 'LANGUAGE' gets priority above any local setting. This means that changing LC_ALL/LC_MESSAGES and LANG as done in almost all examples, won't do anything.

So if you've done
<?php    
    $language = "nl_NL";
    putenv("LANG=$language");
    setlocale(LC_ALL, $language);
    ...
?>
but the text is still displayed in english. Try also setting the LANGUAGE variable.
<?php    
    $language = "nl_NL";
    putenv("LANGUAGE=$language");
    putenv("LANG=$language");
    setlocale(LC_ALL, $language);
    ...
?>

down

birkholz at web dot de ¶

18 years ago

> stefan+usenet at froehlich dot priv dot at wrote at 5-May-2004 01:30:
> Reading the line
> 
> <? php setlocale(LC_ALL, 'de_DE'); ?>
> 
> here over and over again, I have to warn using it, as there are severe caveats.
> For certain locales, LC_NUMERIC swaps period and comma, which may e.g. lead to
> decimals silently stripped of numbers, when inserting rows into an SQL database.
>So DON'T do this, but use
>
> <? php setlocale(LC_MESSAGES, 'de_DE'); ?>
>
> instead, which does exactly what you want, without any nasty side effecs.

For all Windows-Users:
Be warned the LC_MESSAGES seems to be NOT set on Windows with PHP 5.1.2, so if you develope applications for a Linux-System and want to make it multi-language using gettext, you will get problems using LC_MESSAGES on your Windows-Developement-Box.
You can try to solve this problem by putting a 

<?php if (!defined('LC_MESSAGES')) define('LC_MESSAGES', 6); ?>

to your script to get no warning if you pass LC_MESSAGES to the setlocale()-function.

down

Juan Liska ¶

18 years ago

if you're having trouble with setlocale (if it's returning false) on ubuntu or debian:

nano /etc/locale.gen

make sure that the locales taht you want are in the list, if not, add them. for instance, i wanted es_GT (b/c i have an app that must run on redhat and debian, i cant change to es_GT.UTF-8) so, add:

es_GT UTF-8

then run:

locale-gen 

you now have the locales you want, not just the ones the system magically came with

down

milky#users:sf/net ¶

19 years ago

There exists an emulation for the gettext functions - obviously slower than the native binding, but can be used on shared servers which lack the extension. It is believed to be rather useful as fallback (comes already encapsulated with if-function_exists checks).
See the ext/ directory in the [ http://freshmeat.net/p/upgradephp ] tarball.  Support for plural translations isn't there, because that is too hard to get reimplemented reliably.

down

zixia at zixia dot net ¶

20 years ago

If gettext does not work with your locale, ie 'zh_CN', just going to see if the output of command "localedef --list-archive" contains your locale('zh_CN' in this example).
If it not, try to use a exist locale or use "localedef" to create one: "localedef -f GBK -i zh_CN zh_CN" in my case.

down

wouter at grep dot be ¶

21 years ago

Of course, translation is only interesting if you provide the user with the language and encoding he asks for. Since there's part of the HTTP protocol that allows you to specify that, it's nice if one can use that information to pick the 'right' translation out of the ones you have available.

I wrote something that does just that -- it parses the 'Accept-Language' and 'Accept-Charset' HTTP/1.1 headers, and tells you which one the user prefers out of a list you provide. You can download it at http://www.grep.be/articles/php-accept.php

Note that even if the user's browser may support this, the user may not know about it; as such, it's probably good practice not to remove links to other-languaged versions, so that people can still get a version of your site in another language if they so prefer.

down

jc ¶

21 years ago

I had a lot of problems getting gettext to work (RedHat 7.3). After reading ALL the comments in this manual, I got it to work OK.

In summary, take care that:

1) You use a full locale in the setlocale()
2) Your language_country exists in the /usr/share/locale/locale.alias
3) It seems that Apache needs to be restarted (a "graceful" did the trick for me)
4) Your .mo files must be named after the domain

My code:

$language = "es_ES";
$locale = setlocale(LC_ALL, $language);

$gettext_domain = 'messages';
bindtextdomain($gettext_domain, "/full/path/to/locale");
textdomain($gettext_domain);

down

Anonymous ¶

21 years ago

The way I got gettext to work with just a standard "de" or "fr" instead of "de_DE" was I overwrote my /usr/share/locale/locale.alias with /usr/lib/X11/locale/locale.alias file.  The I restarted Apache.  Reason I did this was it appeared the X11 file was more up to date and more modernised!

down

Picco ¶

21 years ago

Note to Chinese programmers....

Took me hours to figure out you cannot use

LANG=zh
but have to use
LANG=zh_TW 
on some machines...

a good way to test will be to check the return of setlocale()

down

robert at klugher dot com ¶

21 years ago

One trick I found after HOURS of tries :

when you use the setlocale(), PHP will use the locale info it will find in, for example, /usr/share/locale to set the language info for LC_ALL, LC_MESSAGES, ...

You can check the exact info it will use by using putenv() with LANG=.... and looking at the return value of setlocale(LC_ALL, ""). The language value your gettext function will use to look for your translation file is the one given for LC_MESSAGES.

Example :

I was setting the LANG as fr_BE, and placed the translation file in dirxxx/locale/fr_BE/LC_MESSAGES/...
As it was locale info in my system for fr_BE but NOT LC_MESSAGES, PHP choosed to use the LC_MESSAGES settings for fr_FR instead and then, was looking for a translation file in dirxxx/locale/fr_FR/LC_MESSAGES/..., which wasn't found of course.

So, just make sure to look at the return value of setlocale to see what language value is associated to LC_MESSAGES and, then, to know in which subdirectory the translation file will be looked for by gettext.

Robert

down

php at zpod dot ca ¶

21 years ago

For those of you just trying to get a script working and your provider doesn't support gettext, you can bypass the international stuff by adding this:

function _($str) {
    return $str;
}

down

Eneko Lacunza enlar at enlar dot net ¶

21 years ago

Some tips from my Red Hat Linux 7.3 system.

It didn't work for me until I set a full locale (i.e. es_ES) with setlocale.

I was trying with Michele Manzato's example (thank you!), but as it sets the language without the country, it was failing for me. Here is the example "fixed" with full locale:

// Change to script directory
// (Not needed in RH 7.3)
$path = dirname(getenv(PATH_TRANSLATED));
chdir($path);

// Set the language as full locale 'es_ES'
$language = 'es_ES';
putenv("LANG=$language");
setlocale(LC_ALL, $language);

// Set the text domain as 'mydomain'
$domain = 'mydomain';
bindtextdomain("$domain", "./locale");
textdomain("$domain");

// The .mo file searched is:
// ./locale/es_ES/LC_MESSAGES/mydomain.mo
// or if previous one doesn't exist:
// ./locale/es/LC_MESSAGES/mydomain.mo

echo gettext("Hello world!"); 

Hope this helps!
Eneko.

down

mgvNOSPAM at fx dot ro ¶

22 years ago

If you're as clueless as I am, please note the following:
1. Although most comments list setlocal() in the code, that's not actually required for translations - read the docs under "string functions" for details (also, the official gettext() examples don't include it);
2. hace_x's example is really cool, except you need to know that all "n"'s at the end of his strings should have a backslash before - they're actually EOL characters, but they somehow got messed up and I needed two hours to find that out...

down

richardbrinkman at hotmail dot com ¶

8 years ago

Gettext caches the machine readable *.mo files. This makes it pretty fast but also impossible to change a .mo file while running an application. Since PHP is running as a server, you cannot update your .mo file and see your new translation immediately. There are two ways to overcome this caching problem:

1. Restart your webserver. For example by a `systemctl restart apache2`. This will kill already running php processes and reload them afterwards.

2. If you don't have rights to restart a webserver (for example you are using a shared host), you can change the domain. Use for example this PHP code to hard link the new domain to the changed .mo files:

$locale = "nl_NL.utf8"; //set this to your language
setlocale(LC_ALL, $locale);
putenv('LANG=' . $locale);
$mtime = 0;
$translationDir = "locale"; //or where ever you store your translations
$originals = glob("$translationDir/*/LC_MESSAGES/messages.mo");
foreach ($originals as $file)
    $mtime = max($mtime, filemtime($file));
$domain = "messages_$mtime";
$current = glob("$translationDir/*/LC_MESSAGES/$domain.mo");
if (count($originals) != count($current)) {
    foreach (glob("$translationDir/*/LC_MESSAGES/messages_*.mo") as $file)
        unlink($file);
    foreach ($originals as $file)
        link($file, substr($file, 0, -3)."_$mtime.mo");
}
bindtextdomain($domain, $translationDir);
textdomain($domain);

What this script does is check whether at least one of the translations is updated and if so remove all messages_*.so and hard link all messages.po to corresponding messages_$mtime.po, where $mtime is set to the latest modified translation file. Since it uses a new domain ("messages_$mtime") it is not cached.

down

Sbastien Ballest-Antich ¶

16 years ago

A workaround to use heredoc and gettext strings with sprintf :
<?php
$hd = <<<EOD
   <p>%s</p>
   <p>%s</p>
EOD;
$hdgt = sprintf($hd, _('Heredoc'), _('gettext'));
var_dump($hdgt);
?>

down

titan at phpdevshell dot org ¶

16 years ago

If you would like to create a .po file with include heredoc scripts inside curly brackets {} solution is as follows;

I want to translate what in here (test.php):
<code>
<?php
$EOF = <<<EOF
{$t->__('I want to translate this string.')}
EOF;
?>
</code>

You will have to use the xgettext (gnu utility) with the Python parser like so:
<code>
$ xgettext --default-domain=test --keyword=__ --keyword --language=Python test.php
</code>

The above terminal command might seem wrong with --keyword used twice, this is however correct.

down

SEWilco ¶

17 years ago

People have suggested several combinations of configuration options.  Consider trying nested loops with various combinations of language names (with and without character set suffixes) and pathnames.  A gettext() call in the middle of the loops can test for success (a string being translated).

"Of 4374 localization setup variations tested there were 0 successes."

Sometimes one just has to fix the system and PHP configuration.

down

jon at nospam dot foo ¶

17 years ago

I'm sure I'll confuse further, but I feel compelled to chime in.  I got stuck on this a bit...

It's absolutely critical that your gettext installation supports the locale you are trying to use in your setlocale(LC_MESSAGES,$locale) call.

This does not work:

setlocale(LC_MESSAGES,"en");

in OpenSUSE 10.2, because /usr/lib/locale does not contain the directory "en" (out of the box), even though your custom LC_MESSAGES domain location might.

In OpenSUSE 10.2, at least, /usr/lib/locale contains for USA English:

en_US
en_US.iso885915
en_US.utf8

(again, not "en").

It might be possible to set up an alias, I'm not sure (does anyone have a idea about this).

My goal was to use HTTP_ACCEPT_LANGUAGE to set locale (I realize that locale != language, but it seems that gettext uses locale to assign language (scratches head) ).  Opera in OS X does not send "en_US".  However, Firefox does out of the box.  I'm not sure if it's supposed to work this way, but it seems like it should, and so the way Opera handles this appears to be an issue.  Incidentally, Safari simples send "en" in HTTP_ACCEPT_LANGUAGE, and will also not work.

This compelled me to set a configurable default locale (e.g "en_US") in my PHP app, which one probably should do anyway, because HTTP_ACCEPT_LANGUAGE might be blank.

down

tucsi at c2 dot hu ¶

19 years ago

If your gettext translation does not work in safe mode, than try to set this in the php.ini:
safe_mode_allowed_env_vars = PHP_,LANG

down

php at dynaperl dot com ¶

22 years ago

If you install from SuSE Dist. you need glibc-locale.rpm to let gettext work.



mfg ralph.

down

Michele dot Manzato at verona dot miz dot it ¶

23 years ago

Gettext is great, but there are a few caveats you have to consider in order to make it work. Unfortunately the gettext docs isn't so plain and clear...



The .mo file created with the gettext utilities must be:



[bindtextdomain's dir]/[language]/LC_MESSAGES/[domain].mo



otherwise gettext() function will fail to find it (this is true in win32, don't know about Un*ces). By the way you don't get any error message, the strings will simply remain untranslated. 



Second, you must make sure which is the current directory if you use a relative path in bindtextdomain. On some systems the script directory isn't the current directory, so you have to chdir() there.



Then, of course, make sure that the appropriate gettext extension are loaded by PHP by looking at the php configuration file.



Here is some sample code:



// Change to the script directory

$path = dirname(getenv(PATH_TRANSLATED));

chdir($path);



// Set the language as 'it'

$language = 'it';

putenv("LANG=$language"); 

setlocale(LC_ALL, $language);



// Set the text domain as 'mydomain'

$domain = 'mydomain';

bindtextdomain("$domain", "./locale"); 

textdomain("$domain");



// The .mo file searched is:

// ./locale/it/LC_MESSAGES/mydomain.mo



echo gettext("Hello world!");



Have fun!

Michele

down

-1

elonen at iki dot fi ¶

19 years ago

For making localized copies of PHP files (statical l10n), here's a GPL'd command line tool: http://iki.fi/elonen/code/pophorator/

down

-1

dpatton at confluence dot org ¶

19 years ago

Make sure you check your webserver configuration before deciding to use gettext, because if you are running in a multi-threaded environment you should not use gettext, as it is not thread-safe.

A future version of gettext(possibly 0.15) may be thread-safe.
Any gettext dependencies, such as glibc would also need to be thread-safe.

Apache 1.3 on Unix generally is non-threaded, but on Windows it is multithreaded.
Apache 2.0 has support for MPMs(Multi-Processing Modules), some of which support multiple threads:
http://httpd.apache.org/docs-2.0/mpm.html

down

-1

mikolaj at webgate dot bg ¶

20 years ago

winXP, PHP 4.3.5 as Apache1.3.29 module

Two hints for Windows users.

I found setting locale is neither sufficient nor nessecery. To get it work I needed to set either LC_ALL or LANG enviroment variable to my locale. Anyway this value must be proper for setlocale so it is good to test with it. In my case it was bgr_BGR for bulgarian according to http://www.unicode.org/onlinedat/countries.html

gettext checks for files once and keeps them in cashe. Especially it means that if it doesn't find your files it won't search again, so restart Apache after any directory changes!! 

My minimal working script:
<?php
// translation file: D:\Apache\htdocs\mypage\locale\bgr_BGR\LC_MESSAGES\messages.mo
putenv("LC_ALL=bgr_BGR");
bindtextdomain('messages', 'D:\Apache\htdocs\mypage\locale\\');
echo gettext("Hello");
?>

down

-1

stefan+usenet at froehlich dot priv dot at ¶

20 years ago

Reading the line

<? php setlocale(LC_ALL, 'de_DE'); ?>

here over and over again, I have to warn using it, as there are severe caveats. For certain locales, LC_NUMERIC swaps period and comma, which may e.g. lead to decimals silently stripped of numbers, when inserting rows into an SQL database. So DON'T do this, but use

<? php setlocale(LC_MESSAGES, 'de_DE'); ?>

instead, which does exactly what you want, without any nasty side effecs.

down

-1

Anonymous ¶

23 years ago

It is probably obvious to many of you,  but I thought it was worth mentioning that the domain is the name of the .mo files that contain the string catalogue (without the extension).



so if you have a catalogue myPage.mo for each page in './locale/lg/LC_MESSAGE' and some generic catalogues (e.g. errorMsg.mo) in '/global/locale/lg/LC_MESSAGE', you can do



bindTextDomain("$myPage", './locale');

bindTextDomain('errorMsg','/global/locale' );

textDomain('myPage');

print(getText('Welcome'));

/.../

if($err)printf(dGetText('errorMsg','you have an error here'));



Ivan

＋add a note

Gettext 関数

目次

Improve This Page

User Contributed Notes 37 notes