> - La langue par défaut n'apparaît pas, puisque la langue
> du navigateur a la priorité
Que se passe-t-il quand la langue du navigateur n'est pas une langue
proposée ?
C'est le français qui s'affiche par défaut... Mais c'est un cas
extrêmement rare dès que SPIP propose une gamme de langues
respectable (disons une dizaine).
Accessoirement le terme "langue par défaut" n'est pas explicite
pour le webmestre s'il ne connaît pas la logique de sélection
de la langue de l'interface... Or il n'est pas censé apprendre
cette logique, surtout qu'elle est conçue pour être invisible.
> - Quant aux "langues proposées", je ne vois pas l'intérêt
> pour un webmestre de restreindre ce choix (sauf s'il est
> allergique au farsi ???)
Moi je le vois (simplification, personnalisation de l'interface par
"traduction" d'une langue...)
Je ne vois pas en quoi c'est plus simple de se faire chier à
configurer des langues "autorisées" et d'autres "interdites".
Pour la personnalisation, on peut prévoir un code langue
spécial afin que les webmestres utilisent tous la même
convention. Il suffit de choisir ce code.
Quant aux langues "en test", je suis d'accord avec Arno :
c'est une notion qui n'a pas de sens dans une version "finale"
de SPIP, et qui est également peu utile dans les autres cas.
Enfin la liste des langues affichées devrait, à mon avis,
simplement être celle des langues présentes dans le
répertoire lang. Ainsi pour supprimer des langues (s'il
y en a que ça titille absolument) il est possible de
supprimer les fichiers langue correspondants, ou de les
renommer.
Bon, ça se discute et tu remarqueras que j'ai simplement
commenté une ligne dans le code
Pour la personnalisation, on peut prévoir un code langue
spécial afin que les webmestres utilisent tous la même
convention. Il suffit de choisir ce code.
A mon sens, pour personnaliser, il faut un fichier mes_langues.php3 qui se
charge APRES les langues, et qui permet donc de renommer certaines chaînes,
langue par langue ou pour toutes les langues (plus dur, mais il suffira de
fournir une API).
Quant aux langues "en test", je suis d'accord avec Arno :
c'est une notion qui n'a pas de sens dans une version "finale"
de SPIP, et qui est également peu utile dans les autres cas.
OK.
Enfin la liste des langues affichées devrait, à mon avis,
simplement être celle des langues présentes dans le
répertoire lang. Ainsi pour supprimer des langues (s'il
y en a que ça titille absolument) il est possible de
supprimer les fichiers langue correspondants, ou de les
renommer.
OK. Mais on ne peut pas scanner ce répertoire à chaque visite dans l'espace
privé, il faut donc un système de mémorisation. Ou alors on scanne, après
tout c'est pas forcément très long de lire un répertoire...
Bon, ça se discute
C'est ce qu'on fait...
et tu remarqueras que j'ai simplement commenté une ligne dans le code
Je ne vois pas en quoi c'est plus simple de se faire chier à
configurer des langues "autorisées" et d'autres "interdites".
Si tu veux utiliser ton SPIP pour autre chose que des articles, il
peut être intéressant d'avoir une version personnalisée du français
avec des libellés de champs modifiés.
Dans ce cas, il ne faudrait pas que le français "normal" soit
disponible.
Enfin la liste des langues affichées devrait, à mon avis, simplement
être celle des langues présentes dans le répertoire lang.
+1 ... euh ... non, pardon Fil, j'arrête les "+1" ...
A mon sens, pour personnaliser, il faut un fichier mes_langues.php3
qui se charge APRES les langues, et qui permet donc de renommer
certaines chaînes, langue par langue ou pour toutes les langues
C'est une autre possibilité en effet, ça évitera aussi peut-être
d'avoir des langues personnalisée incomplètes au fur et à mesure des
mises à jour de SPIP.
(plus dur, mais il suffira de fournir une API).
Oh que j'aime lire ces trois lettres !
on ne peut pas scanner ce répertoire à chaque visite dans l'espace
privé, il faut donc un système de mémorisation. Ou alors on scanne,
après tout c'est pas forcément très long de lire un répertoire...
Une gestion de cache pour ça, c'est pas trop compliqué et ça peut
améliorer pas mal les perfs vu la quantité de chaînes traduites.
C'est une autre possibilité en effet, ça évitera aussi peut-être
d'avoir des langues personnalisée incomplètes au fur et à mesure des
mises à jour de SPIP.
Oui, c'est l'idée.
Une gestion de cache pour ça, c'est pas trop compliqué et ça peut
améliorer pas mal les perfs vu la quantité de chaînes traduites.
Euh, il suffit de regarder la liste des fichiers présents dans lang/ ; on
n'a pas besoin de les ouvrir tous...
Mais je retrouve à l'instant le pourquoi de la config-lang : c'est là qu'on
pourra choisir la langue à appliquer (par défaut) dans l'espace public !
Par exemple : quel moteur typographique ? quelle suite de fonctions
nom_mois, nom_jour ?..
Dans un squelette normal, [(#DATE|nom_mois)] donnerait le mois dans la
langue sélectionnée.
Bien entendu, pour les sites bilingues il y aurait possibilité de préciser
la "langue" de base des filtres au niveau du squelette, avec par exemple
[(#DATE|nom_mois_de)] ou [(#DATE|nom_mois{de})], [(#TITRE*|typo{de})] etc.
Tout ça n'est pas implémlenté, mais meta(lang) est un début...
Mais je retrouve à l'instant le pourquoi de la config-lang : c'est
là qu'on pourra choisir la langue à appliquer (par défaut) dans
l'espace public !
Bof.
Il ne faut pas confondre interface de publication multilangue et
gestion de contenus multilangues, les problématiques sont bien
différentes.
L'idéal serait à mon avis que l'on garde "|nom_mois" et qu'il sache
plus tard s'adapter en fonction d'une langue affectée au contenu
correspondant. Sinon, il va falloir faire un squelette par langue, pas
simple pour un site qui les mélange ...
Il ne faut pas confondre interface de publication multilangue et
gestion de contenus multilangues, les problématiques sont bien
différentes.
L'idéal serait à mon avis que l'on garde "|nom_mois" et qu'il sache
plus tard s'adapter en fonction d'une langue affectée au contenu
correspondant. Sinon, il va falloir faire un squelette par langue, pas
simple pour un site qui les mélange ...
La théorie c'est bien, mais je vois comment faire selon mon idée, et pas du
tout selon la tienne... tu as quelque chose de plus substantiel ?
L'idéal serait à mon avis que l'on garde "|nom_mois" et qu'il sache
plus tard s'adapter en fonction d'une langue affectée au contenu
correspondant.
La théorie c'est bien
Oui, toujours ...
mais je vois comment faire selon mon idée
Moi aussi.
et pas du tout selon la tienne...
Pour l'instant, non, c'est clair, mais c'est normal, ce n'est pas le
même chantier que celui qui est mené actuellement.
Ultérieurement, si un nouveau chantier est lancé pour gérer des
contenus multilangues, il faudra au moins ajouter aux articles une
information de langue, et on pourra avoir des filtres "intelligents"
se servant de cette langue.
Mais je dis bien "ultérieurement", il me semble dangereux de vouloir à
tout pris gérer ça maintenant alors que SPIP n'est pas prévu pour. Ca
peut rendre service à court terme mais s'avérer très pénible par la
suite.
Mais je dis bien "ultérieurement", il me semble dangereux de vouloir à
tout pris gérer ça maintenant alors que SPIP n'est pas prévu pour. Ca
peut rendre service à court terme mais s'avérer très pénible par la
suite.
OK sur la théorie, mais je ne vois pas en quoi le fait de passer une langue
par défaut aux filtres par défaut bloquerait quoi que ce soit pour
l'avenir... D'ailleurs, si tu regardes le code, il contient déjà des bouts
de ça (si meta(lang)==en, pas de typo)...
je ne vois pas en quoi le fait de passer une langue par défaut aux
filtres par défaut bloquerait quoi que ce soit pour l'avenir...
Non, en effet. Je m'opposait plus à une déclinaison de "nom_mois" en
"nom_mois_en", "nom_mois_de", etc. qu'à un fonctionnement paramétrable
d'un unique "nom_mois".
J'ai peut-être mal compris ce que tu proposais.
D'ailleurs, si tu regardes le code, il contient déjà des bouts de ça
(si meta(lang)==en, pas de typo)...
Donc [(#DATE|nom_mois)] se baserait sur la langue par défaut du
site, [(#TEXTE)] et [(#TITRE)] sur la typo par défaut du site.
Non, ils se baseraient par défaut sur la langue (et donc la typo)
définie dans l'article.
Mais il est vrai que l'idéal serait de pouvoir forcer une langue,
par exemple en fonction de celle de l'interface de navigation, ce qui
est une troisième problématique multilangue à gérer ...
Mais la première étape c'est bien d'avoir une "langue du site".
OK.
La seconde étape est d'ajouter une information de langue aux contenus.
La troisième étape, qui doit venir à priori avec la seconde, est de
rendre les filtres "intelligents".
La quatrième, elle aussi sans doute réalisable en même temps, est
d'améliorer les filtres pour qu'ils acceptent une langue en paramètre:
Ultérieurement, si un nouveau chantier est lancé pour gérer des
contenus multilangues, il faudra au moins ajouter aux articles une
information de langue, ...
Je me dis qu'il y a une fonctionnalité à proposer : c'est de permettre que la personne qui consulte un site puisse 1) choisir sa langue de consultation, évidemment, et 2) indiquer si il souhaite voir ou non les articles écrits dans d'autres langues et dans lesquelles.
Ainsi, quelqu'un qui cause pas de langue étrangère n'aurait pas ses sommaires encombrés par des articles illisibles, mais par contre, quelqu'un qui lit l'anglais ou l'allemand aurait accés aux articles écrits dans ces langues : ils apparaitraient dans les sommaires et il pourrait les choisir.
C'est surtout utile pour les sites où des articles existent en différentes langues sans être des traductions l'un de l'autre.
si un chantier est lancé pour gérer des contenus multilangues [...]
Je me dis qu'il y a une fonctionnalité à proposer : c'est de
permettre que la personne qui consulte un site puisse 1) choisir sa
langue de consultation, évidemment, et 2) indiquer si il souhaite
voir ou non les articles écrits dans d'autres langues et dans
lesquelles.
Ca peut être intéressant, en effet, mais uniquement si ces contenus
multilangue sont mélangés.
Ainsi, quelqu'un qui cause pas de langue étrangère n'aurait pas ses
sommaires encombrés par des articles illisibles, mais par contre,
quelqu'un qui lit l'anglais ou l'allemand aurait accés aux articles
écrits dans ces langues : ils apparaitraient dans les sommaires et
il pourrait les choisir.
Cela suppose de pouvoir choisir plusieurs langues, c'est déjà plus
compliqué.
Le Tue, Feb 04, 2003 at 02:10:11PM +0100, Nicolas Hoizey ecrivait :
> Je ne vois pas en quoi c'est plus simple de se faire chier à
> configurer des langues "autorisées" et d'autres "interdites".
Si tu veux utiliser ton SPIP pour autre chose que des articles, il
peut être intéressant d'avoir une version personnalisée du français
avec des libellés de champs modifiés.
Dans ce cas, il ne faudrait pas que le français "normal" soit
disponible.
Exemple concret (je viens de finir d'attaquer un SPIP pour faire ca) :
je veux publier des dates de concert (tres tres different d'un article),
ET des articles. Donc ce serait pas mal si les boutons d'admin des
articles pouvaient etre declines par 'langue', le tout configurable
multisoupapes etc.