[SPIP Zone] Zpip et multilinguisme (suite)

cerdic · Mars 5, 2010, 8:59

Le 5 mars 2010 à 09:15, manu a écrit :

cedric.morin@yterium.com a écrit :

Je ne reproduis pas avec une branche 2.0 a jour (une 2.0.10+patchs)
Utilises-tu forcer_lang ?
Sinon peux tu vérifier si tu reproduis le bug avec la même version que moi ?
http://files.spip.org/spip/dev/SPIP-branche-2.0.zip

Bonjour,
j'ai donc refait l'essai :
> téléchargé l'archive dont tu donnais l'url et l'ai dezippé sur mon poste de travail (ubuntu 9.10).
> Ajout de ZPIP. Aucune modification dans les fichiers si ce n'est l'ajout des [#ENV**|unserialize|print_r{1})] dans squelette-dist/rubrique.html d'une part (pour tester sans l'activation de ZPIP) et dans plugins/zpip/rubrique.html et plugins/zpip/contenu/rubrique.html d'autre part (pour tester après activation de ZPIP)
> pas de forcer_lang, pas de fichier mes_options.php

Je reproduis l'erreur.
Frank reproduit également.

C'est étrange tout de même.... Qu'est-ce qu'il y a qu'on zappe ?

(je rebascule sur la liste car le débat concerne tout le monde)

Ok, je reproduis, c'est moi qui n'étais pas dans les bonnes conditions.

Par défaut SPIP transmet à l'inclusion la langue de l'objet du contexte.
Donc dans zpip/rubrique.html tu as initialement le contexte de langue de l'url, mais ensuite tu propage celui de la rubrique, soit fr par défaut (cas d'une installation neuve, langue principale en français, pas de multilinguisme).

SAUF :

- si le titre de l'objet contient un <multi>... </multi> alors l'objet est considéré comme multilingue, et n'impose pas sa langue

- si $GLOBALS['forcer_lang'] = true => le contexte général de langue est propagé sans être remplacé par celui de l'objet dans lequel tu es

Le comportement de Zpip est donc "standard" par rapport à SPIP.
La différence principale est que dans la dist, tu as un seul squelette principal, tu peux donc distinguer la langue de l'url dans le #ENV et la langue de l'objet dans #LANG
Dans Zpip, le premier niveau d'inclusion force la propagation de la langue de l'objet à la place de celle de l'url, et dans contenu/rubrique on n'a plus accès à la langue demandée dans l'url.

On as trois possibilités :
- soit considérer que c'est normal et au cas par cas les utilisateurs utiliseront forcer_lang quand nécessaire

- soit choisir de propager la langue de l'url dans une variable type #ENV{lang_url}. La langue demandée est donc connue, mais ce n'est pas elle qui s'impose dans le head etc ... Pour cela il faut en revenir à forcer_lang

- soit choisir de garder la langue de l'url dans #ENV{lang} au premier inclure. Dans ce cas, c'est elle qui parvient aux contenu/rubrique, navigation/rubrique, extra/rubrique
Mais ce dernier cas donne quelque chose de batard car du coup toutes les inclusions qui font une boucle rubrique affichent leur contenu dans la langue de la rubrique, et celles qui ne font pas de boucle sur la rubrique affichent leur contenu dans la langue.
Typiquement, sur mon cas test, la page est annoncée en lang=en, mais est à 95% en français. Ce n'est donc pas très pertinent...

Il me semble donc au final que la dernière possibilité n'est pas très judicieuse, et seules la 1 ou la 2 sont défendables.
A voir si la 2 a un intérêt, la 1 consistant à ne rien changer

Cédric

9aa2aa68144b2781ac02 · Mars 5, 2010, 9:06

Le 5 mars 2010 à 09:59, cedric.morin@yterium.com a écrit :

Par défaut SPIP transmet à l'inclusion la langue de l'objet du contexte.
Donc dans zpip/rubrique.html tu as initialement le contexte de langue de l'url, mais ensuite tu propage celui de la rubrique, soit fr par défaut (cas d'une installation neuve, langue principale en français, pas de multilinguisme).

