PHP Localization Best Practices? gettext?

Question

We are in the process of making our website international, allowing multiple languages.

I've looked into php's "gettext" however, if I understand it right, I see a big flaw:

If my webpage has let's say "Hello World" as a static text. I can put the string as <?php echo gettext("Hello World"); ?>, generate the po/mo files using a tool. Then I would give the file to a translator to work on.

A few days later we want to change the text in English to say "Hello Small World"? Do I change the value in gettext? Do I create an english PO file and change it there? If you change the gettext it will consider it as a new string and you'll instantly loose the current translation ...

It seems to me that gradually, the content of the php file will have old text everywhere. Or people translating might have to be told "when you see Hello World, instead, translate Hello Small World".

I don't know I'm getting confused.

In other programming languages, I've seen that they use keywords such as web.home.featured.HelloWorld.

What is the best way to handle translations in PHP?

Thanks

Answer 1

You basically asked and answered your own question, the answer might just be having a slightly better understanding of how PO files work.

Within the PO file you have a msgid and a msgstr. The msgid is the value which is replaced with the msgstr within the PHP file depending on the localization.

Now you can make those msgid's anything you would like, you could very well make it:

<?php echo _("web.home.featured.HelloWorld"); ?>

And then you would never touch this string again within the source, you only edit the string through the PO files.

So basically the answer to your question is you make the gettext values identifiers for what the string should say, however the translators typically use the default language files text as the basis for conversion, not the identifier itself.

I hope this is clear.

Answer 2

I know an answer has been accepted, and the above answer is good. But there is another issue with using permanent machine-style keys like thing.stuff.widget when working with Gettext.

While using permanent keys is a better approach to development, Gettext is not set up for that style of working and this can complicate your workflow.

If you present a translator with a PO file populated with keys in place of source text, they may not know what the English should be. So you'd have to provide them with a second file containing source language translations for them to compare to. Not the end of the world, but more fiddly for them and not how Gettext was designed. (square peg, round hole etc..)

I think PO is perfectly fine as a file format for translations in PHP, and especially recommended if you're not working with a framework that has a good l10n module, but that doesn't mean it's good for workflow and your translation process.

I suggest you arrive at a workflow that allows your programmers to work with permanent keys, your translators work with words, and gives you a MO file out the other end. Take a look at Loco for one solution to this.

Alternatively use a different interim file format that allows the use of keys and words. TMX is one example. If you still want to use Gettext at runtime you can convert the files.

Answer 3

Currently, I am dealing with the same issue. The common practice with gettext is to use the English text as the key. Recently, our copy editor changed whole bunch of English text (other languages are hardly touched) so we have to change all the source code all the PO files.

We are switching to a neutral key. Since we already have some sites on Java. We will use the same property name format.