Internationalisation : utilité et limite.

[Holy]

Suite à une discussion sur les aspects techniques de l'internationalisation. J'ai émis une remarque générale sur l'utilité de celle-ci pour des projets de petite ampleur comme la majorité d'entre nous en conçoit.

En effet, le sujet de l'internationalisation de nos jeux respectifs est souvent mis sur la table. Parfois même, certains créateurs disent vouloir proposer leur jeu en plusieurs langues avant même que celui-ci ait été lancé et éprouvé par une communauté de joueurs.

Selon moi, l'internationalisation nécessite des moyens humains conséquents (modérateurs, traducteurs, ...) que la majorité d'entre nous n'a pas. Cet aspect de l'internationalisation est très peu relevé dans nos discussions alors qu'il me semble plus essentiel encore que la dimension purement technique de celle-ci. Des structures professionnelles comme Motion Twin ont mis un certain temps à s'internationaliser et ce de manière plus que progressive.

Alors je pose la question de manière très franche : n'est-ce pas une chimère que de parler d'internationalisation ?

Autre aspect intéressant à aborder : quel bénéfice réel en tirer (Agrandir sa communauté ? Rentabiliser son jeu ? ... ?), quelle difficulté peut-on affronter (Maintenabilité ? ... ?) ?

[Sephi-Chan]

Pour quelqu'un qui utilise un framework qui supporte l'internationalisation, je conseille de s'en servir systématiquement.

Pour quelqu'un qui n'utilise pas ce type d'outil, je le déconseille. Si le site doit vraiment avoir une portée mondiale, il devrait être crée avec des outils appropriés (dont le développement from scratch ne fait pas partie).


En ce qui me concerne, j'utilise Ruby on Rails, qui supporte l'internationalisation. Avec ce framework, c'est souvent plus simple d'utiliser ces mécanismes que de ne pas le faire, notamment en ce qui concerne les messages d'erreurs des formulaires, le formatage des dates, etc.

Ensuite, les bénéfices sont conséquents si le projet marche puisqu'on peut augmenter son audience sans même avoir à revenir sur le code.

[php_addict]

mon avis est qui faille mieux prevoir avant de se dire "c'est bon je vais traduire le site"

et il est tout a fait possible à mon sens de le faire sans framework, par exemple mon pseudo modele MVC permettra très certainement de faire une internationalisation sans trop de difficultés car tout ce qui est à afficher se trouvent dans les vues. Si les couches sont suffisamment séparée ca passe...

après effectivement cela demande des moyens humains conséquents, cela est certain.

Nous comprenons tous à peu près l'anglais donc à maintenir cela peut être jouable, il faut juste une bonne âme pour traduire les textes...après un forum en anglais cela peut très bien se passer

par contre pour ce qui est des autres langues effectivement il faut une équipe de modérateurs/traducteurs...la plupart des jeux ont des modos non rémunérés et bénévoles, car supposons que sur un jeu il y ai ne serait ce que 3000 joueurs il y aurait forcement quelqu'un qui touche sa bille en anglais (prof d'anglais par exemple, ou bilingue)

donc faire un site avec une version française et anglaise me parait à la portée de nos petits jeux amateurs...

PS: si le jeu est du type "co-opération" cela veut dire un serveur de jeu par langue pour que les joueurs francais ne tombent pas en face de joueurs danois...

[Hideaki]

Du même avis que Sephi et j'ajoute, pour une portée mondiale, il est tout de même préférable de commencer directement à le prendre en compte avant même la programmation, migrer au fur et à mesure un jeu, prend d'avantage de temps, la recherche du petit mot perdu, peut être vraiment chiant
Pour une portée purement francophone, la mise en mise en place de cette solution est inutile.

[Holy]

Pour une portée purement francophone, la mise en mise en place de cette solution est inutile.

Au vu de ce que disait Sephi, je trouve quand même une belle utilité : ajouter une quatrième couche (parallèle aux vues) qui permet d'externaliser tout ce qui touche au texte. Tu as toujours du texte dans tes modèles, comme les messages d'erreurs, les messages de succès ou autres (après une redirection par exemple).

Je pense que l'utilisation d'un système d'externalisation des composantes textuelles permet de maintenir plus facilement l'application en général, même quand il n'y a qu'une langue.

[php_addict]

Tu as toujours du texte dans tes modèles, comme les messages d'erreurs, les messages de succès ou autres (après une redirection par exemple)

les modeles doivent renvoyer des codes d erreur et non pas des textes...apres les codes d'erreur sont traités dans les vues...

[Holy]

Tu as toujours du texte dans tes modèles, comme les messages d'erreurs, les messages de succès ou autres (après une redirection par exemple)

les modeles doivent renvoyer des codes d erreur et non pas des textes...apres les codes d'erreur sont traités dans les vues...

En sortie de modèle, j'ai un tableau $error qui renvoie le code et le texte associés à l'erreur. Ça n'a que peu d'intérêt de gérer ces deux choses là séparément selon moi (sauf à vouloir dupliquer son code pour le plaisir), surtout si tu gères ta vue via un moteur de template un peu complexe où l'affichage des erreurs est automatisé (les erreurs sont associées à des "champs" des formulaires généralement).

Bête exemple, dans ma vue, je peux avoir ceci :

<input id="text" />

Et dans mon modèle, ceci :

if(mb_strlen($sText) < 20) {

  $error['text'] = 'Votre texte est trop court.';

}

Je renvoie le tableau erreur et ma vue affiche automatiquement en-dessous de mon champ "text", le message d'erreur si il existe. J'ai le même type de développement avec les messages de succès.

[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.

[Holy]

Deux premières choses :
- J'utilise un framework. Certes pas totalement complet vu qu'il est en pleine construction (je lui adjoins régulièrement des modules).
- La gestion d'ActiveRecords est intéressante, j'avais déjà pensé à faire un système similaire. Mais ça n'a plus directement attrait à l'internationalisation

Sinon, l'exemple que j'ai donné est trivial, mais tu peux avoir des erreurs plus complexes que ActiveRecords ne gère pas comme tu l'as bien dit. Là où je suis totalement d'accord, c'est que l'internationalisation permet de sortir ce genre de textes des modèles (cf. mon deuxième message), c'est précisément ce que je trouve intéressant même pour des sites unilingues.

[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.