Frontend vs Backend Lokalisierungsstrategie Vergleich

8

Ich entwickle eine Anwendung auf Basis von Sails JS Backend und Web und Mobile Frontends. Meine Pläne für die Frontend-Frameworks sind:

  • Webfrontend - AngularJS + Bootstrap
  • Mobiles Frontend - AngularJS + Ionic mit späterem Port von Apache Cordova

In Bezug auf die obige kurze Erklärung muss ich der Anwendung Lokalisierungsfunktion hinzufügen. Und hier kommt meine Frage auf - da sowohl Sails JS als auch AngularJS die Lokalisierung unterstützen, die ich für mein Projekt brauche?

Theoretisch kann ich haben:

  1. vollständige Backend-Lokalisierung - Ich werde Build in Sails JS-Funktionen verwenden und alle lokalisierten Ressourcen als JSON-Dateien in das Backend
  2. einfügen
  3. komplette Frontend-Lokalisierung - Ich könnte AngularJS Add-On hinzufügen und Schnittstellen am Frontend oder
  4. lokalisieren
  5. Mischen von Backend- und Frontend-Lokalisierungen.

Ich würde mich freuen, wenn Leute mit mehr praktischen Erfahrungen sich mit dem Thema befassen, die Anwendungsarchitektur in Betracht ziehen und mich auf mögliche Vorteile / Nachteile der verfügbaren Optionen aufmerksam machen.

    
Angel Todorov 26.02.2015, 07:13
quelle

1 Antwort

4

Ich bevorzuge etwas wie 1.

Wir arbeiten an einer ziemlich großen Angular.js SPA-Anwendung, die auch i18n-Unterstützung bietet. Zuerst verwendeten wir die komplette Frontend-Lokalisierung (wenn ich mich richtig erinnere, diese )

Aber wenn die Anwendung größer und größer wurde, wurde es mühsam, i18n-Dateien zu verwalten, sie in die Seite zu laden (und Sie müssen nur die benötigten Strings laden, weil die i18n-Datei riesig ist!) usw. etc.

Außerdem wird der Benutzer die Sprache selten ändern, er muss nicht dynamisch, schnell, in zwei Richtungen oder irgendetwas anderes sein. Es ist in Ordnung, wenn wir die ganze App neu laden.

Also dachten wir warum? Wir brauchen kein i18n im Frontend. Wir brauchen i18n in unserer "App". Dann schrieb ich ein Build-System auf node.js, im Grunde ist es ein Präprozessor, der alle *.html and *.js -Dateien analysiert, Zeichenketten daraus extrahiert, sie mit einer i18n-Datei abfragt, die lokalisierte Zeichenkette einfügt und Kopien von Dateien erstellt Sprachanzahl.

Im Grunde erstellen wir also n apps statt 1, alle programmatisch generiert, jedes in einer anderen Sprache.

Es funktioniert ziemlich gut. Wenn der Benutzer die Sprache ändert, laden wir die Seite neu und fügen einen weiteren lokalisierten Dateisatz hinzu, und die Sprache wird geändert!

Beispiel Quell-HTML-Datei:

%Vor%

Beispiel js-Datei:

%Vor%

Nach der Kompilierung:

source.en.html

%Vor%

source.tr.html

%Vor%

sample.en.js

%Vor%

sample.tr.js

%Vor%     
Umut Benzer 23.07.2015 08:54
quelle