Page 2 sur 2

Re: Version multilingue

Posté : 30 juin 2011, 23:56
par Gingko
Bonjour,

L'idée que j'avais était assez proche de la méthode « gettext », à savoir un système qui utilise les chaînes natives (en principe en anglais) comme « clés » et qui cherche à leur substituer la chaîne de remplacement qui leur est associée dans la langue voulue.

Mais je n'avais pas envisagé « gettext » (on peut cependant y songer), en fait je pensais utiliser la méthode utilisée dans les logiciels de Grig Software, qui permettent d'avoir comme fichier de langue un simple fichier de texte avec pour chaque terme à traduire la succession répétitive d'une ligne dans la langue source, une ligne dans la langue cible et une ligne vide.

De cette manière, si une chaîne source n'est pas trouvée dans le fichier de langue, alors la substitution ne se fait pas et on laisse le texte dans la langue source, ce qui éviterait l'inconvénient d'y voir apparaître une clé en clair dans ce cas-là.

Ce qui aurait accessoirement l'avantage de permettre d'utiliser l'utilitaire WinTrans que Grig Software propose pour traduire ses propres programmes. :mrgreen:

Pour les boîtes de dialogue, je pensais créer une fonction appelée à l'initialisation du dialogue, qui s'occuperait d'énumérer un par un tous les items du dialogue en en récupérant les textes, de soumettre les textes à la traduction, et de remettre la version traduite à la place.

J'ai aussi envisagé quelques raffinements, comme par exemple des traductions partielles de chaînes (par exemple les seules parties entourées par des délimiteurs définis, délimiteurs simplement supprimés si la traduction est manquante), ou même carrément par endroits (pas partout pour des questions de performances) l'usage d'expressions régulières, l'une ou l'autre de ces méthodes permettant de traduire sans trop de problèmes certaines chaînes composées dynamiquement.

Gingko

Re: Version multilingue

Posté : 01 juil. 2011, 17:14
par lolo_32
Gingko a écrit :[…] en fait je pensais utiliser la méthode utilisée dans les logiciels de Grig Software, qui permettent d'avoir comme fichier de langue un simple fichier de texte avec pour chaque terme à traduire la succession répétitive d'une ligne dans la langue source, une ligne dans la langue cible et une ligne vide.
Mais cette méthode ne pose-t-elle pas un problème si on utilise on texte contenant des retours de ligne (Entrée) ? Il suffit peut-être d'utiliser la séquence "\n", encore faut-il que le traducteur y pense :?
Gingko a écrit :[…]Ce qui aurait accessoirement l'avantage de permettre d'utiliser l'utilitaire WinTrans que Grig Software propose pour traduire ses propres programmes. :mrgreen:
L'usage de gettext peut aussi passer par l'utilisation d'un excellent éditeur, Poedit, qui peut aussi aider pour traduire certaines chaînes, car il peut les approximer en fonction d'une base de données interne ou d'autres traductions disponibles sur la machine.
Gingko a écrit :Pour les boîtes de dialogue, je pensais créer une fonction appelée à l'initialisation du dialogue, qui s'occuperait d'énumérer un par un tous les items du dialogue en en récupérant les textes, de soumettre les textes à la traduction, et de remettre la version traduite à la place.

J'ai aussi envisagé quelques raffinements, comme par exemple des traductions partielles de chaînes (par exemple les seules parties entourées par des délimiteurs définis, délimiteurs simplement supprimés si la traduction est manquante), ou même carrément par endroits (pas partout pour des questions de performances) l'usage d'expressions régulières, l'une ou l'autre de ces méthodes permettant de traduire sans trop de problèmes certaines chaînes composées dynamiquement.
Il faut de toute manière envisager le traitement de toutes les chaînes de caractères disponibles dans les fenêtres, à partir du moment où l'usage des ressources n'est pas retenu. Ce qui peut entrainer un petit problème : le texte traduit est plus long que le texte original, et la fenêtre n'est pas prévue pour le supporter; celui-ci est alors tronqué.

Ensuite, dernier raffinement par rapport à WinTrans de gettext : celui-ci extrait automatiquement les chaînes devant être traduite du code source

Re: Version multilingue

Posté : 02 juil. 2011, 08:09
par Gingko
lolo_32 a écrit :
Gingko a écrit :[…] en fait je pensais utiliser la méthode utilisée dans les logiciels de Grig Software, qui permettent d'avoir comme fichier de langue un simple fichier de texte avec pour chaque terme à traduire la succession répétitive d'une ligne dans la langue source, une ligne dans la langue cible et une ligne vide.
Mais cette méthode ne pose-t-elle pas un problème si on utilise on texte contenant des retours de ligne (Entrée) ? Il suffit peut-être d'utiliser la séquence "\n", encore faut-il que le traducteur y pense :?
S'il n'y avait que ça à quoi le traducteur devrait penser … :D

