! [spip-dev] Re: multilinguisme / sélection du squelette en fonction de la langue

----- Forwarded message from Fil <fil@rezo.net> -----

@ Luis Speciale <speciale@club-internet.fr> écrivait :
> Une question peut être stupide mais assez courte : on pourra utiliser le
> champ lang pour déterminer un jeu de squelettes (et une cache ?) spécifique
> à chaque langue ?

Le cache non, ça serait inutile. En revanche, le squelette c'est une bonne
suggestion. Si on décide par exemple que article.es.html est le squelette
pour les articles en langue 'es', article.html le squelette pour les autres,
ça peut marcher ; la seule question à résoudre c'est une question de
priorités entre la résolution du nom du squelette via la langue et via la
rubrique (article.es.html, article-7.html, article-7.es.html ???)...

Voilà, c'est programmé, et ça permet de faire tout ce qu'on voulait en
matière de multilinguisme :

* une distribution avec des squelettes par défaut dans toutes les langues :
    sommaire-dist.es.html, sommaire-dist.fr.html, etc....

* des squelettes différents selon la langue de l'article, de la rubrique,
  etc. :
    article.es.html, article-7.es.html

Le mécanisme de sélection d'un squelette est désormais le suivant (partons,
par exemple, d'un article 17 dans la rubrique 8, elle-même sous-rubrique de
la 2).

Premier scan : les fichiers suivants existent-ils ? => si oui sélection,
sinon passer au suivant
    article=8.html
    article-8.html
    article-2.html
    article.html
    article-dist.html

De ce premier scan SPIP titre un squelette (par exemple article-2.html) ;
ensuite, second scan, à partir de la langue de l'article 17 (es) :
    article-2.es.html existe-t-il ? => oui, le sélectionner, sinon
utiliser article-2.html

Idem pour le sommaire (seule la langue du site est prise en compte) ; les
brèves (la langue du secteur si elle est définie, celle du site sinon), etc.

-- Fil

Pour info, j'arrive *jamais* à retrouver la partie qui documente
ces conventions de nommage dans la doc.
Alors bon je m'en sors en me référant à des sites déjà fait,
mais peut être profiter de l'extension de la fonctionalité
pour un peu mieux la flécher ?
JLuc

<<
Le mécanisme de sélection d'un squelette est désormais le suivant
partons,par exemple, d'un article 17 dans la rubrique 8,
elle-même sous-rubrique de la 2

Premier scan : les fichiers suivants existent-ils ? => si oui sélection,
sinon passer au suivant
    article=8.html
    article-8.html
    article-2.html
    article.html
    article-dist.html

...
>>

JLuc

@ JLuc <jluc@no-log.org> :

Pour info, j'arrive *jamais* à retrouver la partie qui documente
ces conventions de nommage dans la doc.
Alors bon je m'en sors en me référant à des sites déjà fait,
mais peut être profiter de l'extension de la fonctionalité
pour un peu mieux la flécher ?

Oui, c'est bien pour ça que j'ai mis ce mail dans "spip-core" :wink:

Si tu te sens de rédiger un brouillon de doc, vas-y, ça aidera d'autant.

-- Fil

Salut,

(Bon, désolé, j'ai voulu bidouiller sur spip.net)

-> Je me cogne assez méchamment le problÚme de pouvoir passer une variable $lang dans l'URL pour en tirer des résultats. Pas trÚs concluant...

-> Est-ce qu'il y a déjà une procédure prévue?

-> Comment je fais pour passer {lang} (ou, si faut ajouter un critÚre, {meme_langue}) pour sélectionner en fonction de la langue du contexte?

-> Comment peut-on, de maniÚre relativement simple, sélectionner en fonction de la langue de l'URL dans une boucle profondément installée dans la structure (genre pouvoir afficher toutes les rubriques d'un site, genre plan du site, et uniquement les articles dans la langue passée en URL?).

Là je sÚche.

A*

