For some, simply looking at a site in a foreign language is daunting, never mind the thought of testing it. So, let’s say your client wants to use a single template to create 
the same site but in various global regions/languages. Here, I’ve put together some pointers to help guide the way.
To start, I’m using both REL Software Web Link Validator and Inspyder InSite, as they have some different abilities and in certain instances one is just easier or faster than the other. With any luck, the English site will be complete, so you can use it as a point of reference. Otherwise, open your regional site in one browser for testing and another to utilize Google translate.
Now for the fun stuff:
1. Links function, but are they going to the correct destination?
To an extent, testing this obviously requires human intervention. But, let’s say I’m testing a German site with a .de extension, and I need to validate that all internal links stay on the German site rather than going off to .com (or the English version).
a. Simply run the link report excluding external URLs, elect to view all pages processed, do a search for .com (or something like us-en — whatever directory or extension is being used to distinguish regions). If both regions are sharing a CSS and imagery, then exclude the directories like */images/* and */themes/*. It will probably require a little finagling to match your specific scenario, but you get the idea.
b. Mailto. View all mailto protocols in a single step to confirm email addresses are updated accordingly.
2. Regional languages
My link checkers also have a spell checkers that enable you to select from several languages. So my goal in this exercise is to make sure all text has been translated from English to German, including the copy within Flash, meta data, javascript and buttons.
a. The first thing I’d do is set up the project by excluding proper names.
b. Run your test, then throw out all the German words that came back as misspelled, as I wouldn’t know if they were really misspelled anyway (that’s what the translation partner is for). Go ahead and add them to the custom, project-specific dictionary, in case you have to run the same test again later.
c. Next, consider that some German product and business names may be in English and not recognized as a proper name by the tool. We don’t want to go translating things like business names, so add those to your custom dictionary, too.
d. Be aware:
i. Unless you have a character recognition software in your bag of tricks, you will have to manually check the copy on images like .jpg, .gif and .png. With these tools though, you can select to view specific file types, so at least you don’t have to click through each page trying to ascertain both what’s an image and which images have copy on them.
ii. Copy that overruns its boundaries: With translated sites (especially German) you will almost always find text that runs outside of its container. I’ve found it most effective to scour each page manually for this. Same deal for Flash, btw.
iii. Copy that’s easy to miss: dropdowns and success/error messaging. For whatever reason, translators like to overlook copy within dropdowns as well as webform success/error messaging. The spell checker should catch the dropdowns. But the validation messaging can be a little more complicated, and this is another aspect that I’ve found most effective to test manually.
e. Compile your results, and back to the translator!
There’s a lot more to do, but hopefully this will get you rolling in the right direction. And to think these tools are called “link checkers” ….