Re: Handling Translations

[michaeld senet com au]

Quoting Christian Rose <menthos menthos com>:
> Joakim Ziegler wrote:
> > It seems to me that both these methods are somewhat complex, and, more
> > importantly, slow.
> Do you have any data on that? I doubt the gettext solution introduces
> any user-noticable difference in speed. If in doubt, test it, compare
> it, produce some data on performerance, and then we can have a
> discussion. Speculating isn't helping.

Ok, agreed.  But if speed is an issue we can always use FOO (where FOO is 
possibly gettext) to localise statically. ie create localised pages using 
gettext and just serve them up.  Speed issue gone.  Make a change in the root 
document and use 'make' to redo the translation (and may include contacting 
translators directly, or marking the page as needing effort from a translator).
  
> > Now, if we think about the fact that if the template
> > system works as it should, and actual PHP functions are externalized,
> > then there won't be any common elements between the different language
> > pages (apart from headers and footers to call templates.)
> > 
> > So why not just use different pages (PHP files) for different languages?
> 
> Because it sucks. It's very much non-maintainable. How do you get
> notification of changes? If random hacker X spots an error on the site
> and commits a fix to cvs, how is translator Y[1-40] to know that spot Z
> on page W changed, without diffing the entire site periodically, and
> manually inspect all diffs, and on top of that try to insert
> corresponding changes in their translated pages? Translators want to
> translate, not spend most of their time trying to track changes.

Like I mentioned, why not keep track of what english text files have changed 
(md5sum on PO files?) and requiring translator input to convert strings to 
their locale?  Then they strings can be updated when the translator gets around 
to it, but at least they're flagged.
 
> gettext/xml-i18n-tools/PO format solves these fundamental problems. We
> have discussed it repeatedly on this list, but you just continue to
> ignore the problem.

We need to try a few things out to see what works before committing ourselves.  
Why not code up a page in your preferred solution, put it up for review and 
discussion, and then we can continue.

What we really need is the initial php templates for Joakim's html screens.  We 
can then hack till sunrise and try out some solutions before deciding upon one.

Just IMHO,

Michael...
-- 
michaeld senet com au
Not an i18n expert by any means.


-------------------------------------------------
This mail sent through SE Net Webmail
http://webmail.senet.com.au