Re: 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 <[email protected]> wrote:
> This discussion seems to confuse several different aspects of message han=
dling.
>
> 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 embedde=
d variables with ordered placement holders, support for message variants ba=
sed 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 incorporat=
e translations into the application.
> You will want a deployment strategy (how are the strings packaged and sen=
t along with the application).
> You may want an update mechanism (adding languages and fixing strings wit=
hout changing code or resending the entire application)
> You may want some tools to verify the translated strings are physically c=
onsistent with the originals (same number of embedded variables, same numbe=
r of strings, etc.)
> You may want inheritance or other hierarchical approach to reusing string=
s across locales. (English for US, Canada, etc.)
>
> Gettext is basically storage and retrieval. It's model is designed for ap=
plications that get packaged and distributed to end-users.
>
> ICU is a complete package for internationalization and Unicode support. I=
t's message storage and retrieval is ok. It's message formatting is much mo=
re robust than gettext. It is sizable, but can be stripped down.
>
> PHP applications being server based, and generally already using a databa=
se 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 translatio=
n and load them, but that is trivial to arrange. To the extent you can prov=
ide a simple php app to enable translators to update the database more dire=
ctly, 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 an=
d let the translators see the results almost immediately without developmen=
t 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 im=
portant.
>
> Gettext has its place, but its not the best solution for php, or more gen=
erally server based, apps.
>
> The php 5.3 functions for message formatting via icu are very good and pr=
ovide the needed capabilities.
>
> If you have existing code and need to extract strings, there are tools th=
at will do that.
> Some freeware, some commercial (like lingoport globalyzer).
>
>
> I would not worry about being doomed to reinvent gettext. It is trivial t=
o 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