History of LanguagesResearch
Version 4 | Current version | |
---|---|---|
InternalizationI have investigate three possibilites for TikiPro Internalization:
I have also Investigated some improvements. I ruled out GNU gettext almost imedialtely, since the other two methods uses Smarty prefilters. Smarty prefilter replaces the strings during template compilation, which means that there is translational overhead when compiled template is used. Since templates are only compiled when they are changed, this method is much prefered over doing it in runtime. Appart from providing some utility functions, that will be described later, IntSmarty's advantage over GNU gettext is that the replacement of strings is not done at runtime, but at template compilation (the advantage of gettext is that it supports many lanugages, but since we have allready chosen PHP and Smarty, we can use their advantages to the fullest. IntSmarty uses a prefilter function that replaces {l}Text to translate{\l} with the the translation. The translation is looked up in a translation translation array where a MD5 sum of the original text is used as index in the array and the translated text as value. Other Smarty tags, like variables, are left for the translator to handle correctly. Since the translator function is a prefilter all tags that are left in the translation will be handled by Smarty. If the a MD5 sum of the text to translate is not found in the array the array is regerated with the new string added. A typical language array looks like this: $__LANG = array { '12345678901234567890123456789012' => 'Text to translate' ... }; The translator then translates 'Text to translate' to whatever that string is in the desired language. One of the downside with this mehtod is that there is no complete list of strings that needs to be translated before all templates have been compiled. Another downside is that if changes or additions is made in the templates at least in the current implementation it is hard to find the new strings, especially in those cases where they only differ in spelling. Furthermore the method saveLanguage needs to be called at the end of every script that uses IntSmarty, if the developper forgets this, there is no update of the language array if there was a need to update it. This will normally be detected by an annoyed tranlator. There also does not seem to be any way to detect when translations can be removed. IntSmarty also redefines the _compile_template mehtod, which i do not think is nessesary (and may be problematic when upgrading Smarty). The way to do this is most probably to redefine the Complier Class but I'm curently not 100% sure if this aproach will work. For the above reasons I do not reccomend a direct use of IntSmarty. Useful things in IntSmarty There are some useful things with int Smarty that should be adopted.
The method for TikiWiki 1.8 is quite simmilar to IntSmarty whith the following main exceptions:
| Three possibilites for bitweaver Internalization:
GNU gettextI ruled out GNU gettext almost imedialtely, since the other two methods use a Smarty prefilter. Smarty prefilter replaces the strings during template compilation, which means that there is no translation overhead when a compiled template is used. Since templates are only compiled when they are changed, this method is much prefered over doing it in runtime.IntSmartyAppart from providing some utility functions, that will be described later, IntSmarty's advantage over GNU gettext is that the replacement of strings is not done at runtime, but at template compilation. The advantage of gettext is that it supports many lanugages, but since we have allready chosen PHP and Smarty, we can use their advantages to the fullest.IntSmarty uses a prefilter function that replaces {l}Text to translate{\l} with the the translation. The translation is looked up in a translation array where a MD5 sum of the original text is used as index in the array and the translated text as value. Other Smarty tags, like variables, are left for the translator to handle correctly. Since the translator function is a prefilter all tags that are left in the translation will be handled by Smarty. If the a MD5 sum of the text to translate is not found in the array the array is regenerated with the new string added. A typical language array looks like this: $__LANG = array { '12345678901234567890123456789012' => 'Text to translate' ... }; The translator then translates 'Text to translate' to whatever that string is in the desired language. One of the downside with this mehtod is that there is no complete list of strings that needs to be translated before all templates have been compiled. Another downside is that if changes or additions are made in the templates, at least in the current implementation, it is hard to find the new strings, especially in those cases where they only differ in spelling. Furthermore the method saveLanguage needs to be called at the end of every script that uses IntSmarty, if the developper forgets this, there is no update of the language array if there was a need to update it. This will normally be detected by an annoyed tranlator. There also does not seem to be any way to detect when translations can be removed. IntSmarty also redefines the compile_template method, which i do not think is nessesary (and may be problematic when upgrading Smarty). The way to do this is most probably to redefine the Complier Class but I'm curently not 100% sure if this aproach will work. For the above reasons I do not reccomend a direct use of IntSmarty. Useful things in IntSmarty There are some useful things with int Smarty that should be adopted:
TikiWiki and getstringsThe method for TikiWiki 1.8 is quite simillar to IntSmarty whith the following main exceptions:
"English string" => "Badly translated string" than like this "12345678901234567890123456789012" => "Badly translated string"
All in all, I do not think that the current method should be abandoned. There are a number of improvements that the current translation feature in bitweaver.
Additional Links and ResourcesA few URL's I've found researching internationalisation techniques for PHP.PHP Internationalization Mailing list & Newsgroup Discussions on PHP Internationalization (i18n) and localization (l10n) issues and features. A searchable archive is available. Light Traffic. Flaimo's little package (FLP) Free collection of PHP classes offering message catalogs, date formatting and message formatting facilities. FLP I18N/L10N The i18n package is a punch of classes for internationalization. It gives you the possibility to maintain multilanguage webpages more easily. The translation strings are stored in flat text files, special Gettext files which are basically precompiled translation files or in a MySQL database. And it works independently from PHP’s setlocale function. STPhp, internationalization tool for PHP STPhp is a PHP-based string translation suite designed as a simple internationalization tool to work without requiring non-standard dependencies. Open source project created by Jacob Moorman. Internationalization and Localization with PHP Internationalization (often abbreviated I18N--there are 18 letters between the first "i" and the last "n") is the process of taking an application designed for just one locale and restructuring it so that it can be used in many different locales. Internationalization Using PHP and GetText (This is from the founder of TikiWiki.) ZPTInternationalizationSupport This document is a proposal to extend Zope Page Templates to provide internationalization support. Note that statements of fact below should be read as proposals. |