Author: Everton da Rosa
Updated on: 2014-12-19
Posted on: 2014-12-19
Package: PHP i81n
This article provides basic instructions for using PHP i81n class, to translate websites and systems developed in PHP.
PHP i81n is a class to extract text to translate from application code.
It can traverse the PHP code files of a project to extract strings that need to be translated to internationalize an application.
The class generates a configuration file in the .INI format that should be translated to other languages to be supported.
The application can read the translation configuration files to return application texts for different languages.
Its use is simple and is based on two basic steps: development / client code adaptation for using the i81n class and the generation of the translation files.
The first stage of development or adaptation of the client code to use the i81n class is based on the configuration of a class instance and the method in use translate the strings to be translated.
Configuration is very simple and boils down to create an instance of the i81n class and set the language to be used:
$i81n = new i81n('en_US', '*');//creates an instance of translation for all domains available
In this example, we create an instance of the class configured to use the English (en_US), applicable to all areas (the second parameter: *).
Keep in mind that en_US should be a subdirectory of the locale directory.
Domains indicates how the fields will be treated.
The options are:
- FILE_DOMAIN: analyzed for each file will be created a domain of the same name;
- UNIQUE_DOMAIN: will create a single domain for all files (domain will be called main);
- DIR_DOMAIN: for each directory will be created a domain.
After set the class instance, it is time to add the strings to translate the translate method of the class. this is done as follows:
$i81n->translate('A biblioteca i81n possibilita a internacionalização de aplicações através do PHP sem a necessidade de gettext ou outra extenção do PHP')
The primary care in this operation is to include only strings without any kind of variable, because the string itself will be the index for the class i81n find the translation in time code processing.
If you need to add variable content within a string, divide the invariable parts by how many uses of the method translate as needed. A good way to do this is to use the printf PHP method.
The second stage of translation is to prepare the source file translation. To do this, you must create an INI file with the parser settings.
Most of the configuration options of the INI file are self-explanatory, but there is one that deserves attention: the option pattern.
The option pattern defines the default search i81n. The normal default is "-> translate" (without the quotes), this is because the method that makes the translation of messages is "translate" (i81n :: translate ()). However you may want to use an alias for this method or even embed it in a function.
This is interesting if you want to use a different method in case you extend the i81n class. It may also be useful to implement a pseudo-gettext method, making it possible to reuse code that originally client uses the PHP extension gettext, i81n adapted to use the class.
After parser settings are made, it's time to run the parser. This is done as follows:
i81n :: parseDir ($ configfile);
The parser will read the files with client code and extrarir strings that are arguments of methods translate (or defined in the pattern option), creating a most INI files in the locale directory.
The INI file with the strings to translate is divided into sessions, where each session is nominated with the hash of the string to be translated.
In each session there are two parameters: OMSG and tmsg.
OMSG corresponds to constant original string in each translate method.
tmsg will be the translation of the string in OMSG.
Once the file has been generated, just change tmsg with OMSG translation.
For each language that you want, you must create an INI file, and whenever there are changes, all INI files should be generated.
If you make small changes and you have many supported languages, it may be more advantageous to manually change the INI files because translate method converts each string received as an argument in a hash and hash this search in the INI file of the language settings in the class instance that was created.
Finding this hash, it returns the tmsg value. So OMSG serves actually as a facilitator in time to translate the INI files.
If the sought hash is not found, translate simply returns the argument string.
And that's all for now.
It can traverse the PHP code files of a project to extract strings that need to be translated to internationalize an application.
The class generates a configuration file in the .INI format that should be translated to other languages to be supported.
The application can read the translation configuration files to return application texts for different languages.
Its use is simple and is based on two basic steps: development / client code adaptation for using the i81n class and the generation of the translation files.
The first stage of development or adaptation of the client code to use the i81n class is based on the configuration of a class instance and the method in use translate the strings to be translated.
Configuration is very simple and boils down to create an instance of the i81n class and set the language to be used:
$i81n = new i81n('en_US', '*');//creates an instance of translation for all domains available
In this example, we create an instance of the class configured to use the English (en_US), applicable to all areas (the second parameter: *).
Keep in mind that en_US should be a subdirectory of the locale directory.
Domains indicates how the fields will be treated.
The options are:
- FILE_DOMAIN: analyzed for each file will be created a domain of the same name;
- UNIQUE_DOMAIN: will create a single domain for all files (domain will be called main);
- DIR_DOMAIN: for each directory will be created a domain.
After set the class instance, it is time to add the strings to translate the translate method of the class. this is done as follows:
$i81n->translate('A biblioteca i81n possibilita a internacionalização de aplicações através do PHP sem a necessidade de gettext ou outra extenção do PHP')
The primary care in this operation is to include only strings without any kind of variable, because the string itself will be the index for the class i81n find the translation in time code processing.
If you need to add variable content within a string, divide the invariable parts by how many uses of the method translate as needed. A good way to do this is to use the printf PHP method.
The second stage of translation is to prepare the source file translation. To do this, you must create an INI file with the parser settings.
Most of the configuration options of the INI file are self-explanatory, but there is one that deserves attention: the option pattern.
The option pattern defines the default search i81n. The normal default is "-> translate" (without the quotes), this is because the method that makes the translation of messages is "translate" (i81n :: translate ()). However you may want to use an alias for this method or even embed it in a function.
This is interesting if you want to use a different method in case you extend the i81n class. It may also be useful to implement a pseudo-gettext method, making it possible to reuse code that originally client uses the PHP extension gettext, i81n adapted to use the class.
After parser settings are made, it's time to run the parser. This is done as follows:
i81n :: parseDir ($ configfile);
The parser will read the files with client code and extrarir strings that are arguments of methods translate (or defined in the pattern option), creating a most INI files in the locale directory.
The INI file with the strings to translate is divided into sessions, where each session is nominated with the hash of the string to be translated.
In each session there are two parameters: OMSG and tmsg.
OMSG corresponds to constant original string in each translate method.
tmsg will be the translation of the string in OMSG.
Once the file has been generated, just change tmsg with OMSG translation.
For each language that you want, you must create an INI file, and whenever there are changes, all INI files should be generated.
If you make small changes and you have many supported languages, it may be more advantageous to manually change the INI files because translate method converts each string received as an argument in a hash and hash this search in the INI file of the language settings in the class instance that was created.
Finding this hash, it returns the tmsg value. So OMSG serves actually as a facilitator in time to translate the INI files.
If the sought hash is not found, translate simply returns the argument string.
And that's all for now.
You need to be a registered user or login to post a comment
1,534,284 PHP developers registered to the PHP Classes site.
Be One of Us!
Login Immediately with your account on:
Comments:
No comments were submitted yet.