La Couronne de Cuivre

A la suite de le proposition d'aide de Doremus, j'ouvre cette discussion pour décrire des outils qui pourraient aider l'équipe. Je vais d'abord exposer mes propres idées. Mais n'hésitez surtout pas à proposer les vôtres.

J'avais d'abord identifié deux outils qui seraient pratiques pour l'utilisation des fichiers tra une fois traduits. Suite à la proposition de Sandman, j'ajoute un troisième outil d'un usage plus immédiat, en phase de traduction :

• un outil pour corriger un fichier tra sur un aspect particulier et pour compléter une information manquante dans les fichiers d'analyse
• un outil permettant de convertir un fichier tra sous forme de deux fichiers csv destinés à mettre à jour la traduction dans l'outil en ligne de Beamdog
• un outil permettant de vérifier l'existence de mise à jour d'un texte par rapport au plus récent dialog.tra

1/ Outil de récupération des noms de fichier son et d'élimination de doublons

Objectifs :

• insertion des références de fichier son manquantes dans les fichiers traduits
• mise en commentaire des textes en doublon
• [vérification que ces textes en doublon sont bien identiques en contenu]

Entrées/sorties : Fichier tra VO BG2EE :
extrait du dialog.tlk du répertoire en_US : on pourrait se limiter à la plage de numéro débutant à 74107
voir fichier dialogBG2EEv2.3.67.3-En.zip dans le répertoire Références de la dropbox


Description du format tra

Pour une première introduction, je suggère de lire l'article présentant les fichiers mis à disposition des traducteurs.

Le format est le suivant :

En VO, les deux cas possibles dans le fichier tra sont :
@numero = ~texte~
@numero = ~texte~ [SON]

La présence de caractères entres crochets après le texte entre tildes indique au jeu qu'il existe un fichier de doublage sonore de la réplique (dialogue, retour pour une action du joueur sur le personnage) ou de l'exclamation (coup reçu, par exemple). Ils indiquent le nom du fichier son qui contient le doublage. Le jeu ajoutera l'extension .WAV et ira typiquement chercher le fichier en question dans un fichier .bif (équivalent à un fichier zip avec un format propriétaire)

En VF, nous aurons potentiellement les cas suivants :
@numero = ~texte~
@numero = ~texte~ [SON]
@numero = ~texte masculin~ ~texte féminin~
@numero = ~texte masculin~ [SON] ~texte féminin~ [SON]

Nota : même s'il serait possible d'avoir un différence de son entre masculin et féminin dans le fichier tra, il n'est pas certain que le jeu le gère et de toute façon, il n'existe aucun jeu de fichiers de ce type pour le français. Nous nous contenterons donc d'utiliser le même fichier son pour les deux déclinaisons dans tous les cas.

Mise en garde concernant le codage (autrement dit spécifications informelles du format tra) :
- les textes utilisent généralement le tilde (~) comme séparateur à la place du classique guillemet
- l'utilisation du guillemet (") à la place du tilde n'est pas totalement à exclure
- dans un cas particulier, le fichier tra des textes anglais va utiliser un groupe de 5 tildes comme séparateur, en raison d'un texte qui comporte à la fois le tilde et le guillemet
- dans les fichiers tra, un texte (entre tildes) peut s'étendre sur plusieurs lignes (objet, sort, ...)


Récupération de la référence de son

En pratique les fichiers d'analyse à partir desquels nous travaillons n'ont pas inclus la référence de son. De sorte qu'elle manque au fichier tra obtenu après traduction. Si le fichier tra était utilisé en l'état dans le mod bg2eetrans, l'implantation dans le fichier dialog.tlk du texte français perdrait la référence du son associé, de sorte que la réplique concernée deviendrait muette.

Exemple : tout premier texte de 2025-Rasaad-V2.tra, dossier "Rasaad SoA\Traduction" de la dropbox ou le forum

@77529 = ~Nous souhaitons seulement savoir si tu es réellement déchu !~

En réalité le texte en VO comporte un doublage son pour ce texte :

@77529 = ~We only seek to know if you have truly fallen away!~ [OH77529]

