![]() The class I've created is called PseudoLocalizer and it automatically pseudo-localizes standard. So I thought it would be fun to write my own and share it with the community as open source under the very permissive Ms-PL license. However, none of the ones I found during a quick search appeared to be free, simple to use, and unencumbered by restrictions (i.e., licensing, distribution, etc.). Pseudo-localization isn't a new concept and there are a variety of tools out there that do a fine job of it. (It's not very sophisticated, but it's good enough for our purposes.) Can you tell if all the strings are properly localizable? Are there any other localization concerns here? Here's the sample application I created for this post running in its normal English mode. Aside: It's important to remember that the character "translations" are chosen exclusively on the basis of how similar they look to the original character and not on the basis of linguistic correctness, cultural influence, or anything like that! (This is one of those " a picture is worth a thousand words" moments, so please check out the Wikipedia article or bear with me for just a moment.) Additionally, because some languages tend to have longer phrases than English ( German, I'm looking at you!), there's often an additional aspect of string lengthening to simulate that and help detect wrapping, clipping, and the like. What pseudo-localization does is create alternate versions of resource strings by using different characters that look similar enough to the original English characters that text is still readable - but obviously "localized". Yep - that process is known as pseudo-localization. It sure would be nice if teams could do some kind of low-cost localization in order to identify - and fix - oversights like this long before they turn into problems. This is a perfectly reasonable approach, but there are invariably a few surprises - usually some variation of " What do you mean that string is hard-coded in English and can't be translated?". ![]() So teams often wait till near the end of the release cycle - after the UI has stabilized - to start localizing the application. You see, localization can be expensive: hiring people to translate an entire application, re-testing it in the newly supported locale, fixing resulting bugs, etc. The techniques I describe in that post constitute a good workflow that's just as suitable for WPF and Silverlight desktop applications! But even with good processes in place, the way localization is done in the real world has some challenges. I've previously written about the benefits of localization and shown how to localize Windows Phone 7 applications.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |