[spip-dev] Nom d'un module de langue et compilateur

Dev
1

Hello,

En scindant le module de langue sarkaspip en deux modules, l’un pour le public, sarkaspip et l’autre pour la configuration sarkapip-config, je me suis rendu compte que le compilateur n’accepte pas le tiret dans le nom du module suivant que l’on utilise :

  • l’écriture <:module:item:>

  • ou l’écriture #VAL{module:item}|_T qui est souvent utilisée aujourd’hui.

J’avoue que je ne me rappelais plus de cette limitation mais je ne comprends surtout pas pourquoi elle existe puisque le module est une partie d’un nom de fichier et pourrait donc accepter le tiret. En outre, utiliser le tiret est plus vertueux à mon avis pour distinguer le nom et la langue.

En outre, nous avons appelé les modules associés au paquet : paquet-$prefixe ce qui veut dire qu’il n’est pas possible d’utiliser la forme classique d’écriture pour afficher le nom, le slogan ou la description d’un plugin dans un squelette.

Si cette limitation n’a plus raison d’être il serait bon de la faire sauter dans une prochaine release car elle n’aurait donc plus de sens surtout quand il existe des écritures qui l’autorisent.

2

Salut Eric

Hello,

En scindant le module de langue sarkaspip en deux modules, l'un pour le public, sarkaspip et l'autre pour la configuration sarkapip-config, je me suis rendu compte que le compilateur n'accepte pas le tiret dans le nom du module

Pour les nom de boucle, la convention du phraseur est de n'accepter que les caractères que PHP lui-même accepte pour ses identificateurs. Le besoin est évident: c'est ce qui permet au compilateur, à partir du nom X d'une boucle, de créer sa compilation sous forme d'une fonction PHP nommée BOUCLE_Xblablabla sans risque de refus par l'interprète PHP (ou collision de nom si on introduisait des conversion comme "-" en "_" ou autre).

Cette règle a été etendue à tout ce qui s'apparente à un idenficateur en SPIP: par exemple les noms de fichier n'ont pas de "-", pour que "charger_fonction" puisse opérer dans les mêmes conditions que ci-dessus.

Je ne crois pas qu'il y ait actuellement un impératif du même ordre pour les noms de modules de langue, mais je pense que ce serait une mauvaise idée de se mettre à déroger à cette règle, par principe et parce qu'un jour on peut vouloir recourir à ça.

suivant que l'on utilise :
- l'écriture <:module:item:>
- ou l'écriture #VAL{module:item}|_T qui est souvent utilisée aujourd'hui.

Quel est exactement ce que tu veux calculer ici, le module ou l'item ?
Pour l'item, j'ai introduit la possibilité à travers le premier argument quand il est anonyme, par exemple:

<:foo:{=#ENV{titre},x=2}:>
qui se compile en:
_T('foo:' . $Pile[0]['titre'], array('x' => 2))

C'est dispo en SPIP 2 et 3 (cf 20035 et 20415) et est préférable à la fois en terme de performance,
et parce que Langonet peut en faire l'analyse assez bien.
Il est vrai qu'il n'y a pas l'équivalent pour un module calculé, mais ça doit pouvoir s'arranger.

Committo,Ergo:Sum

3

Hello,

Non en fait c'est plus simple ce que j'ai essayé dans un fichier HTML:

<:sarkaspip-config:item:> qui n'est pas compris par le compilateur à cause du tiret dans le nom du module alors que <:sarkaspip_config:item:> l'est bien.

Par contre, l'écriture :
#VAL{sarkaspip-config:item}|_T elle fonctionne alors que j'ai bien un tiret dans le nom du module.

Donc je ne me rappelais plus de cette limitation du tiret dans le nom du module et je trouve que c'est pas très cohérent d'avoir deux écritures dans un même fichier qui ne donnent pas le même résultat.

++
Eric

Pour moi l'incohérence est en amont, savoir l'utilisation de _T comme filtre. Un filtre, c'est censé prendre en argument une chaîne quelconque (la plupart du temps un texte dans une langue humaine) pour la transformer (et on pourrait même décider d'écrire les filtres en JavaScript pour faire cette transformation côté client), alors que l'argument de _T désigne un index dans un certain tableau PHP, c'est-à-dire une donnée extrêmement contrainte ne pouvant avoir de sens que côté serveur.