Attention à ne pas confondre avec le cas suivant :
@numero = ~[CONTEXTE] texte~ [SON]
Parfois il se trouve un texte entre crochet à l'intérieur des tildes, qui décrit le contexte d'utilisation. En général ces indications entre crochets sont présentes lorsqu'il y a aussi un fichier son associé


Mise en commentaire des doublons

Exemple concret, toujours au début du même fichier
Les fichiers d'analyse, et donc les fichiers tra qui en sont tirés, répètent la réponse choisie par le joueur à une précédente réplique avant de présenter la nouvelle réplique du personnage ainsi que les nouveaux choix de réponse offert au joueur. Dans le cas ci-dessus, il s'agit de la ligne @77534. Comme elle est présente deux fois dans le fichier, l'outil de vérification de fichier, TraChecker (mentionné ici) va signaler un doublon.
En vérité, si les deux textes sont vraiment identiques, cela ne poserait pas de problème dans le processus de création du fichier d'installation pour le mod de traduction (objet du deuxième message sur la même page). Néanmoins cela serait pénalisant en terme de temps de création et en temps d'installation du mod. Et cela représentera un risque potentiel pour la conversion de fichier tra en csv mentionné au tout début (vis-à-vis de l'import dans l'outil de Beamdog).

L'objectif est donc de mettre en commentaire les apparitions d'un texte déjà présent avant dans le fichier. La syntaxe est la même qu'en langage C. En principe ce genre de doublon ne devrait intervenir que pour des répliques de dialogues, qui ne devraient en principe pas contenir de retour à la ligne. Dans ces conditions, l'ajout de // au début des lignes @numéro en doublon devrait suffire. Si on veut éviter tout risque, il faudrait encadrer l'ensemble de la "ligne" @numéro par /* et */.


Vérification du contenu des numéros en doublon

Il s'agit ici de vérifier que lorsqu'il y a des doublons, les textes sont bien identiques. Dans le cas contraire, il s'agit simplement d'afficher une alerte dans la console.


Forme de l'outil

L'idée serait un outil fonctionnant via la ligne de commande afin de pouvoir le lancer en batch pour traiter autant de fichiers tra que nécessaire.



2/ Conversion de fichier tra en fichiers csv importables dans l'outil de traduction de Beamdog

A suivre...


3/ Vérification de mise à jour d'un texte par rapport au plus récent dialog.tra

Les analyses qui ont permis d'identifier les textes à traduire dans leurs contextes ont été pour la plupart réalisées à partir des textes d'une version préliminaire de BG2EE. Le nombre 2025 et 2031 figurant dans le nom des fichiers d'analyse au format rtf font référence à un nombre incrémental de version, sachant que la version 2030 correspond à la première version officielle et 2032 au premier patch. Nous avons donc à faire à des textes pour la plupart non finalisés.
Par conséquent, vu la propension de Beamdog à raffiner les textes pour modifier la ponctuation, passer les nombres des chiffres arabes à la forme écrite et aux modifications plus ou moins significatives, il y a de grandes chances que de nombreux textes aient été modifiés depuis l'analyse.
Il serait donc utile de disposer d'un outil permettant de détecter facilement les textes qui ont changé entre l'analyse et la toute dernière version du jeu. Dans les deux cas, il s'agira de s'appuyer sur les fichiers au format tra.

En terme de sortie, l'outil devra indiquer les textes présentant des écarts et recopier pour ceux-là les moyens d'analyser la situation. Afin de pouvoir utiliser des outils d'affichage graphique de différence, je propose pour cela de créer deux fichiers au format tra :

• dans le premier, le texte présent dans le fichier tra d'analyse
• dans le second, le texte correspondant dans la toute dernière version du jeu

Afin de faciliter l'exploitation des indications par le traducteur, il faudra préserver l'ordre d'apparition des textes dans le fichier tra d'analyse et repérer le numéro de ligne du fichier tra d'analyse où commence le texte présentant une différence.
L'objectif est d'éviter d'avoir à ouvrir les deux fichiers et à chercher les numéros pour pouvoir comparer les textes considérés par l'outil comme modifiés.
Pour que des outils de diff graphique tel que kdiff3 ou meld puissent être utilisés pour les comparaisons, il faudra également s'assurer de ne pas introduire de différence sur les informations ajoutées (en particulier les informations pour le repérage).

