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
