[geeklog-devtalk] geeklog-devel digest, Vol 1 #354 - 4 msgs

[geeklog-devel-request at lists.geeklog.net]

Send geeklog-devel mailing list submissions to
	geeklog-devel at lists.geeklog.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.geeklog.net/listinfo/geeklog-devel
or, via email, send a message with subject or body 'help' to
	geeklog-devel-request at lists.geeklog.net

You can reach the person managing the list at
	geeklog-devel-admin at lists.geeklog.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of geeklog-devel digest..."


Today's Topics:

   1. Re: Translation stuff for GL2 (Vincent Furia)
   2. Re: Translation stuff for GL2 (Tony Bibbs)
   3. Re: Translation stuff for GL2 (Tony Bibbs)
   4. Re: Translation stuff for GL2 (Vincent Furia)

--__--__--

Message: 1
Date: Tue, 20 Jul 2004 14:04:50 -0400
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Translation stuff for GL2
Reply-To: geeklog-devel at lists.geeklog.net

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

>


--__--__--

Message: 2
Date: Tue, 20 Jul 2004 13:53:22 -0500
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Translation stuff for GL2
Reply-To: geeklog-devel at lists.geeklog.net

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

>  

>


--__--__--

Message: 3
Date: Tue, 20 Jul 2004 14:01:17 -0500
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Translation stuff for GL2
Reply-To: geeklog-devel at lists.geeklog.net

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



--__--__--

Message: 4
Date: Tue, 20 Jul 2004 14:57:35 -0400
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Translation stuff for GL2
Reply-To: geeklog-devel at lists.geeklog.net

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

>



--__--__--

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel


End of geeklog-devel Digest