[geeklog-devel] Translation stuff for GL2

[Tony Bibbs]

If it helps at all, --with-gettext is *not* included in a php build by 
default.

--Tony

Tony Bibbs wrote:

> 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
>>  
>>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel