Carnet Wiki

Autres termes épinglés

Version 16 — 1 month ago — goetsu

voir aussi : Nomenklatura | Contresens

<blockquote class="spip">

Liste de termes mal tournés

Proposition de présentation : en gras : le terme mal tourné, puis liste de caractèristiques : rappel de l’usage ou de la signification du terme, contexte en vue d’un éventuel changement de terme, propositions d’alternatives

</blockquote>

no-image-filtrer
-  C’est le nom d’une classe à appliquer aux modèles d’images insérés dans un champ d’article (ou autre) afin d’empêcher que les filtres appliqués à ce champ par le squelette ne s’appliquent à cette image.
-  Pas de documentation officielle mais présenté sur http://www.weblog.eliaz.fr/article91.html. Utilisé dans des plugins (’diaporama’ par exemple)
-  Alternatives : filtre_inactif , pas-de-filtrage, image-non-filtree, ne-pas-filtrer
-  ACTU Proposition favorite : il a été renommé < code > filtre_inactif</code > ne-pas-filtrer

spip_logos
-  bizarrement au pluriel, alors qu’il s’applique de façon singulière. J’oublie toujours le «s» ! [ <u >[ il s’agit d’un nom générique de classe css, comme aussi “spip_documents”... ][Je vois pas en quoi le fait que ce soit un nom générique justifie le pluriel. spip_documents c’est surtout le nom d’une table qui contient de nombreux documents] </u >

-   d’ailleurs, dans la documentation sur spip.net, c’est au singulier qu’il figure ! [ <u >[ il s’agit d’un “exemple” pour le titre d’un document ! ][Oui, dans un titre de document on est pas contraint par la syntaxe SPIP et libre de choisir ce qui va le mieux. Ça contribue à montrer que le singulier est plus adapté] </u >

vocabulaire des pipelines

-  

déclaration&lt;/code >,  <code>création&lt;/code >,  <code>utilisation&lt;/code >  déclaration ,  création ,  utilisation  d'un pipeline : le  vocabulaire  et  chacun de ces contextes  et  utilisations  devraient  cas  d'utilisation  devrait  être précisé et documenté. La doc n'introduit pas bien ces différents concepts, il y a des ambiguités et  probablement  des  incohérences  dans les  utilisations  l'utilisation  de ces termes. En particulier, il n'est pas fait la distinction entre {création d'un nouveau pipeline} et {création d'un nouveau "point d'exécution" d'un pipeline déjà existant}. Le premier point semble n'être jamais abordé.


{{lang_select}}


<code>lang_select

fait évidemment référence à la manière avec laquelle la langue est sélectionnée, mais n’indique aucunement quelle est cette manière, ce qui ne facilite pas son usage.
-  rappel : Avec {lang_select} c’est la langue de l’objet qui est utilisée pour le traitements des <multi>. Avec {!lang_select} c’est la langue du contexte englobant qui est utilisée.
-  alternatives (à confirmer et compléter) :

  • remplacer lang_select par lang_locale ou lang_item ou lang_objet ;
  • remplacer !lang_select par lang_contexte

Schema

paquet.xml introduit un nouvel attribut ’schema’ : “Cet attribut indique la version courante du schéma de données utilisé par le plugin.”
-  le terme “schema” est un terme peu répandu, inutilement ésotérique pour les non spécialistes.
-  Le terme “schema” ne correspond pas à ce qu’il décrit car en lui même le terme est complètement générique alors que la valeur de cette entrée est en fait un n° de version. L’ancien libellé “version_base” était plus clair et plus complet.

Réponse: l’outil de vérification standard de XML, nsgmls, refuse des attributs ayant un souligné, “version_base” devait donc être abandonné. Le mot “schema” est le terme employé en SQL pour désigner l’ensemble des déclarations de tables, il est donc répandu chez ceux qui doivent déclarer les dites tables. Il est certes dommage que le nom retenu ne suggère pas que la valeur attendue est un nombre, mais l"attribut “version” étant déjà pris, il ne restait pas grand choix. L’autre piste aurait été de passer aux espaces de noms multiples, en écrivant “base:version”, mais rentrer dans ce domaine pour un unique attribut n’était pas raisonnable.