On peut traduire le contenu du fichier XML, mais quel est l'intérêt de traduire les noms de balise ? Le programme ne va pas planter si on remplace <name>Adept</name> par <name>Adepte</name> (et idem pour les autres valeurs).

Si lui s'occupe de traduire les champs de l'interface et des pdf générés (vu que, pour le faire, il faut les sources), une première traduction à partir d'un glossaire existant n'est pas vraiment difficile. Avec le xpath de .net, il est possible de sélectionner chaque balise d'un fichier, de chercher la correspondance dans la colonne (fichier tableur ou table de DB) "English" du glossaire et de la remplacer par celle de la colonne "Français".

Après, il faut vérifier et compléter ce qui n'a pas ou a été mal traduit (au premier jet, on obtient une version partiellement française).

Pour autant que les fichiers générés soient codés en UTF-8 ou UNICODE, ils pourront être lus par l'application (sauf, peut-être, si problème de longueurs de champs trop différentes). Et pour passer d'une version de langue à l'autre, il suffit d'archiver les fichiers originaux et de les remplacer par les nouveaux.

Je vais essayer de dégager du temps pour plancher là-dessus dans les jours qui viennent. Si j'obtiens quelque chose, je le posterai ici

[edit] J'en ai presqu'oublié de dire que ce programme est génial ! [/edit]

Dernière modification par alt-f4 (01/09/2011 01:29:14)

Je pense qu'on se comprend mal. Il faut distinguer la traduction, et l'aspect multilingue, de l'interface de celle des fichiers de données (XML).

La modification de l'interface ne peut être faite que par les développeurs (et, à partir du moment où le code n'est pas partagé, on n'a pas moyen de le faire - sauf en décompilant le bazar, mais cela en vaut-il vraiment la peine ?). C'est donc le job du programmeur (qui gérera l'aspect multilingue comme il l'entend).

Par contre, et c'est ça qui est sympa dans la conception du truc, les données sont en format texte (ouvert) et peuvent être modifiées manuellement ou de manière automatique.

J'ai codé un truc en vitesse en traduisant automatiquement le nom des pouvoirs d'adepte (que j'ai déjà, partiellement, dans une DB relationelle) dans le fichier "powers.xml" (http://rusr.alt-f4.be/sepfiles/powers.xml - afficher la source si le XML ne s'affiche pas correctement dans le navigateur) après en avoir archivé une copie. Les pouvoirs apparaissent en français dans la liste de sélection (http://rusr.alt-f4.be/sepfiles/listepouvoirs.png) et sur la feuille de personnage générée (http://rusr.alt-f4.be/sepfiles/fichepdf.png).

En faisant de même pour tous les fichiers XML (à partir de fichiers tableurs ou bases de données), on peut donc traduire tous les fichiers, les utiliser directement dans le répertoire du programme et disposer des données traduites dans le programme et sur les fiches générées.

Il est donc possible de travailler en parallèle du développement, en générant les fichiers XML en français pour la version actuelle, et repasser manuellement à l'intérieur pour corriger ce qui a été mal ou pas traduit (puis, si on le désire, faire l'inverse, à savoir compléter les données de source avec ce qui a été modifié pour les réutiliser plus tard).

Pour autant que le développeur communique un changelog de la structure XML de ses fichiers à chaque mise-à-jour, les routines de génération peuvent être adaptées, et les fichiers transmis au développeur qui les placera selon la manière dont il gère les langues (sous-répertoire "fr", par exemple).

Cela signifie qu'en l'état actuel, il y a déjà moyen d'avoir une version française des données et que chaque communauté linguistique peut bosser de son côté pour générer les XML corrects dans sa langue (ce qui décharge le développeur qui peut se concentrer sur le code).

effectivement c'est quelque chose de la sorte que l'on doit obtenir. en toute logique, ceci dit plusieurs remarques:
1) comme noté précédement il n'y a pas que le champs name à modifier, mais aussi les champs qualities
2) si tu pouvais sortir dans un fichier à part les noms non traduits pour qu'il soit ajouté manuellement à la DB ce serait terrible
3) l'enjeu final, c'est d'appliquer tout ça aux feuilles de personnage en .chum pour pouvoir les faire passer d'une langue à l'autre

