Should we store format strings in resources?

Question

For the project that I'm currently on, I have to deliver specially formatted strings to a 3rd party service for processing. And so I'm building up the strings like so:

string someString = string.Format("{0}{1}{2}: Some message. Some percentage: {3}%", token1, token2, token3, number);  

Rather then hardcode the string, I was thinking of moving it into the project resources:

string someString = string.Format(Properties.Resources.SomeString, token1, token2, token3, number);  

The second option is in my opinion, not as readable as the first one i.e. the person reading the code would have to pull up the string resources to work out what the final result should look like.

How do I get around this? Is the hardcoded format string a necessary evil in this case?

Answer 1

I do think this is a necessary evil, one I've used frequently. Something smelly that I do, is:

// "{0}{1}{2}: Some message. Some percentage: {3}%" string someString = string.Format(Properties.Resources.SomeString                                   ,token1, token2, token3, number); 

..at least until the code is stable enough that I might be embarrassed having that seen by others.

Answer 2

There are several reasons that you would want to do this, but the only great reason is if you are going to localize your application into another language.

If you are using resource strings there are a couple of things to keep in mind.

1. Include format strings whenever possible in the set of resource strings you want localized. This will allow the translator to reorder the position of the formatted items to make them fit better in the context of the translated text.

2. Avoid having strings in your format tokens that are in your language. It is better to use these for numbers. For instance, the message:
   
   "The value you specified must be between {0} and {1}"

   is great if {0} and {1} are numbers like 5 and 10. If you are formatting in strings like "five" and "ten" this is going to make localization difficult.

3. You can get arround the readability problem you are talking about by simply naming your resources well.
   
   string someString = string.Format(Properties.Resources.IntegerRangeError, minValue, maxValue );

4. Evaluate if you are generating user visible strings at the right abstraction level in your code. In general I tend to group all the user visible strings in the code closest to the user interface as possible. If some low level file I/O code needs to provide errors, it should be doing this with exceptions which you handle in you application and consistent error messages for. This will also consolidate all of your strings that require localization instead of having them peppered throughout your code.