> 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