L'aide intégrée à l'interface de traduction

[Moni]

Bonjour,

je me suis attelée petit à petit à la traduction de l'aide en occitan,
j'avoue que je trouve ça un peu rude...
ça serait vraiment super si c'était intégré à l'interface de traduction...
    - le travail serait plus pratique
    - on verrait les choses s'intégrer au fur et à mesure (ça encourage drôlement)
    - on pourrait comparer avec les autres langues de la même famille (j'avoue que je suis allée de temps en temps regarder le gallego, l'italien et l'espagnol quand j'avais des états d'âme)
    - il y aurait peut-être des volontaires pour m'aider (l'espoir fait vivre)
bref, ce serait le paradis ...

Monia

[Florent_Jugla]

Salut Monia,

On Mon, 2003-07-21 at 09:14, Aprene wrote:

ça serait vraiment super si c'était intégré à l'interface de traduction...
    - le travail serait plus pratique
    - on verrait les choses s'intégrer au fur et à mesure (ça encourage
...

Ah ! content de l'entendre dire

Pour faire cela, il faudrait un peu modifier le fichier "aide" dans le
sens que j'avais proposé il y a quelques temps : transformer le fichier
"aide" en un fichier semblable aux fichiers spip_lang existants en
attribuant un nom de variable arbitraire à chaque ligne du fichier, puis
modifier un peu le code de SPIP pour afficher l'aide en tenant compte de
ces variables (mais ça ne doit pas être trop dur, puisqu'il suffirait
de concaténer toutes les chaines du fichier pour se trouver exactement
dans la situation actuelle).

Ensuite, l'aide serait intégrée à l'interface de traduction comme un
nouveau module (le code de l'interface est déjà prêt).

Je veux bien faire le boulot d'intégration des fichiers "aides" existants,
au niveau SPIP, je pense que la modif à faire est vraiment ridicule (je me
trompe ?)

Peut-être y a t'il une meilleure solution, mais je ne vois pas comme ça.
Des idées ? Je me lance là dedans ?

Florent

[fil]

Pour faire cela, il faudrait un peu modifier le fichier "aide" dans le
sens que j'avais proposé il y a quelques temps : transformer le fichier
"aide" en un fichier semblable aux fichiers spip_lang existants en
attribuant un nom de variable arbitraire à chaque ligne du fichier, puis
modifier un peu le code de SPIP pour afficher l'aide en tenant compte de
ces variables (mais ça ne doit pas être trop dur, puisqu'il suffirait
de concaténer toutes les chaines du fichier pour se trouver exactement
dans la situation actuelle).

Attention : l'aide en ligne peut être sollicitée à un moment où SPIP n'est
pas installé. Sinon, je n'ai pas d'objection sur le fond.

-- Fil

[63438612493668b99328]

Salut,

Ah ! content de l'entendre dire

Pour faire cela, il faudrait un peu modifier le fichier "aide" dans le
sens que j'avais proposé il y a quelques temps : transformer le fichier
"aide" en un fichier semblable aux fichiers spip_lang existants en
attribuant un nom de variable arbitraire à chaque ligne du fichier, puis
modifier un peu le code de SPIP pour afficher l'aide en tenant compte de
ces variables (mais ça ne doit pas être trop dur, puisqu'il suffirait
de concaténer toutes les chaines du fichier pour se trouver exactement
dans la situation actuelle).

Je ne suis toujours pas d'accord. Je n'ai rien contre éditer l'aide
dans l'interface de traduction, mais le format du fichier doit
rester tel qu'il est actuellement. En tout cas, pas moins lisible.

(au fait, découper l'aide en "lignes", c'est totalement idiot.
L'aide est structurée en entrées distinctes qui font un nombre
arbitraire de paragraphes chacune. Si tu ne veux pas perdre
le contexte, tu ne peux pas subdiviser ces entrées)

a+

Antoine.

[Pascale]

Quelques remarque juste avant de partir en vacances :
- pour leiconfort des traducteurs et en vue d'un travail de relecture et
d'amélioration de la trad avec d'autres personnes ( aspect coopératif), et
des évolutions futures éventuelles, l'intégration du fichier "aide" dans
l'interface de traduction de Florent s'impose. Pour l'instant, chacun a
bricolé comme il a pu. Et le travail est lourd et long. Pour certaines
langues, les questions linguistiques sont déjà suffisamemnt balaiseS. Si on
pouvait alléger les pb d'organisation ( intervention à plusieurs) avec un
tel système, ce serait une bouffée d'oxygène. franchement.

Pour couper la poire en deux entre ce que propose Antoine et Florent, on
pourrait peut-être découper le fichier d'aide en gros paragraphes faisant
unités de sens. Ceratins resteraient identiques ( le splus courts) et pour
les très longs, on aurait le même nom plus un numéro indiquant sa place dans
la structure du texte.
On doit pouvoir trouver une solution médiane, qu'en pensez-vous ? En jouant
sur les noms et les numéros, on pourrait contrôler l'ordre d'apparition ( et
peut-être de traduction*) des paragraphes et préserver leur présentation
contextuelle.

Amicalement

Pascale

* quoiqu'en fait actuellement chacun commence et s'organise comme il veut,
même dans un ordre non logique, et suivant le niveau de difficultés, sa
motivation, etc).