<quality>
            <name>Adept</name>
            <bp>5</bp>
            <category>Positive</category>
            <bonus>
                <addattribute>
                    <name>MAG</name>
                    <min>1</min>
                    <max>6</max>
                    <aug>6</aug>
                    <val>1</val>
                </addattribute>
                <enabletab>
                    <name>adept</name>
                </enabletab>
            </bonus>
            <forbidden>
                <oneof>
                    <quality>Magician</quality>
                    <quality>Mystic Adept</quality>
                    <quality>Technomancer</quality>
                </oneof>
            </forbidden>
            <source>SR4</source>
            <page>90</page>
        </quality>

prenons l'example de l'adepte, si j'ai bien compris comment ça marche, dans la qualité adepte il y a une balise <enabletab> qui permet d'activer l'accès à l'onglet en question, ici les pouvoirs d'adeptes (donc ne surtout pas traduire le champ <name> de enable tab).

pour les compétence qui ont une influence sur les calculs on a dans les feuille de perso, on retrouve un certains nombre de champs dans la feuille de perso

<uneducated>False</uneducated>

qui fait écho à ce qu'on retrouve dans le fichiers qualities.xml

<bonus>
<uneducated/>
</bonus>

ceci dit pour spellcasting ton raisonnement à l'air de bien se tenir, et pour le coup ça pourrait etre un énorme frein à une traduction sans toucher au code source, vu qu'il n'y a nulle part de référence au nombre max de sort dans la fiche de perso

<skill>
<name>Spellcasting</name>
<skillgroup>Sorcery</skillgroup>
<skillcategory>Magical Active</skillcategory>
<rating>5</rating>
</skill>

c'est probablement dans l'onglet mage qu'il fait un test sur le champs <rating> du <skill> dont le <name> vaut spellcasting.

Dernière modification par ecstaz (01/09/2011 17:47:34)

Décidement, j'ai l'impression de radoter.

Oui, on peut faire comme vous dites, ça s'appelle des données écrites en dur.

a - Les données sauvegardées dans votre feuille de perso seront en français. Faite le test, créez et sauvez un adepte en VO puis changez adept par adepte dans qualities.xml créez un second perso et sauvez-le. Puis ensuite ouvrez le deuxieme .chum avec notepad++, vous verrez "adepte". Si vous ouvrez le premier .chum, vous verrez "adept". Ensuite essayez d'ouvrir le premier fichier de perso, vous aurez un plantage.
Vous ne pourrez pas ouvrir une feuille de perso, des add-ons ou des trucs custom fait par des anglais utilisant la version anglaise depuis le mois de décembre.
De même, un anglais voulant récupérer votre travail devra se taper de la traduction ou bidouiller l'ouverture et le changement de langue dans une langue qu'il ne comprends pas forcement. Ceci n'est pas dans l'optique du logiciel, que le type voit plus comme une plateforme logiciel d'assistance à shadowrun qu'un bête générateur/gestionnaire de perso.

b - lorsque le développeur veux mettre à jour sa db contenue dans les xml, par exemple les bonus conféré par telle ou telle arme, il faudra effectuer plusieurs modifs, en anglais, en français, en allemand, en japonais, en espanol, en polonais, que sais-je. Et donc sans forcement savoir lire le japonais devoir attendre les résultats de 36 équipes avant de faire une release, ce que le type veux à tout prix éviter.


En passant par des étiquettes, le type veut pouvoir faire évoluer la version anglaise comme il le souhaite, sans prévenir personne ni attendre les gens. Si des nouveaux termes non traduits sont créés, le logiciel utilisera le fichier (complet) de la version anglaise.

- Le logiciel écrira ses informations en utilisant la version anglaise dans les .chum et autres xml (cybersuites, PACKS)
- Pour lire les données, c'est à charge du logiciel de lire ces fichiers de l'anglais et d'afficher à l'utilisateur le tout dans telle ou telle langue selon le paramétrage du logiciel.

