Dans http://zone.spip.org/trac/spip-zone/changeset/25794 esj a
introduit une notation de liens permettant de demander une traduction
(Je suis retombé là-dessus par hasard à l'instant car ça entre en
conflit avec le plugin textwheel et sa surcharge temporaire de
inc_lien.)
Ma question : est-ce qu'il faut adopter cette notation comme standard,
et le cas échéant la mettre dans le core, ou l'amender/l'améliorer ?
-- Fil
Dans Connexion · GitLab esj a
introduit une notation de liens permettant de demander une traduction(Je suis retombé là-dessus par hasard à l'instant car ça entre en
conflit avec le plugin textwheel et sa surcharge temporaire de
inc_lien.)Ma question : est-ce qu'il faut adopter cette notation comme standard,
et le cas échéant la mettre dans le core,
Tu veux dire celui de textwheel ? Parce que c'est dans SPIP depuis longtemps
et spipnet l'utilise à beaucoup d'endroits maintenant.
ou l'amender/l'améliorer ?
Tu as des idées précises ?
Committo,Ergo:Sum
A la réflexion j'ai peut-être mal compris ta question.
C'est la notation "[{}->art1]" ou sa signification qui est en jeu ?
Committo,Ergo:Sum
A la réflexion j'ai peut-être mal compris ta question.
C'est la notation "[{}->art1]" ou sa signification qui est en jeu ?
Cette notation est dans le core ? Si c'est le cas,
Connexion · GitLab n'a plus lieu
d'être ?
-- Fil
La *notation* est dans le noyau, mais sa *signification* est autre que celle donnée par ton URL.
Dans le noyau, un raccourci comme [{en}->art9] est un lien vers l'article 9 dont on affirme a priori qu'il est en anglais par l'attribut hlang='en'.
Avec la surcharge ci-dessus, on fait SELECT id_article WHERE id_trad=9 AND lang='en' et si ça répond par exemple 10,
on retourne un lien vers l'article 10 et le hlang='en' est garanti (s'il n'y a pas de réponse on garde 9 et on vire hlang='en').
On pourrait mettre ce code dans le noyau parce que ça peut être utile pour tout site multilingue, mais c'est une requête SQL supplémentaire à chaque occurrence d'un raccourci d'article. On pourrait peut-être ne le faire que si la meta "gerer_trad" est active ?
Committo,Ergo:Sum
Dans le noyau, un raccourci comme [{en}->art9] est un lien vers l'article 9 dont on affirme a priori qu'il est en anglais par l'attribut hlang='en'.
Avec la surcharge ci-dessus, on fait SELECT id_article WHERE id_trad=9 AND lang='en' et si ça répond par exemple 10,
on retourne un lien vers l'article 10 et le hlang='en' est garanti (s'il n'y a pas de réponse on garde 9 et on vire hlang='en').
Ah mais attention : id_trad n'est pas forcément 9, ça peut aussi bien
être 10 : il faut regarder l'id_trad de l'article 9, puis voir s'il
existe une traduction de même id_trad dans la langue cible.
On pourrait mettre ce code dans le noyau parce que ça peut être utile pour tout site multilingue, mais c'est une requête SQL supplémentaire à chaque occurrence d'un raccourci d'article. On pourrait peut-être ne le faire que si la meta "gerer_trad" est active ?
Si ça ne le fait que pour le raccourci [{x*}->9], pas de problème, car
ça ne ralentira rien dans l'existant, sachant que [{en}->art9] n'a pas
d'utilité actuellement (le lien [->9] adoptant systématiquement le
hreflang="en" si l'article 9 est en anglais et que ce n'est pas la
langue courante).
-- Fil
Ce comportement doit pouvoir rester débrayable. En effet, sur certains sites la valeur du champs lang des articles n'a pas de sens. Je pense en particulier aux sites utilisant des champs multi dans les articles.
Dès lors, la proposition de vérifier le contenu de la meta "gerer_trad" me semble opportun.
Bien cordialement
Dans le noyau, un raccourci comme [{en}->art9] est un lien vers l'article 9 dont on affirme a priori qu'il est en anglais par l'attribut hlang='en'.
Avec la surcharge ci-dessus, on fait SELECT id_article WHERE id_trad=9 AND lang='en' et si ça répond par exemple 10,
on retourne un lien vers l'article 10 et le hlang='en' est garanti (s'il n'y a pas de réponse on garde 9 et on vire hlang='en').Ah mais attention : id_trad n'est pas forcément 9, ça peut aussi bien
être 10 : il faut regarder l'id_trad de l'article 9, puis voir s'il
existe une traduction de même id_trad dans la langue cible.
Oui normalement mais l'idée sur spipnet était que ces références étaient forcément celles de l'article d'origine.
On peut blinder, mais ça implique une jointure, c'est déjà plus cher.
On pourrait mettre ce code dans le noyau parce que ça peut être utile pour tout site multilingue, mais c'est une requête SQL supplémentaire à chaque occurrence d'un raccourci d'article. On pourrait peut-être ne le faire que si la meta "gerer_trad" est active ?
Si ça ne le fait que pour le raccourci [{x*}->9], pas de problème, car
ça ne ralentira rien dans l'existant, sachant que [{en}->art9] n'a pas
d'utilité actuellement (le lien [->9] adoptant systématiquement le
hreflang="en" si l'article 9 est en anglais et que ce n'est pas la
langue courante).
Pas sûr qu'on se comprenne: actuellement ça filtre aussi bien [{...}->9] que [{...}->art9] et [{...}->article9],
et on peut se poser la question d'étendre ça aux rubriques.
Committo,Ergo:Sum
On pourrait mettre ce code dans le noyau parce que ça peut être utile pour tout site multilingue, mais c'est une requête SQL supplémentaire à chaque occurrence d'un raccourci d'article. On pourrait peut-être ne le faire que si la meta "gerer_trad" est active ?
Si ça ne le fait que pour le raccourci [{x*}->9], pas de problème, car
ça ne ralentira rien dans l'existant, sachant que [{en}->art9] n'a pas
d'utilité actuellement (le lien [->9] adoptant systématiquement le
hreflang="en" si l'article 9 est en anglais et que ce n'est pas la
langue courante).Pas sûr qu'on se comprenne: actuellement ça filtre aussi bien [{...}->9] que [{...}->art9] et [{...}->article9],
et on peut se poser la question d'étendre ça aux rubriques.
Ce que je dis c'est que, dès lors que le coût supplémentaire
s'applique uniquement aux liens de la forme [ ... {..}-> objet spip ],
c'est suffisamment rare pour ne pas avoir d'impact dans le cas
général, et qu'on peut donc le mettre dans le core sans retenue. J'ai
dû rater quelque chose car je ne vois pas pourquoi tu sembles avoir
des réserves sur les conséquences en termes de perfs.
-- Fil
Ah ok. Il faut juste vérifier qu'à ce stade il n'y a pas de hlang par défaut ajouté d'office ou qqch de ce genre.
Committo,Ergo:Sum
bonjour
On pourrait mettre ce code dans le noyau parce que ça peut être utile pour tout site multilingue, mais c'est une requête SQL supplémentaire à chaque occurrence d'un raccourci d'article. On pourrait peut-être ne le faire que si la meta "gerer_trad" est active ?
Si ça ne le fait que pour le raccourci [{x*}->9], pas de problème, car
ça ne ralentira rien dans l'existant, sachant que [{en}->art9] n'a pas
d'utilité actuellement (le lien [->9] adoptant systématiquement le
hreflang="en" si l'article 9 est en anglais et que ce n'est pas la
langue courante).Pas sûr qu'on se comprenne: actuellement ça filtre aussi bien [{...}->9] que [{...}->art9] et [{...}->article9],
et on peut se poser la question d'étendre ça aux rubriques.Ce que je dis c'est que, dès lors que le coût supplémentaire
s'applique uniquement aux liens de la forme [ ... {..}-> objet spip ],
euh, j'ai pas tout compris,
Pour {[As->art15]} plutôt que [{As}->art15], ok ; mais un lien comme l'[article sur la revue {AS}->art15] (comme titres, j'ai : A, AIA, AIT, de As, Ça, CNT, Ego, Nie, R, SIA, SN, SUB, Un, etc.) ça devient quoi dans un site multilingue puisque le "ca", le "sn" sont aussi des codes langues ?
Claude
Pour {[As->art15]} plutôt que [{As}->art15], ok ; mais un lien comme
l'[article sur la revue {AS}->art15] (comme titres, j'ai : A, AIA, AIT, de
As, Ça, CNT, Ego, Nie, R, SIA, SN, SUB, Un, etc.) ça devient quoi dans un
site multilingue puisque le "ca", le "sn" sont aussi des codes langues ?
Ca se pose déjà dans le core depuis des années, indépendamment de la
proposition en cours de discussion.
On a déjà :
- '[article sur la revue {AS}->art15] => <a href=... > ... revue <i>AS</i></a>
- '[article sur la revue {as}->art15] => <a href=... hreflang="as">
... revue</a>
- '[article sur la revue {as} ->art15] => <a href=... hreflang="as">
... revue <i>as</i></a>
La question n'est pas de savoir si "as" est un code de langue (car
cette liste peut croître lorsqu'on change de version de SPIP), mais si
c'est une série de lettres minuscules. Un espace à la fin suffit à
sortir de ce mode "hreflang".
P.S/ Si tu veux te prémunir de toute modification surprise en la
matière, n'hésite pas à ecrire des tests unitaires. 
-- Fil
ZUT, j'ai mal copié/collé !
dans le troisième exemple ne pas lire :
- '[article sur la revue {as} ->art15] => <a href=... hreflang="as">
... revue <i>as</i></a>
mais:
- '[article sur la revue {as} ->art15] => <a href=...> ... revue <i>as</i></a>
bref l'espace fait vraiment sortir du mode hreflang 
-- Fil
Dans Connexion · GitLab esj a
introduit une notation de liens permettant de demander une traduction
Intégrée dans le core en http://trac.rezo.net/trac/spip/changeset/15976
j'ai un peu amélioré l'algo, de manière que [{}->art1] demande la
traduction en langue courante de l'article 1, indépendamment de savoir
si "1" est l'id_trad, c'est-à-dire si l'article 1 est ou non
l'original.
-- Fil
de toute façon, ça arrivera sur le bon article ou sur une traduction du bon article, pas forcément dans la bonne langue mais c'est pas trop grave --> un clic de plus ou une correction.