[spip-dev] Multilinguisme : réflexions

Bonjour à tous,

J'ai constaté que les langues ne sont pas toujours bien traitées par
spip, on me dit de vous en parler ici, dont acte.

1. Attributs @lang du HTML

Quand on insère des attributs dans du code HTML qui est ensuite
"nettoyé" par spip, ces attributs disparaissent. C'est sans doute une
question de sécurité et ça se défend, notamment en ce qui concerne les
forums.

En revanche, une balise <code lang="en"> est transformé en spip code,
et au passage l'information de langue disparaît. De même avec les
paragraphes. Autrement dit, empiriquement je dirais que toutes les
balises touchées/réécrites par spip perdent cette qualité d'indication
de langue.

2. Insérer une citation dans une autre langue

ESJ a soumis aujourd'hui même un correctif qui permet de respecter les
règles typographiques d'une langue en insérant un <multi> dans le
cours d'un texte : http://trac.rezo.net/trac/spip/changeset/14718

C'est formidable, et ça donne une bonne base pour en profiter pour
encadrer le texte généré par cette balise <multi> d'une information de
langue. Le souci évidemment sera de trouver la bonne balise porteuse
de l'attribut @lang, puisque si c'est du contenu inline à l'intérieur
d'autres contenus, inline ou non, on pourra mettre un <span>. Mais si
ce contenu comporte des éléments de type block, list, table, alors on
sera obligé d'insérer une <div> (prise de risque avec les CSS déjà en
place sur certain sites).

On pourrait en profiter, comme suggéré sur spip.org par Valéry, pour
voir si on n'est pas des fois en train d'insérer une langue qui n'a
pas le sens de lecture courant, et donc d'ajouter un attribut @dir.

3. Pourquoi je suis soucieux des attributs @lang ?

Je travaille avec des mal- et non-voyants, et il est vital pour nous
que l'attribut @lang soit correctement renseigné, afin que le moteur
phonologique de la synthèse vocale restitue les bons phonèmes (ça
jette, hein ?).

Autrement dit si on ne marque pas les attributs de langue
correctement, un lecteur d'écran français lira toute la page avec son
moteur français, même si je cite de l'anglais. L'anglais devient alors
incompréhensible (bien que cocasse).

4. En résumé

