Frameworks / librairies JavaScript I18n (internationalisation) pour une utilisation côté client?

Question

Nous sommes en train de créer une application JavaScript avec backbone.js, et nous avons besoin de traduire ou, au moins, à l'appui de l'internationalisation (I18n) dans l'avenir.

J'ai regardé autour et a trouvé de nombreuses bibliothèques de l'aide; Certains sont assez simples où d'autres semblent trop complexes. J'ai trouvé ces dans le passé quelques heures:

• i18next.js
• jsperanto.js
• jed.js
• messageformat.js
• jquery.plugin i18n

Y at-il des blogs ou des sites qui permettent de comparer ces cadres? Je voudrais voir si d'autres ont déjà souligné les avantages ou les pièges sur l'un de ces bibliothèques.

Nous avons créé notre application module basé sur Require.js si si, il a le support de module, qui est certainement un plus.

Une autre condition serait définition des paramètres régionaux après l'initialisation, après nous extraire les données à partir d'un webservice. Nous ne pouvons pas stocker statique des fichiers JSON, sauf peut-être pour une langue par défaut, avec l'application. Les traductions proviennent d'une base de données et doivent être envoyées à l'application via un webservice, nous avons donc besoin de définir la localisation des données de façon dynamique au lieu de passer par des fichiers JSON. C'est pris en charge au moins en Jed et i18next et jsperanto, mais très probablement aussi dans d'autres. En tout cas, l'application ne doit jamais être bloqué à partir de l'exécution.

Je suis en demandant de l'aide décider de la bibliothèque qui vous convient le mieux.

---

Quelque chose que j'ai remarqué qui a déjà disparu dans Jed, est de fournir une élégante alternative lorsque la traduction n'est pas présent dans la langue du dictionnaire. Jed juste déclenche une erreur, quelque chose que je trouve dérangeant.

Je préfère une manière plus propre de la manipulation de traductions manquantes, soit de fournir une chaîne par défaut, l'impression de la touche à l'écran. En outre, mais certainement pas nécessaire, on pourrait avoir la fonction comme i18next a, de poster des traductions manquantes à un webservice. Si nous n'avons pas besoin de cela, c'est une fonctionnalité intéressante.

Answer 1

J'ai récemment eu à travers le dilemme est le même donc je vais d'abord vous donner quelques éléments supplémentaires à prendre en compte:

1. Tout le monde fait la traduction des messages, mais le faire correctement le pluriel est dur. Faites une liste des langues que vous attendez de soutien (y compris celles du futur) et de découvrir la complexité de votre pluralisation obtiendrez. Si vous êtes certain que vous ne le fera langues avec un pluriel, la plupart des bibliothèques va le faire.

