[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gettext-based localization



> Also, using the primary language as the tag discourages clean
>  localization patterns, where the author of the code should be collecting 
>  his locale dependent messages in one place so that translators can 
>  easily translate the messages without having to seek them out in the 
>  code.  Or, if the primary language programmer wants to make a 
>  change in said primary language, he has to search out the string in his 
>  code as well.  

I would like to lend support to the need for the package/message id approach.

I have seen efforts for internationalization/localization of applications in 
my company, where both methods have been used. While either can be made to 
work- "it's only code after all", but embeding strings to be 
internationalized through out the code has always caused us more trouble, 
with problems caught late, when the software has already been handed over to 
product test.

What is particularly troublesome is not localization of the GUI (menu items, 
window titles etc.) but things like alarms for telecommunications equipment. 
With GUI menus, button items, etc. designers/testers see these all time if 
they're using the GUI at all. But alarms are only seen when the problems 
occur. Plus these alarms must be documented in great detail. It makes both 
complete handling by programmers and translators easier. But it also makes 
the process of writing customer documentation (both in the primary language 
and the various "foreign languages") easier when all such messages are in a 
single place.

The need for package is in this context is--to me- exactly the same as the 
need for packages in Java. With large numbers of developers working on 
development of the same system, namespace control is a must.

Perhaps others have had different (and better) experiences with gettext and 
including message strings throughout the code.

Jim