[SPIP Zone] ! plugins Trad Rub (tradrub) et Trad Sync (tradsync)

Bonjour,

J'ai déposé tout dernièrement 2 plugins qui peuvent êtres utiles aux webmestres jonglant avec les traductions, ainsi qu'aux traducteurs eux-même.

Le besoin était simple : faciliter le suivi de traductions sur le site Programmer.spip. La page ?exec=articles_tous est déjà une grande aide pour les traducteurs, mais ces plugins apportent des choses un peu différemment.

Je précise tout de suite qu'ils fonctionnent en 2.1 béta, et qu'ils ont un certain nombre de dépendances :
- saisies : pour le sélecteur de rubriques
- bonux : pour la boucle condition, le sélecteur/navigateur de rubrique, le critère {tri} et la balise #TRI
- afficher_objets : pour avoir des listes d'éléments dans le privé en squelette, paginés et triés.

[Trad Rub]

(nécisste 2.1 béta SVN [15314] minimum)

Il permet de :
- créer un champ id_trad sur les rubriques et donc aux critères {traduction} et {origine_traduction} de s'appliquer sur les boucles rubriques (ainsi que les nouveaux critères tradsync)
- créer des traductions de rubriques, avec un bouton dans la rubrique à traduire
- déclarer qu'une rubrique est une traduction d'une autre.

[Trad Sync]

Il vise à faciliter la recherche de traductions à réaliser ou à vérifier. Il offre un espace pour cela : ?exec=traductions.
Il sera bon d'intégrer des parties directement dans la vue des articles et rubriques aussi, mais ce n'est pas fait.

Il permet de :
- lister les articles et rubriques n'ayant pas de traduction pour une langue donnée (en s'appuyant sur id_trad)
- lister les mots n'étant pas traduits (groupes à tester sélectionnables dans une configuration CFG) en s'appuyant sur la présence de polyglottes (<multi>) dans le titre pour une langue donnée.
- lister les articles et rubriques traduits dont la source a été modifiée plus récemment
- lister les articles et rubriques traduits qui n'ont pas exactement les mêmes mots clés que la source, avec un bouton pour synchroniser : copie tous les mots de la source dans la traduction (mais ne supprime pas ceux en sus dans la traduction).
- afficher deux navigateurs de rubriques l'un sous l'autre pour comparer visuellement des arborescence.

