Hardcoded resources
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.