Je viens de compléter le compilateur pour traiter le cas du module de langue calculé, et pour un peu je metterais bien un
warning dans le compilateur quand _T est utilisé comme filtre pour signaler qu'il existe une écriture plus satisfaisante.

Mais en relisant ton premier mail, je tombe sur:

nous avons appelé les modules associés au paquet : paquet-$prefixe ce qui veut dire qu'il n'est pas possible d'utiliser la forme classique d'écriture pour afficher le nom, le slogan ou la description d'un plugin dans un squelette.

autrement dit la règle que j'ai rappelée sur le nom des fichiers a été oubliée au moment où cette décision a été prise Ca a été annoncé où et quand ? C'est surprenant parce que dans ton article:

tu utilises bien le souligné et pas le tiret. Pourquoi, alors que le répertoire ecrire/lang contient des fichiers utilisant systématiquement des soulignés dans leur nom, faudrait-il que les plugins aient un répertoire lang/ qui contienne systématiquement des tirets ? Je suis sûr que plein de gens vont commencer par utiliser le souligné vu l'exemple donné par SPIP lui-même. Je ne sais pas s'il est encore temps de revenir là-dessus, mais ça me semble hautement préférable à modifier le phraseur pour introduire encore une exception dans un système qui n'en a déjà que trop.

Committo,Ergo:Sum

4

Yop,

5

Non non on se comprend pas.
Le underscore est toujoutrs utilisé pour précéder le code de langue.
Mais je parle du nom du module de langue seul.

Ah ok, c'est une peu moins confusionnant que je pensais.

Et ça c'est chiant d'être passé à coté de ce souci au moment de choisir le nom du fichier de langue d'un paquet.

Ben oui, alors je repose la question: ca a été annoncé où et quand ? Y a-t-il un problème à revenir là-dessus ?

Mais j'avoue ne pas comprendre vraiment pourquoi avoir interdit le tiret dans le nom du module.

Je l'ai dit dans mon premier mail: c'est une règle qui est indispensable à charger_fonction et au compilateur de boucle, et qui a été étendu à tout ce qui joue le rôle d'identifiant en SPIP, en particulier un nom de module. Peut-etre est-il sans danger de faire une exception à cette règle ici, mais par principe il faut éviter les exceptions quand on peut.

Committo,Ergo:Sum

6

Humm,

7

Ben oui, alors je repose la question: ca a été annoncé où et quand ? Y a-t-il un problème à revenir là-dessus ?

Euh franchement je ne pourrais plus te dire mais j'ai tellement écrit sur le sujet que je ne crois pas l'avoir fait dans mon coin.
En plus, c'est codé ainsi dans Plugonet et c'est devant les yeux de tous depuis des mois.

Et même 2 ans; ça date d'ici:

soit 1 an après la sortie de la 2.1.0, je ne faisais déjà plus grand chose pour SPIP à l'époque, j'ai pas vu passer.

Je pense surtout que personne n'avait et n'a aujourd'hui en tête cette limitation du tiret dans le nom du module de langue et c'est ça déjà qu'on devrait rappeler.

Ensuite, changer paquet-prefixe en paquet_prefixe devrait pas être trop douloureux sauf si on se sert justement du tiret et du underscore pour bien séparer le nom du module de son code de langue.

Je ne pense pas: en regardant les quelques centaines de plugins qui ont des fichiers dont le nom commence par "paquet-",
il y en a beaucoup qui ont plusieurs soulignés dans leur nom (par exemple il y a 6 paquet-diogene_TRUC suivi de différentes langues).