J'avais songé effectivement à un truc comme ça.

Une autre méthode possible serait de considérer de telles séquences comme deux traductions séparées, qui feraient l'objet de deux entrées séparées dans la liste de traduction.
lolo_32 a écrit :Il faut de toute manière envisager le traitement de toutes les chaînes de caractères disponibles dans les fenêtres, à partir du moment où l'usage des ressources n'est pas retenu. Ce qui peut entrainer un petit problème : le texte traduit est plus long que le texte original, et la fenêtre n'est pas prévue pour le supporter; celui-ci est alors tronqué.
Je sais, c'est une situation que j'ai toujours à l'esprit.

Mais c'est un problème qui se produit surtout en traduisant de l'anglais vers le français, beaucoup plus rarement l'inverse, et je ne sais pas s'il y a beaucoup de langues qui consomment encore plus de lettres que le français pour dire la même chose.

Comme tous nos dialogues ont été conçus en fonction du français, les anglophones ont plus de chances de se retrouver avec des dialogues trop vides qu'avec des textes qui dépassent la taille des items de dialogue.

Il suffit de continuer à concevoir nos dialogues en fonction du français, même si on y met des textes en anglais par défaut, et d'espérer que les futures traductions en hongrois, indonésien ou cherokee ne nous poseront pas de problèmes supplémentaires.
À noter qu'on n'a rien de prévu non plus pour les langues qui se lisent de droite à gauche.

Sinon pour gettext je ne sais pas trop, il faudrait que je prenne le temps de me plonger dans sa documentation, et vu tout ce que j'ai à faire, ça risque de prendre un moment, sauf nécessité urgente genre quelqu'un d'autre qui voudrait entreprendre de faire ça tout de suite.

Gingko

Re: Version multilingue

Posté : 02 juil. 2011, 15:12
par ronaldo1
Bonjour,
Je pense que la solution XML est la plus souple car elle permet une mise à jour rapide, il est aussi possible de faire un mini logiciel qui permet de remplir l'XML sans à se soucier des retours chariot... . Le traducteur peut voir directement ce qu'il fait sans à avoir compiler ni connaitre quoi que soit en programmation.

Voici un exemple de fichier utilisé pour les traductions de MMTv.

Code : Tout sélectionner

<?xml version="1.0" encoding="ISO-8859-2" ?>
<MeuhMeuhTV version="1.0" language="Catalan">
    <Messages>
    <p3000 valeur="Construcció de la barra d'estat... " />
    <p3001 valeur="Impossible assignació de memòria. " />
    <p3002 valeur="Creació de la finestra d'overlay... " />
    <p3003 valeur="Error CreateWindowEx " />
    <p3004 valeur="Inicialització de la configuració... " />
    <p3005 valeur="Fitxer Francais.xml no trobat " />
...
    </Messages>
</MeuhMeuhTV>

Re: Version multilingue

Posté : 02 juil. 2011, 15:28
par Curtis
quelle est la méthode de traduction la plus utilisée par les développeurs windows ?

car si l'idée est d'attirer un maximum de développeurs il serait intéressant d'utiliser la méthode la plus courante et standard pour ne pas les dépayser :mrgreen:

à chaud comme ça j'aurai une préférence pour la méthode gettext, ça se rapproche de ce que j'ai vu dans le développement logiciel en QT4

Re: Version multilingue

Posté : 02 juil. 2011, 15:43
par Gingko
ronaldo1 a écrit :Je pense que la solution XML est la plus souple car elle permet une mise à jour rapide, il est aussi possible de faire un mini logiciel qui permet de remplir l'XML sans à se soucier des retours chariot... . Le traducteur peut voir directement ce qu'il fait sans à avoir compiler ni connaitre quoi que soit en programmation.

Voici un exemple de fichier utilisé pour les traductions de MMTv.

Code : Tout sélectionner

<?xml version="1.0" encoding="ISO-8859-2" ?>
<MeuhMeuhTV version="1.0" language="Catalan">
    <Messages>
    <p3000 valeur="Construcció de la barra d'estat... " />
    <p3001 valeur="Impossible assignació de memòria. " />
    <p3002 valeur="Creació de la finestra d'overlay... " />
    <p3003 valeur="Error CreateWindowEx " />
    <p3004 valeur="Inicialització de la configuració... " />
    <p3005 valeur="Fitxer Francais.xml no trobat " />
