Discussion :

[SekYo]

Plop,

J'ai actuellement commencé à implémenter l'internationalisation de mon projet via le plugin Globalize. C'est très puissant, simple et rapide à utiliser.

Cependant, à chaque fois qu'il y a une string à traduire, ca génère une requête SQL. Ce qui fait qu'on arriver vite à un grand nombre de requêtes sur une page ( du type "SELECT * FROM globalize_translations WHERE (tr_key = 'Create' AND language_id = 1819 AND pluralization_index = 1 AND namespace IS NULL) AND ( (globalize_translations.`type` = 'ViewTranslation' ) ) LIMIT 1" ). Ainsi un peu plus un peu plus un peu...

Bref je voulais savoir si vous étiez plus partisan de l'approche Globalize, avec donc des traductions dans une base de données et un appel au "coup par coup" ou si vous etiez plus pour les fichiers de langue, qu'on charge entièrement en mémoire au début d'une requete http, ce qui évite un grand nombre de requetes.

[bolo]

j'utilise moi même Globalize mais également localisation. Et personnellement je n'utilise pas pour les traductions de stings a cause du problème que tu viens de citer
Je préfère localisation pour les strings, bon je réponds pas vraiment a ta question

[Taum]

Salut,

J'ai pas trop testé globalize mais est-ce qu'il ne devrait pas mettre ses données en cache une fois qu'il les a récuperé ?
Pour les requetes, tu as testé en environnement de dev ou de prod ? En développement ça peut paraitre logique qu'il refasse les requetes à chaque fois, mais je suppose qu'il est possible de mettre les résultats en cache une fois en production

[bolo]

Pour l'instant que en dev car mon application n'est pas terminée

[SekYo]

Toujours en dev, mais mes string dépendant souvent de l'user connecté, c'est pas possible de le mettre en cache, c'est ça qui m'embettait sacrément.

J'vais jeter un oeil du coté de Localization. Le truc c'est que si Localization charge tout en mémoire, si tu commences à avoir un paquet de string dans tin fichier, ca bouffe de la mémoire pour rien. Surtout que j'imagine si t'as 10 users connectés en même temps, même avec la même langue, y doit charger le fichier 10 fois non ? Ca doit commencer à bouffer de la RAM à force :/

[Taum]

Salut,

mes string dépendant souvent de l'user connecté

Désolé mais je ne vois pas trop ce que tu veux dire par là ? Comment un string peut-il dépendre de l'utilisateur connecté ?

même avec la même langue, y doit charger le fichier 10 fois non ?

Pareil, je vois pas bien ce que tu veux dire ici
Pour moi tout les utilisateurs utilisent le même serveur, donc logiquement la mémoire est partagée entre eux non ? Pourquoi la variable qui contient les traductions ne pourrait pas être commune entre chaque requête ?

[SekYo]

Bin typiquement parce que les string, hormis les messages d'erreurs de base, ça va être des trucs du genre "Vous avez X message(s) non lus". Où X va varier selon chaque user. Et d'ailleurs faut reconnaitre que la fonction pluriel de Globalize à ce niveau est assez sympa, ca évite de coder des trucs tout moche fait maison, ou au contraire de squizzer le problème et d'avoir des "vous avez 20 message(s)".


Je connais pas Localization, faut que j'aille voir, mais je suppose qu'en gros il va lire ( dans l'URL, une variable de session ou autre ) quelle langue il doit utiliser pour l'user, charger le fichier correspondant, faire l'action demandée, puis décharger la traduction.
Donc si t'as 2 users avec 2 langues différentes, t'as 2 fichiers chargés en même temps ( ca parait logique ).

La question que je me pose et là faut que je prenne le temps de regarder, si t'as 10 users avec la même langue, j'ai peur que le chargement des traductions fasse appel à un pré-filtre, ca veut dire que pour chacun de des users, il va charger le fichier, faire l'action puis décharger. Sauf s'il a trouver un moyen pour charger les fichiers dans une zone partagée par tous les users et qu'avant de charger un fichier il vérifie s'il est pas déjà en mémoire.
Mais comme je l'ai dit, faut que je regarde, j'en ai aucune idée.

( Bon après pour que la conso mémoire soit significative faut vraiment avoir des gros fichiers de langues et beaucoup d'users en simultanée, donc c'est peut être pas le coup de se prendre la tête m'enfin )

[Taum]

De ce que j'ai vu de globalize, pour traiter des traduction du type "Vous avez 20 message(s)", on défini une chaine à traduire du type "Vous avez %d message(s)" : je vois pas pourquoi cette dernière chaine ne pourrait pas être mise en cache pour tout les utilisateurs

charger le fichier correspondant, faire l'action demandée, puis décharger la traduction.

Comme je te disais précédemment je vois pas pourquoi il déchargerai la traduction à la fin de la requête

Donc si t'as 2 users avec 2 langues différentes, t'as 2 fichiers chargés en même temps ( ca parait logique ).

C'est inévitable quelque soit le système utilisé, l'interêt c'est plutôt de savoir si 200 users avec 2 langues différentes chargent 200 fichiers ou seulement 2


J'essayerais peut-être de faire quelques tests cet après midi pour éclaircir la question (du moins pour Globalize)

[Taum]

Bon je viens de faire un test et j'ai pas le comportement que vous décrivez

Voici ce que j'ai fait :

Une vue toute simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<%= "Hello".t %>

Une traduction pour "Hello" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Locale.set "fr"
Locale.set_translation("Hello", "Bonjour")

Je lance WEBrick et je regarde le fichier log/development.log.

Sur la première requete j'ai :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
Processing TestController#hello (for 192.168.1.4 at 2007-04-27 11:14:08) [GET]
  Session ID: b280ac592d8abe8d45d081ce0c329fb8
  Parameters: {"action"=>"hello", "controller"=>"test"}
  SQL (0.000458)   SET SQL_AUTO_IS_NULL=0
  Globalize::Language Columns (0.007111)   SHOW FIELDS FROM globalize_languages
  Globalize::Language Load (0.002250)   SELECT * FROM globalize_languages WHERE (globalize_languages.`iso_639_1` = 'fr') LIMIT 1
Rendering test/hello
  SQL (0.000329)   BEGIN
  Globalize::ViewTranslation Columns (0.004447)   SHOW FIELDS FROM globalize_translations
  Globalize::ViewTranslation Load (0.001777)   SELECT * FROM globalize_translations WHERE (tr_key = 'Hello' AND language_id = 1930 AND pluralization_index = 1 AND namespace IS NULL) AND ( (globalize_translations.`type` = 'ViewTranslation' ) ) LIMIT 1
  SQL (0.000589)   COMMIT
Completed in 0.08503 (11 reqs/sec) | Rendering: 0.01271 (14%) | DB: 0.01696 (19%) | 200 OK [http://amy/test/hello/]

Pour la deuxième :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Processing TestController#hello (for 192.168.1.4 at 2007-04-27 11:14:41) [GET]
  Session ID: 55c9448fe47a8427e41db2d5f81a93b5
  Parameters: {"action"=>"hello", "controller"=>"test"}
Rendering test/hello
Completed in 0.00697 (143 reqs/sec) | Rendering: 0.00166 (23%) | DB: 0.00000 (0%) | 200 OK [http://amy/test/hello/]

Comme je m'y attendais, il a bien mis la traduction en cache : toutes les requetes suivantes ne feront aucune requete dans la BDD. Même si la première requete est lente, toutes les autres ne devraient poser aucun problème (11 reqs/sec vs. 143 reqs/sec !)