In a typical scenario, software would be built and tested in one base language (such as English), with any localizable elements being extracted into external resources.
[2] The problem with this approach is that many subtle software bugs may be found during the process of localization, when it is too late (or more likely, too expensive) to fix them.
These problems include: In addition, the localization process may uncover places where an element should be localizable, but is hard coded in a source language.
These locales were designed to use character sets and scripts characteristics from one of the three broad classes of foreign languages used by Windows at the time—basic ("Western"), mirrored ("Near-Eastern"), and CJK ("Far-Eastern").
]This process produces translated strings that are longer, include non-ASCII characters, and (in the case of the "mirrored" pseudo-locale), are written right-to-left.
[4] Note that the brackets on either side of the text in this example help to spot the following issues: Michael Kaplan (a Microsoft program manager) describes the process of pseudo-localization as an eager and hardworking yet naive intern localizer, who is eager to prove [himself] and who is going to translate every single string that you don't say shouldn't get translated.
[3]One of the key features of the pseudolocalization process is that it happens automatically, during the development cycle, as part of a routine build.