[spip-dev] Noms des plugins (était: r44442 - _outils_/validerPlugins)

Dev
1

11/02/11, esj@rezo.net:

La construction "multi" de SPIP dans la balise "description" de
plugin.xml n'était pas bien prise en compte. A noter qu'elle apparait
aussi dans la balise "nom", 106 fois, contrairement à ce que propose
la nouvelle interface qui considière qu'un nom de plugin ne se
traduit pas.

Est-ce que la nouvelle DTD prévoit un champ "descriptif court", ou
"sous-titre" ? Ça avait été évoqué dans les discussions, mais je sais
pas si c'est resté.

Souvent on utilise un nom descriptif au lieu d'un nom "propre", car
c'est le seul moyen actuellement de décrire en 3 mots la fonctionnalité
d'un plugin. Mais ce sont deux fonctions différentes, car même si
effectivement un nom ne devrait pas avoir besoin d'être traduit, un
descriptif rapide si.

Il faudrait donc soit autoriser la traduction des noms si on souhaite
continuer le hack actuel de "nom descriptif", soit ajouter un champ
"descriptif rapide" si on souhaite soutenir qu'un nom ne se traduit
pas.

2

Oui Davux !

C’est le slogan et c’est exactement pour cela que nous avions proposé un nom non traduit et un descriptif court traduit.

Fil proposait d’utiliser le terme motto non ?

3

Personnellement, je suis toujours contre.

Notamment parce que pour les plugins que je trouve les plus génériques possibles, et bien je veux que le nom du plugin soit directement le nom de la fonction. C'est volontairement voulu fait exprès. Ex 1.

Pour les autres c'est... autre chose. Ça ne se traduit pas effectivement. Et donc le slogan est utile. Ex 2.

Exemple 1 :
- Menus
- Pages
- Étiquettes
- Saisies
- Vérifier
- Notifications
- Facteur
- Médiathèque
- Corbeille
- Lecteur multimédia
- Forums, Brèves, Mots-clés, Compresseur, !...
- je continue ?

Exemple 2 :
- Formidable
- GIS
- Textwheel
- je n'en trouve pas beaucoup

Le but sur la zone est de collaborer et d'essayer autant que possible de faire un seul plugin pour une fonction précise, sans doublon. En partant de ce point de vue, il ne faut PAS chercher à trouver un nom de plugin "buzz" avec des noms punchy, etc, des noms "propres" comme dit Davux. Déjà c'est super chiant à chercher, et en plus ça ne sert à rien puisqu'on essaye de ne pas se concurrencer mais bien de converger.

On est PAS dans le cas d'un extensions.mozilla, ou drupal/projects où il y a 30 plugins pour la même fonction, avec concurrence.

Toujours dans la mesure du possible : si une fonction = un seul plugin, alors = un seul nom donc un nom logique et compréhensible.

Ce n'est pas le cas pour tout, mais c'est le cas pour la majorité des besoins.

Et pour tous ces besoins, il FAUT donc pouvoir traduire le titre. Afin que l'information importante et grosse (le titre est l'élément qui sera affiché le plus gros, le plus visible) soit pertinente immédiatement, au premier coup d'œil.

Je persiste, je persiste, je persiste. Et je persisterai.

4

Coucou,

Personnellement, je suis toujours contre.

Peut être sauf que je vois pas dan ce que tu dis pourquoi tu es contre. Avoir un nom compréhensible n’interdis pas d’avoir un descriptif court qui par exemple est toujours visualisé dans dessous du nom dans les affichages de l’espace privé.

Notamment parce que pour les plugins que je trouve les plus génériques possibles, et bien je veux que le nom du plugin soit directement le nom de la fonction. C’est volontairement voulu fait exprès. Ex 1.

Ben je vois pas en quoi un slogan peut nuire à cette liste. Menus, Pages, Saisies, Vérifier me paraissent pas si explicites que ça pour un novice. Vérifier quoi ? Saisies de quoi ? Facteur c’est pour les codes postaux ?

