The first in my series of the 9 coding areas pseudo-localization can test.
Note: localization is often abbreviated l10n, because there are 10 letters between the l and the n. Sometimes people will capitalize the L to distinguish it from the 1. (PL1 is Pseudo-Localization 1, not Programming Language 1, for those of you old enough to remember that.)
Providing the pseudo-l10n is configured as a real localization will be, it tests whether or not the product will pick up the translated resources.
Once you run your resource files through a pseudo-translator tool, set them up as being for some locale other than the source locale. For example, if your code is typically written in the US and run on environments set to the en-US language/locale, then treat your pseudo-localized files as if they were the Japanese translation for Japan, that is, ja-JP. That typically means appending "ja-JP" to the file names, but may mean they should be stored in a ja-JP directory or database. This exercise also provides familiarity with the localization structure of the product - where the resources reside and what the naming conventions are.
Next, continuing with the example, the environment needs to look like a typical Japanese customer's. Whether that means the system settings are set to ja-JP, or the software itself is set to Japanese, or just the session, make it so. Maybe any of those settings are supposed to make your software switch to Japanese - all environments should then be tested. A side benefit of this is learning how other language/locale environments are set, and how the product is supposed to behave (yes, many folks don't know what the expected behavior should be in some cases).
Now, run your software. Is it picking up the pseudo-Japanese files in all areas of the product? Is it displaying date, numeric, and other dynamically determined formats according to the Japanese locale preferences? Did it do this without requiring a rebuild?
If not, you've got some work to do.