SAUF :

- si le titre de l'objet contient un <multi>... </multi> alors l'objet est considéré comme multilingue, et n'impose pas sa langue

- si $GLOBALS['forcer_lang'] = true => le contexte général de langue est propagé sans être remplacé par celui de l'objet dans lequel tu es

Le comportement de Zpip est donc "standard" par rapport à SPIP.
La différence principale est que dans la dist, tu as un seul squelette principal, tu peux donc distinguer la langue de l'url dans le #ENV et la langue de l'objet dans #LANG
Dans Zpip, le premier niveau d'inclusion force la propagation de la langue de l'objet à la place de celle de l'url, et dans contenu/rubrique on n'a plus accès à la langue demandée dans l'url.

On as trois possibilités :
- soit considérer que c'est normal et au cas par cas les utilisateurs utiliseront forcer_lang quand nécessaire

Bof.

- soit choisir de propager la langue de l'url dans une variable type #ENV{lang_url}. La langue demandée est donc connue, mais ce n'est pas elle qui s'impose dans le head etc ... Pour cela il faut en revenir à forcer_lang

Cela me semble le plus intéressant. Par contre, c'est pas forcément pertinent de mettre "_url" dans le nom, parce que ça peut aussi venir d'une variable POST, ou être la langue par défaut si pas de valeur spécifiée, non ?

- soit choisir de garder la langue de l'url dans #ENV{lang} au premier inclure. Dans ce cas, c'est elle qui parvient aux contenu/rubrique, navigation/rubrique, extra/rubrique
Mais ce dernier cas donne quelque chose de batard car du coup toutes les inclusions qui font une boucle rubrique affichent leur contenu dans la langue de la rubrique, et celles qui ne font pas de boucle sur la rubrique affichent leur contenu dans la langue.
Typiquement, sur mon cas test, la page est annoncée en lang=en, mais est à 95% en français. Ce n'est donc pas très pertinent...

Non, vraiment pas top.

-Nicolas

--
Nicolas HOIZEY

cerdic · Mars 5, 2010, 9:36

Le 5 mars 2010 à 10:35, manu a écrit :

Suite à la réponse de Cédric, j'ai refait une série de tests... et il s'avère qu'avec forcer_lang, on rétablit effectivement un fonctionnement "plus conforme" (enfin, plus conforme à ma tournure d'esprit !).
Quand on a l'explication, on comprend mieux pourquoi la bête réagit comme cela et je serais du coup d'avis de ne rien changer puisque on est dans la cohérence avec l'existant et que forcer_lang est à disposition...

Cela dit, le truc de la détection de la présence ou non de balises multi dans le nom de la rubrique qui désactive ou pas la propagation de {lang} , moi, ça me fait un peu l'effet d'un de ces lapins qui sortent du chapeau du magicien et qu'on a n'a pas vu venir ! C'est décrit quelque part ?

Dans le code. Je l'ai découvert en cherchant le problème ...

Cédric

romy · Mars 5, 2010, 5:05

Le 05 mars 2010 à 09:59, cedric.morin@yterium.com a écrit :

On as trois possibilités :
- soit considérer que c'est normal et au cas par cas les utilisateurs utiliseront forcer_lang quand nécessaire

- soit choisir de propager la langue de l'url dans une variable type #ENV{lang_url}. La langue demandée est donc connue, mais ce n'est pas elle qui s'impose dans le head etc ... Pour cela il faut en revenir à forcer_lang

- soit choisir de garder la langue de l'url dans #ENV{lang} au premier inclure. Dans ce cas, c'est elle qui parvient aux contenu/rubrique, navigation/rubrique, extra/rubrique
Mais ce dernier cas donne quelque chose de batard car du coup toutes les inclusions qui font une boucle rubrique affichent leur contenu dans la langue de la rubrique, et celles qui ne font pas de boucle sur la rubrique affichent leur contenu dans la langue.
Typiquement, sur mon cas test, la page est annoncée en lang=en, mais est à 95% en français. Ce n'est donc pas très pertinent...