Mais la question est de savoir si seul Plugonet est responsable de la création de ces fichiers (et alors il peut bien faire ce qu'il veut), ou s'il y a déjà eu des créations manuelles.

Committo,Ergo:Sum

8

Mais la question est de savoir si seul Plugonet est responsable de la création de ces fichiers (et alors il peut bien faire ce qu'il veut), ou s'il y a déjà eu des créations manuelles.

sur ce point : à titre personnel j'utilise plugonet que pour migrer d'ancien plugins. Donc oui, je fais des paquet-xxx (mais uniquement parce que c'est la convention, aussi problèmatique soit-elle)

9

Et tu l'as appris par l'exemple de ce que fait Plugonet ?

Committo,Ergo:Sum

10

Ah merci Maïeul, voilà donc la doc de cet aspect de SPIP. Une fois de plus c'est mis un à un endroit improbable et non sur spipnet, ça aide pas. Ou alors si: c'est pas sur spipnet donc ça compte pas !

Committo,Ergo:Sum

11

C’est le problème du _ : il sert à retrouver la langue à partir du nom complet du module.
Le _ etait initialement interdit dans les noms de modules, et j’avais fait l’erreur de l’autoriser ne voyant aucune contre-indication dans le code de SPIP.
Cependant il s’avère que cela pose problème du côté de tradlang qui lui doit remonter du nom du module complet à la langue. Il me semble qu’on a pas de module de langue traduit dans tradlang avec un _ dedans à cause de ça.

Mais peut-être je me trompe complètement, et c’est une limitation qui n’a plus cours sur le nouveau tradlang ?
Quentin peut peut-être nous renseigner ?

Cédric

12

Et tu l'as appris par l'exemple de ce que fait Plugonet ?

non, de Rédaction du paquet.xml - Plugins SPIP

Ah merci Maïeul, voilà donc la doc de cet aspect de SPIP. Une fois de plus c'est mis un à un endroit improbable et non sur spipnet, ça aide pas. Ou alors si: c'est pas sur spipnet donc ça compte pas !

Hum… Je trouve que cette doc est à la bonne place… C'est le site officiel des plugins. Alors quoi de mieux que mettre la nomenclature d'un plugin sur le site dédié ? :wink:

Ybbet

13

Yep,

14

Mets toi à la place de qq qui débarque dans le monde SPIP. Il tape "spip" sur un moteur de recherche, le premier site mentionné c'est spipnet, quant à plugins.spip il n'apparaît meme pas dans la première page des résultats. Alors il fait comment pour savoir comment on écrit un plugin le nouveau venu ? Il cherche dans spipnet pendant des heures, il ne trouve pas ce qu'il faut, alors il dit "ras le bol", et il va utiliser autre chose et dire partout que la doc de SPIP est nulle. Et on ne peut pas lui donner complètement tort.

Committo,Ergo:Sum

15

on a eu beaucoup de module avec underscore rendant la repérage du code de langue très compliqué voire pas totalement déterministe.

Tu veux dire à cause des variantes des langages ? Le fichier foo_fr_fr.php peut être vu soit comme le module "foo" pour la variante "fr" du français, soit comme le module "foo_fr" pour le français en général, c'est bien ça l'indétermination dont tu parles ?

D'où aujourd'hui la seule limitation c'est celle de l'écriture <:module:item:> qui interdit le tiret. Donc il faudrait qu'on décide clairement ce qu'on fait avec le module paquet-prefixe ou si on fait sauter cette limitation.

Il me semble indispensable de régler le problème ci-dessus en même temps que le reste. Ce qui m'apparaît maintenant c'est que le souligné devrait être interdit dans un nom de module, puisqu'il fragilise la déterminantion de la langue dans un nom de fichier de langue à cause de "fr_fr" etc. On pourrait compenser cette interdiction du souligné par l'autorisation du tiret, car si on fait bien les deux en même temps mon argument dans un mail précédent tombe: si un jour on a besoin de créer un identificateur PHP à partir d'un tel nom de fichier, on pourra remplacer "-" par "_" sans risquer de tomber sur identificateur déjà pris à cause d'un fichier identique au "_" près.

Committo,Ergo:Sum

16

Salut,

Et tu l'as appris par l'exemple de ce que fait Plugonet ?

non, de Rédaction du paquet.xml - Plugins SPIP

Ah merci Maïeul, voilà donc la doc de cet aspect de SPIP. Une fois de plus c'est mis un à un endroit improbable et non sur spipnet, ça aide pas. Ou alors si: c'est pas sur spipnet donc ça compte pas !

Hum… Je trouve que cette doc est à la bonne place… C'est le site officiel des plugins. Alors quoi de mieux que mettre la nomenclature d'un plugin sur le site dédié ? :wink:

Moi j'avais un peu l'impression que spip.net faisait office de
spécification : les balises/fonctions/boucles/etc. qui y sont décrits
sont officiels (et donc durables de versions en versions... Sauf
incompatibilités annoncées, elles aussi, sur spip.net). Je pensais
donc que ce qui est écrit ailleurs était plus sujet à fluctuation
(changement de comportement, disparition, etc.). Du coup, il est vrai
qu'une spécification sur un autre site que spip.net : ça me fait
bizarre.

C'est d'ailleurs dommage qu'il n'y ait pas au moins un pointeur depuis
spip.net vers cette spécif'.

17

Yo,

18

Le vrai pb c'est que groupe est pour le moins ... inactif.

J'ai envoyé 3 mails de suggestions dans l'année, jamais eu de réponse

19

Dans Langonet, tu peux regarder dans langonet_utils.php de la version trunk/ en cours (nouvelle version en préparation)

Ah bah, à propos ça aurait été pas mal de créer un trunk et des branches pour Plugonet, notamment quand plugin.xml (i.e. ce qui tournait en 2.1) a été remplacé par paquet.xml.

tu as les regexp :
if (!defined('_LANGONET_PATTERN_FICHIERS_LANG'))
    define('_LANGONET_PATTERN_FICHIERS_LANG', '_[a-z]{2,3}\.php$');
if (!defined('_LANGONET_PATTERN_FICHIERS_LANG_FR'))
    define('_LANGONET_PATTERN_FICHIERS_LANG_FR', '_fr\.php$');
if (!defined('_LANGONET_PATTERN_CODE_LANGUE'))
    define('_LANGONET_PATTERN_CODE_LANGUE', '%_(\w{2,3})(_\w{2,3})?(_\w{2,4})?$%im');

et le code des fonctions trouver_module_langue() et creer_selects(). Ca marche bien mais si on avait un module foo_xx_fr dont le module de langue est foo_xx ça poserait un souci car je considère que les codes de langues sont sur deux ou trois caractères.

Oui c'est insatisfaisant, d'autant qu'ISO 639-6 autorise maintenant 4 caractères.

J'avoue que le tiret aurait ma préférence car il rend la détermination de la langue certaine.

En fait le choix entre tiret ou souligné n'est vraiment pas clair car le RFC 5646 utilise le tiret pour séparer la langue et sa variante. L'essentiel pour nous n'est donc pas de discuter lequel est le mieux, mais seulement de faire un choix. Dans la mesure où ecrire/lang utilise le souligné pour les variantes de langue, il faut l'interdire dans les noms de module, et y autoriser le tiret pour pouvoir structurer les modules de langue d'un plugin.

Maintenant, ça veut dire modifier certains plugins.

Si on envoie un mail sur spip-zone disant qu'on va faire "svn rename" sur le millier de fichiers concernés sur la zone en expliquant pourquoi c'est nécessaire, ça ne devrait poser des problèmes que pour ceux qui ne lisent pas cette liste ou qui ne développent pas sur la zone, sont-ils si nombreux ? En revanche, avant la sortie de versions officielles, il faut modifier le phraseur dans les versions actuelles pour qu'il accepte les 2 caractères afin de ne pas créer d'incompatibilités tout en pouvant poursuivre le développement.

Ce qui est plus embêtant c'est que celle de SPIP.net est fausse sur ce sujet des modules de langue ! voir l'article http://www.spip.net/fr_article2128.html paragraphe "Technique"

Fausse, ce n'est pas le terme qui convient: il est dit de ne pas utiliser le souligné ce qui est justement ce qu'on veut à présent. Qu'en fait le phraseur l'acceptait doit être considéré comme un bug du point de vue de cette doc, qui apparaît du coup prémonitoire. Il lui manque seulement, si on enterinne l'idée du tiret, de parler de celui-ci.

Committo,Ergo:Sum