Differences from version 6 to 10



@@ -1,18 +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.
-
--= 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.
+* 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
 
--= IntSmarty =-
+!GNU gettext
+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.

@@ -28,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.
 

@@ -40,7 +36,7 @@

 
 * It has a functioni18nfile, which selects a file from a directory that is depending on the selected language. This e.g. allows for localized pictures.
 
--=TikiWiki and getstrings=-
+!TikiWiki and getstrings
 
 The method for TikiWiki 1.8 is quite simillar to IntSmarty whith the following main exceptions:
 

@@ -54,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.
 

@@ -79,3 +81,27 @@

 * Handle "dynamic" strings, see UnusedWords. Dynamic strings are strings that does neither exists in PHP code nor Smarty templates. Instead they are extracted from some external source (that must be static either in a specific Tiki verison or a specific Tiki setup). The most prominent example for this is the flags feature in Tiki. The flag names are not encoded in the code but are extracted from the filename of each image file. Currently this has been solved by translators by adding these strings manually. In later version of tiki, the strings has been added in specially crafted comments so that getstrings can extract them. This solution is however inelegant and error prone if the external source changes. To solve this problem satisfactory each module that uses "dynamic" strings, should provide an interface function in a specifically named file that allows getstrings to extract these "dynamic" strings.
 
 * Add plugin support for translations. Currently only one file that contains the translation table is generated. To support the plugin concept completetely getstrings has to be able to genereate one language file for each plugin, but at the same time reuse translations from other plugins and make consistency checks, so that if two plugins have the same original strings, the translations should also be the same.
+
+!Additional Links and Resources
+A few URL's I've found researching internationalisation techniques for PHP.
+
+[http://www.php.net/support.php|PHP Internationalization Mailing list & Newsgroup]
+Discussions on PHP Internationalization (i18n) and localization (l10n) issues and features. A searchable archive is available. Light Traffic.
+
+[http://sourceforge.net/projects/php-flp|Flaimo's little package (FLP)]
+Free collection of PHP classes offering message catalogs, date formatting and message formatting facilities.
+
+[http://php-flp.sourceforge.net/getting_started_english.htm|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.
+
+[http://stphp.sourceforge.net/|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.
+
+[http://www.onlamp.com/pub/a/php/2002/11/28/php_i18n.html|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.
+
+[http://zez.org/article/articleview/42/|Internationalization Using PHP and GetText]
+(This is from the founder of TikiWiki.)
+
+[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.
Page History
Date/CommentUserIPVersion
20 May 2008 (06:23 UTC)
laetzer85.178.39.1310
Current • Source
spiderr66.93.240.2047
View • Compare • Difference • Source
Jan Lindåker81.226.206.1986
View • Compare • Difference • Source
Jan Lindåker213.204.139.355
View • Compare • Difference • Source
Jan Lindåker213.204.139.354
View • Compare • Difference • Source
Jan Lindåker213.204.139.353
View • Compare • Difference • Source