My .resx Resource File Pain Points

83 views Asked by At

When using .resx resource files for localization I have the follwing pain points:

  1. For each label, I need to make an entry in each different language file. It is prone to human error in terms of copying the name of the entry and it would be easier to add different language versions of the same label in one place. For example:

    var lbl_Hello = new { en = "Hello, fr = "Bonjour" };

  2. I cannot seem to search for names or values inside the resx visual editor using Visual Studio search.

Are there alternatives to overcome these?

1

There are 1 answers

1
Vi100 On

I feel your pain. It's ridiculous that Microsoft hadn't provided a better alternative for this in so many years. Even the .NET Core localization uses .resx files. My alternative for this is to create a table with one column foreach language you want to track. Then load it on memory soon in the pipeline (in .NET Core) or in the config phase (older ASP) in the form of a static variable (a dictionary) or I insert it on the local/shared cache with no expiration date.

EDIT

If the quantity of strings to localize is not very big and you have all of them available in all languages you can perfectly put them inlined on the static class itself, rather than having them on an external resource (a database or a file). But having this strings on an external resource has one clear advantage, you can replace them without recompiling the application.

Furthermore, sometimes you won't have all the strings translated in all the availables languages you want to offer. Then, if you have the resources allocated in a database or an external file then you can provide a user interface to allow some users with the required privileges to modify/complete the translations.