CODEWITHSUNDEEP
c#asp.netwebformslocalizationresx
user3447590
user3447590

Reputation: 21

WebForms Localization and Resource Files Practical Implementation

I am currently looking at localizing an ASP.NET website written C#.NET 4.5.1. Now I know about Local Resource Files and Global Resource Files and however I want to get a clearer picture on just how people go about doing this to make it more practical as I don't find it particularly nice having to create one or more local resource files for each webpage.

For example, the site has over 100 .aspx webpages. For each language I need to support I will need to create a separate .resx file. So supporting English, French and German for my home page would looks something like this:

default.aspx.resx

default.aspx.fr.resx

default.aspx.de.resx

Producing all of these files is going to be a hard slog. What I am considering is why can't I just use the Global Resource File for all of my pages? If I prefix each resource appropriately with a page name and textual description surely it is a slightly easier way to manage the localisation maintenance of the pages.

For example, my English Global Resource File would contain:

Default-TitleText - My Web Page Title

Default-BodyText - This is some example text for the body of my home page.

Login-TitleText - Enter your login details:

Login-UsernameText - Username

Login-PasswordText - Password

Login-SubmitButton - Login

User-Default-TitleText - Welcome to your personal page.

User-Default-Username - Hello {0}

User-Default-Logout - Click here to logout

As you can see I would prefix the resource key with page name and the text description. In the case of files in sub-directories I just prefix the page name with the directory name (i.e. User-Default-Logout).

For me this is a much more simple solution. Yes, the file will get quite big but everything is located in one place.

I wanted to get some feedback as to what other people actually do and if this is a practical idea or not.

Upvotes: 2

Views: 1028

Answers (1)

brumScouse
brumScouse

Reputation: 3216

And what about localisation for the different elements on forms. If you make them localisable you wont be able to store this information in your global resource file.

.NET has inherit culture support, why not leverage this. You simply create your new language translations in a resource file with the appropriate naming convention and when the users culture is changed they will pick up the appropriate resources. You will have to manage this manually otherwise, whats the point in occurring this overhead? Also the resources are compiled into satellite assemblies this means adding a new culture might mean just an application restart as opposed to application re-compile (if the resources are edited externally and without having to fix up mapping).

Also I'd hazard a guess most tooling out there will rely upon these conventions. I recently used a tool called Babylon.NET (this is not a plug) and worked with a German transaltor for an application which was initially in English. He was able to author the appropriate translations, get them back across to us and we could publish the changes as necessary. The default structure was a must for this tool to work, i;m sure others have that dependency too. The upshot being that if you go for a bespoke way you may be limiting your options down the line.

Upvotes: 2

Related Questions