[geeklog-devel] GL2 translations (part 2)

[Tony Bibbs]

This is the latest email I have.  When he responds to the for-profit junk 
I'll let you all know where this stands.

-- 
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 11:48:02 -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:
> Uz.ytkownik Tony Bibbs napisa?:
> Well - my idea was not to use the PHP shell scripting either. I was 
> rather thinking about dedicated website, that will generate the correct 
> scripts for the user websites and DBs. The very far plans are to make 
> some money on these scripts - e.g. allowing users to make their sites 
> translations-ready for some amount of money.
> Giving the solution for free will simply cut the possibility to earn 
> something on this :)

Even if you have a dedicated website, that site can call the script 
directly.  So I don't see that as a problem.

However, and I don't mean this as criticism, I don't agree at all with the 
notion of having to pay to make translations with your package.  Don't get 
me wrong, I am all for making money and if that is your aim then more 
power to you.  To be sure I am clear, the implication is that at some 
point in the future, any PHP project using your translation class would 
have to pay for using it, right?

If I am right, this is a deal breaker for me and I would not be interested 
in persuing this further.  Again, don't take that personal.  It would mean 
that we disagree philisophically on this (which is OK).  I'll continue 
with my input below just in case I have misinterpreted your statements.

> I think the Translation Admin should rather work on the DB directly, 
> and, after the changes - it should generate teh XML files. We shouldn't 
> force translators to install eny sophisticated tools on their machines. 
> I think translators can work in 2 possible manners:
> - translator gets the XML file and edits it directly (it's up to him 
> waht tool he's gona use)
> - translator accesses the admin panel on the site he translates and from 
> that panel he changes the strings in DB (or in XML files directly, if 
> the site does not use the DB engine, which will be available since 1.3 
> version). After the changes are commited - the XML files on the server 
> are updated.

Well given this is a web interface, what they are working with should be 
transparent.  They shouldn't care if it is a DB or a file as long as the 
administration works.  Sophisticated tools?  What is so sophisticated?  
Are you referring to XML parsing?

> What for to deal with gettext files, if we alerady have the XML and DB ? 
> Waht is the purpose of converting one file format (XML) to another 
> (gettext) if the Translation class will use them in the same way ?
> The gettext support in the Translation class is intended to be used only 
> in the situation if the user has ONLY the gettext files.
> The only other features I can are
> - some script that will convert gettext files into DB scripts
> - some script that will convert the PHP scripts, that are using the 
> gettext() tehod into scripts, that will use the Translation objects instead
> I just think that converting one file format to another, while the class 
> supports both in the same way is simple waste of time :)

You make a good point.  My only reason for suggesting this is that my 
hunch is that gettext will do the translations better (faster with less 
memory usage) than with anything we implement in raw PHP.  I have no data 
to support that and I'd be interested to see what some rudimentary tests 
would show.

> 
> That is performed by Transation class. It works in the following way:
> 1. While creating you specify the source - DB, gettext or XML
> 2. To get the string you use the gstr() method. The class will check 
> which source is used, and in fact will call in the proper way the needed 
> method. But the methods for the differnet sources will be protected on 
> the class (in fact - it will simply be undocumented - as you cannot make 
> the methods protected in PHP at the moment :) )

We are talking roughly the same thing. Only difference is that the 
translation factory would return the right class with only the exposed 
methods.  The other benefit is you don't include a bunch of code that 
isn't going to be used saving on server memory.  The factory pattern is a 
well established design pattern by the Gang of Four. If you aren't 
familiar I'd seriously consider using it (in fact Horde and many of the 
other PEAR packages use this pattern).  The amount of work to you would be 
minimal, it's just a matter of refactoring the existing code.

> 
> So I think we should go in the following way:
> 1. Complete all the design things - how the whole pavkage i going to work
> 2. Agree what will be done by each of us (I suppose I will edal with all 
> the things concerning the class itself, and you can make the additional, 
> administrative scripts) - after that we'll put the class into PEAR 
> repository (of course I will add you to the developers list, however I 
> will stay as lead if you don't mind)
> 3. You will be able to incorporate the solution in your system - with my 
> full support

Again, I'm hesitant to commit to anything right now because of the 
for-profit idea you had.  Let's toss that around a bit more and from there 
I will be in a better situation to commit or not.

-- 
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