Frontend vs backend localization strategy comparison

I prefer something like 1.

We are working on a pretty huge Angular.js SPA application that has i18n support as well. First we were using complete frontend localization (if I remember correct this one)

But when application got bigger and bigger, it became a hassle to manage i18n files, loading them into page (and you only need to load the needed strings because i18n file it is huge!) etc etc.

Also, user will change language rarely, it doesn't need to be dynamic, fast, two way bound or anything else. It's OK if we reload whole app.

So we thought why? We don't need i18n in frontend. We need i18n in our "app". Then, I wrote a build system on node.js, basically it is a preprocessor that parses all *.html and *.js files we have, extracts strings from them, looks them up using an i18n file, puts the localized string and creates copies of files per language count.

So basically, we create n apps instead of 1, all programmatically generated, each one is in a different language.

It works pretty well. When user changes language, we reload page and include another localized file set, and language is changed!

Sample source html file:

<header>@message("string.to.be.localized.1"i "{{name}}")</header>

Sample js file:

angular.module("app", [])  .directive("x", function(i18n) {    return {      templateUrl: "@HTML/templates/a.html",      link: function() { console.log(i18n("string.in.js", "Umut")); }    }  })

After compilation:

source.en.html

<header>Hello {{name}}</header>

source.tr.html

<header>Merhaba {{name}}</header>

sample.en.js

angular.module("app", [])  .directive("x", function(i18n) {    return {      templateUrl: "/templates/a.en.html",      link: function() { console.log("Hello {0}", "Umut")); }    }  })

sample.tr.js

angular.module("app", [])  .directive("x", function(i18n) {    return {      templateUrl: "/templates/a.tr.html",      link: function() { console.log("Merhaba {0}", "Umut")); }    }  })

I will prefer backend localization, since:

still i feel angular i18n is not mature enough to handle all use case for localization like no code translation(till angular 8). Till now its bestfor static data but not for dynamic data(errors coming from server side). And if we are using placeholders, pluralization in our static data so its complex tounderstand its translation file and cannot translate libraries like material, ng bootstrap,etc.

Where if we are using backend localization, maybe we won't tackle all these situation and hardly users are changing their locale so its ok to re-load the application one time (though with angular i18n still we would have to re-bootstrap the application at runtime)

I prefer front-end localization.On back-end you can throw any exception that contains exception code and explanation in English - these are for developers. On front-end you can use each JSON (or other) file for each language of localization based on codes, that you got from back-end or based on architecture logic of your front-end.

Why I find front-end localization better - because front-end is closer to User that back-end and you can provide him batch of your files with one file of localization of his language. Since front-end application can call several back-end operations in his one, or even calls from several services (both internal or external) the localization of messages is redundant because the User must get any understandable and user-loyal message (but not any like "could not insert data into a table" or "external server not answers") - you ignore that message and provide your one. More from that - back-end nowadays is written to contact with a lot of other services (not people) and localization is redundant here since each developer understands English.