Exemple (proposition) :
Premier fichier Second fichier Comme indiqué dans cet article, certains textes peuvent être répétés. Compte-tenu de la consigne de ne traduire que le premier, il suffira de vérifier le texte lorsqu'il apparaît pour la première fois seulement.
Par ailleurs les fichiers tra à exploiter contiennent les textes anglais, de sorte qu'ils ne comportent que le texte "masculin". Il n'est pas nécessaire de se préoccuper des références à des fichiers de voix (texte entre crochets) vis-à-vis d'éventuels ajouts, suppression ou modification : le premier outil offrira le moyen de mettre à jour le fichier tra traduit avec les références utilisées dans la version la plus récente du jeu.

Forme de l'outil
Idéalement : outil autonome (pas besoin d'environnement à installer pour s'en servir), utilisable sous Windows
A minima : outil fonctionnel avec instructions d'utilisation et installation (si nécessaire)

Utilisation
utilisable en ligne de commande pour permettre le traitement en lot de plusieurs fichiers d'analyse (mais une interface graphique de lancement est envisageable, en complément)



PS : je reprendrai prochainement ce message pour en améliorer la mise en page.

Ok, merci pour ces précisions Isaya, je vais commencer à travailler dessus. Étant vraiment à l'aise en java je pensais plutôt à ce langage pour développer l'outil. Si ça ne dérange personne je préférerais, côté utilisation ça ne changerai rien, ce serait même un peu plus user friendly avec une petite interface toute simple. À vous de me dire...

Tu es libre de choisir le langage qui te convient le mieux. Idem pour la présence d'une interface graphique.
Si tu peux envisager en complément un mode de fonctionnement en ligne de commande, qui court-circuite l'interface et appelle directement le traitement à partir des paramètres passés en paramètres, ce sera un petit plus.
Merci de ton aide.

Très bonne démarche, bon courage, j'ai hâte de pouvoir utiliser ça

Ok, après avoir potasser un peu plus, je vois plus clairement de quoi il s'agit, pour résumer histoire d'être sûr de bien se comprendre :

• L’outil prend deux fichiers en entrée, le fichier dialogEn.tra et le fichier .tra sur lequel travaille le traducteur et recrache en sortie un fichier .tra avec les références audio issues du fichier dialogEn.tra.
• En plus de ça l’outil devra mettre en commentaires les doublons identifier par un @xxxx.

Petite question, si les répliques des dialogues peuvent êtres présentes sur plusieurs lignes une nouvelle réplique commencera bien toujours par @xxxx ?
Je peux donc me fier à cet indicateur pour découper le fichier en autant de réplique que de ligne / ensemble de lignes, commençant par @xxxx ?

Le fichier dialogEn.tra contient-il lui aussi des doublons ?

Pourriez-vous également m'indiquer quel fichier .tra français incomplet je pourrais utiliser pour tester l'outil ?

Je te joins ici quelques fichiers .tra pour tester l'outil :

Un dialogue et sa traduction qui n'est pas terminée :
Un dialogue et sa traduction terminée :

Il me semble que les répliques commencent bien toujours par @xxxx, attention quand même, on retrouve très souvent @xxxx dans les commentaires.
Concernant les doublons, je ne suis certain de rien donc je laisse à quelqu'un d'autre le soin de te répondre.

Doremus a écrit :Ok, après avoir potasser un peu plus, je vois plus clairement de quoi il s'agit, pour résumer histoire d'être sûr de bien se comprendre :

• L’outil prend deux fichiers en entrée, le fichier dialogEn.tra et le fichier .tra sur lequel travaille le traducteur et recrache en sortie un fichier .tra avec les références audio issues du fichier dialogEn.tra.
• En plus de ça l’outil devra mettre en commentaires les doublons identifier par un @xxxx.

