PHP Classes

File: i18nDoc

Recommend this page to a friend!
  Classes of Martin Lacroix   i18n_   i18nDoc   Download  
File: i18nDoc
Role: Documentation
Content type: text/plain
Description: Documentation
Class: i18n_
Get application text from class constants
Author: By
Last change: Removing the limit of 9 parameters max
Date: 11 years ago
Size: 3,641 bytes


Class file image Download
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