6

We are looking to internationalize a web application. Is it best to output translation Server-side (it is written in .net 4 C#) or Client-side (Javascript)?

We have already begun carrying this out Client-side by creating a JS file which contains a single object containing English phrases as the Keys (so developers understand what each message means in context), with values that are the string which is shown to the client for any alerts and prompts. We are thinking of extending this to all wording throughout the front-end.

Is this a good idea or is it best to carry out this kind of work server-side?

Update: Incase it helps to sway the argument, we don't use server-side controls heavily in our web application, the majority of our controls are jQuery/JS based.

Update: This particular application is not publicly visible (apart from the login page) so SEO concerns are not applicable.

killercowuk
  • 1,313
  • 1
  • 11
  • 23
  • 1
    I'd vote server side, but has a poll feel to it. – duffymo Jul 05 '12 at 13:57
  • Yes, unfortunately I can see how this could be highly debatable, however I'd ideally like to hear from someone who may have had to make a similar decision in the past. – killercowuk Jul 05 '12 at 13:59
  • 1
    Client side === accessibility fail – Matt Jul 05 '12 at 13:59
  • Your client side stuff cannot work if the client turns off JavaScript. Some people do. I see no advantage to client side. – duffymo Jul 05 '12 at 14:02
  • The site itself requires Javascript as a minimum requirement for entry as the vast majority of controls are jQuery/Ajax controls. Having translation carried out in JS means we don't have to turn our existing Javascript into dynamically generated files. – killercowuk Jul 05 '12 at 14:10

3 Answers3

5

SEO wise, I would recommend to do it server side and make the application available under a seperate url.

for example:

www.application/en/

www.application/es/ ...

Daniel
  • 601
  • 1
  • 4
  • 13
  • Thanks Daniel, this application is only available on a subscription basis, so the contents of it is not publicly accessible. But I appreciate the comment. – killercowuk Jul 05 '12 at 14:02
  • ok didn't know that. If you choose to do it client side, I have seen some solutions storing the language key/values in json files. It's easy to handle and easy to edit this way. good luck. – Daniel Jul 05 '12 at 14:10
  • Thanks Daniel, sorry I didn't specify earlier. I've seen some of these JS translation tools too, which lead me down this path. Particularly for all the jQuery based controls. – killercowuk Jul 05 '12 at 14:13
2

The first rule of I18n: follow the standard way. Do not re-invent the wheel. In case of Asp.Net that means server-side Internationalization.

Well, sort of. If you happen to have tons of dynamically created controls, you still need some Localization mechanism for client-side scripts. You can centralize it, i.e. create one global array of translated strings and the model+controller, so you can i.e. populate it via AJAX call (although X would be best replaced by J for JSON...).
Anyway, your model should simply retrieve appropriate strings from resource files and controller should feed the JSON to the client side (good idea is to actually request smaller chunks, i.e. just the translation for given view/screen instead of translations for the whole application).

As you can see, the best would be some mixed approach. For many reasons, one would be it is better to use one Localization model for the whole application, i.e. use only *.resx files.
Besides, there is much more to Internationalization than just plain string externalization...

Community
  • 1
  • 1
Paweł Dyda
  • 18,366
  • 7
  • 57
  • 79
  • Thanks for this, I agree that best to keep all translation in one format to be delivered to translators. I had not thought of AJAX retrieval of individual strings from resx files. However, I think I will do have a script that queues all required translations and sends as a single request for all specifically required translation strings for all controls on a page when finished loading all controls. This will mean only fetching required translations once without collecting individually as request overheads would become heavy on control heavy forms. – killercowuk Jul 09 '12 at 11:52
1

If you are showing only static content to user then go by client side internationalization. and if you showing content/messages those are dynamic, you should use server-side. but how are you detecting user locale?

shreyas
  • 1,360
  • 11
  • 11
  • Hi shreyas, user locale is a user setting within the Web Application (which means if they access from abroad, they still see it all in their home timezone/language etc.) Error messages delivered from the server-side (via Ajax), get compared against the Key/Value object in Javascript, and the relevant value shown to the user. – killercowuk Jul 05 '12 at 14:44