Oui, c'est bien ça. Pour être précis, parmi les textes présents plus d'une fois, il doit mettre en commentaire ceux après le premier.
Par ailleurs, j'aimerais que l'outil vérifie si le texte présent dans le ou les doublons est bien identique à la première fois où il apparaît. Dans le cas contraire, il serait utile de d'alerter car le traducteur a traduit deux fois le texte mais de façon différente.

Doremus a écrit :Petite question, si les répliques des dialogues peuvent êtres présentes sur plusieurs lignes une nouvelle réplique commencera bien toujours par @xxxx ?
Je peux donc me fier à cet indicateur pour découper le fichier en autant de réplique que de ligne / ensemble de lignes, commençant par @xxxx ?

Oui, à condition de ne pas tenir compte des fois où le @xxxx apparaît au sein d'un commentaire.
La séquence exacte pour identifier un véritable doublon est "@xxxx = ~un texte~" (texte éventuellement réparti sur plusieurs lignes), situé en début de ligne (on peut éventuellement tolérer des espaces avant @) mais pas à l'intérieur d'un commentaire. On trouve couramment en commentaire "@xxxx" non suivi d'un = dans les commentaires, cette situation ne pose pas de problème.
A proprement parler, tu n'as pas forcément à t'embêter à "découper" le fichier si tu traites le fichier traduit en flux : tu recopies inchangées les lignes qui ne correspondent pas au motif et tu fais un traitement à la volée lorsque tu trouves le motif : réécrire à l'identique ou en ajoutant la référence de son si nécessaire.

Doremus a écrit :Le fichier dialogEn.tra contient-il lui aussi des doublons ?

Non. Il s'agit d'une extraction complète du contenu du fichier dialog.tlk en VO, il contient ainsi tous les textes du jeu. Par définition, il ne peut pas avoir de doublon.

Doremus a écrit :Pourriez-vous également m'indiquer quel fichier .tra français incomplet je pourrais utiliser pour tester l'outil ?

Utilise les fichiers proposés par Scylla dans un premier temps, ils sont pas trop gros. Ce sera plus pratique pour la mise au point. Par contre, je ne peux pas te donner de référence sur ce qu'il faut trouver comme sons sans faire une recherche.
Les exemples que j'ai donnés proviennent du début du fichier concernant Rasaad dont j'ai donné le lien dans le forum. C'est celui que je souhaite traiter en premier en pratique (la traduction est achevée, cela permettrait de la mettre à disposition dans le mod), mais il est énorme et donc pas adapté à la mise au point. Tu pourrais aussi en prendre un extrait des 100 premiers textes. Une fois que tu l'auras traité, je tâcherai de faire une vérification.

Niveau outils, avez-vous pu avancer ? Je suis dev PHP et le traitement de chaînes texte et de fichiers, c'est mon dada, donc si je peux aider, n'hésitez pas !

Isaya, j'ai réussi à pondre une procédure WeiDU qui récupère les références dans les fichiers baf. Pour l'instant, elle fonctionne avec les DisplayString, DisplayStringHead etDisplayStringNoName. Il faut que j'ajoute les références de journal.

Pour l'instant, ça donne ceci :
Je m'aperçois que je n'ai pas lancé la procédure pour DisplayString, donc il en manque une.

Il ne me reste plus qu'à aller chercher la chaîne de caractères dans le dialog.tlk et à intégrer le tout dans un fichier tra.

Note : J'ai utilisé la commande INDEX_BUFFER de WeiDU qui est vraiment rapide.

J'ai un petit souci avec WeiDU et la commande APPEND. J’utilise comme fichier de base un tra en UTF-8 comportant 5 lignes de titres. Chaque fois que WeiDU lui ajoute une nouvelle ligne, il est automatiquement transformé en ANSI.

Ai-je loupé quelque chose ou s'agit-il d'un dysfonctionnement de WeiDU ?

Problème résolu sans comprendre pourquoi, ni comment...

J'ai dropé un fichier bcs_missing_strref_RASAAD.tra qui reprend toutes les stringrefs manquantes de la quête de Rasaad (script des cartes, des éléments des cartes et des créatures).