2. Je suppose que vous avez de gros catalogues de messages, en plusieurs langues (si ce n'est pas le cas, alors bon i18n est pas pertinent, je pense à votre application). Ces catalogues, éventuellement, obtenir complexes et doivent être gérés par les traducteurs. La norme pour l'i18n est gettext (ici pour un résumé). Tous les outils pour gérer les traductions sont faites pour gettext. Ne s'attendent pas à ce que vos traducteurs vont gérer des fichiers json dans certains format obscur.

   Donc en bref: Vous aurez besoin de votre bibliothèque soit la charge .po ou .mo les fichiers générés sur le serveur, ou d'avoir un moyen facile de convertir ceux sur le serveur de la bibliothèque du format json. Qui restreint votre choix pour ceux qui ont les clés de traduction et de mécanismes similaires à gettext est msgid. Immédiatement expulsé pour moi i18next par exemple. Vérifier le reste.

3. Require.js ne doit pas influencer votre décision. Même si la bibliothèque n'est pas AMD compatible vous envelopper et aussi trouver un moyen de async-chargez votre catalogue de ressources.

Maintenant, si je devais choisir un de ceux que vous mentionnez, en fonction de l'exhaustivité, de la fonction de soutien de, la vitesse, la facilité d'utilisation, je n'aurais pas penser à tout. Il faudrait Jed. Au moment où j'ai fait mon choix Jed n'existe pas, et frustré, j'ai écrit une très minime (<100lines) et rapide .po/json chargeur/parser/message d'usine. J'ai toujours l'utiliser, il couvre mes petits besoins, mais pour quelque chose de plus grand, enfin, nous avons la bonne js i18n, et il Jed.

Mise à JOUR J'ai vu de mise à jour de votre question concernant les lacunes de Jed en ce qui concerne touches manquantes. Je présume que c'est parce que généralement avec gettext tout votre texte correspond à une clé dans le défaut de la langue. Alors généré .po/.mo des fichiers de traduction manque la traduction, il suffit de retourner le texte dans la langue par défaut.

Answer 2

La nécessité pour l'I18n, c'est aussi souvent des clients à partir d'emplacements distants avec une bande passante faible temps de latence, etc. Par conséquent, dans ce contexte, il est utile d'avoir un regard pointu sur le nombre et la taille de vos demandes pour conserver des temps de chargement supportable. Il suffit que l'utilisateur s'attend à lire des textes dans sa langue donc, à partir de son point de vue, certains I18n de bibliothèque n'a pas d'apporter toutes les fonctionnalités de l'application - c'est juste un composant qui gonfle le système et les délais de chargement des pages. Cette considérations ont conduit à ce petit exemple qui couvre les exigences de base en matière de localisation des applications web. Il a seulement besoin de jQuery - rien d'autre:

J42R Application Démo

Caractéristiques:

• travaille dans statiquement ou dynamiquement le contenu créé par l'
• basculer entre les différentes langues sans avoir à recharger la page
• charge ressources de la langue, à la demande ou de la précharge toutes les ressources à la page de chargement
• définir la langue en javascript, cookies, url paramètre ou les paramètres du navigateur
• JSON regroupements de ressources
• il y a aussi un bon Éditeur/Traducteur pour la création d'objets de ressource
• affiche les touches lorsque la traduction n'est pas présent
• assez petite (regardez le source de la page)

Créer des fichiers JSON pour chaque langue: ./I18N/<LANGUAGE_CODE> (j'.E. ./I18N/fr):

{
    "path": {
        "to": {
            "message": "this is the message!"
        }
    }
}

Dans votre code HTML à ajouter une classe I18N pour chaque texte seul élément que vous souhaitez traduire:

<span class="I18N">path.to.message</span>

enfin démarrer le traducteur:

<script>J42R.t()</script>

Il permettra de:

• détecter la langue
• charger le fichier de ressources
• remplacer vos clés

Il ne gère pas les choses comme la pluralisation, numéro de la traduction, de la date de mise en forme, etc. Vous pouvez envisager d'utiliser des symboles à la place de la langue dans certains cas, comme

✉(2)

au lieu de

"Vous avez deux nouveaux messages!"

De la même manière à l'aide d'un uniforme international de format de date comme le Standard ISO à la place des dizaines de variantes locales, vous pourriez économiser beaucoup d'ennuis.

Answer 3

Vous pouvez aussi essayer le fichier jquery.i18n de Wikimedia (sans rapport avec le fichier jquery-i18n de Dave Perrett): https://github.com/wikimedia/jquery.i18n

En plus du remplacement de paramètres et des formes multiples plurielles, il prend en charge le genre, une caractéristique plutôt unique des règles de grammaire personnalisées dont certaines langues ont besoin. C'est essentiellement une version du code qui rend Wikipédia internationalisé, mais sans aucune dépendance sauf jQuery.

Answer 4

Il y a maintenant aussi un plugin i18n pour require.js lui-même: https://github.com/requirejs/i18n Je l'ai utilisé avec grand succès. Assurez-vous de consulter la documentation.

Fondamentalement, ce que vous devez faire est d'ajouter à i18n require.js config (coffeescript)

require.config
  config:
    i18n:
      locale: "en"

  paths:
    text: "lib/requirejs/text/2.0.3"
    i18n: "lib/requirejs/i18n/2.0.1"

Puis, quelque part dans votre projet, vous avez un nls le dossier, l'intérieur est votre Locales.coffee le fichier.

define
  "root":
    "topmenu":
      "load": "Load"
      "save": "Save"
      # ...


  # activate additional languages here   
  "de": true

et vous créez un sous-dossier pour chaque langue, par exemple, de et à l'intérieur de chaque dossier est un autre Locales.coffee mais maintenant, sans la root élément:

# de
define
  "topmenu":
    "load": "Laden"
    "save": "Speichern"

Ensuite, vous chargez les paramètres régionaux par require.js comme ceci

Locales = require "i18n!./nls/Locales"

et de les transmettre à votre modèle de vue:

@$el.html @template
  locales: Locales

et à l'intérieur de votre modèle, vous pouvez utiliser:

<li><span class="text">{{locales.topmenu.load}}</span></li>
<li><span class="text">{{locales.topmenu.save}}</span></li>

Dans l'ensemble assez facile et vous pouvez simplement ajouter de nouvelles langues par la traduction de la racine de votre les Habitants de fichier. Espérons que cela aide.

Answer 5

Voulais juste mentionner que nous travaillons sur un sujet similaire, l'internationalisation de la côté client framework MVC, et sont à l'aide de Dust.js notre moteur de template. Notre plan est ceci:

1. Utilisation RequireJS pour définir nos traductions
2. Écrire une coutume de la Poussière de la méthode d'assistance pour les traductions (par exemple appelé " translate()')
3. Mélanger cette méthode dans notre classe de base pour les modèles et vues
4. require() le dictionnaire dans les classes de base

Puisque chaque modèle dans notre colonne vertébrale du projet sera à l'aide d'un modèle (ou peut-être un point de vue), en contexte, il devrait avoir de la Poussière à l'aide, et des traductions disponibles.

J'ai volé l'idée à partir de ce LinkedIn blog en Laissant des pages Jsp dans la poussière: déplacement à LinkedIn dust.js côté client, les modèles, et je suis en train de regarder le LinkedIn github repos pour voir si ils finissent par écrit quelque chose de similaire: LinkedIn/poussière-aides

Pas vraiment sûr de savoir comment ça va fonctionner, mais il semble plus propre depuis que nous venions de profit existants nécessitent poussière/libs.