Non franchement, je vois pas l’incompatibilité mais plutôt un moyen pratique de fournir une petit information supplémentaire.

Et pour tous ces besoins, il FAUT donc pouvoir traduire le titre. Afin que l’information importante et grosse (le titre est l’élément qui sera affiché le plus gros, le plus visible) soit pertinente immédiatement, au premier coup d’œil.

Je persiste, je persiste, je persiste. Et je persisterai.

Sauf si les affichages ne se limitent jamais au nom du plugin uniquement ce qui est toujours (il me semble) le cas !

5

11/02/11, RastaPopoulos:

Exemple 1 :
- Facteur

Mauvais exemple. Le slogan serait "Envoi de courrier". Facteur, c'est
déjà un nom "punchy".

Exemple 2 :
- Formidable
- GIS
- Textwheel
- je n'en trouve pas beaucoup

  - Motus

Le but sur la zone est de collaborer et d'essayer autant que possible
de faire un seul plugin pour une fonction précise, sans doublon.

D'accord avec ça.

Déjà c'est super chiant à chercher, et en plus ça ne sert
à rien puisqu'on essaye de ne pas se concurrencer mais bien de
converger.

Que ça soit chiant à chercher, c'est justement parce que la description
courte n'existe pas actuellement. Et une fois que le champ existe,
c'est une question d'interface.

Toujours dans la mesure du possible : si une fonction = un seul
plugin, alors = un seul nom donc un nom logique et compréhensible.

Entièrement d'accord, mais pour des plugins comme Motus justement, ou
Facteur, on a envie de mettre un nom mignon, et un descriptif rapide
informatif. Ça empêche pas que les gens qui lancent un plugin faisant
doublon se fassent engueuler sur spip-zone (c'est une blague, hein).

Et pour tous ces besoins, il FAUT donc pouvoir traduire le titre.

Oui ça serait un plus de pouvoir le traduire, surtout si ça ne pose pas
de problème technique, pourquoi s'en priver... Mais dans le cas
contraire, le descriptif rapide aidera de toute façon à trouver ce
qu'on cherche, d'ailleurs c'est son but. Du coup, même si le plugin
s'appelle Facteur et qu'on parle espagnol, le descriptif rapide dira
"envío de correo" et on sera content. Que le titre soit traduit en
"Cartero" sera une aide supplémentaire, mais pas nécessaire.

Afin que l'information importante et grosse (le titre est l'élément
qui sera affiché le plus gros, le plus visible) soit pertinente
immédiatement, au premier coup d'œil.

Question d'interface. Le descriptif rapide doit aussi être visible
immédiatement dans les listes et autres résultats de recherche.

6

Cucu.

Ton message part d'un contresens donc je rétabli.

Je ne suis pas contre le slogan, au contraire 1) c'est très bien en soi et 2) c'est doublement très bien pour les RARES plugins dont le noms ne doit pas se traduire.

Mais comme l'explique bien mon message, je suis fondamentalement contre la non-traduction du Nom. Pour tous les arguments précédemment évoqués.

7

Ok,

8

Ah tiens, j'avais pas suivi ça que les titres pourraient dans l'avenir ne plus pouvoir être traduits. Je suis, comme Davux et Rasta favorablement contre !

Même si le slogan et le descriptif existent, il faut pouvoir traduire les noms ! Il faut que les plugins aient la Liberté de traduction de ce qu'ils veulent (exception faite du préfixe !). Ça me parait un non sens que de ne pas pouvoir traduire. Imagine un plugin qui arrive sur la zone, écrit en UTF8 en arabe égyptien. Tu vas savoir prononcer le titre ?

9

Objectiion !

Même si le slogan et le descriptif existent, il faut pouvoir traduire les noms ! Il faut que les plugins aient la Liberté de traduction de ce qu'ils veulent (exception faite du préfixe !). Ça me parait un non sens que de ne pas pouvoir traduire. Imagine un plugin qui arrive sur la zone, écrit en UTF8 en arabe égyptien. Tu vas savoir prononcer le titre ?

