Author: esj@rezo.net
Date: 2009-11-06 09:21:13 +0100 (ven, 06 nov 2009)
New Revision: 14718
Log:
Correction/extension de la balise {{{multi}}}, en réponse à [http://forum.spip.org/fr_218282.html un besoin exprimé dans le forum]. Si la balise multi n'a pas une entrée correspondant à la langue courante du texte, il ne faut pas typographier le texte sélectionné par défaut avec les règles de la langue courante, mais avec celle associée à ce texte. Du coup, il est possible d'obtenir la bonne typographie d'une citation dans une autre langue, en utilisant une balise {{{multi}}} volontairement réduite à une seule entrée.
C'est quand même une modification qui touche l'enchainement des appels des
fonctions de formatage, ce qui n'est pas anodin pour une version stable, non
?
Sur le fond, à ce compte là, il faudrait aussi ajouter un <span
lang='xx'>...</span> autour du contenu qui est dans une langue différente de
celle du contexte, car les changements de langue ne concernent pas que la
typographie, mais aussi les synthèses vocales.
Cédric
Le 6 novembre 2009 09:21, <esj@rezo.net> a écrit :
Author: esj@rezo.net
Date: 2009-11-06 09:21:13 +0100 (ven, 06 nov 2009)
New Revision: 14718
Log:
Correction/extension de la balise {{{multi}}}, en réponse à [ http://forum.spip.org/fr_218282.html un besoin exprimé dans le forum]. Si
la balise multi n'a pas une entrée correspondant à la langue courante du
texte, il ne faut pas typographier le texte sélectionné par défaut avec les
règles de la langue courante, mais avec celle associée à ce texte. Du coup,
il est possible d'obtenir la bonne typographie d'une citation dans une autre
langue, en utilisant une balise {{{multi}}} volontairement réduite à une
seule entrée.
C'est quand même une modification qui touche l'enchainement des appels des fonctions de formatage, ce qui n'est pas anodin pour une version stable, non ?
Je n'ai pas l'impression que l'ordre d'application soit changé: extraire_multi était appelé implicitement dans corriger_typo via son pipeline, j'ai simplement explicité cet appel pour traiter à part les cas ne portant pas sur la même langue, lieu précis du bug.
Sur le fond, à ce compte là, il faudrait aussi ajouter un <span lang='xx'>...</span> autour du contenu qui est dans une langue différente de celle du contexte, car les changements de langue ne concernent pas que la typographie, mais aussi les synthèses vocales.
Oui cette modif n'est probablement pas suffisante, mais comme tu dis ce n'est pas anodin si on n'y va pas doucement.
Sur le fond, à ce compte là, il faudrait aussi ajouter un <span
lang='xx'>...</span> autour du contenu qui est dans une langue différente de
celle du contexte, car les changements de langue ne concernent pas que la
typographie, mais aussi les synthèses vocales.
Oui cette modif n'est probablement pas suffisante, mais comme tu dis ce
n'est pas anodin si on n'y va pas doucement.
C'est super, et en effet l'idée de Cédric s'impose aussi ; mais gaffe
au choix span|div.
Le seul truc qui me chagrine à la lecture du commit, c'est que le code
d'extraction du multi est désormais présent deux fois, et dans deux
fichiers différents : inc/filtres et inc/texte. (et dans deux branches
diffférentes, ce qui ne facilite pas le dev)
Le seul truc qui me chagrine à la lecture du commit, c'est que le code
d'extraction du multi est désormais présent deux fois, et dans deux
fichiers différents : inc/filtres et inc/texte. (et dans deux branches
diffférentes, ce qui ne facilite pas le dev)
Oui ça m'ennuie aussi. En fait extraire_multi etc devraient être dans inc/texte,
j'ai hésité à le faire mais la série d'include sous-jacente n'est pas facile à suivre,
j'ai préféré ne pas prendre de risque.
Mais je pense qu'en fait le pb est ailleurs: les 10 appels à extraire_multi qui restent
sont vraisemblablement porteurs du même bug que celui que je viens de corriger,
il faudrait les regarder un à un et refactoriser le tout.
J'en profite pour signaler que j'ai été surpris de voir que typographie_en est très lacunaire dans ses corrections typograhiques,
il y a un expert dans la salle ?
Le 6 novembre 2009 10:14, Fil <fil@rezo.net> a écrit :
>> Sur le fond, à ce compte là, il faudrait aussi ajouter un <span
>> lang='xx'>...</span> autour du contenu qui est dans une langue
différente de
>> celle du contexte, car les changements de langue ne concernent pas que
la
>> typographie, mais aussi les synthèses vocales.
>
> Oui cette modif n'est probablement pas suffisante, mais comme tu dis ce
> n'est pas anodin si on n'y va pas doucement.
C'est super, et en effet l'idée de Cédric s'impose aussi ; mais gaffe
au choix span|div.
Le span a précisemment été inventé pour pouvoir porter les changements de
langue sans aucune autre information de structure.
La pratique lui a trouvé plein d'autres usages où il est potentiellement en
concurrence avec le div notamment, mais dans ce cas précis c'est bien le
span qui s'impose naturellement.
Le 6 novembre 2009 10:14, Fil <fil@rezo.net> a écrit :
>> Sur le fond, à ce compte là, il faudrait aussi ajouter un <span
>> lang='xx'>...</span> autour du contenu qui est dans une langue différente de
>> celle du contexte, car les changements de langue ne concernent pas que la
>> typographie, mais aussi les synthèses vocales
A ce que je comprends, est-ce qu'il ne suffirait pas de rajouter un paramètre optionnel $lang à code_echappement pour obtenir ça ?
Sinon, je suis en train de regarder les 10 appels à extraire_multi, en fait il y en a beaucoup qui étaient redondants car argument de typo().
Commit à suivre quand j'aurais fini.
La pratique lui a trouvé plein d'autres usages où il est potentiellement en
concurrence avec le div notamment, mais dans ce cas précis c'est bien le
span qui s'impose naturellement.
oui, c'est cela... sauf quand c'est un div
Pour être clair : la question qui se pose c'est de savoir si le bloc
multi remonte ou pas un contenu de type block. Si oui, c'est div, si
non, c'est span.
Le 6 novembre 2009 11:53, Fil <fil@rezo.net> a écrit :
> La pratique lui a trouvé plein d'autres usages où il est potentiellement
en
> concurrence avec le div notamment, mais dans ce cas précis c'est bien le
> span qui s'impose naturellement.
oui, c'est cela... sauf quand c'est un div
Pour être clair : la question qui se pose c'est de savoir si le bloc
multi remonte ou pas un contenu de type block. Si oui, c'est div, si
non, c'est span.
Je ne suis pas sur de comprendre.
Tu veux dire que tu es susceptible de mettre à la main des <div> ou <p> dans
le <multi> ?
Dans ce genre de cas, il y aura toujours des cas ingérables :
Le rédacteur qui fait (exemple idiot)
<multi>[en] Hey <p>Jude</p></multi>
s'attend à avoir son premier mot à la suite du texte qui précède, et le
suivant dans un paragraphe séparé.
Traiter tous les cas tordus va demander de déployer une usine à gaz, j'en ai
peur
D'autant plus que au moment ou on extrait les multi, on n'a pas encore
appliqué le traitement des raccourcis qui peuvent créer des blocs, et il est
difficile de dire ce qui va se passer.
Le 6 novembre 2009 11:53, Fil <fil@rezo.net> a écrit :
> La pratique lui a trouvé plein d'autres usages où il est potentiellement
> en
> concurrence avec le div notamment, mais dans ce cas précis c'est bien le
> span qui s'impose naturellement.
oui, c'est cela... sauf quand c'est un div
Pour être clair : la question qui se pose c'est de savoir si le bloc
multi remonte ou pas un contenu de type block. Si oui, c'est div, si
non, c'est span.
Je ne suis pas sur de comprendre.
Tu veux dire que tu es susceptible de mettre à la main des <div> ou <p> dans
le <multi> ?
Dans ce genre de cas, il y aura toujours des cas ingérables :
Le rédacteur qui fait (exemple idiot)
<multi>[en] Hey <p>Jude</p></multi>
s'attend à avoir son premier mot à la suite du texte qui précède, et le
suivant dans un paragraphe séparé.
Traiter tous les cas tordus va demander de déployer une usine à gaz, j'en ai
peur
D'autant plus que au moment ou on extrait les multi, on n'a pas encore
appliqué le traitement des raccourcis qui peuvent créer des blocs, et il est
difficile de dire ce qui va se passer.
Ok ca a l'air super intéressant seulement cela provoque pas mal de problèmes
...
Sur un site dont le contenu est bilingue ... composé que d'articles
contenant des balises multi pour ces 2 langues et n'utilisant pas le système
de traduction en dupliquant les articles ... et en utiisant
$forcer_lang=true dans mes_options ... le contenu ne prend pas la langue de
l'environnement apparemment et donc ne ressort pas forcément la bonne langue
...
C'est un peu ennuyant d'avoir fait cela sur la branche dite "stable" ... je
trouve
++
kent1
Le 6 novembre 2009 09:21, <esj@rezo.net> a écrit :
Author: esj@rezo.net
Date: 2009-11-06 09:21:13 +0100 (ven, 06 nov 2009)
New Revision: 14718
Log:
Correction/extension de la balise {{{multi}}}, en réponse à [ http://forum.spip.org/fr_218282.html un besoin exprimé dans le forum]. Si
la balise multi n'a pas une entrée correspondant à la langue courante du
texte, il ne faut pas typographier le texte sélectionné par défaut avec les
règles de la langue courante, mais avec celle associée à ce texte. Du coup,
il est possible d'obtenir la bonne typographie d'une citation dans une autre
langue, en utilisant une balise {{{multi}}} volontairement réduite à une
seule entrée.
Le 11 novembre 2009 08:43, Committo,Ergo:sum <esj@rezo.net> a écrit :
Le 11 nov. 09 à 00:53, Quentin Drouet a écrit :
Ok ca a l'air super intéressant seulement cela provoque pas mal de
problèmes ...
un ou plusieurs ?
C'est un peu ennuyant d'avoir fait cela sur la branche dite "stable" ...
Plutôt qu'un jugement de valeur pour le moins discutable, tu ne pourrais
pas donner un exemple précis ?
Committo,Ergo:Sum
Désolé .. un peu énervé car le lancement du site devait se faire aujourd'hui
et que j'ai up hier soir pour avoir la dernière stable
Je suis revenu en arrière du coup en attendant ... je monte un site de test
en rentrant chez moi ce soir pour te montrer le cas ...
Mais c'est juste un site bilingue simple qui ne tenais pas compte réellement
des langues des articles mais uniquement des multi à l'intérieur du texte et
des titres ...
avec $forcer_lang = true; dans mes_options qui auparavant prenait la langue
du menu langue pour afficher le contenu des articles et qui dorénavant ne la
prend plus...
Le 11 novembre 2009 08:43, Committo,Ergo:sum <esj@rezo.net> a écrit :
Le 11 nov. 09 à 00:53, Quentin Drouet a écrit :
Ok ca a l'air super intéressant seulement cela provoque pas mal de
problèmes ...
un ou plusieurs ?
C'est un peu ennuyant d'avoir fait cela sur la branche dite "stable" ...
Plutôt qu'un jugement de valeur pour le moins discutable, tu ne pourrais
pas donner un exemple précis ?
Committo,Ergo:Sum
Désolé .. un peu énervé car le lancement du site devait se faire aujourd'hui
et que j'ai up hier soir pour avoir la dernière stable
Oui, c'est énervant, car ce genre de up devrait toujours pouvoir se faire les yeux fermés du point de vue des utilisateurs.
C'est ce qu'on avait convenu et qu'on essaye de tenir, même si il semble qu'on ait un peu dérapé ce coup là, alors.
J'avoue qu'en voyant passer le commit, j'ai failli dire que ça me parraissait un peu gros pour une branche stable, mais je me suis retenu pour ne pas être l'empêcheur de tourner en rond.
Dans le doute, je ne me retiendrai pas la prochaine fois, alors.
Je suis revenu en arrière du coup en attendant ... je monte un site de test
en rentrant chez moi ce soir pour te montrer le cas ...
Mais c'est juste un site bilingue simple qui ne tenais pas compte réellement
des langues des articles mais uniquement des multi à l'intérieur du texte et
des titres ...
avec $forcer_lang = true; dans mes_options qui auparavant prenait la langue
du menu langue pour afficher le contenu des articles et qui dorénavant ne la
prend plus...
Soit on peut rétablir le comportement antérieur en gardant la nouvelle feature, soit on réserve le nouveau fonctionnement des multi à la branche dev.
Le 11 nov. 2009 à 16:39, Matthieu Marcillaud a écrit :
cedric.morin@yterium.com a écrit :
Soit on peut rétablir le comportement antérieur en gardant la nouvelle feature, soit on réserve le nouveau fonctionnement des multi à la branche dev.
Soit on met un define comme pour les répertoire .plat qui ont aussi posé problème il semble à
certains entre la 2.0.9 et la 2.0.10 ?
Oui d'ailleurs ce coup là aussi était discutable. Sur la branche stable, le define aurais du être conservateur par défaut, pour ne pas changer le fonctionnement.
Le 11 nov. 09 à 16:23, cedric.morin@yterium.com a écrit :
Oui, c'est énervant, car ce genre de up devrait toujours pouvoir se faire les yeux fermés du point de vue des utilisateurs.
Faudrait quand même pas exagérer: 14718 n'est pas la 2.0.X stable, c'est une future 2.0.11 dont un bug, signalé dans les forums, venait d'être corrigé, et comme c'est récent il y a toujours un risque qu'un cas particulier se révèle en souffrir. La dernière stable est la 14697, c'est elle qu'il vaut mieux mettre en production.
Par ailleurs, je ne comprends pas pourquoi tu ne donnes pas l'extrait adéquat de l'article qui pose pb, avec la query-string associée: ça permet beaucoup plus rapidement de localiser le bug que des périphrases.
Désolé je n'ai rien fourni parce que je ne pouvais pas ...
je n'avais à dispo que mes mails via téléphone (réu de famille des jours
fériés on ne fait pas ce que l'on veut)... Bref fini d'épiloguer sur ma
vie...
Apparemment, je pense qu'une vidange de tmp/ manuelle a réglé le problème
(je viens de réup et cela fonctionne)...
Est ce que cela ne pourrait pas être cette modif http://trac.rezo.net/trac/spip/changeset/14718/branches/spip-2.0/ecrire/inc_version.phpqui
se serait mal appliquée ? mais bon j'ai up et déup et vidé le cache
par
SPIP une paire de fois hier avant de crier (inutilement finalement) au loup
hier soir... la seule différence est qu'aujourd'hui avant de continuer à
troller j'ai vidé tmp/
Désolé encore une fois mais là ... je sèche
++
Q.
Le 11 novembre 2009 18:16, Committo,Ergo:sum <esj@rezo.net> a écrit :
Le 11 nov. 09 à 16:23, cedric.morin@yterium.com a écrit :
Oui, c'est énervant, car ce genre de up devrait toujours pouvoir se faire
les yeux fermés du point de vue des utilisateurs.
Faudrait quand même pas exagérer: 14718 n'est pas la 2.0.X stable, c'est
une future 2.0.11 dont un bug, signalé dans les forums, venait d'être
corrigé, et comme c'est récent il y a toujours un risque qu'un cas
particulier se révèle en souffrir. La dernière stable est la 14697, c'est
elle qu'il vaut mieux mettre en production.
Par ailleurs, je ne comprends pas pourquoi tu ne donnes pas l'extrait
adéquat de l'article qui pose pb, avec la query-string associée: ça permet
beaucoup plus rapidement de localiser le bug que des périphrases.
Il y a bien bug quelque part puisque j'ai modifié je ne sais quoi je ne sais
ou certainement dans la configuration des langues... et le site ne rebascule
pas en NL
Le 12 novembre 2009 03:46, Quentin Drouet <kent1@arscenic.info> a écrit :
Désolé je n'ai rien fourni parce que je ne pouvais pas ...
je n'avais à dispo que mes mails via téléphone (réu de famille des jours
fériés on ne fait pas ce que l'on veut)... Bref fini d'épiloguer sur ma
vie...
Apparemment, je pense qu'une vidange de tmp/ manuelle a réglé le problème
(je viens de réup et cela fonctionne)...
Est ce que cela ne pourrait pas être cette modif http://trac.rezo.net/trac/spip/changeset/14718/branches/spip-2.0/ecrire/inc_version.phpqui se serait mal appliquée ? mais bon j'ai up et déup et vidé le cache par
SPIP une paire de fois hier avant de crier (inutilement finalement) au loup
hier soir... la seule différence est qu'aujourd'hui avant de continuer à
troller j'ai vidé tmp/
Désolé encore une fois mais là ... je sèche
++
Q.
Le 11 novembre 2009 18:16, Committo,Ergo:sum <esj@rezo.net> a écrit :
Le 11 nov. 09 à 16:23, cedric.morin@yterium.com a écrit :
Oui, c'est énervant, car ce genre de up devrait toujours pouvoir se faire
les yeux fermés du point de vue des utilisateurs.
Faudrait quand même pas exagérer: 14718 n'est pas la 2.0.X stable, c'est
une future 2.0.11 dont un bug, signalé dans les forums, venait d'être
corrigé, et comme c'est récent il y a toujours un risque qu'un cas
particulier se révèle en souffrir. La dernière stable est la 14697, c'est
elle qu'il vaut mieux mettre en production.
Par ailleurs, je ne comprends pas pourquoi tu ne donnes pas l'extrait
adéquat de l'article qui pose pb, avec la query-string associée: ça permet
beaucoup plus rapidement de localiser le bug que des périphrases.
Committo,Ergo:Sum
--
-----
Arscenic - Luxembourg asbl
Promotion et diffusion des Arts Numériques et des Nouvelles Scénographies
5, rue de la montagne
L-4879 Lamadelaine
Luxembourg
ca a l'air super intéressant seulement cela provoque pas mal de problèmes ...
...
Apparemment bug il n'y a pas finalement ...
Enfin si ... d'une certaine manière... Une page du site posant hier soir problème étaithttp://www.cinepocket.be/events?lang=nl
Apparemment, je pense qu'une vidange de tmp/ manuelle a réglé le problème
.....
Ah non je reviens là dessus ...
Il y a bien bug quelque part puisque j'ai modifié je ne sais quoi je ne sais ou certainement dans la configuration des langues... et le site ne rebascule pas en NL
Bon j'attends la fin de ta partie de ping pong, autrement dit un JEU DE TESTS, avant de donner mon avis sur l'existence de ce bug, d'autant que Fil avait déjà signalé ce faux bug en disant qu'il fallait nettoyer tmp à la main. Car c'était ça qui était trompeur: une dénommée vidange de cache qui oubliait un bon nombre de fichiers. Avec [14730], ça devrait aller mieux.