(Bon, désolé, j'ai voulu bidouiller sur spip.net)

Ah, c'est ça que j'ai commité par erreur en voulant commiter autre chose :wink:
Bidouille pour bidouille....

-> Je me cogne assez méchamment le problème de pouvoir passer une variable
$lang dans l'URL pour en tirer des résultats. Pas très concluant...
-> Est-ce qu'il y a déjà une procédure prévue?

Non. Antoine voulait qu'on fasse comme tu dis (contexte), mais je suis allé
au plus pressé en faisant autrement.

-> Comment je fais pour passer {lang} (ou, si faut ajouter un critère,
{meme_langue}) pour sélectionner en fonction de la langue du contexte?

En l'état actuel des choses tu ne peux pas, sauf à faire des trucs tordus
dans inc-urls (comme sur spip.net justement).

-> Comment peut-on, de manière relativement simple, sélectionner en
fonction de la langue de l'URL dans une boucle profondément installée dans
la structure (genre pouvoir afficher toutes les rubriques d'un site, genre
plan du site, et uniquement les articles dans la langue passée en URL?).

Pas mieux. Et je ne me sens pas de reprogrammer le tout en mode
"contexte"... sans doute faudrait-il...

Attention, chien méchant : phpmyadmin règle un cookie 'lang', qui va être vu
et considéré comme "INSECURE" (à juste titre) par SPIP, qui rendra une page
vide après exit();

-- Fil

Ben, pas qu'un peu, parce que là on perd toute la souplesse habituelle, et plusieurs fonctionnalités attendues vont manquer (rechercher dans les articles en français, naviguer dans une langue spécifique, lister les articles de la même rubrique dans la même langue...).

-> Quelles sont les fonctionnalités qui ont justifié que tu passes par un variable globale et non pas le contexte? Qu'est-ce qu'il faut faire gaffe à ne pas perdre?

-> J'ai loupé le coche, j'ai toujours pas pigé à quoi servaient lang_select et lang_deselect.

-> Dans ce rayon, je trouve que les squelettes par langue sont une horreur... Sachant qu'on autorise les structures multilingues dans tous les sens, en ajoutant des squelettes par langue, c'est totalement imbitable parce que plusieurs structures entrent directement en concurrence. Les éléments qui changent d'une langue à l'autre sont minimes du fait de la langue, et ils changent déjà (dates, sens d'affichage, etc.); les éléments "textuels" supplémentaires, c'est censé être géré par les balises <:toto:>. Là , ça invite les gens à faire des squelettes différents rien que parce qu'ils veulent afficher "Download this document" à la place de "Télécharger ce document"...

Pour moi, le plus propre serait de virer la gestion des squelettes par langue, qui vont produire catastrophes sur catastrophes.

A*

-> Quelles sont les fonctionnalités qui ont justifié que tu passes par un
variable globale et non pas le contexte? Qu'est-ce qu'il faut faire gaffe à
ne pas perdre?

En fait il n'y a pas eu de plan d'ensemble : j'y suis allé morceau par
morceau, et quand ça marchait je continuais. Essais et erreurs, méthode
assez crade... l'idée n'était pas d'aboutir si vite à un truc multilingue,
mais juste de se débrouiller avec spip.net ;^)

-> J'ai loupé le coche, j'ai toujours pas pigé à quoi servaient lang_select
et lang_deselect.

lang_select indique dans quelle langue seront calculés les prochains
éléments. lang_dselect revient un cran en arrière (il y a une pile). En gros
c'est une structure avec des blocs emboîtés les uns dans les autres : chaque
fois que tu arrives sur un élément (ex: un article), les trucs qui suivent
sont calculés dan sla langue de cet élément ; quand tu en sors (ex: tu
reviens dans la rubrique), il faut que SPIP se ressouvienne de la langue de
la rubrique. D'où la structure de pile (avec l'idée aussi que tu peux
empiler la langue du visiteur pour afficher les boutons d'admin et autres
joyeusetés).

-> Dans ce rayon, je trouve que les squelettes par langue sont une
horreur...

C'était la première idée pour des squelettes mulltilingues, avant même qu'on
pense à <:toto:> et à #LANG_DIR, #LANG_RIGHT, #LANG_LEFT. Je ne sais pas si
c'est utilisé ; si personne ne se manifeste on peut virer la fonctionnalité
(ou décider de simplement la commenter). L'idée était d'avoir un design par
langue (ce qu'on se disait au début de spip.net), mais ça n'a pas abouti.
Cela dit, ce n'est pas très différent de la logique d'un design par rubrique
(article-x.html). Compliqué, donc, mais pas tant que ça.

Là, ça invite les gens à faire des squelettes différents rien que parce
qu'ils veulent afficher "Download this document" à la place de "Télécharger
ce document"...

Le plus important sera de bien documenter l'ensemble. En même temps, on ne
lance pas un site multilingue sans faire un peu gaffe :wink:

Pour moi, le plus propre serait de virer la gestion des squelettes par
langue, qui vont produire catastrophes sur catastrophes.

On peut décider de ne pas le mettre en avant ; ou le commenter en attendant
d'installer les ébonnes habitudes".

-- Fil