Internationalisation : utilité et limite.

[Sephi-Chan]

Rassure toi, mon dernier paragraphe ne t'était pas spécifiquement destiné. ^^

En fait le système d'erreur est très souple. Admettons que j'ajoute une validation custom qui vérifie qu'une date n'est pas dans le future (ce contrôle n'est pas fournie par Rails) :

class User < ActiveRecord::Base

  validates :name, length: 3..20, format: /^[a-z]+$/i

  validate :birthday_is_not_in_future





  def birthday_is_not_in_future

    errors[:birthday] = :date_in_future if birthday.future?

  end

end

Et dans le fichier de traduction :

fr:

  activerecord:

    errors:

      models:

        user:

          attributes:

            birthday:

              date_in_future: "La date de naissance doit être passée."

      messages:

        date_in_future: "La date indiquée doit être passée."

Là j'ajoute un message d'erreur générique pour toutes les erreurs de type date_in_future, et j'en spécifie un plus spécifique pour l'anniversaire des utilisateurs. Automatiquement, le mécanisme d'i18n de Rails prendra la traduction la plus spécifique.

Puissant. Sans les mains.


Voilà pourquoi c'est bien d'utiliser l'i18n quand on le peut facilement, même si comme tu le dis on ne prévoit pas forcément d'ajouter plus langues.

Si c'est pénible à faire (et n'oublions pas qu'on n'a parlé queddu contenu statique), c'est inutile de s'embêter. Il y a de forte chances que ce soit péter plus haut que son cul.