Hi guys,
Here’s a handy way to implement an internationalization mechanism for your PHP website.
The concept is to write one main class that rules the others…
- All files are written in PHP (no other parser),
- The system support multi-bytes strings,
- You can have both kind of messages: constant or/and parametred,
- It’s possible to build a complex architecture of classes for your translations,
- And the icing on the cake: you will be able to use any modern ide’s autocompletion to parse your strings!
--------------------
--- Requirements ---
--------------------
The “handy way” comes from the last PHP’s features: late static binding and __callStatic(), so if you’re coding on prior versions to PHP 5.3, this will not work.
---------------
--- Concept ---
---------------
The logical is divided:
- One class that pilots the translations (must extends the base class i18n)
- One class per language with the translations
Here’s an example:
- abstract class i18n # main routine with the on fly translation mechanism
- class i18nData extends i18n # class that pilots any kind of messages
- final class i18nData_en # English translation of the messages
- final class i18nData_fr # French translation of the messages
The routine uses 3 global constants that must be defined before any call:
- GCT_LANG__USER: browser language or explicitly asked language
- GCT_LANG__DEFAULT: default system language
- GCT_LANG__TRANSLATION_MISSING: any message that will be sent if the translation routine doesn’t work or find a component
--------------------
--- Coding rules ---
--------------------
- Absolutely all classes must have this code:
const __SELF__ = __CLASS__;
- Simple messages use class constants
- Parametred messages use static functions
- The translation classes must share the same namespace than the pilot class
- Once a constant or static function is defined, it must not be redefined anymore
- It is preferable to define the translation classes as final (they must not be derived)
- For parametred messages, the linguistic logical is deported into the translation classes
- Multiline translations must be resumed to one line of text
- Naming the translation classes is strict and must follow this pattern: pilotClassName_language (as above)
- All parametred messages in the pilot classes will always be written like that:
static function myParamMsg($paramA, $paramB, $lang = GCT_LANG__USER) {
return parent::translate(__FUNCTION__, array($paramA, $paramB), $lang);
}
--------------------
--- How it works ---
--------------------
First, the normal process for any web request must define the 3 global constants, then to translate a simple message you just have to transform the class constant to a function call by adding brackets ()
constant => i18nData::DATA_NOT_FOUND
translation => i18nData::DATA_NOT_FOUND()
You can also ask for a specific language:
translation => i18nData::DATA_NOT_FOUND(‘fr’)
translation => i18nData::DATA_NOT_FOUND(‘de’)
If you don’t, the routine will check (in this order):
- GCT_LANG__USER
- GCT_LANG__DEFAULT
For complex messages using others parameters, just call the static function and provide the needed parameters.
----------------------
--- Error trapping ---
----------------------
If, for any reason there is a problem with a given translation, the routine will try first to translate with the default system language and if this doesn’t work too, it will send the content of the global constant GCT_LANG__TRANSLATION_MISSING
Enjoy
|
Download