Je vote pour le réglage de forcer_lang à true par défaut, sans hésitation !

Je ne sais pas construire un site SPIP multilingue sans forcer_lang (ça fait d'ailleurs partie de mes pré-réglages systématiques de SPIP, cf.: ma « trousse à têtue ») qui permet de *construire une page selon la langue demandée*, sans en être dérouté par les langues, parfois incohérentes, des objets (notamment des rubriques) et inclures intermédiaires.

Dans ce cas d'une approche différente (forcer_lang à false), un autre moyen de récupérer la langue environnante, comme #ENV{lang_url}, pourrait effectivement être utile...

-- Romy

fil · Mars 5, 2010, 5:12

Je vote pour le réglage de forcer_lang à true par défaut, sans hésitation !

non !

-- Fil

9aa2aa68144b2781ac02 · Mars 5, 2010, 5:44

Le 5 mars 2010 à 18:12, Fil a écrit :

Je vote pour le réglage de forcer_lang à true par défaut, sans hésitation !

non !

Non plus. Comment on gèrerait alors des pages qui listent des contenus dans plusieurs langues ?

-Nicolas

--
Nicolas HOIZEY

romy · Mars 5, 2010, 6:25

Le 05 mars 2010 à 18:44, Nicolas Hoizey a écrit :

Le 5 mars 2010 à 18:12, Fil a écrit :

Je vote pour le réglage de forcer_lang à true par défaut, sans hésitation !

non !

Pas dans SPIP, mais dans ZPIP, qui semble le nécessiter davantage à cause de son système d'inclusions qui perd la langue environnante. Non ?

Non plus. Comment on gèrerait alors des pages qui listent des contenus dans plusieurs langues ?

En quoi est-ce problématique ??

Comme ceci par exemple :
http://www.cartografareilpresente.org/auteur162.html?lang=fr
http://www.cartografareilpresente.org/auteur162.html?lang=it

Non ?

Question réciproque : comment aurais-je pu faire cela, attribuer la bonne langue à cette page auteur (c'est-à-dire celle des contenus effectifs), sans forcer_lang ?

-- Romy

fil · Mars 5, 2010, 7:00

non !

Pas dans SPIP, mais dans ZPIP, qui semble le nécessiter davantage à cause de son système d'inclusions qui perd la langue environnante. Non ?

$forcer_lang est vraiment un truc dérogatoire ; ce qui est "pensé"
dans notre système, c'est l'option sans $forcer_lang. Où chaque objet
a sa langue, ce qui permet d'afficher proprement, par exemple, les
résultats en plusieurs langue d'une recherche. Peut-être que le mode
standard demande des adaptations et améliorations, mais dire "on fout
tout à la poubelle par défaut" c'est abandonner la notion qu'un
contenu est typé par une langue.

Question réciproque : comment aurais-je pu faire cela, attribuer la bonne langue à cette page auteur (c'est-à-dire celle des contenus effectifs), sans forcer_lang ?

Je ne comprends pas la notion de "bonne langue d'une page auteur" : là
en effet la langue n'est pas définie par l'objet auteur (le champ
spip_auteurs.lang définit sa préférence dans l'espace privé). Du coup
je comprends que tu sois tentée d'utiliser ici $forcer_lang plutôt que
la langue par défaut = langue du site. Mais c'est plutôt ça qu'il faut
améliorer : cette équation "langue par défaut = langue du site", qui
est obligatoirement une langue donnée.

On pourrait avoir quelque chose du genre :

langue de l'objet > langue de l'url > langue par défaut du site

alors qu'actuellement c'est, au choix :

langue de l'objet > langue par défaut du site (normal)
langue de l'url > langue par défaut du site (forcer_lang)

-- Fil

9aa2aa68144b2781ac02 · Mars 5, 2010, 9:01

Le 5 mars 2010 à 20:00, Fil a écrit :

Question réciproque : comment aurais-je pu faire cela, attribuer la bonne langue à cette page auteur (c'est-à-dire celle des contenus effectifs), sans forcer_lang ?

Je ne comprends pas la notion de "bonne langue d'une page auteur" : là
en effet la langue n'est pas définie par l'objet auteur (le champ
spip_auteurs.lang définit sa préférence dans l'espace privé). Du coup
je comprends que tu sois tentée d'utiliser ici $forcer_lang plutôt que
la langue par défaut = langue du site. Mais c'est plutôt ça qu'il faut
améliorer : cette équation "langue par défaut = langue du site", qui
est obligatoirement une langue donnée.

On pourrait avoir quelque chose du genre :

langue de l'objet > langue de l'url > langue par défaut du site

alors qu'actuellement c'est, au choix :

langue de l'objet > langue par défaut du site (normal)
langue de l'url > langue par défaut du site (forcer_lang)

Oui, il faudrait en fait pouvoir distinguer langue de l'interface et langue de chaque contenu, comme dans l'espace privé en fait. C'est peut-être tout simplement parce qu'on n'a qu'un paramètre "lang" de géré, que ça bloque.

-Nicolas

--
Nicolas HOIZEY

9aa2aa68144b2781ac02 · Mars 5, 2010, 9:06

Le 5 mars 2010 à 19:25, romy@rezo.net a écrit :

Le 05 mars 2010 à 18:44, Nicolas Hoizey a écrit :

Non plus. Comment on gèrerait alors des pages qui listent des contenus dans plusieurs langues ?

En quoi est-ce problématique ??

Comme ceci par exemple :
http://www.cartografareilpresente.org/auteur162.html?lang=fr

Je n'ai pas compris tout de suite que le "it" à côté de son nom est un lien vers la version italienne, je pensais que c'était la langue en cours, et que ça ne marchait pas...

http://www.cartografareilpresente.org/auteur162.html?lang=it

Si le contenu que tu présentes n'a pas de multi, comme c'est visiblement le cas ici, comment tu fais ? Quelle est la langue que tu utilises ? Celle de l'URL, ou celle du contenu ?

Question réciproque : comment aurais-je pu faire cela, attribuer la bonne langue à cette page auteur (c'est-à-dire celle des contenus effectifs), sans forcer_lang ?

En distinguant langue de l'interface, et langue du contenu. forcer_langue est plutôt lié à la langue du contenu, si j'en crois certains mécanismes.

-Nicolas

--
Nicolas HOIZEY

rastapopoulos · Mars 5, 2010, 9:50

Le 05/03/2010 22:06, Nicolas Hoizey a écrit :

En distinguant langue de l'interface, et langue du contenu. forcer_langue est plutôt lié à la langue du contenu, si j'en crois certains mécanismes.

Ben moi pour les sites multilingues j'ai toujours mis forcer_lang comme tetue, justement pour cette raison.
Pour moi forcer_lang c'est la langue de l'interface, celle choisie par le visiteur du site, celle dans laquelle lui veut lire le site.

Que le site en question comporte des articles en français, en basque ou en espagnol ne doit pas faire changer l'interface du site, qui doit rester dans la langue choisie par le visiteur.
Il peut y avoir plein de comportements différents suivant les sites, mais c'est clairement celui que je trouve le plus logique (donc par défaut).

--
RastaPopoulos

cerdic · Mars 5, 2010, 10:07

Le 5 mars 2010 à 20:00, Fil a écrit :

non !

Pas dans SPIP, mais dans ZPIP, qui semble le nécessiter davantage à cause de son système d'inclusions qui perd la langue environnante. Non ?

$forcer_lang est vraiment un truc dérogatoire ; ce qui est "pensé"
dans notre système, c'est l'option sans $forcer_lang. Où chaque objet
a sa langue, ce qui permet d'afficher proprement, par exemple, les
résultats en plusieurs langue d'une recherche. Peut-être que le mode
standard demande des adaptations et améliorations, mais dire "on fout
tout à la poubelle par défaut" c'est abandonner la notion qu'un
contenu est typé par une langue.

Il y a en fait plusieurs besoins cachés dans $forcer_lang :

- le besoin de propager dans les INCLURE la lange demandée pour la page (celle de l'url ou du cookie) pour pouvoir la prendre en compte dans tous les squelettes
Je pense que ce premier automatisme est trop envahissant. Il est passé (relativement) inaperçu tant qu'on utilisait surtout un squelette principal, mais avec une structure très emboitée, ce n'est pas idéal.

- le besoin de ne pas changer automatiquement la langue sur un objet qui en a une. Ce mécanisme par défaut semble plus licite.

Je pense qu'on devrait pouvoir piloter plus finement ce qu'on veut faire en forcant par exemple que les inclusion gardent la langue de #ENV, mais en laissant SPIP changer la langue dans les boucles pour afficher le contenu d'un objet dans sa langue.

Cédric

romy · Mars 6, 2010, 4:01

Le 05 mars 2010 à 20:00, Fil a écrit :

$forcer_lang est vraiment un truc dérogatoire ; ce qui est "pensé"
dans notre système, c'est l'option sans $forcer_lang. Où chaque objet
a sa langue, ce qui permet d'afficher proprement, par exemple, les
résultats en plusieurs langue d'une recherche. Peut-être que le mode
standard demande des adaptations et améliorations, mais dire "on fout
tout à la poubelle par défaut" c'est abandonner la notion qu'un
contenu est typé par une langue.

Je ne sais pas s'il faut tout jeter, effectivement

Mais ce qui est certain, c'est que je n'ai jamais réussi à faire un site multilingue sans forcer_lang, qui
1) permet de proposer une navigation cohérente, c'est-à-dire dont la langue est constante tout le long de la navigation, comme le décrit RastaPopoulos (que le site soit symétriquement traduit ou pas, construit en secteurs ou pas, etc.).
2) permet de baliser correctement le HTML pour identifier les changements de langue au sein de la page, à commencer par la balise <html>
3) permet d'extraire le contenu dans la langue demandée (avec les multi, sur les objets sans langue, ou en bouclant, sur les articles), sinon rien, pour éviter les patchworks imprévisibles

Question réciproque : comment aurais-je pu faire cela, attribuer la bonne langue à cette page auteur (c'est-à-dire celle des contenus effectifs), sans forcer_lang ?

Je ne comprends pas la notion de "bonne langue d'une page auteur" : là
en effet la langue n'est pas définie par l'objet auteur (le champ
spip_auteurs.lang définit sa préférence dans l'espace privé). Du coup
je comprends que tu sois tentée d'utiliser ici $forcer_lang plutôt que

Oui

Le 05 mars 2010 à 22:06, Nicolas Hoizey a écrit :

En distinguant langue de l'interface, et langue du contenu. forcer_langue est plutôt lié à la langue du contenu, si j'en crois certains mécanismes.

Non. Mais j'ai posé la question à l'envers

forcer_lang me permet d'extraire les contenus qui existent dans la langue que je demande. Ce qui me permet ici, avec les multis, de construire plusieurs versions d'une même page, d'un même objet SPIP, en particulier sans langue.

Ce qui est important ici, c'est le balisage HTML, qui identifie correctement les changements de langue ; voir <html> (sans forcer_lang, je ne sais pas passer la "bonne langue" sur la balise <html>, mais il a peut-être des choses qui m'ont échappé) et les listes multilingues de ce meilleur exemple :
http://www.cartografareilpresente.org/auteur4.html

Le 05 mars 2010 à 20:00, Fil a écrit :

je comprends que tu sois tentée d'utiliser ici $forcer_lang plutôt que
la langue par défaut = langue du site. Mais c'est plutôt ça qu'il faut
améliorer : cette équation "langue par défaut = langue du site", qui
est obligatoirement une langue donnée.

On pourrait avoir quelque chose du genre :

langue de l'objet > langue de l'url > langue par défaut du site

alors qu'actuellement c'est, au choix :

langue de l'objet > langue par défaut du site (normal)
langue de l'url > langue par défaut du site (forcer_lang)

Hmm...
Voici l'usage habituellement souhaité :

langue demandée (actuellement transmise via url) > langue principale du site > langue de l'objet

Je n'arrive pas à imaginer d'autre cas et suis preneuse d'exemple.

Ce qui me fait penser que j'ai souvent rêvé d'un critère de tri par langue, qui ne trie pas comme actuellement dans l'ordre alphabétique des codes iso, mais dans par importance, laquelle pourrait être fonction du nombre d'articles dans telle ou telle langue, ou être justement cet ordre (par défaut ou modifié par forcer_lang)...

Concernant la langue des objets, j'avais noté :

* Pas de langue sur les rubriques : ce sont des conteneurs, qui permettent de définir une arborescence et doivent rester neutres.

* Article : c'est parfait tel que c'est

Je m'éloigne de la construction de site multilingue, mais :

* Auteur : ce serait bien de pouvoir associer une langue à un auteur, pour signaler sa langue maternelle. Ça permettrait par exemple de pouvoir afficher le formulaire_ecrire_auteur dans la langue qu'il parle, en invitant ainsi les internautes à s'exprimer dans cette langue de façon à être compris par leur destinataire.

* Site : ce vraiment serait bien de pouvoir associer une langue à un site, pour stocker sa langue principale du site référencé, ce qui serait évidemment pratique pour en avertir l'internaute (en hreflang par exemple).

Je rêve tout haut

-- Romy

9aa2aa68144b2781ac02 · Mars 6, 2010, 9:04

Le 6 mars 2010 à 17:01, romy@rezo.net a écrit :

Le 05 mars 2010 à 22:06, Nicolas Hoizey a écrit :

En distinguant langue de l'interface, et langue du contenu. forcer_langue est plutôt lié à la langue du contenu, si j'en crois certains mécanismes.

Non. Mais j'ai posé la question à l'envers

forcer_lang me permet d'extraire les contenus qui existent dans la langue que je demande. Ce qui me permet ici, avec les multis, de construire plusieurs versions d'une même page, d'un même objet SPIP, en particulier sans langue.

OK.

Ce qui est important ici, c'est le balisage HTML, qui identifie correctement les changements de langue ; voir <html> (sans forcer_lang, je ne sais pas passer la "bonne langue" sur la balise <html>, mais il a peut-être des choses qui m'ont échappé)

Mais la « bonne » langue de <html>, c'est celle de l'interface, pas forcément celle du contenu, même principal, s'il y en a plusieurs.

Donc je pense vraiment qu'il faut distinguer les deux, et que forcer_lang est une solution actuelle à un mécanisme incomplet.

et les listes multilingues de ce meilleur exemple :
http://www.cartografareilpresente.org/auteur4.html

Exemple plus parlant que les précédents, effectivement, avec de l'anglais en plus...

-Nicolas

--
Nicolas HOIZEY

romy · Mars 7, 2010, 10:19

Le 06 mars 2010 à 22:04, Nicolas Hoizey a écrit :

Ce qui est important ici, c'est le balisage HTML, qui identifie correctement les changements de langue ; voir <html> (sans forcer_lang, je ne sais pas passer la "bonne langue" sur la balise <html>, mais il a peut-être des choses qui m'ont échappé)

Mais la « bonne » langue de <html>, c'est celle de l'interface, pas forcément celle du contenu, même principal, s'il y en a plusieurs.

Euh, non, les attributs lang (que ce soit sur <html> ou autre balise) annoncent la langue du contenu qui suit ! Qu'appelle-tu « langue de l'interface » ??

(Cf.: http://romy.tetue.net/bien-preciser-la-langue-d-une-page-web )

-- Romy

9aa2aa68144b2781ac02 · Mars 8, 2010, 9:17

Le 7 mars 2010 à 11:19, romy@rezo.net a écrit :

Le 06 mars 2010 à 22:04, Nicolas Hoizey a écrit :

Ce qui est important ici, c'est le balisage HTML, qui identifie correctement les changements de langue ; voir <html> (sans forcer_lang, je ne sais pas passer la "bonne langue" sur la balise <html>, mais il a peut-être des choses qui m'ont échappé)

Mais la « bonne » langue de <html>, c'est celle de l'interface, pas forcément celle du contenu, même principal, s'il y en a plusieurs.

Euh, non, les attributs lang (que ce soit sur <html> ou autre balise) annoncent la langue du contenu qui suit !

Oui, je sais bien...

Qu'appelle-tu « langue de l'interface » ??

Tout ce qui concerne le bandeau d'identification du site, la navigation, etc. Tout ce qui n'est pas du contenu, en fait.

Tu peux avoir des sites où tu navigues dans une interface en anglais, avec du contenu en français, ou inversement, ou un mélange, et bien sûr avec plus de langues...

La langue de navigation doit pouvoir être différente de celle du (des) contenu(s) principal courant, pour certains utilisateurs.

-Nicolas

--
Nicolas HOIZEY

guytarr · Octobre 12, 2010, 10:41

Le 8 mars 2010 10:17, Nicolas Hoizey <nicolas@hoizey.com> a écrit :

Le 7 mars 2010 à 11:19, romy@rezo.net a écrit :

Le 06 mars 2010 à 22:04, Nicolas Hoizey a écrit :

Ce qui est important ici, c’est le balisage HTML, qui identifie correctement les changements de langue ; voir (sans forcer_lang, je ne sais pas passer la « bonne langue » sur la balise , mais il a peut-être des choses qui m’ont échappé)

Mais la « bonne » langue de , c’est celle de l’interface, pas forcément celle du contenu, même principal, s’il y en a plusieurs.

Euh, non, les attributs lang (que ce soit sur ou autre balise) annoncent la langue du contenu qui suit !

Oui, je sais bien…

Qu’appelle-tu « langue de l’interface » ??

Tout ce qui concerne le bandeau d’identification du site, la navigation, etc. Tout ce qui n’est pas du contenu, en fait.

Tu peux avoir des sites où tu navigues dans une interface en anglais, avec du contenu en français, ou inversement, ou un mélange, et bien sûr avec plus de langues…

La langue de navigation doit pouvoir être différente de celle du (des) contenu(s) principal courant, pour certains utilisateurs.

-Nicolas

–
Nicolas HOIZEY
http://www.gasteroprod.com/
http://flic.kr/nicolas-hoizey/

Je ressort ce sujet des combles car il y a quelque chose que je ne comprends pas :

Sur un site avec zpip (testé en 1.7.9 et 2.00-dev) avec [fr] en langue préférée et [en] en autre langue, sans découpage par secteur, malgré un $forcer_lang=true, c’est toujours la langue de l’objet qui définit l’affichage des items de traduction, à part sur l’accueil.

Si je veux avoir l’interface dans la langue choisie et pas dans la langue de l’objet, comment je dois faire ?

Suite à cette petite expérience, je tente une navigation sur contrib en autre chose que du français, et comme 95% des contenus sont en français, on retombe toujours sur du français. je trouve ça un peu bizarre de cliquer sur [en], de voir dans la colonne de droite « Start with spip », et de retomber sur du français avec l’interface en français quand je clique sur « Start with spip » (qui devient donc « Commencer avec SPIP »).

Suite à ça, je créer une traduction d’un article français en anglais sur mon site de test. Je mets une bio en multi sur mon auteur. Quand je suis sur l’article anglais (la traduction de l’article de référence), je clique sur l’auteur, je tombe sur la page auteur avec l’interface en français. Il faut à nouveau que je sélectionne langue du site : anglais pour avoir la bio en anglais ??? Si je proviens d’un article en anglais, ça me parait pas tellement normal !?

C’est pas un peu bizarre tout ça ? Moi je suis complètement paumé… Faut abandonné Zpip dès qu’il y a du multilingue ? Rahhh.

guytarr · Octobre 13, 2010, 3:58

Je ressort ce sujet des combles car il y a quelque chose que je ne comprends pas :

Sur un site avec zpip (testé en 1.7.9 et 2.00-dev) avec [fr] en langue préférée et [en] en autre langue, sans découpage par secteur, malgré un $forcer_lang=true, c’est toujours la langue de l’objet qui définit l’affichage des items de traduction, à part sur l’accueil.

Si je veux avoir l’interface dans la langue choisie et pas dans la langue de l’objet, comment je dois faire ?

Suite à cette petite expérience, je tente une navigation sur contrib en autre chose que du français, et comme 95% des contenus sont en français, on retombe toujours sur du français. je trouve ça un peu bizarre de cliquer sur [en], de voir dans la colonne de droite « Start with spip », et de retomber sur du français avec l’interface en français quand je clique sur « Start with spip » (qui devient donc « Commencer avec SPIP »).

Suite à ça, je créer une traduction d’un article français en anglais sur mon site de test. Je mets une bio en multi sur mon auteur. Quand je suis sur l’article anglais (la traduction de l’article de référence), je clique sur l’auteur, je tombe sur la page auteur avec l’interface en français. Il faut à nouveau que je sélectionne langue du site : anglais pour avoir la bio en anglais ??? Si je proviens d’un article en anglais, ça me parait pas tellement normal !?

C’est pas un peu bizarre tout ça ? Moi je suis complètement paumé… Faut abandonné Zpip dès qu’il y a du multilingue ? Rahhh.

Bon, après différentes tentatives un peu dans tous les sens, le $GLOBALS[‹ forcer_lang ›]=true décrit ici : http://programmer.spip.org/Choix-de-la-langue-de-navigation

reste inopérant avec Zpip, excepté pour le formulaire d’administration qui lui suit bien la langue choisie. Je voudrais simplement avoir l’interface dans la langue choisie même si le contenu est dans une autre langue (ce que permet normalement le forcer_lang)

Suis-je le seul dans ce cas ? Ou est-ce un comportement normal et souhaité de Zpip ?

Un peu de retour serait très bienvenue…

rastapopoulos · Octobre 14, 2010, 7:41

Le 13/10/2010 17:58, Guy Cesaro a écrit :

Un peu de retour serait très bienvenue...

- Tu vas là : http://www.ipluse.eu/
- Tu choisis la langue française (par exemple)
- Ensuite par défaut dans les menus moi j'ai fait le choix de n'afficher que les trucs de la langue choisie donc faut aller sur une URL à la main. Donc par exemple tu peux aller sur l'article 27 qui est en Euskara : http://www.ipluse.eu/spip.php?article27
==> L'interface est en français et l'article est en basque.

C'est du pur ZPIP avec juste des surcharges de squelettes et un thème.

Donc ce serait plutôt à toi d'en dire plus.

--
RastaPopoulos

guytarr · Octobre 14, 2010, 6:22

Le 14 octobre 2010 09:41, RastaPopoulos <rastapopoulos@spip.org> a écrit :

Le 13/10/2010 17:58, Guy Cesaro a écrit :

Un peu de retour serait très bienvenue…

Retour assez simple : © chez-moi-ça-marche.

Tu vas là : http://www.ipluse.eu/

Tu choisis la langue française (par exemple)

Ensuite par défaut dans les menus moi j’ai fait le choix de n’afficher que les trucs de la langue choisie donc faut aller sur une URL à la main. Donc par exemple tu peux aller sur l’article 27 qui est en Euskara : http://www.ipluse.eu/spip.php?article27
==> L’interface est en français et l’article est en basque.

C’est du pur ZPIP avec juste des surcharges de squelettes et un thème.

Donc ce serait plutôt à toi d’en dire plus.

–
RastaPopoulos

Merci !!!

Trouvé la « bêtise », je suis un gros boulet. $forcer_lang dans mes options mais couteau kiss installé, et la case décochée pour $forcer_lang. Je pensais que mes_options étaient pris en compte après le tmp/ck_options.php. Ca m’a l’air d’être le contraire. Il faudrait peut être désactiver le formulaire du couteau kiss pour les configurations correspondantes (lorsqu’il y en a) qui sont définies dans mes_options, non ?

Enfin, bref, ouf !!! Et encore merci Rasta
++