Re: Using Translation from PEAR, other libraries

Jacob Singh wrote:
> What is the common framework people use for I18N on your sites?  John 
> Coggenshall has an article in PHPBuilder about using smarty filters. I 
> don't really approve of this approach because it is forcing me into 
> Smarty, which I am not particularly fond of.
> 
> I like the look of PEAR::translation2, but I am not sure about the best 
> way to implement it.  I feel that a good I18N package, like any other 
> package, doesn't compromise your framework intentions.  This one seems 
> to require that you use PEAR:DB through their connection, which is a 
> problem because of connection pooling, and the fact that I don't use 
> PEAR:DB, I am using propel.
> 
> Any thoughts on this?  I need to make a site that is UTF-8 and has 
> translations not only for labels and images, but in many cases for 
> actual data.

a few thoughts:

1. I believe translation is integral to any web framework because a 
framework is about managing contextual content display (and the language 
is a variable attribute of the content). Also I wouldn't expect alot of 
code out there that doesn't come with some baggage (from the point fo 
view of your own framework), then again there is nothing to stop you 
from stripping down a PEAR module to suit your needs.

2. I view static text (e.g. button labels) and user text as 
fundamentally different - for the static texts I use a class that 
handles translating placeholder strings and for user created text I have 
an integrated translation service in my data objects - one tells the DB 
class to attempt (if a translation for the current language is not found 
then the original value is shown) to translate relevant values (i.e. 
fields marked in the data objects as 'translatable') when 'getting' 
values, the translations
are stored in a seperate table ala:

KEY	- a user created string taken from an arbitrary row & table
	  in the DB.
LANG	- a language code relating to the language of the value of the
           TEXT field
TEXT    - the translated value of KEY

> 
> I'm thinking of storing my data in an XML format in MySQL with multiple 
> translations and making my own search index for each language.  The 
> problem with this is that I have to grab the entire XML doc for each 
> field which may have 10-15 translations, parse and then display, wasting 
> lots of processing and database time.
> 
> I'm not farmilliar with XML databases, and I'm told they are bad voodo, 
> but what is another solution if you have to store user entered records 
> in 'n' languages?

the table I describe above actaully covers that scenario - how you 
present the management interface is ofcourse up to you. for a given KEY 
(text te translate) and LANG (id of the desired language) it is possible 
to retrieve a translation - the table stipulate the 3 bits of 
information required for every/any specific translation that needs to 
occur. you could alternatively implement it as a set of arrays (one for 
each lang). e.g.

$Lang['KEY'] = 'TEXT';

(I do something like this for what I call 'static' texts).

Bare in mind that you could use foreign key relationships to create
a M-to-N joining table(s) that stores translations for given entities in 
the DB e.g.

WEBPAGES
id
title
url

WEBPAGE_CONTENTS
webpage_id	--> WEBPAGES.id
lang_id		--> LANGS.id
content

LANGS
id
name

(another trick I use when it is not feasable to use a default value as a 
key - i.e. a whole page of text makes rather a large key value - rather 
larger than most DBs expect for indexable key fields)


You mention John C.'s  article about smarty filters - you might then 
want to look at Apache2 output filters, very cool stuff by all accounts, 
although I have no personal experience with them

---

I18N / L10N can be a bitch, I mean not only do you have to implement it 
but then you have users who want to quickly/easily manage 100's/10,000's 
of translatable text. on top of which you will find yourself in the 
murky waters of encoding translation and/or Unicode (UTF8/16) - the 
reason I say this is that these things can be complex enough with out 
making life even harder by starting off determined to use XML as part of 
the solution. besides unless you are going to use some serious caching 
of output (e.g. smarty caching, homebrewed output caching, squid etc 
etc) then extracting large chunks of XML from a DB and then having to 
parse it before extracting the relevant values (probably repeated more 
than once per request) is probably going to make your site alot slower. 
I'll say that another way - deciding to use XML should be the endpoint 
of your investigation not the starting point.

Hope thats given you some stuff to think about and maybe spark some ideas!

grds,
Jochem

> 
> Thanks
> Jacob
> 

-- 
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php