Des informations sur les langues pour SVP - commentaires

Des informations sur les langues pour SVP

Je reviens sur le fichier « archivelist.txt », parce qu'y donner un plein accès à tout ceux qui veulent juste y rajouter une ligne ne me paraît fondamentalement pas bon.

On rajoute une ligne à ce fichier typiquement lorsqu'on développe un plugin, et qu'une nouvelle version de SPIP force à le modifier de sorte que le résultat soit compatible avec la nouvelle version de SPIP mais incomptabile avec les anciennes. Du coup, on fait un « svn copy » de la version courante, qu'on gèle, et on demande un Zip de plus. Mais avec Subversion, « svn copy » est équivalente à la création d'un Tag, aussi en définitive ce fichier « archivelist.txt » n'est pas autre chose que la liste implicite des Tags des utilisateurs de la zone.

Que ce soit implicite conduit à des insatisfactions : le répertoire d'un plugin n'est plus le plugin mais un ensemble de « sous-plugin », et le nom des plugins tend à intégrer le numéro de version de SPIP pour lequel il est compatible, ce qui prête à confusion.

Je pense donc que le plus simple serait de renoncer à ce fichier, et de dire simplement que smart_parquets crée des Zip pour chaque sous-répertoire de la Zone, les utilisateurs étant invité à faire « svn copy » dans le répertoire Tag quand il s veulent geler un état de leur plugin et consorts.

Des informations sur les langues pour SVP

Ah en effet oui, voici la bonne syntaxe :

svn co —depth=files svn ://zone.spip.org/spip-zone/

En cherchant « SPIP archivelist.txt » sur le Web, j'ai fini par trouver la page qui parle de la gestion de ce fichier, elle est sur SPIP-Contrib : Publier-archivelist-txt-via-svn mais elle donne la syntaxe obsolète avec -N (j'ai signalé la nouvelle dans le forum). Mais si même toi ne retrouvais plus la bonne syntaxe, ça veut dire qu'il n'y a pas grand monde qui l'utilise. Ok, pour laisser tomber ma conclusion qu'il fallait un sous-répertoire, en revanche une mention dans le Wiki de Zone-SPIP parait nécessaire, et encore mieux le formulaire de modif, qui aurait l'avantage d'éviter les accidents où des lignes disparaissent involontairement.

Des informations sur les langues pour SVP

Non avec SVN il y a une option pour récupérer le contenu d'un répertoire en désactivant la récursivité.

svn co —depth files svn ://....

Un truc comme ça.

Des informations sur les langues pour SVP

Ce n'est pas exactement le sujet, mais c'est quand même très lié : sauf erreur, on ne peut modifier le fichier archivelist.txt qu'avec SVN lequel impose qu'on ait copié tout le répertoire où figure ce fichier, c'est-à-dire toute la zone ! Il serait tout de même plus raisonnable de mettre ce fichier dans un sous-répertoire afin de pouvoir le charger et l'envoyer sans saturer son disque local.

Une alternative serait de prévoir un formulaire de modification de ce fichier, lié aux droits du visiteur sur le site de dépôt.

Des informations sur les langues pour SVP

Voilà exactement,

Dans le fichier archives.xml on a toutes les informations nécessaires pour reconstituer l'url des sources car l'idée est qu'en s'appuyant sur SVP, STEP puisse aussi faire des mises à jour par SVN si le serveur le permet.

Pour les fichiers de langue de SPIP, oui il faut trouver un autre moyen mais aujourd'hui c'est déjà un peu « bancal ».

Des informations sur les langues pour SVP

Je reviens sur le dernier paragraphe de mon précédent message (le premier c'était de l'humour, hein). Contrairement à mon souvenir, on a bien prévu de mémoriser dans le fichier XML final le répertoire précis des sources empaquetées, répertoire donné par
archivelist.txt mais sans spécifier l'URL complète qui est reconstituée implicitement à l'aide de l'URL où on trouve arhivelist.txt, autrement dit l'URL du dépot que tu as effectivement ajouté dans l'attribut « src » de la balise « depot » à la racine du fichier XML final.

Il est donc possible de retrouver à partir de ce dernier fichier ce qui est fourni actuellement par traductions.txt, à l'exception toutefois des fichiers de langues du noyau de SPIP. Si l'on veut que ce fichier XML puisse aussi fournir ces informations, il est indispensable qu'on passe sous forme d'extension les fichiers de langues du noyau.

Des informations sur les langues pour SVP