Ce n'est pas en prenant des exemples improbables qu'on va faire avancer le débat !
L'idée c'est que le nom participant à l'identité du plugin à l'instar de son logo n'a pas besoin d'être traduit.
Je vais pas prendre des exemples comme Zpip-dist :stuck_out_tongue: mais par exemple Login Facebook c'est dans quelle langue ? Le français, l'anglais, autre (cocher votre choix comme dirait Denis) ?

Je pense que ça n'ajoute rien de le traduire et qu'on peut donc s'en passer sachant que tous les affichages des plugins proposeront le slogan en regard du nom.

10

Ah mais que si ! Rien n'empêche d'ajouter le nom du plugin dans les chaines de traductions et de ne pas le traduire pour certains plugins (peut être la majorité) mais pour certains, c'est mieux que ce soit traduit, je suis désolé ; ils ne sont pas tous à base de sigles ou termes inventés. «Article PDF» est traduit par exemple.

Matthieu.

11

Salut à tous !

Je suis d'accord avec ceux qui ne sont pas d'accord !
:slight_smile:

Ah mais que si ! Rien n'empêche d'ajouter le nom du plugin dans les chaines
de traductions et de ne pas le traduire pour certains plugins (peut être la
majorité) mais pour certains, c'est mieux que ce soit traduit, je suis
désolé ; ils ne sont pas tous à base de sigles ou termes inventés. «Article
PDF» est traduit par exemple.

Rien que si je pense aux plugins auxquels j'ai participé, je me
demande bien ce que leur nom veut dire chez les francophobes:
"intertitres hiérarchisés", "icônes sémantiques", "ciations bien
balisées", etc.

Quand on cherche à piocher dans une liste de plugins, c'est plus
simple de le faire à partir du nom (court et évocateur) qu'à partir
d'un slogan (plus long). Comme Rasta, je ne suis pas contre le slogan,
mais pour la traduction des noms de plugins.

12

* Matthieu Marcillaud tapuscrivait, le 12/02/2011 09:09:

11/02/11, RastaPopoulos:

Et pour tous ces besoins, il FAUT donc pouvoir traduire le titre.

Oui ça serait un plus de pouvoir le traduire, surtout si ça ne pose pas
de problème technique, pourquoi s'en priver...

Ah tiens, j'avais pas suivi ça que les titres pourraient dans l'avenir
ne plus pouvoir être traduits. Je suis, comme Davux et Rasta
favorablement contre !

Le problème, c'est les plugin.xml qui "necessite" : ils indiquent le préfixe.
Et quand le préfixe est différent du nom, ça perd les utilisateurs à qui, par exemple, SPIP dit que X nécessite "medias" et qu'il y a un plugin "Média" mais qu'en fait, c'est "Médiathèque" qui est demandé... Et que son dossier sur la zone ne s'appelle pas medias mais mediatheque.

En disant ça, je ne dis pas qu'il ne faut pas traduire les nom des plugins, juste qu'il faut trouver un moyen de retrouver un plugin "nécessité" et que le prefix, bien qu'unique n'est pas pratique.

Déjà, si le nom des dossiers sur la zone était le même que le prefix, ça aiderait la recherche...

-- RealET

13

Mais NON. :slight_smile:

Ça c'est une approche de type "marketing" quand on doit trouver un nom qui pète et qui est unique. Genre "Twitter", "Google", "iPad", etc.

