[spip-dev] Nouveau filtre pour remplacer singulier_ou_pluriel()

Hello,

Suite à une discussion sur irc, voici les spécifications d’un nouveau filtre destiné à remplacer singulier_ou_pluriel… en mieux !

  • Proposition de nom : un_ou_plusieurs()

  • Prototype de la fonction : un_ou_plusieurs($nb, $chaine_un, $options=array())

  • Résumé :
    Permet d’afficher la chaine correspondant au singulier, au pluriel voire au duel pour les langues qui supportent cette spécificité (arabe, par exemple).
    Les options permettent principalement d’ajouter des paramètres supplémentaires de personnalisation de la chaine de langue…
    Cette fonction n’est pas destinée à conserver la compatibilité avec singulier_ou_pluriel mais à la remplacer petit à petit.

La base du traitement est de considérer qu’un item pluriel ou duel est construit sur la base du nom de l’item singulier de la manière suivante :

  • singulier : ‘item_un’
  • pluriel : ‘item_un_pluriel’
  • duel : ‘item_un_duel’

Pour illustrer voilà des exemples avec les items de langue français, pour un module de langue “test” :

‘un_article’ => ‘article’
‘un_article_pluriel’ => ‘articles’

‘un_fichier’ => ‘@nb_fic@ fichier’
‘un_fichier_pluriel’ => ‘@nb_fic@ fichiers’

‘un_autre_fichier’ => ‘@nb@ fichier de type @type@’
‘un_autre_fichier_pluriel’ => ‘@nb@ fichiers de type @type@’

Appels en php :

de façon classique, dans un contexte français :

  • un_ou_plusieurs(1, ‘test:un_article’) => renvoie la chaine ‘article’
  • un_ou_plusieurs(3, ‘test:un_article’) => renvoie la chaine ‘articles’

en supposant que nous sommes en arabe et que la chaine un_article_duel existe :

  • un_ou_plusieurs(2, ‘test:un_article’) => renvoie la traduction arable correspondant à l’item ‘un_article_duel’

Pour l’utilisation de $options, on a la possibilité de préciser le nom du paramètre représentant le nombre (cela permet de ne pas modifier les chaines actuelles sauf le nom de l’item) :

  • un_ou_plusieurs(1, ‘test:un_fichier’, array(‘nb’ => ‘nb_fic’)) => renvoie la chaine ‘1 fichier’
  • un_ou_plusieurs(3, ‘test:un_fichier’ array(‘nb’ => ‘nb_fic’)) => renvoie la chaine ‘3 fichiers’

Enfin, pour passer des paramètres supplémentaires :

  • un_ou_plusieurs(1, ‘test:un_fichier’, array(‘type’ => ‘php’)) => renvoie la chaine ‘1 fichier de type php’
  • un_ou_plusieurs(3, ‘test:un_fichier’ array(‘type’ => ‘log’)) => renvoie la chaine ‘3 fichiers de type log’

Les différents cas peuvent bien entendu se combiner.

Voilà voilà
J’attends vos remarques avant de déverser le code dans SPIP.

16/04/11, Eric:

Suite à une discussion sur irc, voici les spécifications d'un nouveau
filtre destiné à remplacer singulier_ou_pluriel... en mieux !

- Proposition de nom : *un_ou_plusieurs()*
- Prototype de la fonction : un_ou_plusieurs(*$nb, $chaine_un,
$options=array()*)

- Résumé :
Permet d'afficher la chaine correspondant au singulier, au pluriel
voire au duel pour les langues qui supportent cette spécificité
(arabe, par exemple). Les options permettent principalement d'ajouter
des paramètres supplémentaires de personnalisation de la chaine de
langue... Cette fonction n'est pas destinée à conserver la
compatibilité avec singulier_ou_pluriel mais à la remplacer petit à
petit.

