|
The purpose of this testing is to review message files in the context of the areas listed below. It is also helpful to have a technical writer review these files.
NOTE: It is important to review the actual .msg, .po,
Java, or other resource or
property files, because the cost of changing even one message is
high and requires more than just changing the code. It may require
changes to
documents and other elements as well. Changes take time, and unnecessary
changes can
severely delay a localized product's time to market.
A. Message Content and Cultural Assumptions
Messages should not contain references to words or phrases peculiar to one culture only, such as local slang or hacker slang. Also, some words that do not have a negative impact in one country or culture may have a negative connotation in other languages or cultures. You cannot know this for all words in question, but you can look for obvious ones.
This review also helps to disclose strings that should not be messaged. The nature of these strings depends on the product, but it usually concerns messages not intended for the user.
B. Message Clarity and Avoidance of Fragmented Messages
Messages should be clear and directed to the user's probable level of knowledge. If, for example, the product does not require knowledge of UNIX® commands or system calls or internals, then messages should not use words referring to them.
Do not fragment messages. A message should not be made up of message fragments joined together at the time of the message. If a certain situation can evoke one of two possible messages, then provide two complete messages.
C. Message Comments
Translators of a product may not know as much about the product and software details as you might think. Thus, messages should contain comments to help clarify things. For example, a comment might indicate that a certain word in a message should not be translated, or it might clarify the meaning of a certain word or phrase in a message.
D. Message Catalog Numbering Consistency
The catgets messaging scheme uses the idea of message sets and message numbers within sets. Each development team should have a way of keeping set and message numbering organized so that duplicate sets and message numbers do not occur in the catgets statements in the source code.
NOTE: Do not use duplicate keys in the same message file.
For this type of review, scan the .msg files or use other methods to see that the files that make up one .cat file do not have duplicate sets or message numbers within a set.
| 
Print-friendly Version
