As an example, let us consider a typical "Windows Desktop Application" developed using .NET technologies as a Localization testing candidate.
For starters, please go through the link given below:
http://msdn.microsoft.com/en-
In addition, here are some of the points which one can think of:
1. Localization strings testing(If they are displaying correct/meaningful Japanese)
2. Font management(Check the character encoding system which is followed Unicode, JIS, Shift JIS)
3. Areas where string processing is involved(input/output of the Japanese strings)
4. Locale setting on OS.(Setting Japanese Locale on English OS, vice versa, check the RS/FS to see the expected behavior)
5. Behavior of S/W on higher end of Windows Vista (Ultimate/Enterprise editions - They support a feature called as language pack.Due to this, even if OS is English, we can see OS UI in Japanese, etc.)
6. S/W based specific cases of localization.(such as requirement to switch language at runtime)
7. Display of Japanese characters correctly.(Sometimes if the character encoding is not supported at any point(OS level, fonts missing, S/W level - encoding support missing))
8. Looking at String table(in case of .NET applications for strings)
These are the points which are common to all Japanese localization processes.
The procedures to be followed may vary depending on following points:
Developement environment
SDLC type - Waterfall, Agile.
Delivery Document in Japanese (Test Cases in Japanese language)
STLC - Manual, Test Automation using QTP, Test Complete, etc.