Si tu n'est pas coupable de contradiction dans ton point 3, alors au moins tu es coupable d'utiliser du franglais, idiome qui ne fait pas partie des codes ISO-639, d'où mon incompréhension.

Pour la production du nom d'un traducteur, je les voyais plutôt à placer dans les fichiers qu'il a traduit, sur le modèle du Copyright qu'il y a en tête des fichiers du noyau de SPIP. Mais c'est vrai que demander à Salvatore de produire directement un fichier XML contenant la balise « traduction », ses sous-balises « langue » et sous-sous-balise « traducteur » serait plus facilement exploitable. Mais alors il serait sympa que l'en-tête du fichier de langue mentionne son existence. Un point qui est encore à préciser c'est comment joindre un traducteur : si on refuse le mail (cf. ci-dessus), il faudrait sa page d'auteur sur spipnet. Mais existe-t-elle toujours et TradLang la connaît-il ?

Enfin, il me semble que tu as oublié un point important quand tu parles de l'URL du dépôt : ce dont a besoin TradLang c'est l'URL complète du répertoire de langues de l'extension de SPIP concernée, or il ne suffit pas de connaître l'URL du dépot pour retrouver cette information : cette extension n'est pas forcément dans le sous-répertoire « plugins » de la racine, et elle peut avoir comme sous-répertoires différentes versions. L'URL complète est donné par archivelist.txt,, mais sauf erreur on n'a pas prévu de la mémoriser dans le fichier XML produit au final.

Des informations sur les langues pour SVP

@Esj

Non non il n'y a rien de contradictoire dans ma proposition mais tu viens de préciser une chose importante sur la génération du fichier traductions.txt utilisé par TradLang. Dans ce cas oui il est possible d'insérer l'information de traduction du plugin dans son fichier xml.

Cela valide aussi le fait que tradLang génère un fichier par plugin ou module pour préciser les informations sur les langues disponibles et les traducteurs. Je préfèrerais un fichier xml directement intégrable dans archives.xml.

Enfin, je ne pense pas que ce soit à smart-paquets de créer le fichier traductions.txt. Donc je serais plutôt favorable à ce que TradLang utilise archives.xml car j'ai intégré il y a peu des informations sur le dépôt, dont l'url.

Des informations sur les langues pour SVP

@Rasta

Deux remarques :

Si SVP est dans le core il mettra toutes ses informations à disposition.
Cela va demander à smart-paquets d'ouvrir systématiquement ces fichiers pour en récupérer les informations. C'est possible mais dan ce cas il faudrait que ce soit un format xml directement intégrable dans archives.xml

Des informations sur les langues pour SVP

Pour le coup, c'est entre nous deux qu'il y a de l'incompréhension. Je reprends point par point.

Ok pour interdire les fichiers de langues ailleurs que dans le sous-répertoire « lang » de la racine.

Pour l'existence des modules, c'est un luxe sans doute inutile pour un plugin, mais comme le noyau les utilise massivement, il faut le gérer de toutes façons.

Les points 1 et 3 de ta première liste me paraissent contradictoires entre eux, et contradictoires avec les messages précédents qui, il est vrai, sont parfois un peu elliptiques. Je précise donc certaines choses.

Pour dire que des fichiers de langues d'un module de plugin doivent être traduits par Salvatore à partir d'une certaine langue de référence, il faut que que plugin.xml (ou plutôt paquet.xml) contienne une ligne comme :

Le script smart_paquets construit le fichier archive.xml à partir de chaque fichier paquet.xml, auquel il rajoute plusieurs choses décrites dans Des DTD pour décrire et archiver les plugins, et la présente discussion dit qu'en plus il va ajouter du contenu à la balise « traduction » ci-dessus. Ce contenu est composé de plusieurs balises « langue » comme indiqué par le message ci-dessus, ces balises « langue » étant déduites de l'analyse du répertoire « lang ».

