qui contient une balise
<language>fr-FR</language>
dans son en-têtr de channel, mais pas d’autre description de lang sur les item, je me retrouve avec un lang="fr-FR" en base sur tous les articles syndiqués, et du coup si j’applique {lang} sur ma boucle (SYNDIC_ARTICLES) dans un contexte fr tons mes articles syndiqués sont exclus car fr-FR n’est pas fr.
Est-ce que c’est normal ?
Est-ce que c’est un bug dans la syndication qui devrait remettre la langue au bon format ?
Les deux optiques sont défendables, mais je serais tenté de dire qu’il vaut mieux valider l’entrée (donc transformer fr-FR en fr), de manière à pouvoir l’utiliser spipement.
Ah, si il y a des modifs à faire, j'en profite pour dire que la langue du français féminin passant par #LANG retourne fr-fem ce qu'aucun système ne connait.
qui contient une balise
<language>fr-FR</language>
dans son en-têtr de channel, mais pas d’autre description de lang sur les item, je me retrouve avec un lang="fr-FR" en base sur tous les articles syndiqués, et du coup si j’applique {lang} sur ma boucle (SYNDIC_ARTICLES) dans un contexte fr tons mes articles syndiqués sont exclus car fr-FR n’est pas fr.
Est-ce que c’est normal ?
Non.
Est-ce que c’est un bug dans la syndication qui devrait remettre la langue au bon format ?
"Remettre au bon format" voudrait dire qu'on modifierait l'information, il y aurait donc une perte.
Si on prend l'exemple du français, voici un liste de codes possibles :
C'est ce que je m'étais dit aussi :
- si #ENV{lang} = fr on récupère toutes les variantes
- si #ENV{lang} = fr-XX on récupère uniquement fr-XX et fr-xx
Mais dans ce cas, comment ne récupérer que les "fr" seuls ? Enfin, seulement si ça peut avoir un sens, bien sûr.
Après on peut aussi dire que c'est un cas particulier aux syndications (car pour les objets SPIP on connait normalement les valeurs de lang internes). Et que {lang} n'est pas un critère défini explicitement, c'est un critère classique "de champ SQL". Et que donc c'est au squelette en question de prendre les variantes ou pas, suivant le besoin.
Oui évidemment on peut faire des trucs compliqués pour contourner, mais mon propos c’est surtout que si moi j’y connais rien :
je lis la doc, je syndique un flux français, et je filtre mon affichage avec {lang} sur la version française de mon site, ben ça marche pas.
De ce point de vue, c’est cassé.
Donc soit on ajoute plein de doc pour expliquer aux utilisateurs qu’il faut aller voir la source du flux, comprendre que c’est fr-FR et faire des critères compliqués, soit on répare le critère {lang} (sur la boucle de syndication uniquement ?), soit on répare la syndication…
Le dernier cas pouvant vouloir dire qu’on garde l’info fr-FR dans un champ à cet effet pour ne pas perdre d’info et qu’on reformatte fr dans le champ lang.
En même temps dire que « on perd de l’information » c’est quand même un peu biaisé car de toute façon, on perd déjà de l’information dans la syndication, en reformattant les titres, supprimant des balises qui trainent/foirent etc…
C’est du contenu automatique dont on sait qu’il est pas complètement fiable et qu’on accepte déjà de remettre en forme, je ne vois pas en quoi reformater fr-FR en fr serait très différent.
D'où mon premier mail, mais corriger {lang} me parait compliqué car tout le monde ne l'utilise pas dans sa forme seul, vu que c'est actuellement un critère de champ SQL. Donc il y a des {lang =} {lang LIKE} {lang IN} etc. Même en restreignant à la boucle syndicale, ça casserait, me semble-t-il.
Donc ce serait plutôt une transformation lors de l'insertion en base si "aa-bb" :
- on cherche si la forme composée existe dans SPIP, et si oui on met lang=aa-bb (avec transformation en minuscules et underscore)
- sinon on cherche si "aa" existe dans SPIP et on met lang=aa
- si "aa" n'existe pas non plus, on laisse le truc de départ complet et on met lang=aa-bb ?