_______________________________________________
spip-trad@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-trad
Traductions de SPIP et de sa documentation : http://rezo.net/trad_spip/

[63438612493668b99328]

Salut,

Pour couper la poire en deux entre ce que propose Antoine et Florent, on
pourrait peut-être découper le fichier d'aide en gros paragraphes faisant
unités de sens. Ceratins resteraient identiques ( le splus courts) et pour
les très longs, on aurait le même nom plus un numéro indiquant sa place dans
la structure du texte.
On doit pouvoir trouver une solution médiane, qu'en pensez-vous ? En jouant
sur les noms et les numéros, on pourrait contrôler l'ordre d'apparition ( et
peut-être de traduction*) des paragraphes et préserver leur présentation
contextuelle.

Le problème se situe en amont. Florent propose de remplacer le
format actuel du fichier d'aide (lisible, éditable) par un format
PHP (imbouffable pour des textes longs). Je réponds que l'on peut
"intégrer" les fichiers d'aide à l'interface de traduction, mais
que ce n'est pas une raison pour changer le format de fichier
en un format plus médiocre. Il est plus commode d'utiliser un
éditeur de texte qu'un formulaire HTML pour éditer un texte long ;
il ne faut pas remettre en cause cet acquis.

Après, pour l'histoire du découpage en paragraphes ou "unités
de sens", je trouve ça idiot : est-ce que l'interface d'édition
de SPIP découpe les articles en "unités de sens" ? Mais là,
c'est le problème des traducteurs, pas le mien (tant que
le format de fichier ne change pas ;-))

Pour ce qui est de "couper la poire en deux", il est sûrement
possible de résoudre le problème posé sans toucher au format
de fichier, ou en le remplaçant par un format tout aussi
facilement modifiable...

a+

Antoine.

[Florent_Jugla]

Salut Antoine,

On Mon, 2003-07-21 at 13:17, Antoine wrote:

Salut,
e fichier ne change pas ;-))

Pour ce qui est de "couper la poire en deux", il est sûrement
possible de résoudre le problème posé sans toucher au format
de fichier, ou en le remplaçant par un format tout aussi
facilement modifiable...

je ne vois pas trop comment faire sans toucher le fichier... le problème
est d'arriver à faire correspondre des chaines entre les différentes
langues. On ne peut pas conserver un fichier "plat" pour faire cela. A
partir de là, il faut ajouter une manière d'identifier les chaines.

Par ailleurs, je ne crois pas que le fichier deviendrait moins lisible.
En gros, au lieu d'avoir un fichier du genre :

----------------
...
<UL><LI>vous connecter par le Web avec votre butineur habituel; lorsque
vous lancez l'action, SPIP vous indique un nom du type
&laquo;admin_{xxxxx}&raquo;, qu'il vous faut recopier;</LI>

<LI>vous connecter au serveur de votre site par FTP; l&agrave;, dans
le dossier <TT>/ecrire/data</TT>, cr&eacute;ez un fichier (ou un
r&eacute;pertoire vide) portant le nom
&laquo;admin_{xxxxx}&raquo;;</LI>

