Discussion :

[pada51]

Bonjour je suis actuellement sur le developpement d'un site en ROR. Ce site sera traduit dans 5 langues, j'ai donc regarde du cote des solutions apportees par certains plugins ROR mais je me noie un peu sous la masse d'information ... auriez vous quelques conseils ? quels plugins utilisez-vous ? pourquoi ?

[SekYo]

Perso j'utilise un plugin français, Globalite, qui utilise des fichiers de traductions YAML (donc ultra simple à éditer), après avoir testé Globalize (gros gros plugin de localisation).

J'ai changé parce que le gros, gros problème de Globalize, c'est qu'il génère grosso modo 1 requete SQL par String à traduire, vu qu'il stocke tout en base de données. Alors quand t'as des pages assez statiques, ne dépendant pas de l'utilisateur connecté, tu peux jouer avec le cache, mais sinon le nombre de requete SQL par page grimpe très, très vite et ça commence à être assez génant. D'autant plus que ça implique soit d'utiliser un truc genre phpMyAdmin ou une UI faites maison pour traduire les strings, c'est pas forcément trop pratique.

Bref j'suis passé à Globalite, qui est largement suffisant pour l'usage que j'en fais, très facile à configurer/personnaliser et qui permet d'ajouter/changer des trads avec un simple notepad.

[pada51]

merci beaucoup pour la reponse mais enormement du contenu a traduire devra etre gere via un back-office (pour pouvoir ajouter facilement certains textes) ... et le travail serait largement facilite par des basses de donnees, j'ai peur que des solutions comme globalite (ou gettext) me pose certains problemes (si je veux ajouter un texte, qui devra etre traduit, je ne veux pas aller le faire via un fichier mais directement sur une interface connecte a la bdd) ....
apres tu me poses un autre probleme .... je ne peux pas me permettre de rajouter de multiples requetes sur chaque page rien que pour la traduction ... peut-on se debrouiller avec le cache, ou devrais-je me contenter des fichiers ???


merci d'avance

[SekYo]

Tu vas pouvoir te dépatouiller avec le cache SI tes pages ne dépendent pas trop de QUI les visite en gros. Si par exemple t'as un bloc qui t'affiche les 5 dernières news de ton site, c'est trivial à mettre en cache en fonction de la langue. Par contre, si pour ce même bloc, le contenu change en fonction des users (par exemple parce que certains ne sont interessés que par les news technologiques, d'autres que par les news financières, d'autres par les 2 mais pas le sport etc... ) là ton gain via le cache sera beaucoup, beaucoup plus limité.

Je rebondi juste sur ta remarque concernant la facilité de gestion via un back-office, c'est vrai que c'est légérèrement plus simple avec Globalize, vu que pour accéder à la DB tu fais ça très bien en Rails. Mais avec Globalite par exemple, tu utilises des fichiers YAML, qui sont également très bien supportés par Ruby. Donc c'est pas totalement impossible de créer a la mano une petite interface web pour charger et éditer ces fichiers YAML (même si je t'accorde que c'est un peu plus long que d'aller taper en base).

Edit : L'autre grosse distinction quand même, c'est que Globalite ne traduit pas le contenu des models, il te faut gérer ça à la main (par exemple en ajoutant un champ "language" à tes models susceptibles d'être traduit)

[titoumimi]

attention tout de même, quand on traduit les modèles "automatiquement" avec globalize, on perds énormément de choses d'un point de vue ActiveRecord.. et ça devient très gênant...

[SekYo]

Ouaip, c'est pour ça qu'ils ont ajouté récemment à Globalize une feature permettant de stocker les champs traduits des models dans la table d'origine, en faisant a la mano des champs content_LANGUAGE ( genre news_fr, news_en etc... ) et Globalize allant chercher tout seul la bonne traduction.

M'enfin ca réduit sacrément l'aspect automatique de la chose ( mais ca permet de réuitiliser les trucs de AR )

[pada51]

Merci beaucoup pour ces reponses, je me penche donc sur globalite :-)