Re: Using Translation from PEAR, other libraries

Just my 2 cents - I'm making my site using John's IntSmarty.  For me it 
was the 'easiest' way to go - and has been relatively painless thus far. 
  Until now I have only had exposure to Smarty through tutorials - so I 
really didn't have any opinion about it.  I looked into the gettext 
option and just got really confused.  Until now I have never heard of 
the PEAR I18n packages.

My site is pretty small and will have low traffic (in an Administrative 
area of an Intranet) but must be in a minimum of English, Japanese, and 
Korean.


Respectfully,
Ligaya Turmelle


Jochem Maas wrote:
> 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