Localization Quality
Localization bugs are often classified into these symptom buckets:
Build/BVT (1) breaks
This kind of bug would make it impossible to produce a localized build, or would make a build completely unusable. These bugs are increasingly rare; when they do occur, they're hard not to notice, so customers should never suffer this.
Functional
This kind of bug is one where functionality is affected. It might be as serious as an application crashing because of a localization bug, or as trivial as a menu with duplicate hotkeys.
These bugs typically occur because a dependency between code and localization has been broken. Maybe a translation is longer than code allows (2). Or maybe a translation contains more placeholders than expected - think:
Console.WriteLine("Are you sure you want to {0} the file \"{1}\"", fi.Name);
These days we're pretty good at preventing these bugs, and test automation finds most of the ones that aren't prevented. We're still not perfect - there's always room for weird problems (3), but we've gotten pretty good.
Cosmetic
This kind of bug usually affects layout or display. They might make Windows look ugly or they might confuse the user, but they typically don't cause any loss of functionality.
Common causes are poor layout (4) and truncated text (5).
This is tricky to prevent, because the difference between what the translator sees and the user sees is growing with every Windows release. Auto-layout technologies give the translator less control over the look'n'feel and makes it harder to predict how a translation will be used. Controls may be rendered slightly differently depending on e.g. DPI setting. Font linking makes things interesting. Text is often supplied at runtime. These are just some reasons why it's hard to predict and prevent cosmetic issues.
The good news is that test automation is pretty good at spotting clipped text. Many issues can be found fairly easily. Other types of cosmetic issues (e.g. misaligned controls) are harder to spot through automation and may slip through.
Linguistic
This is the final bucket. This covers translations that are too vague, too specific, or totally wrong. It covers typos, poor grammar, inconsistent terminology and style, profanity, and other fun stuff.
These types of issues are the hardest to prevent and to spot.
We're dealing with natural language, which is iffy enough when processing large bodies of text. Software often deals with disconnected paragraphs, sentences or even fragments. Automated tests therefore tend to either have low coverage or be very noisy.
Different languages have different rules , which makes it expensive to create and maintain validation. The rules for a given language may change across time and projects - maybe there's a spelling reform or a terminology change; the new rules are in effect for Windows 7, but the old rules may still apply for Windows Vista Service Pack 2. Oftentimes linguistic bugs are subjective - what one person might consider a show-stopper; someone else might think is perfectly fine.
Of course, fixing one bug may cause another. Maybe a string is abbrev'd to work around a functional problem, but the result may be an ugly transl'n.
Oftentimes, there's disagreement whether something should even be translated. Service display names? Event provider names? Command line utilities? The display names of Unicode characters (6)? Different language versions of Windows have made different decisions.
What'll Windows 7 Look Like?
Linguistic bugs is definitely our weakest area. Linguistic bugs are hard to prevent and expensive to find, but we try and we are getting better. We spend a lot of effort on terminology work before and through-out any new Windows version. In Windows 7, our translators are given better context than ever before. Language packs makes it very easy to try out languages, which enables broader self-hosting within Microsoft. The amount of user interface being reviewed for linguistic issues is higher in Windows 7 than in any previous version.
That's not to say that we're "done". The whole reason for my group - Windows International - to exist is to produce localized versions of Windows and related projects. Now, there's a difference between the Highest Possible Quality and the Highest Quality Possible. We're aiming for the former; we're still not even achieving the latter.
In fact, I don't think we can achieve this on our own. We desperately need the help of users across the globe. Some languages are available under the beta programs, but that's not nearly enough. I think we have a lot of work to do to simply make it possible for any user to offer their help and for us to listen and react.
Make no mistake, localized Windows 7 will look good. But we got a ton of work to do to make Windows 8 noticably better.
(1) BVT: Build Verification Test. Answers questions like "Can this build even be installed?"
(2) E.g. https://blogs.msdn.com/jesperh/archive/2004/12/23/331412.aspx.
(3) E.g. https://blogs.msdn.com/jesperh/archive/2004/11/15/257694.aspx
(4) E.g. https://blogs.msdn.com/jesperh/archive/2006/07/25/678001.aspx, https://blogs.msdn.com/jesperh/archive/2004/12/08/278403.aspx
(5) E.g. https://blogs.msdn.com/jesperh/archive/2004/12/14/301273.aspx
(6) https://blogs.msdn.com/jesperh/archive/2004/12/15/316184.aspx; Swedish text