C'est pas un sujet simple. Certes, limiter les possibilités à =1 ou >1
est réducteur et handicapant, mais ajouter seulement le cas =2 l'est
aussi, même si ça marche pour le breton :smiley:
Par exemple le russe change de forme à partir de 5 (je croyais que
c'était 8 d'ailleurs mais apparemment c'est 5). C'est même plus
complexe que ça: pour un bon aperçu des cas possibles, l'article
Pluriel — Wikipédia est une mine d'or, qu'il faut à
mon avis lire entièrement avant de se frotter à ce sujet.

Bref, on devrait peut-être trouver une manière de généraliser un peu
plus le truc. Après, c'est évident qu'on pourra jamais trouver *le*
mécanisme parfait qui marche pour toutes les langues et toutes les
situations, mais migrer de système est toujours lourd, donc quite à le
faire, autant en profiter pour trouver quelque chose qui soit le plus
universel possible.

Pas de proposition concrète à ce stade (j'ai lu l'article wikipedia
mais en diagonale), mais vraiment migrer pour ajouter juste le cas du
duel serait contre-productif, je trouve.

Une piste serait de voir comment le font les autres logiciels
souhaitant être "sérieux" sur le sujet.

17/04/11, davux:

Pas de proposition concrète à ce stade (j'ai lu l'article wikipedia
mais en diagonale), mais vraiment migrer pour ajouter juste le cas du
duel serait contre-productif, je trouve.

Après une lecture un peu moins en diagonale, il semblerait que dans
notre cas c'est surtout la section "Types de nombres" qui nous
concerne. Plus spécifiquement, ce chapitre dit que c'est
essentiellement le seuil qui change :

- Duel (2): en lituanien, slovène, sorabe, grec ancien, sanskrit,
  hébreu, arabe
- Triel (3): dans certaines langues australiennes et austronésiennes
  tel le mwotlap
- Quatriel (4): certains mots du marshallais et du sursurunga de
  Nouvelle-Irlande (voir article anglophone sur le quadral pour les
  précisions)
- Paucal (peu): en warlpiri, en hopi, arabe et russe pour quelques noms
- Pluriel: dans tous les cas, au-delà du dernier seuil éventuel.

Pour le singulatif vs. singulier, le partitif et plein de distinctions
faites dans l'article, ça va dépendre du mot donc c'est un choix
lexical du traducteur.

Le reste de l'article porte sur la construction du pluriel (S à la fin,
etc.), la prononciation, le nous-exclusif vs. nous-inclusif, la
conjugaison et ce genre de trucs, donc pour notre histoire de filtre on
s'en fiche.

Du coup, une idée serait d'utiliser un nombre en suffixe au lieu du mot
"pluriel". Ce nombre est le seuil à partir duquel on change de forme.

Par exemple, en anglais:
souris: mouse
souris_2: mice

en français :
souris: souris
(rien d'autre car c'est invariable)

en russe :
souris: blablabla
souris_6: blublublu

Avec ce système on gère toujours le cas du duel (_2 pour le duel, puis
_3 pour le pluriel), en plus générique car le seuil peut être différent
pour chaque langue et même pour chaque mot, ce qui est super car dans
plein de langues on va avoir des formes spécifiques pour certains trios,
quatuors, etc., par exemple le russe (encore) mais aussi plein
d'autres. Souplesse totale pour les traducteurs, donc.

Cerise sur le gâteau, on peut même utiliser _0 pour dire "aucun" ou si
la forme du nom change (genre pas de gants, un gant, @nb gants).

Un autre avantage c'est que le système est simple, tant pour les
traducteurs que pour SPIP: chaque nombre représente la première valeur
à partir de laquelle ça change.

L'inconvénient c'est qu'un "_2" est moins joli qu'un "_pluriel" (dixit
Eric), mais je trouve que vu la généralisation que ça permet, ça vaut
carrément le coup. Et d'ailleurs l'argument de la beauté est
réversible: les non-francophones préfèreront sûrement _2 à _pluriel car
ça fait un mot français de moins dans le jargon spipien.

Est-ce que ce système referme des portes ouvertes par la version
_pluriel et _duel ?

Est-ce qu'on peut l'améliorer ?

Hi

Je salue l'introduction de plus d'un pluriel surtout pour l'arabe. Je ne sais pas si j'ai bien compris les $options de la fonction mais est_ce qu'elles peuvent satisfaire toutes les conditions "des pluriels" arabes. Pour ces pluriels se referer au message:

George

17/04/11, George:

Je salue l'introduction de plus d'un pluriel surtout pour l'arabe. Je
ne sais pas si j'ai bien compris les $options de la fonction mais
est_ce qu'elles peuvent satisfaire toutes les conditions "des
pluriels" arabes. Pour ces pluriels se referer au message:

Discuter chez rezo.net

Est-ce que pouvoir écrire le fichier de langue de la façon suivante
résoudrait la question ?

'temps_minutes_1' => 'منذ دقيقة واحدة',
'temps_minutes_2' => 'منذ دقيقتين',
'temps_minutes_3' => 'دقائق @nb@ منذ',
'temps_minutes_11 => 'دقيقة @nb@ منذ',

Les suffixes numériques (éventuellement différents suivant les mots)
représenteraient la quantité à partir de laquelle la forme
correspondante s'applique (cf. mon mail précédent sur le sujet).

