Comment structurez-vous les fichiers YAML i18n dans Rails?

Question

J'ai commencé le remplissage d'un fr fichier yaml dans les Rails et je peux déjà dire qu'il va déraper et de la main avant trop longtemps. Est-il une convention pour conserver ce fichier est-il organisé?

Pour l'instant j'ai cette structure:

language:
  resource:
    pages: # index, show, new, edit
      page html elements: # h1, title
  activerecord:
    attributes:
      model:
        property:

Maintenant, j'ai les choses suivantes que je veux pour s'intégrer dans cette structure, mais je n'en suis pas sûr comment:

1. La Navigation
2. Texte du bouton (enregistrer les modifications, créer un compte, etc)
3. Les messages d'erreur du contrôleur de flash
4. Comment ajouter multi-mot-clés. Dois-je utiliser un espace ou un trait de soulignement? Pour exemple, t(".update button")) ou t(".update_button")

Est-il une convention locale de la structure du fichier?

Answer 1

J'ai trouvé que la meilleure stratégie consiste à reproduire un peu la structure du fichier de sorte que, compte tenu de toute traduction, je peux immédiatement trouver l'endroit où il a été appelé à partir. Cela me donne une sorte de contexte pour faire la traduction.

La majorité de la demande de traductions sont trouvés dans les points de vue, donc, mon plus haut niveau de l'espace de noms est habituellement views.

- Je créer des sous espaces de noms pour le contrôleur nom et le nom de l'action ou partielle être utilisés ex :

• views.users.index.title
• views.articles._sidebar.header

Ces deux exemples devraient à l'évidence qu'une partie de mon application, nous sommes la traduction et le fichier à regarder dans pour trouver.

Vous mentionnez la navigation et les boutons, s'ils sont génériques, alors qu'ils appartiennent à l' views.application espace de noms que leur vue homologues :

• views.application._main_nav.links.about_us - un lien dans notre application principale de navigation partielle
• views.application.buttons.save
• views.application.buttons.create - J'ai un tas de ces boutons prêt à être utilisé en cas de besoin

Les messages Flash sont générés à partir du contrôleur, de sorte que leur haut niveau de l'espace de noms est... controllers! :)

Nous appliquons la même logique que nous faisons de vues :

• controllers.users.create.flash.success|alert|notice

De nouveau, si vous vouliez génériques flash des messages comme "Opération réussie", vous devez écrire quelque chose comme ceci :

• controllers.application.create.flash.notice

Enfin, les touches peuvent être ce qui est valable YAML, mais s'il vous plaît tenir à l'utilisation de périodes d' . des séparateurs et des traits de soulignement _ entre les mots comme une question de convention.

La seule chose qui reste à trier maintenant, est en train de rails pour les traductions, dans son propre espace de noms pour nettoyer notre haut niveau :)

Answer 2

Je sais que la réponse a déjà été acceptée, mais cette question m'a fourni de la nourriture pour la pensée, et j'ai pensé que je devais partager une autre structure pour les Rails i18n yml fichiers pour votre examen et à la critique.

Étant donné que je tiens à

1. conservez la valeur par défaut d'application de la structure si je peux utiliser le raccourci "paresseux" recherches comme t('.some_translation') de mon point de vue,
2. éviter autant chaîne de répétitions que possible, en particulier avec des mots qui ne sont pas les mêmes, mais aussi qui ont les mêmes contextes et les significations,
3. suffit de modifier une clé une fois pour qu'il reflète partout où il est référencé,

pour une config/locales/fr.yml fichier qui ressemble à quelque chose comme ceci:

activerecord:
  attributes:
    user:
      email: Email
      name: Name
      password: Password
      password_confirmation: Confirmation
  models:
    user: User
users:
  fields:
    email: Email
    name: Name
    password: Password
    confirmation: Confirmation
sessions:
  new:
    email: Email
    password: Password

