PHP seems to resist time and is still quite a popular choice for building web apps. We’ve already discussed how to translate PHP apps. Our focus today is on Zend Framework, an open source, object-oriented PHP framework comprised of more than 60 packages, each one serving a particular purpose. It is the zend-i18n package that makes PHP i18n of web apps possible. There is another one calledzend-mvc-i18n which is needed for the integration of the zend-i18n package into the MVC framework. As most of the web applications that we create follow an MVC design pattern, we’ll usezend-mvc-i18n in this tutorial.
You can install the Zend package using the following command:
You can also install onlymvc-i18n using the following command:
Composer is a dependency management tool that will install all the required dependencies of Zend Framework for you. If you haven’t installed Composer on your machine yet, you can get it here.
For this tutorial, I’ve created an example project. Here’s how the folder structure of a simple project looks like:
Three sections are important for us: languages, public, and src. We’ll discuss them as we move forward with the tutorial.
zend-i18n comes with a complete translation suite supporting all major formats. It also includes popular features that come with a translator object. Our next task is to define the Translator object. To do that, three aspects need to be configured:
- Translation format
- Translation resource location
- Translation resource file
There are different formats you can use to represent translations:
- PHP arrays (store translated texts in PHP arrays),
- gettext (translated texts as normal texts in a file)
- Tmx (an XML standard called Translation Memory Exchange)
- Xliff (XML-based file format)
Using PHP arrays is not the most optimal practice. You should always separate translation strings from source code;gettext is the easiest and probably the most common method – that’s exactly what I’ll be using in this application. Nevertheless, I’ll show you how to store translated texts in the xliff andTmx formats as well.
Once you’ve created files with translated texts, you need to place them somewhere easy to find. Quite common locations are:
As you can see, I use the application/language path to store my translation files.
The third configuration is feeding translation files to Translator object. You can either add each file individually or add all files at once using a pattern. Assume you’ve got 10 translation source files for 10 different languages. It could be quite cumbersome to add each file separately. Therefore, it’s a good practice to use a file pattern to add all files to the Translator.
Let’s create now Translator object:
Note how I’ve set a pattern – something like asprintf pattern.%s.mo tells the Translator to accept any string with MO extension. There are four files in my language es.po, es.mo, fr.po, andfr.mo (ES standing for Spanish and FR for French); .PO files contain the actual translation, while .MO files contain the machine object or a binary data file. The Translator needs binary files. Therefore, %s.mo feeds es.mo and fr.mo to the Translator.
After creating the Translator object, we can now move on to translating messages. This can be done using the translate method of the Translator object. Translating text is done in the view. In our application, the view is the index.php file in the Public folder. Before using Translator object, you need to includetranslator.php in theindex.php file.
The format of the translate method is:
Its parameters represent the following:
- $message – the message to be translated
- $textDomain – the text domain where translation resides. It is an optional parameter. The default value is “default”
- $locale – Locale should be used. It is an optional parameter. If unset, default locale will be used
An example of the translate method would be:
Anyway, in our application, we’ll use the translate method a bit differently. It doesn’t make much sense to set a locale in each translated message. It’s hardly ever you use several locals in the same view. You can set the locale usingsetLocale() method.
Finally, ourindex.php file will look like this:
As noted at the outset, I’d also like to show you how to store translated texts in different formats. In our application, there are three strings. In gettext, translated texts are stored in .PO files.
Ourfr.po file looks like this:
If we use the XLIFF format, it will more or less look like this:
If we use the TMX format, it would be something like this:
Zend I18n Helper Classes
If you read our blog, you already know that there are some concepts for which locality is very important – certain things simply can’t exist without locality. We can give currency, data format, number formats as examples. If you’re going to provide internationalization support for your application, it’s essential that you translate these objects accordingly. Zend helper classes make the process easier by introducing those respective classes with locality support:
- NumberFormat helper
- CurrencyFormat helper
- DateFormt helper
Let’s get to know them better by taking a look at some examples.
One of the most evident differences in different locales is how numbers are formatted. NumberFormat class handles these variances for you. Look at the following two examples:
What it will display is 2.453.678,26.
2,453,678.26 gets displayed.
The globe is flooded by different currencies. As the custom is, people in a specific country should be able to pay for a product or service in their own currency. Currency becomes, thus, one of the main factors to be considered for adjustment in an internationalization project. It is the currencyFormat method that does the internationalization for you here. Check out the following code:
What it will display is $2,543.91.
It will display 2.543,91 €.
When you use en_US, the local currency is the US dollar. When you use de_DE, which stands for Germany, the currency turns into euro. However, that’s not it. If you take a better look, the number format of the price has changed as well. The reason for that is that the CurrencyFormat method is a wrapper for the NumberFormat class.
The last important helper class we’re looking at is the DateFormat helper. Different countries use different date formats. The following example compares date formats created by theen_US and de_DE locales.
May 1, 2019 is the result displayed.
It results in 01.05.2019 being displayed.
Zend Framework provides a whole lot more helper classes. You can find the complete list in their documentation.