12

I work on a product where we have to worry a bit about localization. Currently, this is the workflow for when I have to use(or add) a localized string:

  1. Search resources.resx file(which has hundreds of items)
  2. If found, then copy the name. Otherwise, add a new string and copy the name
  3. Then, use ResourceFactory.ResourceMgr.GetString("MY_MAGIC_STRING") (where ResourceMgr is just a static field to a ResourceManager)

This 3 step process for any strings is a real pain. Are there any patterns or ways to make this process easier?

svick
  • 236,525
  • 50
  • 385
  • 514
Earlz
  • 62,085
  • 98
  • 303
  • 499
  • 1
    Be careful about reusing the same string, there are phrases/sentences/words that have to be translated differently into other languages, depending on context. E.g. conjugation of verbs in Slavic languages depending on the subject of the sentence. – svick Jan 14 '13 at 17:19
  • @svick of course. We usually try to keep things all together(especially by using String.Format style strings) and let the translators tell us when there's something we need to change – Earlz Jan 14 '13 at 17:48
  • If this a clean code thing or make it execute faster? – paparazzo Jan 14 '13 at 18:41
  • @Blam for clean code primarily(though more performance never hurts) – Earlz Jan 17 '13 at 20:32

2 Answers2

5

Auto-generated files with access to each individual string are much easier to use - set "Custom tool" for RESX file to PublicResXFileCodeGenerator.

Code would look like:

using MyProject.Resources;
...
localizedText = Resources.SomeReasonableName;

Side notes:

  • having multiple RESX files along with auto-generated IDs have additional benefit of intellisense giving you reasonable number of choices.
  • depending on how translation is handled you may be better not worrying about duplicated text in RESX file (except maybe OK/cancel kind of strings). It may be easier to deal with duplicated strings at translation time.
Alexei Levenkov
  • 98,904
  • 14
  • 127
  • 179
  • But this will only make step 3 slightly better, so it's not that big of an improvement, no? – svick Jan 14 '13 at 17:57
  • 1
    @svick, your call. "Slightly" as in "compile time vs. run-time checks". Also if strings are organized into files by feature you get intellisense that with reasonable number of choices, if all in one file - not so much. But at least you get compile time errors instead of run-time. – Alexei Levenkov Jan 14 '13 at 18:18
0

There is this Java solution that might give you some ideas: http://rodionmoiseev.github.com/c10n/

The idea is to store translations in the source code itself, using annotations on interface methods. Then, by using a special utility, you can dynamically create proxies (classes dynamically implementing the interface) that would return localised string value when invoking the interface method.

This way, "MY_MAGIC_STRING" is replaced with a call to MyMagicString() method, which gives you some spelling/type safety and makes it more refactoring friendly.

rodion
  • 14,729
  • 3
  • 53
  • 55
  • Posting an answer that contains just a link is not very useful. Could you add a short explanation of what the library does? – svick Jan 15 '13 at 14:56