Les sous-balises « traducteur » de ces balises langues doivent pouvoir être obtenues par analyse des dits fichiers de langues, ce qui veut dire que les noms des traducteurs doivent se trouver à un endroit conventionnel de ce fichier, ce que ce message sur spip-trad semblait amorcer (mais qu'il faudrait conclure).

A partir de ces informations, smart-paquets peut synthétiser le fichier traduction.txt actuellement géré collectivement par tous les auteurs de plugins traduits, et exploité par TradLang.

Je pense toutefois que la production de ce fichier ne s'impose plus, TradLang pouvant exploiter archive.xml. Mais en l'état, sauf erreur, il y manque l'URL du dépot des plugins, qu'il faudrait alors rajouter quelque part.

Des informations sur les langues pour SVP

Non, avec Fil on parlait de faire en sorte que Salvatore ajoute des fichiers d'informations sur les contributeurs dans chaque dossier de contribution. Car c'est une information qui doit être trouvable dans le dossier peu importe comment on l'a récupéré. Et il doit pouvoir être exploité, interfacé, affiché, etc, pareil peu importe la manière dont on l'a récupéré. C'est pas juste pour SVP quoi ! Dans la page d'admin des plugins, on doit pouvoir afficher « traduit par Machin, Bidule, et Truc » afin de remercier et de mettre en avant ces contributeurs au même titre que l'auteur, alors qu'ils sont invisibles actuellement.

Il y aurait donc un fichier lang/traducteurs.xxx (format indéfini pour l'instant), qui serait ajouté par Salvatore en même temps que les lang/module_xx.php.

Des informations sur les langues pour SVP

Hello,

Bon je reprends au bond votre conversation après avoir relu calmement et discuté avec Rastapopoulos.

Les fichiers de langue en dehors de racine/lang sont à proscrire à mon avis : ça n'apporte rien sauf des cas tordus à gérer. Déjà que je trouve inutilement complexe le fait d'avoir plusieurs modules possibles pour un plugin, souvent avec public et privé ce qui est un non sens car in fine si on voulait séparer il faudrait souvent dupliquer !

Pour revenir à la vraie discussion, une mise en oeuvre possible pour permettre à SVP de récupérer ces informations serait :

Tradlang genère un fichier des traductions supportées par salvatore (je sais pas si tout est salvatorisé dans tradlang ?).
Ce fichier est dans la zone, au même niveau que archivelist.txt et se nommerait traductions.xxx
Tradlang fait donc un up régulier de ce fichier

Ensuite, coté smart-paquets :

pour chaque paquet on rajoute la scrutation de tous les modules et traductions dans lang/ (on sait pas à ce moment si c'est salvatorisé ou pas)
On lit le fichier des traductions pour construire un tableau module/paquet - traductions et traducteurs
lors de la création du fichier archives.xml on ajoutent les informations de traductions comme un bloc xml inclus dans

Je pense ensuite créer un ou deux champs dans la table paquets pour y stocker toutes ces informations en tableaux sérialisés et des fonctions d'affichage idoines.

Des informations sur les langues pour SVP

Ok, ce coup-ci on s'est bien compris.

On a laissé tomber l'attribut « dir », mais dans le fichier traduction.txt il y a 13 cas où le répertoire des fichiers de langues n'est pas le sous-répertoire de la racine nommé « lang », il faut voir si on introduit ce paramètre ou si on peut exiger un renommage standard (a priori ce serait mieux).

Si on veut laisser tomber ce fichier, outre le problème ci-dessus, il y a le cas des 3 modules de langues du noyau qu'il faut bien déclarer quelque part à Salvatore. Mais la je me demande si ça ne serait pas l'occasion de passer tous les fichiers de langue du noyau dans les Extensions, ce qui aurait d'autres avantages.

Enfin, mais ce n'est pas vraiment lié, je ne trouve pas très commode la situation actuelle où Fil doit se coller à la main les envois de Salvatore. Ca me paraîtrait plus logique que l'auteur d'un plugin ou d'une extension puisse (et doive) provoquer cet envoi pour ce qui le concerne.

Des informations sur les langues pour SVP

Allez même si on explique de manière descriptive, c'est toujours mieux de visualiser en même temps. :)

<traduction module="menus" gestionnaire="salvatore" reference="fr"> ...
</traduction>

Ça me parait pas mal, tout ça.

Des informations sur les langues pour SVP

Ah ok, tu parles de ce qu'on nomme en SPIP les « modules de langue », on ne parle pas de « préfixe de langue ». Et j'ai été abusé par l'attribut « id » : il ne faut surtout pas l'utiliser ici car en XML l'attribut de nom « id » est spécial en ce qu'il ne peut y avoir dans un document XML deux attributs « id » de même valeur, et donc ici ça exclurait que deux plugins utilisent les mêmes noms de modules.

Donc effectivement il faut une balise englobante pour les balises langues, ok pour l'appeler « traduction » mais il faut prendre autre chose que « id » comme nom d'attribut, par exemple « module ». Par ailleurs, la valeur « oui » de l'attribut « reference » n'est pas très internationale, je propose plutôt que cet attribut passe dans la balise « traduction » avec comme valeur le code de la langue de référence.

Des informations sur les langues pour SVP

Mon attribut « id » correspond au préfixe qui identifie le fichier de langue traduit. Car lorsque tu parles des « infos connus » ce n'est pas le préfixe du plugin, mais le préfixe du fichier de langue, qui peut être n'importe quoi, et surtout qui peut être multiple. Dans une même contribution « montruc », on peut avoir « lang/montrucpublic_fr » et « lang/montrucprive_fr ». Bref, on fait ce qu'on veut.

C'est pour ça que pour un même paquet dans archivelist.txt, il y a une ligne par paquet, sauf que pour les fichiers de langue ça peut être plusieurs lignes... : c'est justement le truc pertinent que tu disais dans ton premier message et que j'avais complètement zappé.

Voilà pourquoi aussi dans mon exemple de XML, ce ne sont pas deux exemples l'un à la suite de l'autre, mais bien un seul exemple d'une seule contribution qui a deux ensembles de fichiers de langue. L'un nommé « truc » (truc_fr, truc_en, etc) qui est géré avec Salvatore, l'autre nommé « bidule » (bidule_fr, ...) qui est pour l'instant écrit à la main.

Des informations sur les langues pour SVP

Pour le mail j'ai bien écrit que c'était optionnel, et on a déjà eu une discussion là-dessus dans le
forum de discussion de la DTD de paquet.xml, j'y renvoie.

Je trouve assez lourd le fait que chacun doive modifier le fichier commun « traductions.txt », pour y copier des infos connues : le préfixe du plugin et l'URL de son dépot suivi dans 99% des cas de « /lang/ ». Je trouverai plus simple que chacun mette dans son plugin.xml une balise « traduction » avec l'attribut « ref » de valeur la langue de référence, et d'attribut « gestionnaire » la valeur « salavatore » s'il veut se faire traduire par lui (et rien si c'est manuel). On peut ajouter un attribut « dir » pour préciser le répertoire des fichiers de langues, mais le pourcentage ci-dessus montre que la valeur par défaut est devinable. Les 3 infos nécessaires à Salvatore seraient mise dans archivelist.

S'il ne faut effectivement pas déclarer automatiquement qu'un plugin est à traduire, en revanche si le paquet est fait systématiquement n'est pas dramatique : on peut donc se contenter de ça.

Sinon, je ne comprends pas ton attribut « id ».

Des informations sur les langues pour SVP

La décision « cette contribution est maintenant traduite avec Salvatore » est un choix qui doit absolument rester manuel, à la discrétion de l'auteur.

Le rôle de smart-paquet est uniquement de réussir à trouver l'information : oui ou non cette contribution dont je vais générer un paquet est-elle traduite avec Salvatore ?

Tu ajoutes une information qui m'avait échappé : la décision est bien faite fichier par fichier, et non pour tout un dossier, j'avais complètement zappé ça.

Je suis d'accord avec le fait de déjà découper l'information. Mais attention : le choix de Salvatore il n'est pas vraiment fait fichier par fichier mais préfixe par préfixe. Donc c'est un ensemble de fichiers ayant le même préfixe qui est traduit manuellement ou avec Salvatore. On ne peut donc pas avoir un élément « langue » pour chaque fichier avec un seul code de langue.

L'information complète serait donc :

un découpage préfixe par préfixe
si c'est manuel, on a juste la liste des langues
si c'est par Salvatore on a en plus
- quelle est la langue de référence (elle n'a donc pas de traducteurs)
- quels sont les traducteurs ayant participé

Ce qui donne alors :

<traduction id="truc" gestionnaire="salvatore"> <langue code="fr" reference="oui" /> <langue code="de"> <traducteur>Klaus</traducteur> <traducteur>Kent1</traducteur> </langue> <langue code="en"> <traducteur>Paolo</traducteur> </langue> <langue code="it"> <traducteur>Renato</traducteur> </langue>
</traduction>
<traduction id="bidule" gestionnaire="manuel"> <langue code="fr" /> <langue code="en" /> <langue code="es" />
</traduction>

Note : La production de ce XML est automatique, il est donc totalement impensable pour moi qu'on ajoute des informations normalement cachées, tel que le courriel, qui seront alors visible et récupérable par tous. On ne doit utiliser que le pseudonyme que la personne aura bien voulu mettre dans son compte spip-trad.

Des informations sur les langues pour SVP

Oui il est important de rajouter cette fonctionnalité, et c'est à smart_paquets de le faire. Il y a cependant, il me semble, des choses à revoir ou à préciser

Le fichier traductions.txt utilisé par Salvatore est modifié à la main par décision d'un auteur de plugin que celui-ci est suffisamment mûr pour être traduit. Si maintenant on dit que cette info est produite automatiquement par smart_paqet, comment celui-ci peut-il la déduire ? Parce que « etat » dans plugin.xml est « stable » ? Parce qu'il y a un commentaire qui le dit dans le fichier de langue de référence ? Parce qu'il n'y a plus de _L dans le code, seulement des _T ? Bref, comme le dit Rasta ce sont deux choses différentes, il faut continuer à pouvoir les dissocier. Mais ça n'interdit pas la fusion avec archivelist : il suffit d'un attribut qq part disant que ce paquet est à traduire mais pas à archiver.

Il faut aussi tenir compte du message d'hier soir sur spip-trad demandant aux traducteurs de se nommer. C'est intéressant de retrouver le nom d'un traducteur pour parler avec lui de problème de traduction, c'est une information à rajouter.

Par ailleurs, on peut avoir dans un même plugin des fichiers gérés par Salvatore et d'autres non, et on peut être amené un jour à devoir indiquer des numéros de version de Salvatore, ou le remplacer par autre chose, il vaudrait donc mieux un attribut, disons « gestionnaire », qui vaudrait « salvatore » ou « manuel » aujourd'hui, mais éventuellement autre chose plus tard.

Enfin, par principe il faut éviter des attributs dont la valeur nécessite une analyse syntaxique, le rôle de XML c'est de décomposer tout ce qui peut l'être, donc je pense qu'il faut une balise par langue, comme Rasta le disait au début (mais la balise englobante est une verbosité inutile).

Au final, je propose donc une balise « langue » répétable, d'attribut « code » obligatoire dont la valeur est un code de langue (« fr », « en » etc), et un deuxième attribut « gestionnaire » optionnel. Cette balise est composée de sous balises « traducteur », en nombre quelconque y compris 0, d'attributs optionnels « mail » et « site » donnant le mail et le site du traducteur dont le nom forme le contenu de la balise. Elle est répétable car il peut y avoir plusieurs traducteurs.

Des informations sur les langues pour SVP

Oui ouiiiiiiii, en fait je m'étais super mal exprimé ! Lorsque je disais d'ajouter ces informations dans le XML, c'était le XML global des paquets, donc dans les , et donc dans ma tête c'était bien à smart-paquet de s'en occuper !

Sinon ta proposition d'élément/attribut est mieux aussi, en un coup.

Pour le mix des traductions dans dans le même fichier qu'archivelist, attention, on peut vouloir traduire dans Salvatore mais ne pas générer de paquet du tout pour l'instant. Donc il faut voir la syntaxe la plus adaptée... De plus ce sont deux choses complètement différentes et qui ne sont pas utilisées par le même script (l'un c'est smart-paquet, l'autre c'est Salvatore). Alors les rendre trop inter-dépendant n'est pas forcément la solution... Je n'ai pas d'avis là-dessus pour l'instant.

Des informations sur les langues pour SVP

Hello,

Oui je suis tout à fait d'accord et c'est d'ailleurs ce que fait déjà plugins.spip.net dans sa version sans SVP. Pour la mise en oeuvre je propose plutôt l'approche suivante :

Salvatore
Aujourd'hui Salvatore utilise un fichier traductions.txt contenant des lignes du type :

svn://zone.spip.org/spip-zone/_plugins_/acces_restreint/lang/;accesrestreint;fr

Pour récupérer cette information dans SVP, ie dans archives.xml, le mieux serait que smart-paquets s'en occupe. Et vu le type d'information nécessité par Salvatore on peut imaginer que traductions.txt soit en fait remplacé par archivelist.txt en adaptant légèrement la syntaxe du fichier (évident en YAML, moins évident sur ce fichier txt)

Traductions
Là encore je pense que c'est à smart-paquets de s'en occuper en cherchant les fichiers de langues et en extrayant les traductions disponibles (existe déjà dans Langonet).

Ainsi, smart-paquets pourrait rajouter dans le bloc de chaque paquet, une balise :

<traduction salvatore="oui" langue="fr:en:es" />

Cela a l'avantage de ne pas modifier le plugin.xml.