| @@ -1,21 +1,14 @@ |
| -!Internalization
|
| -
|
| -I have investigate three possibilites for bitweaver Internalization:
|
| +Three possibilites for bitweaver Internalization: |
|
|
| {maketoc}
|
| * GNU gettext
|
| * IntSmarty (described in PHP Architect, April 2004 by John Coggshell)
|
| -* Internalization method used in TikiWiki 1.8 (getstrings), which is the method currently used in bitweaver
|
| -
|
| -I have also Investigated some improvements.
|
| -
|
| -
|
| +* Internalization method used in ((TikiWiki)) 1.8 (getstrings), which is the method currently used in bitweaver - (:idea:) This is the method we ended up choosing for the LanguagesPackage |
|
|
| !GNU gettext
|
| -I ruled out GNU gettext almost imedialtely, since the other two methods uses Smarty a 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.
|
| +I 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. |
|
|
| !IntSmarty
|
| -
|
| 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 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.
|
|
|
| @@ -31,7 +24,7 @@ |
|
|
| 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__ 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.
|
| +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.
|
|
|
|
|
| @@ -57,7 +50,13 @@ |
|
|
| * TikiWiki has the option to store it's tranlation tables in a database. I have a hard time to see any use for this feature, since translation string lookup is only done at compile time, so its impact should be minimal. This is only true if an output filter that replaces tra("string"); in PHP scripts is provided, prooved to be a problem.
|
|
|
| -* TikiWiki's translation table is in principle the same as in IntSmarty. The only differnece is that the translation key is __not__ the MD5 sum, instead it is the original key. This is a big advantage, since for a translator it is __much__ easier to make corrections to translations that look like this: ^"English string" => "Badly translated string"^ than like this ^"12345678901234567890123456789012" => "Badly translated string"^
|
| +* TikiWiki's translation table is in principle the same as in IntSmarty. The only differnece is that the translation key is __not__ the MD5 sum, instead it is the original key. This is a big advantage, since for a translator it is __much__ easier to make corrections to translations that look like this: |
| + |
| +^"English string" => "Badly translated string"^ |
| + |
| +than like this |
| + |
| +^"12345678901234567890123456789012" => "Badly translated string"^ |
|
|
| * Tiki 1.8 also has specific language selection code (see langmapping.php), which enables the language to selection dropdown to both be shown in the native language and in the currently selected language.
|
|
|
|
|
| @@ -106,5 +105,3 @@ |
|
|
| [http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ZPTInternationalizationSupport|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.
|
| -
|
| - |
|
|