Menu
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.
290
Client-side developers focus on creating the parts of a website or application that users can see, such as visual design elements and web page layouts. Server-side developers focus more on behind-the-scenes components like how an application transmits data to a server.
Client devices send requests to the servers for webpages or applications, and the servers serve up responses. The client-server model is used because servers are typically more powerful and more reliable than user devices.
It also involves any actions performed by the app within the user's browser. The browser on the client-side interprets markup languages like CSS and HTML. Many developers now run client-side methods in their application architecture as business logic for dynamic webpages, such as in modern web applications.
If you right click -> View Source, you'll see exactly what the server sent. But if you right click -> inspect element and look at the html with your dev tools, you'll see everything as it is now, ie, after a full client side render.
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/ ...
116
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...
27
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?
44
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
