This page is part of the web mail archives of SRFI 29 from before July 7th, 2015. The new archives for SRFI 29 contain all messages, not just those from before July 7th, 2015.
> 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