Verifing 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. Simply checking the source code is not sufficient; there may be messages in which it is unclear that a string should be messaged until a problematic situation occurs in a running program. Even when a string in the source code is wrapped with the correct message call, such as gettext or catgets, the string has to get into the correct message catalog file, with the correct set and message number in the case of catgets messages. A good approach is to bracket each message with a prefix and a suffix, then create a modified catalog and install it in another locale. For multibyte locales, at least part of the prefix and suffix should be made up of multibyte characters. When the messages in the original .po file have been translated, using the prefix and suffix, and compiled to the proper .mo files with msgfmt(1), and the .mo files have been 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.
| ||||||||
|
| ||||||||||||