Comment gérer le process de localisation?

Version imprimable

19/11/2010, 11h27
joseph_p

Comment gérer le process de localisation?

bonjour

Nous avons au boulot un problème récurrent: comment gérer la localisation de l'application.

En effet, actuellement, le product owner s'occupe de la partie traduction (soit lui même soit en déléguant). Pour se faire, il check out le projet concerné et met à jour directement les fichiers properties.

Toutefois, cela a de nombreux désavantages, notamment;
- cela implique que le projet en question "build" correctement sur sa machine, ce qui n'est pas toujours aisé
- utilisation d'eclipse par le PO => son poste n'est pas autant une foudre de guerre que le notre, problématique des mises à jour d'eclipse, problématique du besoin de rafraichissement manuel des fichiers modifiés hors d'eclipse

bref, tout cela n'est pas optimal. Toutefois, et malgré des tentatives d'améliorations de ci ce là, nous n'avons pas trouvé de processus "propre" pour résoudre ce problème.

Aussi, la question est la suivante: comment faites vous ? Etes vous satisfaits ? Avez vous d'autres propositions ?

merci d'avance

++
joseph
19/11/2010, 16h35
Pill_S

Nous, nos traductions sont récupérées au chargement par un webservice, qui les charge en une fois. Le traducteur, lui, utilise une interface d'admin html

C'est pas top, surtout niveau perf, mais quand ça va vraiment pas on a un process d'export vers du xml et on embarque ça directement dans nos applis. Les inconvénients sont évidment que si c'est embarqué, on ne peut plus modifier ça sans recompiler, et si ça ne l'est pas, bin niveau perfs c'est pas exceptionnel...

D'autres ont certainement des idées meilleures

;)
21/11/2010, 00h04
joseph_p

Citation:

Envoyé par Pill_S

Nous, nos traductions sont récupérées au chargement par un webservice, qui les charge en une fois. Le traducteur, lui, utilise une interface d'admin html

hum, comment fonctionne cette interface d'admin ?

dans le cas d'appli web, si je ne m'abuse, le développeur se contente d'opter pour une clé à localiser quelque part dans son code. Comment gérez vous alors la suite du cycle de vie (cad détection de cette clé, mise en contexte puis traduction) ?

Citation:

Envoyé par Pill_S

D'autres ont certainement des idées meilleures

je crains fort qu'il s'agit d'un sujet pas très excitant à priori et pourtant bien complexe en pratique. On risque de ne pas avoir trop de candidats pour de meilleures approches :aie:

merci bien en tout cas :)

++
21/11/2010, 00h19
tchize_

après plusieurs tentative chez nous, on utilise la solution suivante:

Le dev crée ses fichier properties initiaux
On importe ces fichiers properties dans tongue tied
A partir de la, le dev et les traducteurs travaillent tous les deux sur le fichier properties dans tongue tied. C'est loin d'être aussi évolué que rosetta de ubuntu, mais ça fait ce que ca doit faire en trois étape (a traduire, a vérifié, traduit).
Avant les releases on récupère les .properties de tongue tied et on les intègre dans le svn.

Je rêverais que tongue tied soit capable de gérer directement le svn :roll:
21/11/2010, 23h25
joseph_p

Citation:

Envoyé par tchize_

après plusieurs tentative chez nous,

on est po tous seuls, cool ;) lol

Citation:

Envoyé par tchize_

on utilise la solution suivante:

Le dev crée ses fichier properties initiaux

juste pour avoir une bonne vue de votre méthodologie: le développeur doit il avoir la rigueur de mettre à jour lui même les fichiers properties ou pas ?

Ou si vous avez une génération auto comment fonctionne t elle ? Parsing du code pour extraction des appels de méthodes qui vont bien ou génération d'une entrée dans un fichier idoine lorsqu'une propriété manquante est requise ?

Citation:

Envoyé par tchize_

On importe ces fichiers properties dans tongue tied

tongue tied, je ne connaissais pas, je viens de regarder rapidement et je le ferai sans doute de façon plus poussée prochainement (y manque de screenshot leur projet google).

petite question tout de même: gère t il les variables au sein des fichiers propriétés ? Sinon, comment faites vous ?

Citation:

Envoyé par tchize_

A partir de la, le dev et les traducteurs travaillent tous les deux sur le fichier properties dans tongue tied. C'est loin d'être aussi évolué que rosetta de ubuntu, mais ça fait ce que ca doit faire en trois étape (a traduire, a vérifié, traduit).

si je comprends bien, le traducteur n'a pas accès au contexte d'utilisation, mais ne fait que proposer ce qui semble coller et le développeur valide vis à vis de la langue qu'il connait ? Ou éventuellement le développeur propose des valeurs par défaut pour une langue ?

encore merci pour ta réponse... et embarrassé de toutes mes questions :oops:
21/11/2010, 23h37
tchize_