<LI>une fois ce fichier ou ce dossier cr&eacute;&eacute;, retournez
&agrave; votre butineur Web, et rechargez la page. D&egrave;s lors,
l'authentification par FTP est r&eacute;alis&eacute;e, et l'action
d&eacute;sir&eacute;e est d&eacute;clench&eacute;e.</LI>
...
--------------

tu aurais un fichier du genre
----------------
...
chaine_0050 = "<UL><LI>vous connecter par le Web avec votre butineur
habituel; lorsque vous lancez l'action, SPIP vous indique un nom du type
&laquo;admin_{xxxxx}&raquo;, qu'il vous faut recopier;</LI>",

chaine_0060 = "<LI>vous connecter au serveur de votre site par FTP;
l&agrave;, dans le dossier <TT>/ecrire/data</TT>, cr&eacute;ez un
fichier (ou un r&eacute;pertoire vide) portant le nom
&laquo;admin_{xxxxx}&raquo;;</LI>",

chaine_0070 = "<LI>une fois ce fichier ou ce dossier cr&eacute;&eacute;,
retournez &agrave; votre butineur Web, et rechargez la page. D&egrave;s
lors, l'authentification par FTP est r&eacute;alis&eacute;e, et l'action
d&eacute;sir&eacute;e est d&eacute;clench&eacute;e.</LI>
...
--------------

... je suis d'accord avec toi, c'est moche. Mais bon, je ne vois pas
d'autre solution.

Florent

[63438612493668b99328]

Salut,

je ne vois pas trop comment faire sans toucher le fichier... le problème
est d'arriver à faire correspondre des chaines entre les différentes
langues. On ne peut pas conserver un fichier "plat" pour faire cela. A
partir de là, il faut ajouter une manière d'identifier les chaines.

Je ne vois toujours pas l'intérêt de travailler sur des chaînes
découpées dans le texte plutôt que sur une entrée entière de la doc.
En quoi est-il plus difficile de comparer deux textes en vis-à-vis ?

(surtout que tout cela présuppose que les traductions soient
littérales, alors qu'on peut imaginer qu'un traducteur ait
envie d'ajouter des paragraphes d'explication, de réordonner
le texte... il n'est pas interdit d'améliorer le texte si on
en a envie ; si tu figes l'aide en paragraphes, cela devient
impossible)

Au pire, tu peux ajouter des balises autour des "unités de sens"
dont parle Pascale... Mais bof.

a+

Antoine.

[George_Kandalaft1 (George Kandalaft)]

Antoine wrote:

Je ne vois toujours pas l'intérêt de travailler sur des chaînes
découpées dans le texte plutôt que sur une entrée entière de la doc.
En quoi est-il plus difficile de comparer deux textes en vis-à-vis ?

(surtout que tout cela présuppose que les traductions soient
littérales, alors qu'on peut imaginer qu'un traducteur ait
envie d'ajouter des paragraphes d'explication, de réordonner
le texte... il n'est pas interdit d'améliorer le texte si on
en a envie ; si tu figes l'aide en paragraphes, cela devient
impossible)

Je partage l'avis d'Antoine sur le fichier d'aide. La traduction, quoique un peu longue n'a pas ete genante (et pourtant j'en ai fait deux: arabe et anglais). On a devant soit tout le contexte de l'idee developpee. Je crois que si c'etait decoupe on perd un peu ce contexte. La seule chose qui serait bien, a l'avenir, c'est de pouvoir savoir tout de suite, dans une nouvelle version de l'aide, ce qui a ete modifie, ce qui est nouveau, et ce qui est reste inchange. Donc j'imagine qu'il y aurait une internetion quelconque sur ce fichier.

George

[Florent_Jugla]

On Mon, 2003-07-21 at 14:43, Antoine wrote:

Salut,

Au pire, tu peux ajouter des balises autour des "unités de sens"
dont parle Pascale... Mais bof.

ok, je vais voir ce que je peux faire (surement demain mardi).

Florent

[Florent_Jugla]

On Mon, 2003-07-21 at 17:56, George Kandalaft wrote:

Antoine wrote:

>
>
Je partage l'avis d'Antoine sur le fichier d'aide. La traduction,
quoique un peu longue n'a pas ete genante (et pourtant j'en ai fait
deux: arabe et anglais). On a devant soit tout le contexte de l'idee
developpee. Je crois que si c'etait decoupe on perd un peu ce contexte.
La seule chose qui serait bien, a l'avenir, c'est de pouvoir savoir tout
de suite, dans une nouvelle version de l'aide, ce qui a ete modifie, ce