Je peux voir qu'il est important de répétition, et que le contexte des mots comme "e-Mail" et "Mot de passe" sont sans ambiguïté et ont le même sens dans leurs vues respectives. Il serait un peu ennuyeux d'avoir à aller changer tous si je décide de changer de "Courriel" pour "e-mail", donc j'aimerais refactoriser les cordes pour faire référence à un dictionnaire de la sorte. Alors, que diriez-vous d'un dictionnaire de hachage pour le haut du fichier avec quelques & ancres comme ceci:

dictionary:
  email: &email Email
  name: &name Name
  password: &password Password
  confirmation: &confirmation Confirmation

activerecord:
  attributes:
    user:
      email: *email
      name: *name
      password: *password
      password_confirmation: *confirmation
  models:
    user: User
users:
  fields:  
    email: *email
    name: *name
    password: *password
    confirmation: *confirmation
sessions:
  new:
    email: *email
    password: *password

Chaque fois que vous obtenez plus d'une instance de exactement le même mot/phrase dans vos vues, vous pouvez refactoriser le dictionnaire. Si le dictionnaire de traduction d'une clé dans la base de la langue n'a pas de sens dans la langue cible, alors il suffit de changer la valeur de référence dans la langue cible pour une chaîne statique ou d'ajouter une entrée supplémentaire vers la langue cible du dictionnaire. Je suis sûr que chaque langue du dictionnaire peut être reconstruit dans un autre fichier si elles deviennent trop grandes et lourdes.

Cette façon de structurer i18n les fichiers yaml semble bien fonctionner avec certains locaux, test d'applications, j'ai essayé sur. J'espère que la merveilleuse Localeapp fournira un appui à ce type d'ancrage/référencement dans l'avenir. Mais de toute façon, tous ce dictionnaire parler ne peut pas être une idée originale, donc il y a des problèmes avec l'ancre de référencement en YAML, ou peut-être juste avec tout le "dictionnaire" concept en général? Ou est-il plus juste d'arracher le backend par défaut entièrement et de le remplacer avec Redis ou quelque chose?

Answer 3

Votre question n'est pas facile de répondre, et il n'y a pas beaucoup de matériel disponible sur ce sujet. J'ai trouvé la meilleure des ressources sont les suivants:

• Rails Styleguide, la section de l'Internationalisation
• Il y a beaucoup de ressources dans l' I18n wiki, mais je n'ai pas trouvé il y a certains qui répondent à vos questions.

Je vais donc essayer directement ici:

• La Navigation

  Je pense que tu veux dire ici les éléments de navigation comme les chemins de navigation, onglets, ... Vous devez définir des vues pour eux, et s'en tenir ensuite à la règle pour déplacer tous affichage des éléments dans des dossiers séparés dans le répertoire views (voir le styleguide de la règle).

• Texte du bouton (enregistrer les modifications, créer un compte, etc)

  Affichage des éléments, d'aller dans le même dossier. Si vous utilisez les mêmes boutons dans les différents points de vue, de définir un fichier commun, et de l'utiliser ensuite.

• Les messages d'erreur du contrôleur de flash

  Je voudrais utiliser la même règle que pour les vues. Définir un répertoire distinct, inclure les fichiers pour les contrôleurs.

• Comment ajouter multi-mot-clés. Dois-je utiliser un espace ou un trait de soulignement? Pour exemple, t(".bouton de mise à jour")) ou t(".update_button")

  Personnellement, je préfère utiliser .update_button, pas .update button, parce qu'il est plus explicite que c'est une des clés.

Answer 4

La modification directe des fichiers yaml conduit à des fichiers en désordre et illisibles.
De plus, il vous sera difficile de fournir un accès aux traducteurs si, un jour, vous souhaitez qu'un non-développeur ajoute un nouveau langage.

Je recommanderais d'utiliser localeapp , qui génère un seul fichier yaml.
Mais vous permet de voir et de gérer facilement vos traductions dans une interface Web.
Et pour créer un accès supplémentaire aux traducteurs.