Thanks Wil.

The ideas I put down are not new and have been implemented elsewhere so I am 
sure the Mozilla guys are aware.

I thought this list should be aware there are other accepted approaches to 
gettext.


Tex

From: clous...@gmail.com [mailto:clous...@gmail.com] On Behalf Of Wil Clouser
Sent: Monday, May 03, 2010 9:05 PM
To: Tex Texin
Cc: php-i18n@lists.php.net
Subject: Re: [PHP-I18N] Gettext (was how to i18n better?)

If you are really interested in this kind of thing and want to look at
improvements over gettext, you should get in touch with the people
working on https://wiki.mozilla.org/L20n .  It has a long ways to go,
but there is a lot of thought being put into how to make a better
system.

Wil

On Mon, May 3, 2010 at 5:59 PM, Tex Texin <texte...@xencraft.com> wrote:
> This discussion seems to confuse several different aspects of message 
> handling.
>
> I don't have time for a lengthy note, so briefly:
>
> To support localization of text you need several different capabilities.
>
> There is of course storing and retrieving of strings by locale.
> This is gettext's main mission.
> On top of that you need message formatting functions- support for embedded 
> variables with ordered placement holders, support for message variants based 
> on number (singular, plural, and other).
>
> You may want tools for extraction.
> You will want a way to send strings out for translation and to incorporate 
> translations into the application.
> You will want a deployment strategy (how are the strings packaged and sent 
> along with the application).
> You may want an update mechanism (adding languages and fixing strings without 
> changing code or resending the entire application)
> You may want some tools to verify the translated strings are physically 
> consistent with the originals (same number of embedded variables, same number 
> of strings, etc.)
> You may want inheritance or other hierarchical approach to reusing strings 
> across locales. (English for US, Canada, etc.)
>
> Gettext is basically storage and retrieval. It's model is designed for 
> applications that get packaged and distributed to end-users.
>
> ICU is a complete package for internationalization and Unicode support. It's 
> message storage and retrieval is ok. It's message formatting is much more 
> robust than gettext. It is sizable, but can be stripped down.
>
> PHP applications being server based, and generally already using a database 
> in conjunction with most applications, can easily use a simple database 
> design for string storage and retrieval by locale.
> You need to address how you will package strings to go out for translation 
> and load them, but that is trivial to arrange. To the extent you can provide 
> a simple php app to enable translators to update the database more directly, 
> you can greatly simplify and accelerate localization and testing.
>
> An important aspect of localization is to enable translators to view the 
> context and the results, to raise quality.
>
> If you can eliminate the string file submission, compile, build stages and 
> let the translators see the results almost immediately without development 
> involvement, it is a big win.
>
> Performance of string retrieval from the database is very high.
> Eliminating the management and workflow around lots of string files is 
> important.
>
> Gettext has its place, but its not the best solution for php, or more 
> generally server based, apps.
>
> The php 5.3 functions for message formatting via icu are very good and 
> provide the needed capabilities.
>
> If you have existing code and need to extract strings, there are tools that 
> will do that.
> Some freeware, some commercial (like lingoport globalyzer).
>
>
> I would not worry about being doomed to reinvent gettext. It is trivial to do 
> so, and all in all there are better approaches for server-based apps.
>
> tex
>
>
>
>
> --
> PHP Unicode & I18N Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



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

Reply via email to