J’initie cette discussion pour échanger sur les traductions quand plusieurs options son possibles.
On y trouvera des noms ou slogans de plugin ou des concepts utilisés largement dans spip et ses plugins.
J’ai commencé un article du wiki de Contrib pour compiler un glossaire standard : Glossaire de traductions FR-EN
Excellente initiative. Juste sur spip.net on a pris l’habitude d’écrire plug-in sur toutes les trads (en) alors si on standardise il faudrait aussi homogénéiser avec la doc (soit l’un soit l’autre)
Très bonne idée.
Je me demande la raison de tes propositions concernant le nom du plugin :
En outre, quand on veut utiliser le nom d’un plugin on doit utiliser la balise #PLUGIN et non redéfinir un item de langue, à savoir :
- dans un squelette, on utilise
#PLUGIN{prefixe, nom}- dans un item de langue, on utilise une variable du type
@plugin@et on lui passe#PLUGIN{prefixe, nom}
Il n’est pas clairement expliqué pourquoi il ne faut-il pas traduire le nom du plugin au delà de l’item de langue nom (monplugin_nom).
Peut-être devrais-tu argumenter ce choix ? Comme « afin d’éviter des traductions multiples du nom du plugin à retrouver dans différents items de langue, il est de bonne pratique de… » (si c’est la raison retenue).
Fait.
La série « bloc », « zone », « noisette », « block », « inclusion » me perturbe un peu je dois dire 
Pour « noisette », pourquoi pas « nuts » ? En assumant ce choix en français transposé en anglais on évite cette histoire de doublon avec le mot « block ». Pourquoi chercher midi à 14h ? Autant rester dans l’imaginaire 
Pour « inclusion », je proposerais bien… « inclusion » histoire de se faciliter la vie tout en restant cohérent avec la sémantique 
Pour la paire « bloc » (FR) et « zone » (EN), s’il s’agit d’un endroit où on inclut des trucs, je proposerais bien « zone » en version FR pour raison sémantique… mais je ne voudrais pas faire grincer des dents 
Pour le reste : simple, clair, efficace, sémantique 
Pourquoi pas zbloc / zblock, ou blocZ / blockZ ? Ce serait explicite.
Mais ce qui me gêne c’est l’inversion du sens de bloc/block selon EN FR
Si on a des discussions avec des anglophones, les quiproquos seront pas évidents à suivre.
Et quitte à ne pas reproduire en anglais cette private joke de noisette, pourquoi pas l’abandonner et utiliser en français aussi bloc pour noisette ?
Il y avait eu des discussions qui poussaient à cet abandon.
Là on serait vraiment raccord et sémantique.
Sinon, il faut assumer et traduire noisette par nut.
Pour moi, telle que je le conçois, il y a une différence entre une noisette et une inclusion : la noisette produit un bout de code HTML « autonome », qui peut être réutilisable dans différents contextes. Ce qu’on appele un composant en UX/UI.
Par exemple : les auteurs ou les mots clés d’un objet, les derniers articles d’une rubrique, une pagination, le minipanier du plugin paniers qui affiche le nombre d’items dans le panier et le prix total, etc.
Un inclusion peut concerner plein de choses différentes, ne faire que charger des js/css par exemple, déporter une boucle dans un INCLURE pour l’ajaxer, etc.
Ce qui donnerait :
Moi depuis le tout début je suis pour l’abandon de cette private joke qui n’apporte rien du tout (ni en code ni en ergonomie pour les gens, ni pour les FR seuls, ni pour les discussions avec les autres langues). À chaque fois, vraiment à chaque fois, on doit passer du temps à expliquer aux gens ce que ça veut dire, et pourquoi, en plus du temps de formation à l’utilisation, et X mois plus tard illes s’en souviennent plus forcément (parce que qui retient une private joke comme ça chez les simples users de l’admin ? personne) donc faut leur redire où ça se trouve.
Ma position est simple : dans en gros 100% des autres CMS ayant cette fonctionnalité, ça s’appelle « bloc », et point. Et les endroits où on peut placer ces blocs, ça s’appelle des « zones » ou des « regions » (mais ça colle moins en français, ça serait plutôt « zones »).
Donc c’est ce que tout le monde connait en passant d’un logiciel à un autre et faut pas perdre les gens inutilement.
C’est cool de donner des leçons mais celui qui a renommer les trucs dans le noiZetier c’est moi.
Franchement je me fous qu’on utilise tel ou tel terme, le but ici est de diffuser une logique réutilisable par tout le monde afin d’avoir une cohérence global spip.
Maintenant, je n’ai pas écrit ce petit tableau par hasard en voulant changer les habitudes : j’ai fait la collection de ce qui existe et j’ai proposé une traduction en anglais, traduction qui peut être améliorée si besoin, c’est fait pour ça.
Alors si on prend Z, une zone du layout comme header, footer, content, etc. s’appelle un bloc, un bloc Z. Donc je n’ai rien inventé j’ai repris bloc et je l’ai traduit en zone en anglais ce qui parait logique.
D’où j’ai repris aussi le terme noisette pour le distinguer du terme bloc.
Maintenant pour une inclusion ou une noisette qui est inclus dans un bloc Z, si on reprend comme l’avait suggéré @rastapopoulos lui-même le terme anglais c’est block, donc j’ai traduit la noisette en block.
Ce n’est que de la traduction et c’est vrai que l’anglais est plus conforme dans ce cas.
Maintenant, si on veut renommer les termes français c’est un autre sujet mais on le peut le faire et là oui, je pense que zone et bloc seraient plus adaptés. Après, je pense que rajouter Z n’a pas trop d’intérêt dans le cas général.
Bof ça me parait super anglais mais je suis d’accord avec toi que c’est différent d’un bloc-noisette car on ne sait pas si l’inclusion est autonome ou pas ;).
J’ai proposé include sur le carnet.
Je ne suis pas fluent en angliche mais j’ai demandé à Deepl de traduire « Inclusion d’un fichier » et il propose « Inclusion of a file »
Et on trouve énormément de résultats dans des docs de logiciels en cherchant « File Inclusion ».
Donc je pense que ça doit pas être trop déconnant.
« Include » c’est plutôt le verbe.
Yop, mais include ou include file est communément utilisé dans la programmation pour désigner une inclusion (en français).
