Internationalisation : utilité et limite.

[Sephi-Chan]

Arf, c'est pas top d'avoir des chaînes comme ça dans tes modèles.
Et c'est exactement ce à quoi je faisais référence en disant qu'avec un bon framework, c'est plus facile d'utiliser l'i18n que de ne pas l'utiliser.

Exemple d'une classe User avec des validations basiques (le nom doit comprendre 3 à 20 caractères alphabétiques).

class User < ActiveRecord::Base

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

end

Ici, si j'envoie un formulaire construit autour d'un objet @user (de la classe User), l'attribut @user.errors contiendra un objet ActiveModel::Errors avec plein de méthodes pratiques. Cet objet contient un hash qui associe à chaque attribut ses erreurs de validation sous forme d'un tableau de symboles, du style [ :invalid, :too_short ].

Ça rend la chose triviale à internationaliser. Alors que si j'avais voulu fournir les messages, j'aurais écrit :

class User < ActiveRecord::Base

  validates_length_of :name, within: 3..20,

                      too_long: "Le nom ne doit pas dépasser %{count} caractères.",

                      too_short: "Le nom doit comprendre au moins %{count} caractères."



  validates_format_of :name, with: /^[a-z]+$/i,

                      message: "Le nom n'est pas valide."

end

Tu imagines à quel point ça serait pénible ?

Et ce n'est qu'un infime bout ! Jette un œil au fichier français, qui contient les traductions de tous les helpers fournis de base dans Rails. Et comme tu peux le voir, il y a la même chose pour un bon paquet de langues.

Car en plus des erreurs, il y a les formates de date et d'heures, les devises, les séparateurs de nombres, les indications type "il y a environ 5 minutes", etc.


Désolé à tous ceux qui n'utilisent pas de frameworks (ou un nul), mais vous êtes vraiment dans la merde pour ce genre de choses et pour des tas d'autres. Plus vite vous comprendrez ça, mieux ça vaudra pour vous, vos projets et vos compétences.