Wo soll ich lokalisieren (serverseitig oder clientseitig)?

Derzeit entwickle ich eine neue Webanwendung auf der Basis eines umfangreichen JavaScript-Clients, der mit mehreren REST-Webdiensten auf meinem Server kommuniziert. Diese Anwendung soll in mindestens zwei Ländern mit unterschiedlichen Sprachen verwendet werden, daher müssen wir sie lokalisieren.

Meine Frage ist, wo ich die Lokalisierung verwalten soll: Sollen die REST-Services Anfragen empfangen und Antworten mit lokalisierten Daten senden, oder sollte der Client generische Daten empfangen und senden und dann für die Lokalisierung verantwortlich sein?

Ihre REST-API kann von anderen einfacher verwendet werden, wenn Sie anstelle übersetzter Zeichenfolgen Zeichenfolgen-IDs angeben. Die Verwendung einer zurückgegebenen API "E_NOT_AUTHORIZED"ist einfacher, als wenn eine bestimmte menschliche Sprache und sogar eine lokalisierte Zeichenfolge zurückgegeben wird.

Möglicherweise möchten Sie auch die lokalisierten Zeichenfolgen in zukünftigen Versionen ändern. Dies wäre eine wichtige Änderung der API. Mit dem String-ID-Ansatz kehren Sie dennoch zurück "E_NOT_AUTHORIZED"und behalten Ihre API-Kompatibilität bei.

Wenn Sie ein Framework wie Angular.js verwenden , ist es einfach, die Sprachumschaltung im laufenden Betrieb zu implementieren, wenn Sie den String-ID-Ansatz verwenden. Sie laden einfach eine andere Stringtabelle, und alle Strings ändern automatisch ihre Sprache, da Sie in Ihren Vorlagen lediglich eine Filterlogik verwenden, z {{errorStringID | loc}}.

Eine weitere Überlegung: Um die Serverlast zu verringern, sollten Sie Ihr Back-End so einfach wie möglich gestalten. Sie können mehr Clients mit der gleichen Anzahl von Servern bedienen. Stellen Sie Ihre Stringtables über ein CDN bereit und lokalisieren Sie sie im Front-End.

Lassen Sie die Clients den standardisierten Accept-LanguageHeader in Anforderungen senden , lokalisieren Sie ihn dann auf dem Server und fügen Sie einen Content-LanguageHeader in die Antworten ein. Weitere Informationen finden Sie in RFC 7231, Abschnitt 5.3.5 .

Die Lokalisierung auf der Serverseite führt zu weniger Roundtrips und Bandbreitenverbrauch als das Senden von Client-Lokalisierungsmetadaten. Ein Server kann jedoch nicht davon ausgehen, welche Sprache ein Client wünscht. Was ist, wenn dieser Client ein Proxy ist, der diese Sprache für einen anderen Benutzer bereitstellt? Was ist, wenn zwischen Client und Server eine Caching-Ebene besteht? Wie soll ein Server "nur herausfinden", welche Sprache für eine beliebige Anfrage verwendet werden soll?

Der Versuch, diese Fragen zu beantworten, ist kompliziert. Erfordern Sie stattdessen, dass die Anforderungen selbsterklärend sind und den Standardheader verwenden, damit die Kunden die gewünschte Sprache aushandeln können . Das nennt man Inhaltsverhandlung. Der Accept-LanguageHeader ist eine Form der proaktiven Inhaltsaushandlung, bei der ein Client einem Server die Einstellungen mitteilt und der Server anhand dieser Einstellungen entscheidet, mit welchen Einstellungen er reagiert. Bei der reaktiven Inhaltsverhandlung sendet ein Client eine Anfrage an den Server, in der er fragt, welche Art von Inhalt vorhanden ist, erhält normalerweise eine Antwort mit einer Liste von Links und wählt dann den gewünschten Link aus, indem er einen Link auswählt, dem er folgt.

Ich würde auf der Serverseite so viel wie möglich sagen, wenn Sie mehrere Geräte unterstützen möchten.

Jedes Gerät verwendet natürlich einige Übersetzungen für sich, aber freigegebene Inhalte, da Fehlermeldungen von der API usw. unabhängig von den Geräten gleich sind.

Es ist eine Frage des persönlichen Geschmacks, aber wenn Sie Dinge clientseitig tun, sparen Sie Serverlast (vorausgesetzt, statische oder zwischengespeicherte Wörterbücher) und können sprachunabhängige Tools zum Testen des Dienstes verwenden.