Là, dans *le contexte* de la zone, nous essayons de faire en sorte qu'une fonctionnalité soit représenté par un seul plugin, autant que l'on peut (je sais je me répète mais c'est ce contexte qui implique ce que je dis).

Et du coup on essaye pas de trouver des noms qui ne veulent rien dire, mais un ou deux mots très simples qui indique la fonctionnalité. Exactement comme les plugins du core, et qui n'ont pas forcément vocation à le rester !

Le plugin "Brèves" ou le plugin "Mots-clés" ne vont pas s'appeler "Groovy flop glop" ou "Youpi youpa". Et il y a tout intérêt à ce que le mot "Brèves" soit traduit immédiatement. Aucune différence pour la majorité des autres plugins.

Ceux qui ont un nom propre devraient être, et même sont déjà (dans ceux les plus utilisés), une minorité.

14

Non là je pense que c'est hors sujet car c'est un BUG de l'interface. Qui grâce au travail d'Éric sur SVP sera parfaitement en mesure d'afficher le vrai nom des plugins dans la majorité des cas.

15

Yop,

16

Héhé,

Ce n'est pas en prenant des exemples improbables qu'on va faire avancer
le débat !
L'idée c'est que le nom participant à l'identité du plugin à l'instar de
son logo n'a pas besoin d'être traduit.

Mais NON. :slight_smile:

Ça c'est une approche de type "marketing" quand on doit trouver un nom qui pète et qui est unique. Genre "Twitter", "Google", "iPad", etc.

Formidable ?

Là, dans *le contexte* de la zone, nous essayons de faire en sorte qu'une fonctionnalité soit représenté par un seul plugin, autant que l'on peut (je sais je me répète mais c'est ce contexte qui implique ce que je dis).

C'est un voeu pieu et loin de la réalité...

Et du coup on essaye pas de trouver des noms qui ne veulent rien dire, mais un ou deux mots très simples qui indique la fonctionnalité. Exactement comme les plugins du core, et qui n'ont pas forcément vocation à le rester !

Même les mots simples n'expriment que rarement la réalité du plugin. Facteur ? Menus ? C'est pas si évident même si c'est simple et que j'aime beaucoup ces noms de plugins.

Maintenant comme je vous l'ai déjà dit, ce n'est qu'une décision à prendre sur de bons critères ;-).

17

Salut

Que voilà encore une de ces discussions sans fin qui oublie l'essentiel.
Car il faut poser la question qui fâche:
il y a combien d'utilisateurs de SPIP qui n'ont aucune connaissance du français
et réclament des noms de plugins évocateurs dans leur langue maternelle ?
Encore une des ces discussions où on prétend parler au nom des intérêts de quelques uns,
mais dont on ne s'occupe jamais d'aller leur demander leur avis.
Car après avoir eu peut-être l'intuitition de ce que fait un plugin grâce à la traduction de son nom,
il faudra à cet utilisateur qu'on a ainsi grandement choyé, aller lire un fichier plugin.xml
bourré d'informations étiquettées "utilise" et "necessite" (prononcer: "nEUcessite")
dont la différence subtile ne lui échappera évidemment pas.

Comble de la mauvaise foi, toute cette discussion est partie du rejet de la conviction d'Eric et moi
qu'il fallait évacuer du fichier de description en XML les textes bruts et leurs lacunaires balise multi,
en les plaçant de manière standard et bien visible dans des fichiers de langues
afin que les traducteurs puissent enfin faire ce boulot de traduction prioritaire.
Car ces fichiers de description sont les choses les plus importantes dans le développement de SPIP depuis
la sortie de 2.0, le développement COLLABORATIF du noyau étant en panne depuis cette date.
Normaliser les informations de description, pour que celles textuelles soient traduites systématiquement,
et celles techniques soient fiables, rien que ça semble impossible au motif que ça bousculerait des petites habitudes.

Eric et moi avons fait des propositions précises, et nous avons tenu compte des objections.
Peut-on enfin déboucher sur une décision collective ferme de réaliser tout ça ?
Ou bien faut-il une fois plus qu'on se risque à balancer du code dans le core,
de sorte qu'au premier problème rencontré, au lieu d'avoir le soutien de tous pour trouver une solution,
on ait droit à des condamnations rivalisant dans la mauvaise foi ?

Et je vous laisse méditer cette phrase de Paul Valéry:

Rien de grand ne s'est fait sans arbitraire.

E.

18

Salut,

pour ma première participation dans la liste, juste une idée:

- pourquoi ne pas mettre un code technique / identifiant unique pour chaque plugin, facilement "googlelisable" (du style SPIPGEN025BONUXV3) afin de trouver toutes les références, docs, problèmes, etc .. relatives à ce plugin, indépendamment de la langue et pour pouvoir être sûr de faire référence à la même chose. Le code serait attribué au moment de la publication dans spip-contrib. Ce code servirait aussi pour les dépendances entre plugins.

- laisser les espagnols, les arabes et les japonais traduire le nom.

- de même pour le sous-titre ou descriptif qui détaillerait la foncionnalité du plugin...

Un saludo
François

19

Bonjour Emmanuel,

Je ne suis pas certain d'avoir compris ton intervention.

[...]

Car après avoir eu peut-être l'intuitition de ce que fait un plugin grâce à la traduction de son nom,
il faudra à cet utilisateur qu'on a ainsi grandement choyé, aller lire un fichier plugin.xml
bourré d'informations étiquettées "utilise" et "necessite" (prononcer: "nEUcessite")
dont la différence subtile ne lui échappera évidemment pas.

Es tu en train de dire que
- la traduction du nom ne sert à rien
- qu'un administrateur aura besoin de lire le fichier plugin.xml pour installer un plugin ?

Si tel est le cas, d'une part, je n'ai absolument rien contre le tag «slogan» proposé, bien au contraire, d'autre part, je ne vois pas le rapport à ne pas vouloir traduire, parfois, le titre du plugin.

Pour le second point, oui, utilise et nécessite ne sont actuellement pas connus à l'avance par qui installe un plugin (créant des phrases parfois absconses à l'installation, genre «impossible d'activer X, nécessite le plugin Y en version Z»), et c'est bien cette recherche qu'effectue actuellement le plugin STEP en 2.1 lorsqu'on souhaite lui faire installer un plugin : il va récupérer automatiquement les dépendances à installer. Je crois que c'est également le but de ces tags de faciliter les installations ; et le fait qu'ils soient déclarés dans plugin.xml rélève du travail de développeur, et non forcément d'un administrateur (qui n'a pas besoin, lui, de connaitre le code xml sous-jacent du plugin.xml).

Comble de la mauvaise foi, toute cette discussion est partie du rejet de la conviction d'Eric et moi
qu'il fallait évacuer du fichier de description en XML les textes bruts et leurs lacunaires balise multi,
en les plaçant de manière standard et bien visible dans des fichiers de langues
afin que les traducteurs puissent enfin faire ce boulot de traduction prioritaire.

Je crois que nous sommes d'accord là dessus.

Il me semble qu'il faut également qu'un plugin puisse fournir ses fichiers de traductions sans forcément passer par tradlang.

20

12/02/11, Emmanuel:

Que voilà encore une de ces discussions sans fin qui oublie
l'essentiel. Car il faut poser la question qui fâche:
il y a combien d'utilisateurs de SPIP qui n'ont aucune connaissance
du français et réclament des noms de plugins évocateurs dans leur
langue maternelle ?

C'est exactement la question de ce fil, traduire ou pas les noms des
plugins, pour les gens qui ne parlent pas français. Je ne comprends pas
le ton emphatique de discours politicien (j'ai même entendu le larsen
de test du micro en ouvrant le mail, puis poussé un soupir).

Encore une des ces discussions où on prétend
[...]

Là, désolé, mais je n'ai rien compris. J'ai lu plusieurs fois.

Veux-tu parler de la présentation visuelle des "necessite", ou autre ?
Très bien, mais parlons concrètement et sur des points précis.

Personnellement je suis ce fil car il s'appelle "noms des plugins",
j'aimerais bien y trouver ce qu'il y a sur l'emballage.

Et des phrases courtes si possibles, allant à l'essentiel. Et humbles.

Désolé, c'est pas pour être grossier ni rien, mais sincèrement j'ai
rien compris.