[geeklog-devel] Translation stuff for GL2

[Vincent Furia]

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
>