[geeklog-devel] Translation stuff for GL2

[Tony Bibbs]

I think option 2 is out.  I've peaked at the code and, frankly, I'm not 
impressed. 

I'd be interested to hear from those of you who regularly do 
translations on how option #1 sounds.  Basically what he is saying is 
using option 1 you might have code like this:

gettext('some english string');
gettext('som other english string');

Then you would create the english (en) translation file using xgettext.  
We would then distribute the file to translators.  This is fine and 
dandy for those who have gettext support compiled into PHP.  The first 
issue is is the general adoption of gettext support in PHP such that we 
should just assume it is included?  If so, this is the clear winner.  If 
not then what Vinny was eluding to is we would write a script that would 
take another language file, say german, and we would replace all the 
english based gettext() calls in the .php files and insert the user's 
language of choice.  In otherwords a script would change:

gettext('some english string'); to gettext('some german string');

 In addition to his drawbacks, an additional drawback would be that in 
this instance user's couldn't have their own custom language setting.

--Tony

Vincent Furia wrote:

>Tony, JellyBob, and I discussed some possibilities concerning the
>translation stuff on IRC today.  We discussed a couple of possible
>alternatives to using a custom built translation class.
>
>1.  Use GNU gettext.  We could use gettext to support user selectable
>languages for installations that support gettext.  For installations
>that don't support gettext we can simply support a single language
>decided on during installation (this would not be user selectable).
>
>Things to do: We would have to write a custom script to convert the
>default english strings in the php files to the desired, supported
>language using the gettext files.  Hence the replacement language
>would become the default language in the converted files.  We could
>then either have the installer run this conversion script, or else
>create downloads for each language (which can be automated).  Since
>installations without gettext will already support the default
>language (english I presume), we can make the creation of the
>translation script a low priority.
>
>Possible problems: upgrades and security releases would need some
>planning as non-gettext installs would need files configured for their
>language.  A good auto-update system might be able to handle this.
>
>2. Use PEAR::Translation2
>This class does most of what we want, include support DB.  
>
>Possible Problems: The downside is it doesn't support merging of
>translation versions and is large and cumbersome.
>
>Personally, I like option 1.  If no one agrees that that is a viable
>alternative than I think we should skip the PEAR::Translation2 class
>(at least for the time being) and use the custom version.
>
>Any feedback?
>-Vinny
>
>On Mon, 19 Jul 2004 16:06:32 -0500, Tony Bibbs <tony at tonybibbs.com> wrote:
>  
>
>>Vinny,
>>
>>Per your request I'm outlining what remains for for GL2's translation
>>engine.  First a recap.
>>
>>First, I wrote the translation engine from scratch mainly because the
>>one in PEAR didn't, at the time, make upgrading to new releases easy on
>>translators.  Basically, with each new release, as with 1.3.x, the
>>translators have to manually update the new file OR hack a way to merge
>>them.  It is probably worth looking at what is in PEAR again to see if
>>merging of translation files is supported.  If it is, I could be
>>compelled to simply use it.
>>
>>However, assuming it still doesn't work that way here is what I have done:
>>1) The combination of getstrings and StringExtractor.class.php currently
>>work in PHP5 and parse anything of the form "->translate('[some
>>string]')" OR "->translate('[some other string]', '[some section name]]);
>>2) The data is collected in an array and is outputted to an xml file
>>with the following basic structure
>><application name="" version="">
>>    <translator name="" email=""/>
>>    <translation language="">
>>        <section name="">
>>            <entry>
>>                <string_id></string_id>
>>                <string></string>
>>            </entry>
>>        </section>
>>    </translation>
>>A couple of notes about the format.  the section and entry tags can
>>repeat.  Also, the string_id is the native language string and the
>>string tag is the translated version
>>
>>Here is what is left:
>>1) The big issue to iron out is how to incorporate plugins.  My original
>>thought was that plugins would each have their own XML file and would
>>not share the main Geeklog
>>     file but given our plugin-centric approach this may not make sense
>>anymore.  We may want to consider inserting <plugin> tags around the
>>section tags.   Just a though, regardless
>>     this probably needs some talking outload.  Dirk, any suggestions
>>here since you are a big user of the translation stuff?
>>2) mergeversions needs to be ported to PHP5 and should honor the new
>>section tags. Furthermore, it should be written to use the new PHP5 XML
>>features
>>3) We should add optional support of storing the strings in a database.
>>To that end, we should add the ability to import the xml files into a
>>database table.  Not sure of the best way to do this as there are a few
>>options.
>>4) similarly Translator.class.php should be ported to PHP5 and use the
>>new PHP5 XML parsing features
>>5) Build an xml schema we can use in mergeversions and in getstrings to
>>validate the XML of the translation file.  PHP5 has a built in XML
>>validator to help do most of this work.
>>6) As mentioned, look at StringExtractor.class.php for performance
>>improvements.
>>7) We should look into PEAR::Cache and how it might make the translation
>>process faster.  You might want to ask JellyBob (Jon Wood) how
>>PEAR::Cache works exactly...while he hasn't committed any time to GL2
>>persay, I'm sure he'd be willing to explain it abit.
>>
>>Anything else?
>>
>>--Tony
>>
>>_______________________________________________
>>geeklog-devel mailing list
>>geeklog-devel at lists.geeklog.net
>>http://lists.geeklog.net/listinfo/geeklog-devel
>>
>>    
>>
>_______________________________________________
>geeklog-devel mailing list
>geeklog-devel at lists.geeklog.net
>http://lists.geeklog.net/listinfo/geeklog-devel
>  
>