Page 1 sur 1

Dialog.tlk : Gestion de textes déjà existants par WeiDU

Posté : ven. 05 avr. 2013, 17:34
par Freddy_Gwendo
Comme souvent, une idée saugrenue me titille au moment de coder.

Voilà, je me demandais si lors d'une compilation de script ou de dialogue, WeiDU créait systématiquement une nouvelle entrée où s'il utilisait un élément du dialog.tlk déjà existant en cas de doublon.

Je m'explique :

Jusqu'à présent, j'utilisais ceci :

Code : Tout sélectionner

IF
  Name("Info01",Myself)
  Range([PC],15)
THEN
  RESPONSE #100
    DisplayStringHead(Myself,[color="#FFFF00"]5767[/color]) // ~[color="#FFFF00"]Vous remarquez que ce bâtiment tombe en ruines. Ce serait folie d'y pénétrer.[/color]~
    TriggerActivation(Myself,FALSE)
END
en utilisant #5767 après avori vérifié que la traduction correspondait bien à l'esprit du texte original en anglais.

En reprenant mes scripts, je comptais utiliser plutôt ceci :

Code : Tout sélectionner

IF
  OR()
    Name("Info01",Myself)
  Range([PC],15)
THEN
  RESPONSE #100
    DisplayStringHead(Myself,[color="#FFFF00"]@2001001[/color]) // ~[color="#FFFF00"]Vous remarquez que ce bâtiment tombe en ruines. Ce serait folie d'y pénétrer.[/color]~
    TriggerActivation(Myself,FALSE)
END
Je me demandais donc si dans ce cas WeiDU créait une nouvelle entrée dans le dialog.tlk ou s'il utilisait #5767.

Le but du jeu étant de diminuer au maximum la tâche des futurs traducteurs.

Je précise de plus que j'ai toujours vérifié la pertinence des strings réutilisés car il arrive souvent que la traduction française ne corresponde pas tout à fait à l'esprit de l'original. Ex : "Oui" tout seul correspond souvent à une formule beaucoup plus longue en anglais. La traduction convient cependant car dans l'esprit, elle fonctionne parfaitement avec l'esprit du dialogue. Mais employer ce "Oui" dans une autre situation poserait de graves non-sens en anglais, et je suppose, dans d'autres langues.

Posté : sam. 06 avr. 2013, 10:55
par Isaya
WeiDU réutilise un numéro existant si un texte à ajouter correspond parfaitement à un texte existant. C'est ce mécanisme même qui lui permet de désinstaller et réinstaller des mods/composants automatiquement quand on désinstalle un mod au milieu de sa liste de mods installés. Autrement cette opération créerait de nouveaux textes à la réinstallation et le fichier dialog.tlk grossirait très vite.

J'ignore s'il applique un contrôle particulier vis à vis du doublage sonore pour vérifier s'il peut effectivement réutiliser un numéro existant mais qui diffèrerait sur le doublage.

En tout cas, la deuxième solution que tu envisages ne fera économiser aucun temps à un traducteur, ou alors seulement s'il pense à vérifier si le texte n'existe pas déjà. En effet, si tu reprends le texte à l'identique dans ton mod au lieu de pointer directement sur le numéro de texte existant, le traducteur aura un texte à prendre en compte dans le fichier tra et si tu n'indiques pas par un commentaire qu'il s'agit du même texte que le numéro N d'origine, il ne saura pas qu'il peut s'économiser un effort de traduction.

Posté : sam. 06 avr. 2013, 11:58
par Freddy_Gwendo
Merci pour ta réponse.

Juste deux précisions :

1. En me relisant, je me rends compte que je m'étais mal exprimé : c'était la première solution que j'employais pour alléger les éventuelles trads. C'est pourquoi la question m'a taraudé l'esprit lorsque j'ai commencé à recoder en utilisant la seconde.

2. D'expérience, je pense que WeiDU vérifie aussi la présence de fichiers sons.
Lors de mes premières compilations, j'avais utilisé certaines références comme :

@nnnnnn = ~Texte existant : xxxxx~ [NOUVEAU FICHIER SON]

WeiDU créait alors une nouvelle entrée dans le fichier dialog, que la référence originale xxxxx dispose ou non d'un fichier son dédié.


Mais je pense que je vais utiliser un mix. Dans l'exemple, ça donnera ceci dans le fichier tra :

@2001001 = ~Vous remarquez que ce bâtiment tombe en ruines. Ce serait folie d'y pénétrer.~ //#5767

après avoir précisé en début de fichier tra que dans ce cas, le texte @2001001 correspond exactement à l'enregistrement #5767 du fichier dialog.tlk.