c'est bien de cela qu'il s'agit. Pour connaitre cette information, il
faut pouvoir repérer dans le fichier les changements. Cela signifie soit
qu'on peut les repérer en comparant directement les fichiers, ce qui est
quasi impossible dans ce cas (ou si tu connais l'algo, je suis preneur),
soit qu'on maintient une liste de marqueurs permettant de faire les
correspondances quelque part à l'extérieur des fichiers, mais ça va vite
devenir lourd à gérer, soit qu'on marque chaque chaine, ce qui est la
solution proposée. Ainsi, quand Antoine enlève ou ajoute une chaine,
celle-ci passe automatiquement dans le statut NEW ou CONFLIT dans
l'interface de traduction. Tu peux donc les repérer tout de suite.

Florent

[Daniel]

Je partage l'avis d'Antoine sur le fichier d'aide.

A travailler sur l'aide en espagnol, je trouve aussi que le pseudo-xml existant est très bien, même si une gestion des caractères spéciaux HTML serait un plus par rapport au fichier texte brut dans un éditeur de base.

La seule chose qui serait bien, a l'avenir, c'est de pouvoir savoir tout
de suite, dans une nouvelle version de l'aide, ce qui a ete modifie, ce

c'est bien de cela qu'il s'agit. Pour connaitre cette information, il
faut pouvoir repérer dans le fichier les changements. Cela signifie soit
qu'on peut les repérer en comparant directement les fichiers, ce qui est
quasi impossible dans ce cas (ou si tu connais l'algo, je suis preneur),

Je ne connais pas le code de l'interface de traduction et je suis peut être un peu naïf et simpliste, mais :

1/ qu'est-ce qui empêche de développer un module pour l'interface de traduction qui "parse" le pseudo-xml du fichier existant?

2/ le "diff" classique de GNU/Linux, ne permet-il pas justement d'identifier les différences entre deux fichiers textes (comme dans un CVS)?
Certes, à traiter le fichier directement dans un éditeur, on fait des coupures de ligne un peu n'importe où (sans compter les CR/LF mac-win-unix...), ce qui le rend difficilement exploitable avec diff, mais justement, si la saisie et sauvegarde se fait depuis un formulaire de saisie, ça devrait normaliser tout cela.

---
Daniel (dani@easynet.fr)
--------
" Con libertad, ni ofendo ni temo "
José Gervasio Artigas - divisa de MonteVIdeO

[Florent_Jugla]

On Mon, 2003-07-21 at 19:56, Daniel Viñar Ulriksen wrote:

Je ne connais pas le code de l'interface de traduction et je suis peut
être un peu naïf et simpliste, mais :

1/ qu'est-ce qui empêche de développer un module pour l'interface de
traduction qui "parse" le pseudo-xml du fichier existant?

rien n'empêche cela, mais ça ne résoud pas le problème de faire
correspondre les chaines entre elles entre fichiers dans des langues
différentes.

2/ le "diff" classique de GNU/Linux, ne permet-il pas justement
d'identifier les différences entre deux fichiers textes (comme dans un
CVS)?

le diff est pratique lorsque on travaille sur des versions différentes
d'un même fichier. Ici il s'agit de trouver les différences entre
fichiers différents. On peut imaginer un système où on stockerait les
différentes versions du fichier français par exemple, puis on ferait les
différences sur ces versions, mais là encore, on ne saurait pas comment
faire correspondre les différences trouvées avec les fichiers dans les
autres langues.

Certes, à traiter le fichier directement dans un éditeur, on fait des
coupures de ligne un peu n'importe où (sans compter les CR/LF
mac-win-unix...), ce qui le rend difficilement exploitable avec diff,
mais justement, si la saisie et sauvegarde se fait depuis un formulaire
de saisie, ça devrait normaliser tout cela.

oui c'est un des avantages.

Florent