...
    </Messages>
</MeuhMeuhTV>
En tout cas, XML ou pas XML, ce que je ne veux surtout pas voir dans Pouchin TV Mod, c'est cette référence par numéros.

Justement après avoir étudié le code source de MMTv.

Gingko

Re: Version multilingue

Posté : 02 juil. 2011, 16:57
par lolo_32
Gingko a écrit :
ronaldo1 a écrit :Je pense que la solution XML est la plus souple car elle permet une mise à jour rapide, il est aussi possible de faire un mini logiciel qui permet de remplir l'XML sans à se soucier des retours chariot... . Le traducteur peut voir directement ce qu'il fait sans à avoir compiler ni connaitre quoi que soit en programmation.

Voici un exemple de fichier utilisé pour les traductions de MMTv.

Code : Tout sélectionner

<?xml version="1.0" encoding="ISO-8859-2" ?>
<MeuhMeuhTV version="1.0" language="Catalan">
    <Messages>
    <p3000 valeur="Construcció de la barra d'estat... " />
    <p3001 valeur="Impossible assignació de memòria. " />
    <p3002 valeur="Creació de la finestra d'overlay... " />
    <p3003 valeur="Error CreateWindowEx " />
    <p3004 valeur="Inicialització de la configuració... " />
    <p3005 valeur="Fitxer Francais.xml no trobat " />
...
    </Messages>
</MeuhMeuhTV>
En tout cas, XML ou pas XML, ce que je ne veux surtout pas voir dans Pouchin TV Mod, c'est cette référence par numéros.

Justement après avoir étudié le code source de MMTv.
Tout a fait d'accord, car pour suivre les messages affichés, il faut obligatoirement avoir en parallèle le fichier de langue, et rechercher sans cesse dans celui-ci la signification du sigle.

En effet, que signifierait "p3000" dans le code source sans faire le parallèle :?

Re: Version multilingue

Posté : 02 juil. 2011, 17:31
par ronaldo1
Il est claire que ce n'est pas parlant la numérotation. Par contre l'utilisation de fichier externe pour qu'un un traducteur non développeur puisse traduire les phases rend la traduction plus facile surtout on leur propose un logiciel qui facilite la tâche (plus besoin de connaitre la structure du fichier).

Re: Version multilingue

Posté : 03 juil. 2011, 00:42
par ronaldo1
J'ajouterai qu'avec un logiciel externe il sera possible de mettre en valeur les rajouts et les modifications par rapport à une version de PTV

Re: Version multilingue

Posté : 08 août 2011, 17:44
par lolo_32
Par contre, après avoir analysé plus en profondeur, et pour faciliter la vie des « futurs » traducteurs, je me demande s'il est toujours utile de maintenir une version « SBCS » en même temps que la version « UNICODE » ?

En effet, à cause des « A2t », « T2a », « T2w », « W2t », et autres fonctions utilisées pour maintenir cette compatibilité, les chaînes de caractères générées ne sont pas identiques en fonction du type de compilation choisit. Sinon, il faudrait utiliser un caractère de substitution dans les chaînes devant être traduites.

Re: Version multilingue

Posté : 09 août 2011, 00:47
par Gingko
lolo_32 a écrit :Par contre, après avoir analysé plus en profondeur, et pour faciliter la vie des « futurs » traducteurs, je me demande s'il est toujours utile de maintenir une version « SBCS » en même temps que la version « UNICODE » ?
Étant donné que ça existe et que c'est fonctionnel, j'aime autant qu'on le garde, même si on ne diffuse pas ces compilations. Ça peut servir dans le futur. Et puis ça va avec la technique « TCHAR » de Microsoft, qui a été prévue pour ça.
lolo_32 a écrit :En effet, à cause des « A2t », « T2a », « T2w », « W2t », et autres fonctions utilisées pour maintenir cette compatibilité, les chaînes de caractères générées ne sont pas identiques en fonction du type de compilation choisit. Sinon, il faudrait utiliser un caractère de substitution dans les chaînes devant être traduites.
C'est sûr que c'est un souci auquel il faut penser, mais ce n'est pas un problème épouvantable. Pas plus en tout cas que celui des « & » dans les menus et boîtes de dialogue, pour définir certains types de raccourcis clavier.

Gingko

Re: Version multilingue

Posté : 18 août 2011, 22:23
par F5BJR
*