Verifying that Messages Come from Locale-specific Message FilesThe purpose of this type of testing is to verify that all appropriate strings have been internationalized and that innapropriate ones have not. This applies to button and menu labels, footer and other window text messages, and command line messages. History shows that simply checking the source code is not sufficient. In some cases it is unclear that a string should be messaged until a problem arises when the program is run. Even when a string in the source code is wrapped with the correct message call, such as gettext or catgets, the string must access the correct catalog and, for catgets messages, with the correct set and message number. A good approach is to bracket each message with a prefix and suffix, then create a modified catalog and install it in another locale. For multibyte locales, at least part of the prefix and suffix should contain multibyte characters. When the messages in the original .msg file are translated using the prefix and suffix and compiled to the proper .cat files using gencat(1), and the .cat file is properly installed in locale-specific locations, then the messages should be read from the modified catalog when the product is run in that locale. If any messages appear without the prefix and suffix, they may have been hardcoded or otherwise not prepared properly for messaging. The prefix and suffix can be long enough to make the total message length up to 200% larger than the original message. These longer messages can also show that various widgets are able to resize to handle longer strings. How to Test
Sample ProgramsNOTE: These tools and scripts are customized for testing the messages in a certain product. These tools and scripts are working versions and will probably need customization for your product. There are other approaches one could take to implement what these tools and scripts do.
| ||||||||
|
| ||||||||||||