Citation:

Envoyé par joseph_p

juste pour avoir une bonne vue de votre méthodologie: le développeur doit il avoir la rigueur de mettre à jour lui même les fichiers properties ou pas ?

Définitivement oui. Si c'est destiné à l'utilisateur, le dev sais que ca doit entre dans uen fichier properties et le fait.

Citation:

petite question tout de même: gère t il les variables au sein des fichiers propriétés ? Sinon, comment faites vous ?

Il gère les fichiers properties au sens ou RessourceBundle les gère. Donc dans tongue tied, le traducteur voit
"Erreur, la valeur {0} n''est pas comprise entre {1} et {2}"

Après, une petite formation vite fait pour lui dire que les '' (simples quoetes doublées) ne sont pas des " (double quotes) et qu'elles ont un raison d'être doublée. Si c'est doublé dans le document d'origine, il double dans la traduction ;)

Citation:

si je comprends bien, le traducteur n'a pas accès au contexte d'utilisation, mais ne fait que proposer ce qui semble coller et le développeur valide vis à vis de la langue qu'il connait ? Ou éventuellement le développeur propose des valeurs par défaut pour une langue ?

Voilà, le traducteur ne passe pas par l'application à traduire pour vérifier. Maintenant, l'application passe par une phase de béta test où les incohérences de traduction dues aux incompréhensions de contexte sont repérées et mises en évidence auprès des traducteur. C'est pas la panacée, mais comme notre application est purement à usage interne, on fait avec et c'est pas la mort si il y a des soucis de traduction. Tout de même je reprocherais à tongue tied de ne pas avoir de suivi des changements dans la langue d'origine. C'est au dev, quand il change un clé dans la langue d'origine à bien marquer toutes ses traduction comme nécessitant un retraduction. Mais comme non traducteur font aussi d'autres choses dans la société, on essaie de simplifier au max leur boulot :d
23/11/2010, 14h53
joseph_p

Citation:

Envoyé par tchize_

Définitivement oui. Si c'est destiné à l'utilisateur, le dev sais que ca doit entre dans uen fichier properties et le fait.

hum, s'agit de convaincre les développeurs alors ;) Ici on utilise wicket et on a modifié le cycle de localisation pour qu'il créé automatiquement les clés si besoin, sous réserve que le code en question soit accédé. Et ce n'est pas la panacée.

Je me demande d'ailleurs si un analyseur statique des classes java et des fichiers html (wicket autorise d'y mettre directement des clés) ne pourrait pas générer automatiquement les clés...

Citation:

Envoyé par tchize_

Voilà, le traducteur ne passe pas par l'application à traduire pour vérifier. Maintenant, l'application passe par une phase de béta test où les incohérences de traduction dues aux incompréhensions de contexte sont repérées et mises en évidence auprès des traducteur. C'est pas la panacée, mais comme notre application est purement à usage interne, on fait avec et c'est pas la mort si il y a des soucis de traduction. Tout de même je reprocherais à tongue tied de ne pas avoir de suivi des changements dans la langue d'origine. C'est au dev, quand il change un clé dans la langue d'origine à bien marquer toutes ses traduction comme nécessitant un retraduction. Mais comme non traducteur font aussi d'autres choses dans la société, on essaie de simplifier au max leur boulot :d

on est entièrement d'accord sur l'aspect "économiser les traducteurs". Chez nous ils sont un peu le goulot d'étranglement, surtout avec notre façon de faire qui implique qu'ils fassent tourner l'application et navigue dedans (l'effet positif est cela du test que cela implique, mais bon le temps passé est trop important).

bref, on risque de se diriger vers votre type de solution. Avec une génération auto des clés dans les fichiers properties, ce serait le bonheur :)

encore merci pour tous ces éclaircissements qui valent le coup d'être tentés!
23/11/2010, 18h22
tchize_

pour certains types de fichiers (ex classes java), ca fait des années que les IDE sont capable d'extraire les String pour en faire des clés ;)
23/11/2010, 19h08
joseph_p

Citation:

Envoyé par tchize_

pour certains types de fichiers (ex classes java), ca fait des années que les IDE sont capable d'extraire les String pour en faire des clés ;)

euh, ok :oops:

j'ai pas encore regardé de ce côté.

par ailleurs, j'aimerai un truc automatique, pas que le développeur ait besoin de pointer chaque string concernée à son IDE.

et sans logiciel dédié, je dois avouer un certain sceptisme: wicket utilise des string pour les identifiants de ses composants, faudrait pas que ces identifiants deviennent des clés. De même, wicket propose un certain nombre de méthodes pour faciliter la localisation, genre "getString(String key, Map variables, String default)". Je vois mal un programme non spécifique prendre ça en compte.

ceci dit, si je me trompe, tu m'en verrais ravi ;)

lol