The other day, the loc team here in Redmond was wondering if the registry was something that can get localized, and if yes, to what extent? Can we localize key names, types values?
So we knew already that localizing key names shoult not be done, not because it's not doable but because it complicates the code without a real benefit (how do you go about retrieving a localized key name, without knowing that value, if it's not already in your resources? How do your customers/partners go about it?). But what about values? That was still a valid question no?
So a couple of facts first:
- Registry keys support Unicode, whether it's in terms of input, display, or copy/paste (back and forth)
Same for values
So it's feasible for values also, and can even work in multilingual environments if the creation and retrieval of the key has some LCID (or language-culture, or other) logic built-in (e.g. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\TEST\1033\ for en-USA).
We asked the International PMs about this and their opinion was that localizing registry values wasn't indeed a good idea, with the recommendation that "What people could do is use a resource id as the registry value that maps to a resource in a satellite .dll. That way there’s nothing in the registry that we actually have to localize".
So that's our recommendation: avoid placing localizable data anywhere in the registry, whether it's in the keys or in their values.
For reference, Doctor International has written about this topic as well, and the entry can be found here: http://www.microsoft.com/globaldev/DrIntl/columns/011/default.mspx//lEFB#EFB.
When we think about localizability, the first thing that jumps to our mind is "hardcoded strings". Check on the GlobalDev page about isolating localizable resources (
http://www.microsoft.com/globaldev/getwr/steps/wrg_locresources.mspx), it's right there , first entry. The page is filled with words like "most extreme cases", "biggest nightmare", which should scare everyone reading the post.
On the day-to-day side, this is what we tell our developers: "It's OK (note the word choice: OK, not good, not recommended, but OK, acceptable) to hardcode a string if you're working on a prototype; as soon as your code will turn into production, even if there aren't short-term plans to localize your project, DON'T HARDCODE". What we notice is that for sure, it's a lot easier to write:
// Display string in MessageBox
MessageBox.Show("Hello world!");
Than:
// Declare a Resource Manager instance
ResourceManager LocRM = new ResourceManager("MyStrings",Assembly.GetExecutingAssembly());
// Assign the string for the "strHelloWorld" key to a messagebox
MessageBox.Show(LocRM.GetString("strHelloWorld"));
Besides that on top of that, you've had to add the "Hello World!" string to a resource file! It takes 30 seconds in the first case, it takes the double in the second one. That's a lot...
But then, when you've written 1000 lines, 10000 lines, 500000 lines projects, with the first method, and you have to make your project localizable by moving all these hardcoded strings into resources, you're not going to get this done in 30 seconds per string; you're going to forget strings; bump into false positives (you're going to have to crawl through double-quoted strings that should stay in the code and not go in the resources). Even if your V1 application is targeting your local market, let's imagine that it gets so successful that you want to expand its reach… That's the benefit of doing it right from the start, and not hardcoding strings.
Like any topic, this can get controversial of course, especially when it comes to the contrary situation: putting in resource files strings that shouldn't be localized, e.g. registry keys, references to function names, filenames, … Why would you have in the resources a string that says "user32.dll"?! There are lot of cons to this practice:
- the biggest risk you take when you do this is that your strings can get over-localized (user32.dll becomes utilisateur32.dll; I know, I'm pushing this a little here with this example, but these things happen…). So now you're reading the string, your code is expecting an existing and valid filename, and your functionality is broken, because of localization (!). And we are not even going into the scenario of a malicious usage of the string, that could direct your code somewhere else.
- these kind of resources can add-up to your word count estimates, and you'll end up paying unnecessary "translation" work for them
This makes sense, so why is it controversial? Because as a developer, you'll say: "It was easier to have it in the resources than adding another global variable/constant to my program". That's a valid reason, but not one we hear very much on these days of memory galore. What we hear most of the time now is: "My resources are being shared with other programs, I just can't hardcode them". We, localization teams, don't have the silver bullet against that one; we still have a recommendation that will help though: if you're developing in managed code, give your resource ID a meaningful name, such as "
DoNotLoc_User32_Filename". Localizers will see these resource IDs, can hopefully even filter them and not pay attention to them. If you're in non-managed code, then get an agreement with your localization team: "All resources which ID > 10000 must not be localized".
Communication is key with our day-to-day work. You mitigate a lot of risk by building this developer-localization dialog. As you can see, I haven't talked about tools, just best practices, common sense, communication.
Last week for English and the week before for Spanish, the "San Fermín desktop theme for Windows XP" was released. Just in time for the feria in Pamplona. What a riot!
I'm usually not too keen on themes, but I'm keen on GlobalDev (http://www.microsoft.com/globaldev) and it's there, listed in the Top Stories section.
Enjoy !
Olivier.
There have been several changes in the .NET Framework setup and packaging that are important from an international perspective and Aaron Stebner's blog has several good posts detailing the changes between v1.0, v1.1 and v2.0. His first entry gives a good description of these changes and a related entry answers some questions related to the changes.
The localization team also drives International QA for the US Developer Division through the International Test Lead position. The International Test Lead works with the Localization Program Managers, International Program Managers and the worldwide regional QA teams to coordinate our international test strategy and also drives the Redmond IntlQA Contacts group, which is made up of representatives from each of the division’s feature teams. The Redmond IntlQA Contacts group is responsible for:
· recommending international test strategies
· coordinating the globalization and localization testing for their feature
· creating the IntlKit (a set of international specific test cases) for use in the DevDiv subsidiary QA offices
· supporting the subsidiary QA teams on feature specific test issues
This blog is not an individual's blog but a team one: the US Developer Division localization blog. We are the team within Visual Studio that drives for localizability of the product. So from the diagram on this page
, we are the little box next to Globalization.
As we ramp up with you, we'll tell you about the localizability and localization processes we leverage, our best practices, the issues we face and how we resolve them, the tools we use etc...
We'd love to hear from you, on whether you're using a non-English version of Visual Studio (or the .NET framework for that matter), if you have feedback on the translations, or whether you want us to write about a specific topic or issue. Your feedback and comments are more than welcome !
Don't miss Achim's blog
: he's one of the International Program Managers (IPM) we work with A LOT. He's driving for Globalization in the Developer Division (so he's in that other little box I mentioned above :), and physically not sitting far from us (line between globalization and localizability sometimes blurs).
Thanks for reading and please do come back !
Olivier.