[Note: Je ne parle pas l'arabe donc j'ai fait un bête copier-coller
pour cet exemple, j'espère que les outils intermédiaires (arbrows,
firefox, claws-mail) ne se sont pas mélangé les pinceaux dans les
changements de sens d'écriture, mais je ne crois pas car ça semble
cohérent.]

On pourrait mais j'imagine la taille du fichier de langue qui va recenser tous les mots utilises avec des nombres et inclure leurs trois formes. De plus, si on veut etre typographiquement puritain les nombres jusqu'a dix s'ecrivent en toutes lettres et pas en chiffres. En tout cas, quelque soient les tentatives, elles ne pourront qu'ameliorer la situation actuelle ou tous les mots accompagnes de nombres sot prennent la quatrieme form dans l'exemple meme si le nombre est compris entre 2 et 10 (c'est parti de la supposition que 10 objets sont vite depasses dans un site d'activite normale et donc apres un petit laps de temps on tombe sur la bonne forme).

Je ne suis pas certain de ça.
Je penshe qu'il faudrait plutot partir de comment font les fichiers .po utilisés avec gettext.

gettext s'ulitise par exemple :
- gettext('chaine')
- gettext('chaine', 'chaines', 3) // singulier/pluriel basique, + on passe le nombre

Dans les fichiers .po se trouvent une définition des formes de pluriels
(http://www.gnu.org/software/hello/manual/gettext/Plural-forms.html - milieu du document)

Notamment, on indique le nombre de pluriel différents et comment on fait pour trouver l'état correspondant par rapport au nombre passé :

Pas de pluriel :
Plural-Forms: nplurals=1; plural=0;

1 pluriel (0 est pluriel) :
Plural-Forms: nplurals=2; plural=n != 1;

1 pluriel (0 singulier) :
Plural-Forms: nplurals=2; plural=n>1;

3 pluriels
Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n != 0 ? 1 : 2;

et ainsi de suite.
du coup, c'est le fichier de langue qui défini ses formes de pluriels 0 étant le singulier, 1 le premier pluriel, 2 le second pluriel...

Mais le nombre de formes est indéfinissables puisqu'on le voit clairement sur certains exemples : le pluriel dépend du modulo d'un nombre. On ne peut pas écrire (dans ce que proposait George) :
"chaine_1" si la forme de pluriel s'applique aussi sur 101 1001, 10001...

Donc... que SPIP connaisse les formes de pluriel d'une langue me semble une piste à creuser, de sorte qu'on puisse dire que
'chaines_1' correspond à la forme 1 de pluriel dans la langue

Je verrais plus donc, en plus de _T, une fonction _PT (plural trad) (ou une modification de _T pour accepter ces nouvelles choses) qui aurait 3 arguments ou 4 arguments (singulier, pluriel, nb, opts).

_T('chaine') // normal
_T('chaine', 'chaines', 3, opt) // pluriels

Dans une langue,
'chaine' = le singulier
'chaines' = le pluriel par défaut
'chaines_1' = la forme 1 de pluriel
'chaines_2' = la forme 2 de pluriel

On doit même pouvoir dire que 'chaines' est une des formes de pluriels tel qu'on puisse par exemple se passer d'écrire 'chaines_3'

Voilà mes idées du jour :slight_smile:

Matthieu

Bon,

J’envoie ce soir un petit plugin de dev “Pluriel” avec une ou deux approches et on commence à tester. Une fois qu’on est satisfait on déversera la fonction choisie dans SPIP.

Quoting Eric <eric@smellup.net>:

Bon,

J'envoie ce soir un petit plugin de dev "Pluriel" avec une ou deux approches
et on commence à tester. Une fois qu'on est satisfait on déversera la
fonction choisie dans SPIP.

++
Eric

faut-il une version particuliere de SPIP pour ce plugin ou la version actuelle suffit? (c'est pour voir si je met a jour la 2.3 dev chez moi)

George

Non, non ça marchera avec la 2.1

Re,

Donc voilà le plugin de dev est sur la zone et fonctionne.
Il est dans dev/ et s’appelle “Pluriel”.

Pour récupérer son zip utiliser l’url suivante :
http://zone.spip.org/trac/spip-zone/changeset/latest/dev/pluriel?old_path=/&format=zip

Il fonctionne par intervalle. On définit pour la langue les seuils min des intervalles.
les items de langues sont définis ainsi :

  • item_pour_le_un
  • item_pour_le_un_pluriel : standard ou dernier intervalle
  • item_pour_le_un_${seuil_bas} des intervalles nécessairs aux formes spéciales de pluriel.

Par exemple pour l’arabe j’ai configuré un seuil à 2, un seuil à 3 et un seuil à 11. Le seuil à seuil correspond au pluriel standard.
Donc pour fonctionner il faut définir dans ce cas :
‘temps_minute’ => ‘منذ دقيقة واحدة’,
‘temps_minute_2’ => ‘منذ دقيقتين’,
‘temps_minute_3’ => ‘دقائق @nb@ منذ’,
‘temps_minute_pluriel’ => ‘دقيقة @nb@ منذ’,

Le nom du filtre est un_ou_plusieurs.
Un page de tests du privé est disponible à l’adresse exec=pluriel

Il me semble que le “0” était discuté dans un mail précédent, j’en aurais bien besoin pour remplacer mon filtre spécifique :
http://zone.spip.org/trac/spip-zone/browser/plugins/clevermail/2_0/inc/clevermail_filtres.php#L11

2011/4/18 Eric <eric@smellup.net>

Yop,

Encore une fois, quitte à me faire taper dessus, je ne pense pas que ce soit suffisant (même si c'est mieux que ce qu'on a actuellement) et il me semble plus intéressant que spip sache utiliser tout cru les formules mathématiques de pluriels incluses dans les fichiers po.

:slight_smile:

Yep,

2011/4/18 Matthieu Marcillaud <marcimat@rezo.net>

Encore une fois, quitte à me faire taper dessus, je ne pense pas que ce soit suffisant (même si c’est mieux que ce qu’on a actuellement) et il me semble plus intéressant que spip sache utiliser tout cru les formules mathématiques de pluriels incluses dans les fichiers po.

Non non on adore quand tu te répètes… :stuck_out_tongue:

J’ai jamais dit que j’avais commité le plugin ultime de ce point vue.
Ta proposition, je viens de la regarder, est une généralisation de ce que j’ai codé dans pluriel actuellement.
Aujourd’hui la fonction c’est juste l’intervalle (qui a priori doit souvent convenir).

Donc au lieu du tableau simple avec la liste des seuils (qui correspond à des fonctions du type <= ou >) il faudrait un tableau de règles (en php, pour simplifier l’eval à mon avis) et recoder la partie spécifique ainsi.

Ca me parait pas insurmontable.
Bon ensuite faut apprendre le php aux traducteurs :stuck_out_tongue:

2011/4/18 Matthieu Marcillaud <marcimat@rezo.net>

Oui pour la première assertion à cause de la gestion des priorités de chargement assez compliquée en SPIP, en revanche on pourrait ne rien changer pour les traducteur en faisants un transcodage du format actuel en format PO en aval. Mais on retombe sur la même discussion qu'avec la syntaxe actuelle des squelettes: les utilisateurs de SPIP sont-ils prêts à renoncer à des syntaxes propriétaires pour lesquelles il n'existe ni habitude ni aucun outil outil autre que ceux développés par la communauté, ou bien continue-t-on à estimer qu'abandonner des syntaxes sans avenir est leur demander un sacrifice énorme restreignant leur liberté, notamment celle de rester une fausse piste ?

Committo,Ergo:Sum

C'est très désagréable de lire ceci.
ça commence comme une question mais ça se termine pasvujtembrouille
comme un lot d'affirmations prophétiques, ce qui pourrait être risible,
pas complètement idiotes non plus
mais très sombres et professées d'une manière non argumentée...
Au final, ce n'est pas de rire que ça me donne envie;
pas de gerber non plus je ne vais pas exagérer,
mais pas non plus de se rallier à ton opinion.

JLuc

L'argument est historique et de bon sens: on n'a jamais vu des syntaxes minoritaires s'imposer à la majorité si elles n'ont pas une supériorité incontestable et bien visible. L'histoire de l'informatique est jonchée de projets abandonnés faute d'avoir compris ça. Il y a 10 ans on pouvait écrire XML Go Home, parce qu'il était encore peu utilisé, aujourd'hui, puisque personne n'a trouvé mieux, il faut lire sa doc soigneusement et tirer le meilleur parti de ses outils. Aujourd'hui il y a des extensions de Dreamweaver pour tous les outils comme SPIP sauf pour SPIP, et la raison à mon avis en est là, avec toute la mauvaise image qui en découle pour SPIP. Pour les fichiers de langues il va se passer la même chose: les outils autour d'eux se développement, et SPIP sera là aussi à la traine.

Alors je le répète: l'argument "si on oblige à changer les habitudes on fait fuir" est un faux argument parce que fatalement la fuite aura lieu vers des outils plus complets que ceux que peut développer une petite communauté comme la nôtre, sans parler de ceux qui ne viendront même pas. C'est hélas aussi simple que cela.

Committo,Ergo:Sum

Hello,