Il offre des critères (qui servent à l'interface) et peuvent servir aux webmestres pour des situations particulières :

- {traductions en} : tous les éléments anglais etant des traductions = {!origine_traduction}{lang=en}
- {!traductions en} : tous les éléments d'origine non traduits en anglais
- {origine_modifiee} : tous les éléments traduits dont la source a été modifiée (date plus récente)
- {!origine_modifiee} : tous les éléments traduits dont la source n'est pas plus récente
-* {polyglotte titre} : tous les éléments ayant un polylotte (<multi>) dans le titre
-* {polyglotte titre,en} : tous les éléments ayant un polylotte (<multi>) dans le titre comportant l'anglais
-* {!polyglotte titre} : tous les éléments n'ayant pas de polylotte
-* {!polyglotte titre,en} : tous les éléments n'ayant pas de polylotte (<multi>) dans le titre comportant l'anglais

Tradsync nécessite Tradrub (ça pourrait se corriger en testant avant les inclusions des listes de rubriques que la colonne id_trad existe bien dedans)

En espérant que ces plugins pourront servir, vous êtes invités à les améliorer bien entendu, et à les tester éventuellement :slight_smile:

--
MM.

On 24/02/2010 12:12, Matthieu Marcillaud wrote:

[Trad Rub]

(nécisste 2.1 béta SVN [15314] minimum)

Ou maintenant aussi sur la 2.0 svn [15316] minimum.

--
MM.

On 24/02/10 12:12, Matthieu Marcillaud wrote:

[Trad Rub]

(nécisste 2.1 béta SVN [15314] minimum)

Il permet de :
- créer un champ id_trad sur les rubriques et donc aux critères
{traduction} et {origine_traduction} de s'appliquer sur les boucles
rubriques (ainsi que les nouveaux critères tradsync)

Matthieu -- magnifique. Merci !
Je vais tester cela dès que je le pourrai.

Tu sais, depuis un certain temps j'ai crée pour notre site un champs id_rubrique dans la table spip_rubriques. Et je l'utilise pour lier les rubriques entre elles.

Si maintenant j'installe le plugin, il va me laisser en place les id_trad qui existe déjà ?

Paolo

On 24/02/10 15:05, Paolo wrote:

Tu sais, depuis un certain temps j'ai crée pour notre site un champs
id_rubrique dans la table spip_rubriques. Et je l'utilise pour lier les

(Je n'apprends jamais : il faut tjrs relire avant de poster. Pardon.)

pour notre site un champs *id_trad* dans la table spip_rubriques.

P.

On 24/02/2010 15:09, Paolo wrote:

On 24/02/10 15:05, Paolo wrote:

Tu sais, depuis un certain temps j'ai crée pour notre site un champs
id_rubrique dans la table spip_rubriques. Et je l'utilise pour lier les

(Je n'apprends jamais : il faut tjrs relire avant de poster. Pardon.)

pour notre site un champs *id_trad* dans la table spip_rubriques.

Oui, normalement, il garde les id_trad existants (une sauvegarde préalable n'est jamais trop prudente ! :slight_smile: ). Veille seulement à ne pas «désinstaller le plugin» après, sinon pour le coup, il te supprimera ce champ.

Cependant, j'ai découvert un truc en faisant ce plugin, c'est que la rubrique/article d'origine prend aussi un id_trad (= id_rubrique pour le coup). Je ne sais pas si tu les as aussi renseignés dans ta base. Ça ne doit pas être trop gênant sinon.

--
MM.

On 24/02/10 15:24, Matthieu Marcillaud wrote:

Cependant, j'ai découvert un truc en faisant ce plugin, c'est que la
rubrique/article d'origine prend aussi un id_trad (= id_rubrique pour le
coup).

Oui, je savais cela. D'habitude je l'avais renseigné. Mais je n'utilise pas.

Ce que j'avais trouvais avant en essayant d'utiliser {traduction} pour les rubriques (sans aucune programmation préalable), c'était que SPIP ne savait pas bien s'il cherchait une rubrique ou un article. J'imagine que tu as levé cete ambiguité ?

Je suis bien content de pouvoir visualiser les traductions des rubriques.

Par contre :
- je ne trouve pas comment « défaire » un lien de traduction (c'est facile pour les articles).
- je ne comprends pas l'interface « Modifier ou définir l'origine de cette traduction ». On peut pas avoir la même chose que pour les articles ?

+ Un micro bug. Dans cette interface « Modifier ou définir l'origine de cette traduction » le lien « Modifier » s'affiche non dans la langue de l'interface (comme il devrait), mais dans la langue de la rubrique en cours. Donc utilisant l'interface en français pour regarder une rubrique en japonais, je trouve que Modifier s'affiche : [修正] ... ce qui complique le travail :wink:

et surtout merci pour ce progrès multiligue !

Paolo

On 24/02/2010 20:12, Paolo wrote:

Ce que j'avais trouvais avant en essayant d'utiliser {traduction} pour
les rubriques (sans aucune programmation préalable), c'était que SPIP ne
savait pas bien s'il cherchait une rubrique ou un article. J'imagine que
tu as levé cete ambiguité ?

Non, je n'ai pas touché au critères. Le problème que tu rencontrais peut être avec {traduction} sur un site qui n'a pas de id_trad sur spip_rubriques est qu'il devait peut être chercher id_trad dans les boucles parentes (et donc dans un éventuel spip_articles).

Par contre :
- je ne trouve pas comment « défaire » un lien de traduction (c'est
facile pour les articles).

Normal, je n'ai pas fait :slight_smile:
En fait il suffit d'indiquer «racine du site» dans «modifier ou définir l'origine de cette traduction» Mais ce n'est pas génial. Je regarderais pour faire mieux, avec un lien explicite pour délier.

- je ne comprends pas l'interface « Modifier ou définir l'origine de
cette traduction ». On peut pas avoir la même chose que pour les articles ?

Je pense que ça offre la même chose, mais dit différemment. Le sélecteur de rubrique a un champ, au dessus, «ajout rapide», qui permet de saisir un identifiant de rubrique. En théorie.
En pratique il y a des difficultés :
- appuyer sur «entree» alors qu'on est dans l'input ne lance pas le bon bouton de submit. Il faut cliquer manuellement sur «modifier»
- un identifiant seul ne fonctionne pas, il faut passer un «rubXX», par exemple «rub123». Ce n'est pas du plus géant.

C'est un sélecteur/navigateur intégré dans le plugin spip_bonux. Il y a peut être des améliorations à lui apporter

+ Un micro bug. Dans cette interface « Modifier ou définir l'origine de
cette traduction » le lien « Modifier » s'affiche non dans la langue de
l'interface (comme il devrait), mais dans la langue de la rubrique en
cours. Donc utilisant l'interface en français pour regarder une rubrique
en japonais, je trouve que Modifier s'affiche : [修正] ... ce qui
complique le travail :wink:

Bizarre, je ne reproduis pas... mais j'ai que du français et de l'anglais :slight_smile:

et surtout merci pour ce progrès multiligue !

Merci de tes retours.

--
MM.

On 24/02/10 20:57, Matthieu Marcillaud wrote:

Non, je n'ai pas touché au critères. Le problème que tu rencontrais peut
être avec {traduction} sur un site qui n'a pas de id_trad sur
spip_rubriques est qu'il devait peut être chercher id_trad dans les
boucles parentes (et donc dans un éventuel spip_articles).

Pas tout à fait. L'expérience que j'ai faite était la suivante. (Et, si tu n'as rien fait avec les critères, je pense que le plugin risque de faire bugger des squelettes de la même manière.)

Depuis longtemps j'avais des boucles (qui produisent le sélecteur de langues) avec cette suite :

<BOUCLE_check586(ARTICLES){traduction}{id_secteur=586}>
...
<BOUCLE_langs1(RUBRIQUES){....} >
...
<BOUCLE_checktrad1(ARTICLES){traduction}{...}>

Avant d'avoir un champ id_trad dans la table rubriques, cela marchait très bien. Mais après l'introduction de celui-ci tout à coup la deuxième boucle articles commencaient à donner n'importe quoi, et je comprenais qu'elle prenait l'id_trad de la boucle rubriques !

Pour faire fonctionner correctement j'ai dû réécrire la boucle comme ça :

<BOUCLE_checktrad1(ARTICLES){id_trad=#_check586:ID_TRAD}{id_trad != 0}{...}>

Je suis content de pouvoir dire ça à quelqu'un qui peut-être s'y intéresse, car lorsque je l'ai vu (en novembre) je me suis dit que personne ne comprendra si j'écrivais à spip-dev pour annoncer un bug qui allait arriver, mais n'etait pas encore né :wink:

J'écrivais :

- je ne comprends pas l'interface « Modifier ou définir l'origine de
cette traduction ». On peut pas avoir la même chose que pour les
articles ?

Mais il y avait quelque chose de tordu avec le css du site (2.0.10) où je l'essayais. Je ne voyais pas le « plongeur ». Maintenant c'est bcp. mieux.

+ Un micro bug. Dans cette interface « Modifier ou définir l'origine de
cette traduction » le lien « Modifier » s'affiche non dans la langue de
l'interface (comme il devrait), mais dans la langue de la rubrique en
cours. Donc utilisant l'interface en français pour regarder une rubrique
en japonais, je trouve que Modifier s'affiche : [修正] ... ce qui
complique le travail :wink:

Bizarre, je ne reproduis pas... mais j'ai que du français et de
l'anglais :slight_smile:

J'avais ça sur le site 2.0, avec 2.1 c'est bon.

Paolo

On 24/02/10 15:24, Matthieu Marcillaud wrote:

Veille seulement à ne pas
«désinstaller le plugin» après, sinon pour le coup, il te supprimera ce
champ.

N'est-ce pas trop dangereux, cela ?
Pour ma part, je préfererais que la désinstallation laisse le champ intact.
C'est tellement de travail qui peut partir en fumée à un clic, que je n'oserai pas mettre sur le site en production.

Paolo

On 24/02/2010 22:17, Paolo wrote:

On 24/02/10 15:24, Matthieu Marcillaud wrote:

Veille seulement à ne pas
«désinstaller le plugin» après, sinon pour le coup, il te supprimera ce
champ.

N'est-ce pas trop dangereux, cela ?
Pour ma part, je préfererais que la désinstallation laisse le champ intact.
C'est tellement de travail qui peut partir en fumée à un clic, que je
n'oserai pas mettre sur le site en production.

Bah... désinstaller, c'est différent de «désactiver» (décocher simplement le plugin). Cependant je suis d'accord, j'ai hésité, mais un plugin qui à l'installation crée des champs, en général les supprime à la désinstallation... Mais on peut faire une exception :slight_smile:

--
MM.

Le 24/02/2010 22:37, Matthieu Marcillaud a écrit :

Bah... désinstaller, c'est différent de «désactiver» (décocher
simplement le plugin). Cependant je suis d'accord, j'ai hésité, mais un
plugin qui à l'installation crée des champs, en général les supprime à
la désinstallation... Mais on peut faire une exception :slight_smile:

Il suffit qu'à l'installation tu enregistres quelque part si le champ était pré-existant ou pas.
Et lors de la suppression totale tu laisses le champ si c'était le cas.

--
RastaPopoulos

S'lt

C'est un peu la même problématique que remove et purge chez les copains apt.
C'est une désinstallation pas un nettoyage par le vide. Option qui
manque pour le moment.

Km

Le 24/02/2010 23:07, cam.lafit@azerttyu.net a écrit :

S'lt

C'est un peu la même problématique que remove et purge chez les copains apt.
C'est une désinstallation pas un nettoyage par le vide. Option qui
manque pour le moment.

Km

Ben j'ai pas l'impression. Pour moi la désinstallation c'est lorsqu'on désactive le plugin (il n'est plus disponible pour SPIP mais ce qui a été enregistré avec reste) et la purge c'est la désinstallation de SPIP (on supprime tout).

Quand bien même, là si le champ était pré-existant, même en purgeant il ne faudrait pas l'enlever.

--
RastaPopoulos

Le dépot http://zone.spip.org/trac/spip-zone/changeset/35558 améliore la gestion de ces traductions, et ne supprime plus systématiquement id_trad à la désinstallation.

Reste un problème d'ajax lorsqu'on déclare une traduction : seul le formulaire se recharge, mais pas l'inclusion parente, du coup, la liste des traductions entre rubrique n'apparait pas. Il faut alors recharger la page si on veut les voir.

--
MM.

On 25/02/10 11:56, Matthieu Marcillaud wrote:

Le dépot Connexion · GitLab améliore la
gestion de ces traductions, et ne supprime plus systématiquement id_trad
à la désinstallation.

Magnifique ! Je me prépare à l'installer sur le site en prod.

- Tu as compris mon autre message à propos du critère {traduction} ?

- Il y a (chez moi) toujours un pépin avec la langue des etiquettes «Titre» (en haut à gauche du bloc) et «Tout afficher» (en bas à droite). Ces deux textes chez moi, aussi bien en 2.1 qu'en 2.0.10 s'affiche dans la langue de la rubrique courante, et non pas, comme ils devraient, dans la langue de l'interface.

Paolo

On 25/02/2010 17:42, Paolo wrote:

Magnifique ! Je me prépare à l'installer sur le site en prod.

Je ne sais pas si tu as eu le temps de tester un peu alors ? Ça donne quoi ? des choses à améliorer / corriger ? des problèmes rencontrés ?

- Tu as compris mon autre message à propos du critère {traduction} ?

Oui... cependant, ce sont surtout tes boucles dont je n'ai pas compris ce qu'elles faisaient. Mais sur le principe le "bug" si on le considère comme ça est là, vu que

<BOUCLE_r(RUBRIQUES)> suivi de
<BOUCLE_a(ARTICLES){traduction}> va chercher un id_trad dans la boucle rubriques parente. Mais que pourrait-on attendre sinon ?

--
MM.

On 08/03/10 22:20, Matthieu Marcillaud wrote:

Mais sur le principe le "bug" si on le considère
comme ça est là, vu que

<BOUCLE_r(RUBRIQUES)> suivi de
<BOUCLE_a(ARTICLES){traduction}> va chercher un id_trad dans la boucle
rubriques parente. Mais que pourrait-on attendre sinon ?

Cela n'a pas de sens. Je dirais que dans une telle situation le critère {traduction} doit chercher les traductions de *l'article environnant* même si il y a une boucle RUBRIQUES interposée entre les deux boucles articles.

Paolo