Il n'existe pas à proprement parler de fichier "ANSI" ou UTF-8. Ce que tu vois correspond probablement à la perception de l'éditeur avec lequel tu ouvres le fichier. Par exemple notepad++ essaie de deviner l'encodage à partir, semble-t-il, des premiers caractères spéciaux qui apparaissent dans le fichier. En fonction d'un réglage dans les options, il considère a priori comme UTF-8 ou "ANSI" un fichier qui ne comporte aucun caractère spécial (i.e. avec un code > 127), c'est à dire un fichier purement au format ASCII.
De sorte que notepad++ va indiquer comme UTF-8 un fichier n'ayant aucun caractère spécial. Si tu édites ce fichier avec notepad++ et que tu tapes des accents, comme il considère qu'il est en UTF-8, il va les encoder en UTF-8, ce qui va renforcer (cette fois-ci à juste titre) le fait qu'il le considère au format UTF-8.
Au contraire, si un autre outil ajoute dans ce fichier purement ASCII des caractères spéciaux au format "ANSI", notepad++ va alors le considérer comme "ANSI".

Cela dit, quand tu travailles à partir de fichiers de BG2EE, je suis surpris que WeiDU puisse introduire des caractères que notepad++ va considérer comme ANSI.

Je vais étudier ton fichier. J'ai vérifié le relevé que tu avais pour dialogues et scripts et je me suis attaqué au dialogue manquant. Côté script, je n'ai pas trouvé de texte à traduire (2 textes sont bien nouveaux mais je les avais déjà récupérés à partir d'IWDEE).

Tombé sur ce sujet l'avant-veille, juste avant de commencer un nouveau BG2EE, j'ai découvert puis codé le projet 1 sous forme de mod Weidu.

Voici le readme rapide:
- Mettre tous les tras anglais et francais dans Shadow-TRA/Input avec cette normalisation: dialog01.tra et dialog_FR.tra, toto.tra et toto_FR.tra, etc.
- Lancer le mod à volonté (NO_LOG_RECORD)
- dans Shadow-TRA/Output, se trouvera dialog_FR.tra, toto_FR.tra comprenant les [sound] provenant des fichiers anglais
- Ainsi que le fichier MultipleTranslations.txt résumant les traductions multiples, exemple:
DORN SOA - 13 - RENCONTRE UR-GOTHOZ_FR.tra/@75402/Male: -[Je suis déçu, Dorn. Je m'attendais à mieux de ta part.]- vs -<blalblabla.>-


Note 0: NE JAMAIS UTILISER DE COMMENTAIRE MULTI-LIGNES
Note 1: les textes multi-lignes sont gérés
Note 2: disponible pour projet 2 et 3 si les spécifications sont abouties

Me contacter si besoin...

Merci beaucoup, shadowlich. Je ferai un essai avec le long fichier de Rasaad, que j'ai dû traiter cet été en passant au format csv afin d'utiliser le langage de macro de Libre Office pour récupérer les références de son et identifier les doublons. Cela m'avait pris des heures, ce sera un énorme gain de temps. Je te ferai un retour si je rencontre des cas particuliers.

Le sujet numéro 2 n'est pas urgent compte-tenu de l'avancement de la traduction. Néanmoins je pourrai fournir un petit fichier d'exemple pour donner une idée du format. Il faudrait que je me renseigner auprès de Beamdog pour avoir une précision sur un champ qui ressemble à un codage de temps écoulé depuis 1970 afin de déterminer s'il faut le mettre à jour ou pas.

Pour le sujet numéro 3, je vais vérifier ce que j'ai écrit et compléter lorsque c'est nécessaire.

Je n'ai pas compris pourquoi il fallait mettre en commentaire les traductions similaires en double, Weidu gère ça tres bien a priori et sans forcément ralentir...

Néanmoins, après maintes hésitations, pour satisfaire la spéc., voici la version avec la mise en commentaire souhaitée (donnant un retour direct sur ce qui est unique juste en ouvrant le fichier, peut-être est-ce la réponse directe à ma propre question... )


Les specs de tout autre projet et ce sera fait dans les 2-3 jours ouvrés, pour avancer sur cette sacrée traduction...