Il va/est en train de séparer les données de gameplay avec des étiquettes et les données localisées dans des fichiers différents, tout en utilisant la version anglaise pour gérer les I/O et la version choisie par l'utilisateur pour gérer les affichages.

Quel est votre soucis avec ça ? L'impatience ?

alt-f4 a écrit:

en écrasant les fichiers du répertoire data avec ceux du package).

ce qui ne manquera pas de :
- soit faire planter sa prochaine autoupdate.
- soit être écrasé par sa prochaine autoupdate.

Dernière modification par Jazz (01/09/2011 18:36:18)

Jazz a écrit:

Décidement, j'ai l'impression de radoter.

Oui, on peut faire comme vous dites, ça s'appelle des données écrites en dur.

(...)

Quel est votre soucis avec ça ? L'impatience ?

alt-f4 a écrit:

en écrasant les fichiers du répertoire data avec ceux du package).

ce qui ne manquera pas de :
- soit faire planter sa prochaine autoupdate.
- soit être écrasé par sa prochaine autoupdate.

Perso, je n'ai pas de souci avec ça. On ne parle pas de la même chose

J'ai juste testé la possibilité de maintenir/générer/compléter automatiquement les fichiers de données en version française. Ca pose problème parce que la chaîne affichée sert parfois de clé dans d'autres fichiers et dans la vérification des règles. Mais dès qu'on pourra attaquer les balises <text> sans se soucier de ça, c'est réglé.

Et en-dehors du test d'aujourd'hui, je n'ai aucune ambition particulière, ni attente : l'anglais ne me dérange pas.

Le glossaire officiel bouge pas mal au fur et à mesure des bouquins traduits, je vous passerai un lien vers la dernière version d'ici ce weekend.

ecstaz a écrit:

Jazz, je vais tenter ce que tu as dit car compte tenu de la feuille de personnage je ne suis meme pas sur que ce soit un probleme

Verdict ?

Après l'application multilingue, le passage à une application multi-plateformes (ce qui demande beaucoup plus d'adaptations) ?

Pour ceux que ça intéresse toujours :

- un ZIP de sortie de routine sur tous les fichiers (0-output.txt avec statistiques globales, #-fichier.txt avec les termes manquants à partir du glossaire disponible dans chaque fichier) : http://rusr.alt-f4.be/sepfiles/Output-184.zip

- pour traduire la feuille de personnage à imprimer, il suffit de modifier les xsl associées dans le répertoire "sheets" (ex. rapide ici : http://rusr.alt-f4.be/sepfiles/Shadowrun%204.xsl - afficher la source si le navigateur ne l'affiche pas bien)

euh, colonne vo et colonne vf ok, mais pour les jum page, faudra attendree mastrr index ou le faire de votre côté, on n'a malheureusement pas le temps de notre côté...

Maintenant, est-ce vraiment problématique d'avoir les références des bouquins originaux ? Elles ne doivent pas être bien loin dans la VF ...

Il y a aussi moyen de mettre à jour au fur et à mesure et de générer de nouvelles versions du fichier (vu qu'apparemment, il n't en aura qu'un par langue). J'ai le code pour le faire (à adapter à la nouvelle structure, mais ce sera rapide). Je veux bien le filer ou générer les premières versions moi-même (il n'a rien de bien sorcier, ceci dit ... quelques lignes de .net avec les biblibothèques xpath).

Point de vue protection de données, quel est l'intérêt de se le filer sous le manteau à partir du moment où il sera distribué (en partie, du moins) avec Chummer ? Au moins, on peut "garantir" l'utilisation des traductions officielles, même pour des projets tiers ou amateurs.

Namergon a écrit:

(...) pour les num page (...) pas le temps de notre côté...

Hmm, le guide du runner...

Sinon, par hasard, vous auriez les tables parues dans Unwired/Augmentation/Arsenal et compagnie, au format document electronique ?
En croisant ces fichiers et le glossaire, via excell ou autre on doit déjà pouvoir arriver à un truc de bien sympathique !