[geeklog-devel] GL2 and languages (part 1)

[Tony Bibbs]

So that you all don't think I've given up on GL2, I am sending a few 
messages from the PEAR author of a translation package.  I think we may 
have hit a bump that may not allow us to use it...be looking for the 
subsequent posts

-- 
Tony Bibbs          "I guess you have to remember that those who don't
tony at tonybibbs.com  hunt or fish often see those of us who do as      
                    harmlessly strange and sort of amusing. When you  
                    think about it, that might be a fair assessment." 
                    --Unknown


---------- Forwarded message ----------
Date: Wed, 19 Feb 2003 10:11:38 -0600 (CST)
From: Tony Bibbs <tony at tonybibbs.com>
To: Wojciech Zielinski <voyteck at caffe.com.pl>
Subject: Re: You language file

On Wed, 19 Feb 2003, Wojciech Zielinski wrote:
> I suppose the xgettext.sh is a script that will extract all the strings 
> from the PHP code files to XML file ? Why do you use the shell-scripting 
> ? In such case you're making this solution platform-dependend. I would 
> suggest to do it as PHP scripts

Sorry, yes, xgettext.sh would be a PHP shell script that should run fine 
on both windows/*nix.  Keep in mind, too, that only the project admins 
need access to this.  PHP shell scripting seemed to make sense because 
windows version of php now has the php-cli by default.  I also like it 
because it would be an easy transition for gettext users.

 - I was thinking about the webpage, on 
> which user will upload the code file, and this will get all the strings 
> and present them to the user. The presentation would be the table with 
> the columns: StringID, String, Parameters. User will be able to modify 
> the extracted files and then generate the new code for the page, the XML 
> file or even the SQL code that will update the DB.
> 
> Translation interface
> This one I do not uderstand at all... Please clarify whjat you wanted to 
> say :)

Ok, in most applications there is some sort of administration interface.  
>From there you would be able to access the 'translation interface'.  This 
is the interface translators would use to translate english strings to 
some other language.  When accessed, the translation interface will look 
for the english.xml file parse it and show a form similar to the one you 
described which shows the english strings on the left and a text field on 
the right to hold the translated text.  The translator would simply run 
through all the strings, translate them and hit 'save'.  When they 
hit save it will simply create a new xml file (e.g. german.xml)  My 
diagram didn't explain this too well.  

See the attached diagram for updates.

> 
> Admnistration process
> does it deal only with the gettext files ? What is the purpose of 
> converting XML files to gettext files, if we can use the XML files in 
> the Translation class ?

Well, this part needs more clarification too. Keep in mind that the 
translated .xml files are the basis for implementing all translation types 
(db, gettext, file-based).  I don't envision the XML file really being 
used directly.  I envision in the apps configuration file a setting called 
something like:

$confTranslationMethod = 'gettext'; // can be 'gettext', 'db', or 'file'

I think something I missed here is that the PEAR_msgfmt.sh script will 
need to do a few things:
1) generate gettext file
2) pump translations into DB

See the updated diagram I've attached.

This way, no matter what method they choose for $confTranslationMethod, 
the underlying data would already be in the available forms.

> 
> Object model
> Looks good - however I suppose the TranslatorFactory is my Translation 
> class - am I right ? Besides in the 1.3 version it's going to be 
> completelly transparent if user uses the XML, Db or gettext files. I 
> mean - the method for getting any of them is the same - just inside the 
> class the specific source is determined.

Well, this is just a factory design pattern.  All the translation factory 
does is create the right translator and return it to caller.  All 
translation classes (DB, gettext, XML) would have the same exact methods.  
Let me know if that didn't make any sense.

> I hope this will help you. As I understand - we can work together and 
> after that we'll be able to publish the new solution on PEAR. As I saw - 
> all the things you described are to be implemented in 1.3 version of 
> Translation.

I'd be more than happy to help!

-- 
Tony Bibbs          "I guess you have to remember that those who don't
tony at tonybibbs.com  hunt or fish often see those of us who do as      
                    harmlessly strange and sort of amusing. When you  
                    think about it, that might be a fair assessment." 
                    --Unknown

-------------- next part --------------
A non-text attachment was scrubbed...
Name: translations.vsd
Type: application/octet-stream
Size: 90624 bytes
Desc: 
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20030219/196ebac8/attachment.obj>