Ce serait bien :
- de ne pas détruire les indications de langue quand elles existent
(test sur la présence de l'attribut @lang et sans doute vérification
par sécurité de la validité de la chaîne qui s'y trouve)
- d'utiliser l'évolution intégrée aujourd'hui par Emmanuel pour là
encore fournir de l'information de langue

Je n'ai toujours rien compris à la question des tickets, où les
déposer etc., donc vous me pardonnerez j'espère d'avoir jeté ça en
vrac sur spip-dev.

Merci de votre attention :slight_smile:

Stephane Deschamps a écrit :

ESJ a soumis aujourd'hui même un correctif qui permet de respecter les
règles typographiques d'une langue en insérant un <multi> dans le
cours d'un texte : http://trac.rezo.net/trac/spip/changeset/14718

... dont je n'ai pas réussi à décoder le mode d'emploi (honte sur moi, ma famille et mes proches).

à partir d'une saisie dans le corps d'un article en français :

   ceci est du texte en français? oui!
   _ on place une «fine» avant les doubles ponctuations.

   is this an english text ? yes !
   _ there is no space before “double” punctuation.

est-ce sensé afficher dans le public :

   ceci est du texte en français ? oui !
   _ on place une « fine » avant les doubles ponctuations.

   is this an english text? yes!
   _ there is no space before “double” punctuation.

parce que si 'oui', je n'y suis pas arrivé ;
que ce soit avec :

   ceci est du texte en français? oui!
   _ on place une «fine» avant les doubles ponctuations.

   <multi>[en]is this an english text ? yes !
   _ there is no space before “double” punctuation.
   </multi>

qui m'affiche le seul :
   >

ou encore avec :

   <multi>[fr]ceci est du texte en français? oui!
   _ on place une «fine» avant les doubles ponctuations.

   [en]is this an english text ? yes !
   _ there is no space before “double” punctuation.
   </multi>

qui m'affiche le seul bloc correspondant à la langue
choisie grâce au 'menu langue' mais sans en modifier
les formes typographiqes.

bref : je sèche.
(ikéa : revient !)*

* pour le mode d'emploi (bien sûr)

Bonjour Stéphane,

En résumé

Ce serait bien :
- de ne pas détruire les indications de langue quand elles existent
(test sur la présence de l'attribut @lang et sans doute vérification
par sécurité de la validité de la chaîne qui s'y trouve)
- d'utiliser l'évolution intégrée aujourd'hui par Emmanuel pour là
encore fournir de l'information de langue

Merci de tes remarques.

La bibli safehtml utilisée par SPIP pour sécuriser le code n'est plus maintenue, il faut qu'on la remplace.
C'est un serpent de mer récurrent, ça finira par arriver, et on en profitera pour intégrer ça.

Pour le 2e point, cf http://forum.spip.org/fr_218282.html j'aimerais bien faire mieux, mais faut réfléchir pour que ça ne casse pas la validité.

Committo,Ergo:Sum

Stephane Deschamps a écrit :

ESJ a soumis aujourd'hui même un correctif qui permet de respecter les
règles typographiques d'une langue en insérant un <multi> dans le
cours d'un texte : http://trac.rezo.net/trac/spip/changeset/14718

... dont je n'ai pas réussi à décoder le mode d'emploi

...

<multi>[fr]ceci est du texte en français? oui!
_ on place une «fine» avant les doubles ponctuations.

[en]is this an english text ? yes !
_ there is no space before “double” punctuation.
</multi>

qui m'affiche le seul bloc correspondant à la langue
choisie grâce au 'menu langue' mais sans en modifier
les formes typographiqes.

Comme signalé dans mon premier mail, j'ai découvert à cette occasion de typographie/en.php est très lacunaire dans ses interventions, en particulier ceci manque. [14718] garantit que l'appel à la fonction de typo concernée est le bon, mais pas que cette fonction est bonne.

La bibli safehtml utilisée par SPIP pour sécuriser le code n'est plus
maintenue, il faut qu'on la remplace. C'est un serpent de mer récurrent, ça finira par arriver,

realet a fait un plugin pour une alternative à safehtml (dont j'ai
oublié le nom), mais des tests montraient que c'était beaucoup plus
lent. Avec la mémoization on peut gagner un peu, mais il faut tout de
même faire attention à ça. Mais si quelqu'un connait d'autres
librairies, ce serait sympa de les indiquer. Sinon c'est peut-être un
chantier à ouvrir, mais alors par pitié faisons quelque chose qui soit
indépendant de SPIP.

et on en profitera pour intégrer ça.

je pense que ça n'a rien à voir, d'autant que safehtml n'est pas
appliqué sur les articles, mais seulement sur les contenus plus
dangereux provenant de l'extérieur (forums, signatures de pétition).

Il me semble (de tête) que code@lang est éliminé par le raccourci
<code>, et que p@lang est éliminé par paragrapher(). Avec les div@lang
ça n'est pas transformé.

* Fil tapuscrivait, le 06/11/2009 22:45:

La bibli safehtml utilisée par SPIP pour sécuriser le code n'est plus
maintenue, il faut qu'on la remplace. C'est un serpent de mer récurrent, ça finira par arriver,

realet a fait un plugin pour une alternative à safehtml (dont j'ai
oublié le nom)

Et que je n'ai pas maintenu depuis fort longtemps (honte sur moi).
C'est svn://zone.spip.org/spip-zone/_plugins_/htmlpurifier
De mémoire, il est en version 2 dans le plugin alors que la 4 est sortie :
http://htmlpurifier.org/news/2009/0708-4.0-released

À noter HTML Purifier nécessite PHP 5 !

J'ai testé le nouveau système sous les deux branches, et ça buggue sur
la stable (d'où les malheurs de denisb):

Dans un article fr:
    elle m'a dit <multi>[en]Come here bastard!</multi> j'étais conquis

ancien: bastard&nbsp;!
nouveau, 2.0: bastard&nbsp;!
nouveau, 2.1: bastard! (correct)

souhaité : <span lang="en">bastard!</span>
et, dans le cas d'un changement de dir: <span lang="ar" dir="rtl">(arabe)</span>

-- Fil

Bon déjà voici une bonne chose de faite : safehtml a quitté le core
pour entrer dans un plugin (enfin, une extension fortement
recommandée).

[14722] sur le core
[32716] pour le plugin

Cette librairie n'a pas été mise à jour depuis 4 ans, et le site de
ses auteurs a disparu. Il ne reste comme trace qu'une page sur
ohloh...

-- Fil

C'est étrange, moi j'ai le comportement correct dans les 2 branches quand j'insère cette même chaîne dans un même article (une copie de spipnet en 2.0 et l'autre en 2.1).

Committo,Ergo:Sum

C'est étrange, moi j'ai le comportement correct dans les 2 branches quand
j'insère cette même chaîne dans un même article (une copie de spipnet en 2.0
et l'autre en 2.1).

Ah! mes excuses, après vidage de tmp/charger* c'est bon !

Committo,Ergo:sum a écrit :

ancien: bastard&nbsp;!
nouveau, 2.0: bastard&nbsp;!
nouveau, 2.1: bastard! (correct)

C'est étrange, moi j'ai le comportement correct dans les 2 branches quand j'insère cette même chaîne dans un même article (une copie de spipnet en 2.0 et l'autre en 2.1).

ok ok ok. milexcuses...

après rafraîchissement de mon neurone, *effectivement*
en 2.0.10 stable, cela fonctionne comme prévu.
à savoir :

dans un article en français :
   ceci est du texte en français? oui!
   _ on place une «fine» avant les doubles ponctuations.

   <multi>[en]is this an english text? yes!
   _ there is no space before “double” punctuation.</multi>

est bien rendu par (source html) :
   <p>
   ceci est du texte en français&nbsp;? oui&nbsp;!
   <br />
   on place une &#171;&nbsp;fine&nbsp;&#187; avant les doubles ponctuations.
   </p>

   <p>
   is this an english text? yes!
   <br />
   there is no space before “double” punctuation.
   </p>

où l'on voit bien que l'insécable n'a pas été glissé entre 'text' et '?'
alors qu'il l'a été (et à bon escient) entre 'français' et '?'

so: ruuulezzz !!!*

* ou l'art de se rattraper (maladroitement) aux branches...

Il me semble (de tête) que code@lang est éliminé par le raccourci
<code>,

Ah en effet. Alors maintenant ce n'est plus le cas:
http://trac.rezo.net/trac/spip/changeset/14723

pour répondre à denisb, le moteur typo n'est PAS un moteur de
*correction* typographique, mais un moteur typographique tout bête,
destiné à automatiser les trucs répétitifs et chiants, comme d'ajouter
les insécables en français. En anglais il ne viendrait à personne
l'idée de taper

is this an english text ? yes !

(et, dans le cas où on tape ça, j'admets qu'on ajoute un insécable à
la place de l'espace dans ces deux cas, je pense que ce serait une
erreur de supprimer l'espace).

Pas sûr que tout le monde voit ça comme ça.
Si je suis un franchouillard qui baragouine 3 mots d'anglais, je crois bien faire en mettant un espace avant "?" comme ma maîtresse elle m"avait appris à mon école de quand j'étais pas grand. Si l'ordinateur il me dit que c'est lui ka raison, eh ben je le crois et je suis content.

Mais bon, ce n'est qu'un avis de franchouillard.

Committo,Ergo:Sum

Il me semble (de tête) que code@lang est éliminé par le raccourci
<code>,

Ah en effet. Alors maintenant ce n'est plus le cas:
http://trac.rezo.net/trac/spip/changeset/14723

Cool, et j'ai aussi réparé paragrapher() pour conserver les attributs des P.

le moteur typo n'est PAS un moteur de *correction* typographique

Si je suis un franchouillard qui baragouine 3 mots d'anglais, je crois bien
faire en mettant un espace avant "?" comme ma maîtresse elle m"avait appris

SPIP offre un moteur typographique qui ne vise pas à corriger, mais à
automatiser. Mon assertion n'était pas normative, mais descriptive.
Autrement dit : libre à qui veut d'y ajouter un moteur de correction
typographique multilingue. Ce n'est juste pas le propos du code
actuel.

En parlant de typographie, je crois qu'une amélioration prochaine sera
d'installer des espaces fines à la place des gros &nbsp; -- quitte à
les retransformer à la volée en &nbsp; lorsqu'on détecte un navigateur
mal embouché. Mais ce sera alors certainement un plugin.

-- Fil

En parlant de typographie, je crois qu'une amélioration prochaine sera
d'installer des espaces fines à la place des gros &nbsp; -- quitte à
les retransformer à la volée en &nbsp; lorsqu'on détecte un navigateur
mal embouché. Mais ce sera alors certainement un plugin.

Zut, nos mails se sont croises.