bravo pour le boulot à tous les deux

alt-f4 a écrit:

Mon optique est "Data Centric", pas "Application Centric".

Comme je l'ai dit plus haut, mon objectif n'est pas directement lié à Chummer.exe, mais à ses données. Si le modèle de données est hérité de l'application, l'application (l'interface) n'est, par contre, qu'une manière d'exploiter ces données.

à ce sujet je serais curieux d'avoir l'avis de Nurw0d4sh, pour savoir comment sont traitées ses données pour son assistant de combat

alt-f4 a écrit:

Jazz a écrit:

Je ne suis pas pour cette méthode car en cas de mise à jour des fichiers équipement (comme par exemple sur la 193 qui a remplacé le fichier armor.xml, etc), ce qui est relativement courant, le processus de mise à jour écraserait les fichiers en français.

Ceci force une équipe a constamment tenir à jour un fichier en français, ce qui n'est pas très pratique.

Cela force aussi les francophones à mettre a jour leur outil manuellement. C'est pas très compliqué, mais c'est chiant à fairre, surtout qu'il y a des updates deux fois par semaine.

Mon optique est "Data Centric", pas "Application Centric".

Comme je l'ai dit plus haut, mon objectif n'est pas directement lié à Chummer.exe, mais à ses données. Si le modèle de données est hérité de l'application, l'application (l'interface) n'est, par contre, qu'une manière d'exploiter ces données.

Chummer.exe dépend entièrement d'une personne, la seule qui ait la main sur le code et ne compte pas l'ouvrir (si j'en crois ce que tu as dit plus haut, j'avoue ne pas avoir eu le courage de lire toutes les pages du topic sur dumpshock). C'est donc un projet qui, par définition, n'est pas fiable parce qu'il peut péricliter du jour au lendemain (selon ce que Nebular décide ou ce qui lui arrive).

Le modèle de données, par contre, reste exploitable (et pas seulement pour la création et l'évolution de personnages).

J'ai bossé maintenant 5 ans dans les bases de données, notamment en migration et en maintenance sur serveur mainframes. Je ne dis pas tout ça "pour" avoir raison (m'en fout ! ), mais par expérience parce que je sais que ça évite plein d'emmerdes que j'ai connu par la suite.

Puisqu'on fait le parallèle avec les DB, tu propose un modèle par record (type DL1, sur IBM) alors que je propose un modèle relationel (type DB2, toujours sur IBM). Les problèmes de MCD n'ont rien à voir, je te parle d'intégration et d'intégrité référentielle entre soft en anglais ou en français. D'ailleurs l'un des problèmes avec ta solution c'est aussi qu'il rends Chummer VF ou VO, pas international.

L'un et l'autre ont leur avantages (DL1 est plus rapide, DB2 mieux maintenable), mais dans le cas de modèle par record, tu va te prendre le chou dès qu'il s'agit de mise à jour : par exemple, à chacun de tes crashs, tu va devoir demander une opération de maintenance spécifique sur une version spécifique d'un logiciel alors qu'on peux contourner tout ça avec ce type de solution relationelle puisque le code écrit en dur, on s'en fout s'il est écrit des noms d'item en dur dans le soft ou pas puisqu'on utilise le nom original, provenant d'une seule version du soft, comme clef.

Dans ton code tu va avoir partout du "si c'est tel langage, fait ça comme ça, si c'est tel langage, fait ça autrement".

"- Euh bonjour, je voudrais traduire Chummer en espagnol...
- Dégage !"

Et tout ce genre de trucs. Tu comprends ce que je veux dire ?

alt-f4 a écrit:

La manière de travailler par contre est bonne (croiser avec le glossaire en xml et regénérer des xml par la suite)

Voila ce qu'a besoin le soft, à mon avis :
- des fichiers xml normaux, an anglais (par exemple armor.xml)
- des fichiers xml de traduction (par exemple fr_armor.xml)
- un index dans le fichier armor.xml (un bête numéro incrémental)
- le fichier fr_armor.xml avec le même index, avec une correspondance d'item.
- lorsque Chummer lit le fichier armor .xml, il colle très probablement ses informations dans un tableau de lecture => evol demandée, ajout d'une nouvelle colonne dans ce tableau de la même taille que pour le nom de l'item et éventuellement une autre pour l'index.
- au moment de la lecture : lire l'enregistrement normalement armor.xml, lire aussi l'index du fichier armor.xml.
- rechercher le nom correspondant dans le fichier fr_armor.xml, le stocker dans la colonne du tableau correspondante. On peut aussi imaginer que les item fr possèdent des infos différente de la gamme en. Dans ce cas, ces infos peuvent éventuellement être mise dans le fichier fr_armor.xml, et écraser les données lues dans armor.xml (comme par exemple, la prise en compte de certain erratas allemands ou les numéros de page)
- faire tout les calculs normalement, et la prise en compte des bonus divers avec les infos du tableau de lecture, notamment les noms des items en anglais.
- dès que le soft doit écrire dans l'UI, utiliser à la place du nom anglophone, le nom provenant de fr_armor.xml

Oublions le soft un moment : ce qui manque au modèle pour l'adapter, de base, à la gestion des langues, ce sont effectivement des index sur ses clés (termes de référence utilisés comme clés dans par d'autres termes de référence, mais plus sur base de leur chaîne de caractère d'affichage linguistique).

Bref, un truc du genre en xml : "<quality><key>QU01</key><bonus>...</bonus>...</quality>" avec un (ou plusieurs) fichier(s) de langue contenant des entrées comme "<item><key>QU01</key><english>Adept</english><french>Adepte</french><german>...</german></item>" (ou "<item><key>QU01</key><text>Adepte</text></item>" pour un fichier isolé en français).

A partir de là, n'importe quelle interface peut aller retrouver la chaîne de caractère dans n'importe quelle langue intégrée au modèle.

Sauf si l'objectif est de demander de virer TOUT les noms écrits en dur dans le soft, ce qui représente un boulot énorme. Il ne s'agit ici que d'un index de lecture, pour pouvoir gérer les trucs en plus ou en moins dans les suppléments selon les langues (allemande, par exemple, ou japonaise, plus tard).

Ma solution est de remplacer le process de lecture (en 20-50 lignes de code) et de trouver tout les endroits où le soft s'adresse aux variables de l'UI, ce qui est très bien fait par les IDE modernes.

Pour un type maitrisant de A à Z son soft, c'est faisable. La longueur, je sais pas, mais c'est surement moins cher que ta solution.
-edit, j'espere que tu'na pas encore eu le temps de lire le post- en fait, on propose presque la même chose... sauf que j'utilise les nom anglais comme clef princale alors que pour toi, c'est une donnée comme une autre. Du coup pourquoi pas.

alt-f4 a écrit:

Je pense que c'est ce qui demandera le moins de boulot à Nebular, car en traduisant directement les .xml (armor.xml), il faudra identifier tout les endroits où les noms des items sont écrits en dur et avoir ce problème de mise à jour dés qu'un fichier est écrasé par une mise à jour.

Je vais demander ce qu'en pense Nebular car il n'a pas été très parlant sur ce sujet.

Tout dépend, effectivement, de ce que Nebular décide de faire ou ne pas faire (il n'avait pas l'air vraiment chaud à aller plus loin que l'interface). Si quelque chose de sérieux se dessine (à savoir une réflexion globale sur la gestion de plusieurs langues, Omae et feuilles de personnage inclus), j'y participerai avec plaisir si on me le demande. Sinon, le peu que j'ai est à disposition.

Au niveau des données, je pense que tu tiens le bon bout en voulant merger glossaire et xml de Chummer. Mais pour la façon de les lire, franchement, je suis à peu près sûr d'avoir trouvé un bon compromis (sauf si Chummer marche pas du tout comme ça et là, bah, il faudra un peu plus d'étude).

après, on en a un peu rien à fiche de savoir s'il y a des trucs écrit en dur ou pas, du moment que ça marche. Pour lui, ca sera d'ailleur beaucoup plus simple d'utiliser l'anglais pour le develloppement, les tests et la maintenance. Alors certes, c'est pas "comme à l'école". Mais si tu savais le nombre de conneries non-pragmatique qu'on apprends à l'école aussi...

Pour info Omae tire la valeur de ses champs d'une DB internet, m'enfin pour trois boutons...

alt-f4 a écrit:

Mais je me méfie toujours des projets collaboratifs qui ne dépendent que d'une personne, quelle qu'elle soit. Surtout à une époque où l'open source a plus que fait ses preuves

Voici son avis sur la question, tiré de la faq :

Is Chummer open source? Can I help you develop it?
No, nor do I plan to ever make it open source. I have had too many bad experiences working with open source projects - people making undocumented changes, making unapproved changes without discussion, never checking things in, being a general pain in the butt, and people fighting to become the project lead even when one has already been established and is the most active person. While I do appreciate the offers for development help, I'm just not willing to make this open source and deal with those problems again. You're certainly welcome to create custom data or character sheets though and share with in the Custom Data for Chummer Character Generator thread on Dumpshock though. If I ever decide to stop working on Chummer, I will make the source code available to anyone who wishes to continue developing it.

Dernière modification par Jazz (13/09/2011 16:02:53)

il y a deux manières de procéder dans ces cas là. Soit tout mettre au même endroit, ce qui implique une modification de MCD dès qu'un type arrive en disant "je veux une version polonaise", soit en séparant les libéllé et en passant par des clefs.

Si tu passe par des clefs, tu as :
- un soft moins rapide (2 IO au lieu d'une)
- un code pas super lisible (ou alors a commenter lourdement mais sans compil sans pouvoir s'assurer de ne pas avoir fait de faute de frappe)
- des difficultés de devellopement/test/maintenance ("c'est quoi déja le nom d'item qui déconne ? XXX ? euh, c'est dans tel partie de la DB, a tel endroit, et ça dit...")
- Modèle Conceptuel de Donnée mieux indépendant du code (juste modifier un bout de process de lecture/écriture là ou il y a des evol)
- Idem pour les fichiers
- c'est cencé être le modèle défendu par les écoles.

Si tu passe par "tout en un record" :
- soft plus rapide
- code lisible
- devellopement/maintenance/test simplifié
- gros problèmes dès qu'il s'agit de modifier le MCD
- gros problèmes si un de te fichiers est modifié.
- c'est souvent un modèle rencontré en entreprise (et entre autre "abération mathématique" vraiment pas connes du tout, il y a aussi des phénomènes type redondance d'index ou autre truc qui ferait hurler des profs d'info qui n'ont jamais bossé sur de la maintenance/evol ou du dimensionnement de db), car il est moins consomateur de ressource. Les profs, eux, n'ont pas de problèmes de cout de ressources, c'est un truc qui n'est jamais enseigné en école à propos des données.

Passer d'un modèle a un autre est une question fondamentale, définissante d'une application. Dans certains cas, il vaud presque mieux réécrire l'appli.
Et le résultat n'est qu'une question "éthique", pour un résultat identique (sauf le cout des resources, justement). pour passer d'un modèle à un autre, je conseille largement la redondance d'info, c'est ce qui est le plus rapide en temps de dev.

@alt-f4 : ah la Belgique et son brol informatique ! Très bonne école, je suis super content d'avoir bossé à Bruxelles pour ma premiere mission. Comme tu a vu, je bossais du coté IS, pour Fortis encore "AG" à l'époque
C'est une boite géniale en tout cas, je la recommande à toute personne voulant bosser en mainframe, j'ai pas encore vu mieux ailleurs (au niveau des outils, notament).

Bref, juste pour dire qu'il confirme que ce que je lui dit est dans l'esprit de ce à quoi il pensait mais c'est pas pour tout de suite car il veux dégager tout les problèmes de trad de l'UI avant.

La phase béta est close et lui envoie le fichier maintenant

*Si l'option apparaît "Yummy"

J'avais regardé vite fait ta bêta Jazz, déjà beau boulot...et là je viens de jeter un oeil à la build 197 de Nebular: vraiment excellent boulot pour la traduction

Tiens d'ailleurs y a des bug concernant les IA
Il est impossible de sélectionner leurs programmes inhérents ou de construire leur "home node" et de l'attribuer comme niveau de vie.

Comme j'ai pas les termes en anglais qui s'y rapporte sous la main je n'ai pas encore poser la question sur le wiki.

a ajouter aussi un nouveau référentiel de page... On a pas forcement les même nom de bouquin et encore moins les même pages...

dragrubis a écrit:

a ajouter aussi un nouveau référentiel de page... On a pas forcement les même nom de bouquin et encore moins les même pages...

Prévu mais disons que si la sortie de "la possibilité" de traduction sur Chummer (boulot de prog par Nebular) est pour, disons "le moyen terme" (genre ça se compte en x mois, à vue de nez), la trad version bugguée rhinoceros en elle même est prévu sur du "moyen terme" + 1 mois, la trad debugguée en +2 mois et la trad avec numéros de page fr disons sur du +3 mois/+4 mois. Sauf si on peux mettre la main sur une version numérique des tableaux du runner's toolkit en français (appel du pied en mode madame irma à peine déguisé :p)

il vaut mieux faire ça comme ça, je pense : trois release, une "un peu pourrie mais qui fait un peu l'affaire quand même", une "correcte" et une idéale.

Namergon a écrit:

Attention, le glossaire contient des lignes barrées, notamment sur Longarms, qui avait été par erreur traduit par Armes d'épaules dans la première mouture de SR4. On a gardé la référence pour garder trace de l'erreur et ne pas re-générer de discussion en interne.

Shit, shit, shit. Je ne sais pas s'il existe une fonction sur open office pour détecter du barré. J'enquête.

Namergon a écrit:

Selon comment tu extrais les infos du fichier, il vaudrait peut-être mieux que tu fasses d'abord une version épurée de ce genre d'entrée.

J'extrait rien, c'est du RechercheV tout con avec une extraction des xml de Chummer.

Namergon a écrit:

Sur les skills, tu verras qu'hélas toutes n'avaient pas été glossarisées.

Ok, alors je pense qu'il serais bien qu'on vous mentionne tout les trucs qu'on verra, du coup. Ca vous permettra d'être au courant des entrées manquantes.

Namergon a écrit:

Vettech, Riding, etc : il semble que tu aies des décalages de ligne. Si tu vérifies manuellement, tu verras que le fichier est correct, mais ton extraction semble taper dans la mauvaise ligne.

J'ai ni VetTech ni Riding dans la version du Glossaire que je possède (v1.14_20100904). Je me suis ararngé pour ne pas avoir de décalages de ligne, justement (des $ dans la matrice de ma rechercheV).

Je penche plus pour une vieille version du glossaire, non ?

Dernière modification par Jazz (18/09/2011 19:07:33)

Oups, merci.

On va probablement y ajouter trois colonnes pour bosser. La catégorie Chummer VO ou VF, qui représente en fait soit le terme de gameplay, soit le nom du paragraphe où le flavor text est trouvé, le numéro de page, et un indicateur de "canonicité", pour avoir un filtre possible sur "en barré"/"en pas barré".

J'avoue que j'arrive pas à trouver une fonction qui trouve la police barrée, il faut passer par des macros et sous calc, je sais pas faire. Et tant que je suis au duduch', j'ai pas Excel. :-/

Y a pas un pro d'Excell/Calc qui pourrait nous rencarder sur comment faire pour détecter une police barrée dans une cellule ?

edit -  c'est bien bien mieux, ça donne ça :

Aeronautics Mechanic    Mécanique aéronautique
Animal Handling    Animaux
Animal Training    Dressage
Arcana    Arcanes
Archery    Armes de trait
Armorer    Armurerie
Artisan    Artisanat
Assensing    Analyse astrale
Astral Combat    Combat astral
Automatics    Armes automatiques
Automotive Mechanic    Mécanique automobile
Banishing    Bannissement
Binding    Contrôle d’esprits
Blades    Armes tranchantes
Chemistry    Chimie
Climbing    Escalade
Clubs    Armes contondantes
Compiling    Compilation
Computer    Informatique
Con    Escroquerie
Counterspelling    Contresort
Cybercombat    cybercréature ==> nope. Calc c'est vraiment de la merde.
Cybertechnology    Cybertechnologie
Data Search    Recherche de données
Decompiling    Décompilation
Demolitions    Explosifs
Disguise    Déguisements
Diving    Plongée
Dodge    Esquive
Electronic Warfare    Papier électronique ==> absent du glossaire
Enchanting    Enchantement
Escape Artist    Évasion
Etiquette    Étiquette
First Aid    Premiers soins
Flight    Vol
Forgery    Falsification
Gunnery    Armes de véhicules
Gymnastics    Gymnastique
Hacking    Hacking
Hardware    Hardware
Heavy Weapons    Armes lourdes
Industrial Mechanic    plaque à induction ==> confirmation que Calc c'est de la merde
Infiltration    Infiltration
Instruction    Enseignement
Intimidation    Intimidation
Leadership    Leadership
Locksmith    Crochetage
Longarms    soins magiques à longue terme /de longue durée ==> (pb de barré à résoudre)
Medicine    Médecine
Nautical Mechanic    Gaz vomitif ==> oui, c'est bien l'effet que me procure CALC SCRONGNEUGNEU
Navigation    Navigation
Negotiation    Négociation
Palming    Escamotage
Parachuting    parachimiste ==> absent du glossaire
Perception    Perception
Pilot Aerospace    Appareils Spatiaux
Pilot Aircraft    Appareils Volants
Pilot Anthroform    Anthropomorphes
Pilot Ground Craft    Véhicules terrestres
Pilot Watercraft    Véhicules aquatiques
Pistols    Pistolets
Registering    Inscription
Riding    Monte ==> Equitation, ça comprends aussi la descente... :p Et si vous vouliez l'utiliser en monte de dragon, "Montures" aurait été un peu plus heureux... 'fin bref, osef.
Ritual Spellcasting    Lancement de sorts rituel
Running    Course
Shadowing    Filature
Software    softs (en général) ==> homonymie
Spellcasting    Lancement de sorts
Summoning    Invocation
Survival    Survie
Swimming    Natation
Throwing Weapons    Armes de jet
Tracking    Pistage
Unarmed Combat    Combat à mains nues
VetTech    Technologie vétérinaire


==> je pourrais faire carrément mieux si j'avais confiance dans la catégorie... (si autofilter, y a plusieurs fois les mêmes noms, y a parfois rien du tout...)
==> je ne m'inquiète pas pour certains termes ne provenant pas du glossaire. Cela correspond probablement aux noms des skills des futurs suppléments de la gamme. L'inconvénient c'est qu'ici, pour les skills, j'ai pas les ref à vous donner.

Dernière modification par Jazz (18/09/2011 23:27:35)

Jazz a écrit:

Binding    Collage

Ca, c'est juste parce qu'il y a 2 entrées "Binding" en anglais (compétence et pouvoir de créature). Et qu'il tombe séquentiellement d'abord sur le pouvoir.

Sinon, je pense que le plus simple est de générer/maintenir un glossaire pour Chummer plutôt que de bosser avec une version de travail des traducteurs (parce qu'après avoir détecté du barré, tu devras peut-être t'attaquer au rouge, au souligné, à la détection de la police de caractère, ...).

Pour les modif d'armes dans l'ui : remplacer "Partie de base de l'arme" par "modification de série" ou "inclus de base" par exemple ou autre si meilleure idée. C'est plus parlant