[geeklog-devel] Translation stuff for GL2

Vincent Furia vfuria at gmail.com
Tue Jul 20 14:57:35 EDT 2004 

Also recall this article from a while back:
http://www.geeklog.net/article.php?story=20030121174254562&query=gettext

Most ISPs in the surrvey had it installed.  Not scientific, but interesting.

-Vinny

On Tue, 20 Jul 2004 14:01:17 -0500, Tony Bibbs <tony at tonybibbs.com> wrote:
> 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
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>

More information about the geeklog-devel mailing list