I'm just having a debate about the best (future-proof, safe, user-friendly, developer-friendly, technologically nice) approach to localization of a web-application. We are using basically processing on the server, prepare pages there and use some JS, also use Syncfusion (who offer "something" with their latest release), but I am having mixed emotions about handling that via JS (on the (possibly thin) client) - I can't exactly name it, but my concerns seem to be about about language/culture-dependencies in the data being presented. And also, this would imply that the client would handle the localization of the UI, whereas otherwise we could deliver an already localized page to the client...

I've read the few questions that I found here, but was wondering if you could share some experiences/comments on the subject: would you rather localize by building localized pages or return generic pages and translate on-the-fly via JS?

  • 1
    Are the pages themselves built on-the-fly by JS? They seem to, in the case of that datepicker. Then you have no choice but to do the localization there. Similarly if you prepare things on the server side (data or whole pages) then the localization must happen there as well. – RemcoGerlich Jun 1 '16 at 10:03
  • The tier that does the rendering should do the translation. – plalx Jun 3 '16 at 2:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy