Comment structurer les fichiers i18n yaml dans les Rails?

je sais qu'une réponse a déjà été acceptée, mais cette question m'a donné matière à réflexion et j'ai pensé que je partagerais une autre structure pour les fichiers Rails i18n yml pour votre considération/critique.

étant donné que je voudrais

1. conserver la structure par défaut de l'application pour que je puisse utiliser des Lookup "paresseux" comme t('.some_translation') dans mes vues,
2. éviter autant de répétition de chaîne que possible, en en particulier avec des mots qui ne sont pas seulement identiques, mais qui ont aussi des contextes/significations identiques,
3. il suffit de changer une clé une seule fois pour qu'elle se reflète partout où elle est référencée,

pour un 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 y a une répétition significative, et que le contexte des mots comme "Email" 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'ajouter un hachage de dictionnaire en 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 d'exactement le même mot/phrase dans vos vues, vous pouvez le reformuler à dictionnaire. Si la traduction du dictionnaire d'une clé dans la langue de base n'a pas de sens pour une langue cible, alors il suffit de changer la valeur référencée dans la langue cible en une chaîne statique ou de l'ajouter comme entrée supplémentaire au dictionnaire de la langue cible. Je suis sûr que le dictionnaire de chaque langue pourrait être refactorisé dans un autre fichier s'ils deviennent trop gros et lourds.

cette façon de structurer les fichiers i18n yaml semble bien fonctionner avec certaines applications de test locales. essayé sur. J'espère que le merveilleux Localeapp fournira un soutien pour ce genre d'ancrage / référencement à l'avenir. Mais quoi qu'il en soit, tous ces dictionnaires ne peuvent pas être une idée originale, alors y a-t-il d'autres problèmes avec le référencement d'ancre dans YAML, ou peut-être juste avec le concept de "dictionnaire" en général? Ou est-ce qu'il est juste préférable de simplement enlever l'arrière-plan par défaut et le remplacer par Redis ou quelque chose comme ça?

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é les meilleures ressources sont:

• Rail Styleguide , section internationalisation
• il y a beaucoup de ressources dans le i18n wiki , mais je n'en ai pas trouvé qui répondent à vos questions.

donc je vais essayer directement ici:

• Navigation

  je pense que vous voulez dire ici les éléments de navigation comme breadcrumbs, tabs,... Vous devez définir des vues pour eux, et coller ensuite à la règle pour déplacer tous les éléments de vue dans des fichiers séparés dans le répertoire views (voir le styleguide pour la règle).

• texte du bouton (Enregistrer les modifications, créer un compte, etc.)

  éléments de vue, aller dans la même les fichiers ainsi. Si vous utilisez les mêmes boutons dans des vues différentes, définissez un fichier commun, et utilisez-le alors.

• messages D'erreur du contrôleur flash

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

• comment ajouter des touches Multi-mots. Est-ce que j'utilise un espace ou un underscore? Pour exemple, t(".bouton de mise à jour")) ou t(".update_button")

  personnellement, je préférerais utiliser .update_button , pas .update button , parce que cela rend plus explicite qu'il s'agit d'une clé.

il y a presque deux ans que j'ai posé cette question, et je veux partager quelques idées. Je pense que la structure optimale est de traduire l'espace de noms en fonction de leur rôle MVC (modèles, vues, contrôleurs). Cela maintient le fichier de localisation ordonné, et prévient les collisions d'espaces de noms (par exemple, le scope en.users peut représenter une vue ou un contrôleur).

en:
  controllers:
    users:
      show:
        welcome_flash: "Welcome back!"
  mailers:
    users_mailer:
      welcome_email:
        subject: "Good of you to join us"
  views:
    users:
      show:
        notice: "Oh no!

mais en utilisant des espaces-noms bien rangés comme cela casse la fonction de recherche paresseuse dans les Rails. Si vous utilisez paresseux lookup, les Rails inséreront automatiquement l'espace de noms pour vous, et il n'inclura pas les espaces de noms de haut niveau que vous avez créés ( views , controllers , etc...).

par exemple, le champ d'application de t('.welcome_flash') se réduit à en.users.show . Ce qui est nul parce que les utilisateurs ne sont pas clairement définis. Quel est-il? Un contrôleur? Une vue? Quelque chose d'autre?

Pour résoudre ce problème j'ai créé le gem I18nLazyLookup . Il vous permet d'utiliser paresseux recherche avec vos propres espaces de noms.

au lieu d'utiliser t , vous pouvez utiliser t_scoped('welcome_flash') , ce qui résoudrait automatiquement le champ d'application à en.controllers.users.show . Il fonctionne également pour les vues et les mailers, et vous pouvez personnaliser l'espace de noms comme vous le souhaitez.

éditer directement les fichiers yaml conduit à des fichiers désordonnés et illisibles.

De plus, il vous sera difficile de fournir l'accès aux traducteurs si, un jour, vous voulez qu'un non-développeur ajoute un nouveau langage.

je recommande d'utiliser localeapp , qui génère un seul fichier yaml.

Mais vous permet de voir et de gérer vos traductions dans une interface web.

Et créer un accès supplémentaire aux traducteurs.

plusieurs années après la bataille, mais voici une réponse (un peu totalement) différente.

pour commencer, je n'aime pas le style standard t('.xxx') avec l'espace de noms par défaut basé sur la structure du fichier. Je n'aime pas non plus la catégorisation des traductions en fonction de la structure DOM. Bien qu'il s'agisse d'une bonne approche pour des traductions très structurées, elle est souvent répétitive, et pas très intuitive.

je préférerais me regrouper mes traductions dans des catégories plus utiles, pour faciliter la tâche de mes traducteurs, car ils peuvent travailler sur des thèmes concrets, plutôt que sur des styles bizarres (certains traducteurs ne savent même pas ce que MVC signifie)

donc mon fichier de traduction est structuré comme ceci

fr:
  theme1:
    theme11:
      translationxxx: blabla
  theme2:
    translationyyy: blabla

Selon les besoins, les "thèmes" peut être un modèle, un plus abstrait, contexte, etc. c'est le plus intuitif pour les traducteurs.

parce que ce ce serait compliqué d'écrire à chaque fois le scope dans mes vues, j'ai ajouté quelques méthodes pratiques dans Mes helpers pour avoir un contexte de traduction basé sur une pile.

• je push/pop traduction étendues sur une pile de mon point de vue en appelant t_scope([new_scope] et pop_t
• je remplace les t aide pour l'utilisation de la dernière portée de la pile

le code pour les méthodes de détermination de la portée de la traduction est disponible en que répondre à