Şu anda sunucumdaki birden çok REST web hizmeti ile iletişim kuran zengin bir JavaScript istemcisine dayanan yeni bir web uygulaması geliştiriyorum. Bu uygulamanın farklı dillere sahip en az iki ülkede kullanılması amaçlanmıştır, bu yüzden yerelleştirmemiz gerekir.
Sorum şu: Yerelleştirmeyi nerede yönetmeliyim: REST hizmetleri yerelleştirilmiş verilerle istek almalı ve cevap göndermeli mi yoksa istemci genel veriler alıp göndermeli ve ardından yerelleştirmeden sorumlu olmalı mı?
Yanıtlar:
Çevrilmiş dizeler yerine dize kimlikleri sağlarsanız REST API'nizin başkaları tarafından kullanımı daha kolay olacaktır. Geri dönen bir API kullanmak, bir "E_NOT_AUTHORIZED"insan dili ve hatta yerelleştirilmiş dize döndürmekten daha kolaydır.
Ayrıca, gelecekteki sürümlerde yerelleştirilmiş dizeleri değiştirmek isteyebilirsiniz, bu da bir API değişikliği anlamına gelir. Dize kimliği yaklaşımıyla, "E_NOT_AUTHORIZED"API'nızı uyumlu tutarak yine de geri dönersiniz .
Angular.js gibi bir çerçeve kullanırsanız, dize kimliği yaklaşımını kullanırsanız, sıcak geçiş dili uygulamak kolaydır. Başka bir dizgiyi yüklersiniz ve şablonlarınızda gibi bazı filtre mantığını kullandığınız için tüm dizeler dillerini otomatik olarak değiştirir {{errorStringID | loc}}.
Dikkat edilmesi gereken başka bir nokta: Sunucu yükünüzü azaltmak için arka ucunuzu olabildiğince basit tutun. Aynı sayıda sunucuyla daha fazla istemciye hizmet verebileceksiniz. Dizgi dosyalarınızı bir CDN aracılığıyla iletin ve yerelleştirmeyi ön uçta yapın.
İstemcilerin standart Accept-Languageüstbilgiyi isteklerde göndermesini sağlayın, ardından sunucuda yerelleştirin ve Content-Languageyanıtlara bir üstbilgi ekleyin . Ayrıntılar için RFC 7231 Bölüm 5.3.5'e bakın.
Sunucu tarafında yerelleştirme, istemcilerin yerelleştirme meta verilerini göndermekten daha az gidiş dönüş ve bant genişliği tüketimi ile sonuçlanır. Ancak bir sunucu bir istemcinin hangi dili istediğini kabul edemez, çünkü bu istemci başka birine hizmet eden bir proxy ise? İstemci ile sunucu arasında bir önbellek katmanı varsa ne olur? Bir sunucunun, keyfi bir istek için hangi dilin kullanılması gerektiğini nasıl "anlaması" gerekir?
Bu soruları cevaplamaya çalışmak karmaşıktır, bunun yerine taleplerin kendi tanımlayıcı olmasını isteyin ve standart başlığı kullanın, böylece müşteriler istedikleri dili müzakere edebilirler . Buna içerik pazarlığı denir. Accept-LanguageBaşlık şeklidir proaktif bir istemci 's tercihleri ne bir sunucu söyler içerik müzakere, daha sonra sunucu bu tercihlere dayalı olan yanıt verdiklerini ne karar verir. Reaktif içerik anlaşması, bir istemcinin sunucuya ne tür içerik olduğunu soran bir istek gönderdiği, tipik olarak bir bağlantı listesi içeren bir yanıt aldığı ve daha sonra takip etmek için bir bağlantı seçerek hangisinin istendiğini seçmesidir.
Birden fazla cihazı destekleyecekseniz, sunucu tarafında mümkün olduğunca çok şey söyleyebilirim.
Her cihaz elbette kendi çevirilerini kullanacaktır, ancak api'den gelen hata mesajları, cihazlar ne olursa olsun aynı olacaktır.
Bu çok kişisel bir zevk meselesidir, ancak istemci tarafında bir şeyler yaparsanız, sunucu yükünden tasarruf edersiniz (statik veya önbelleğe alınmış sözlükler varsayarak) ve hizmeti test etmek için dil agnostik araçlarını kullanabilirsiniz.