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
