[SPIP Zone] Traduction de pages en site multilingue "non sectorisé "

Hello, bonjour, bonsoir, goedenavond,

Je donne un coup de main pour un site qui sera intégralement et uniquement
bilingue (Fr/Nl). Le choix tactique qui est fait:
- langue et liens de traduction sur les articles uniquement
- rubriques, auteurs, etc. seront donc en champs multi
- pas de brèves

Justification: comme toute page doit être traduite dès sa publication, cette
disposition permet de suivre plus facilement les choses dans la "salle de
rédaction" (une seule structure et les articles et leur traductions seront
toujours quasi simultanés => sinon pas de publication !)

Dans cette configuration, pas de problème particulier pour l'application du
contexte de langue (merci spip !): les lang_select et variables "lang" dans
l'URL permettent de s'y retrouver. On n'emploie pas le cookie de lang car il
entraînerait des affichages bilingues ou... une certaine complication dans le
squelette (que j'espère mettre sur spip-contrib au début 2008).

La seule "difficulté", c'est la demande de trouver sur chaque page des liens
de traductions identiques à ceux fournis en standard dans la dist pour les
articles !

Heureusement pour moi, Natalia a publié "Formulaire menu_lang plat sans URL
sur la langue sélectionnée" sur contrib et cy_altern a donné en forum les
codes nécessaires pour un fonctionnement sur 193SVN. Il m'a suffi de
remplacer l'appel de cookie par une variable lang dans l'URL.

J'en suis donc à un résultat satisfaisant basé sur une noisette et un passage
par mes_fonctions;php:

- noisette:

<div class="traductions">
<p><:trad_page_traduction:></p> // et le fichier local_fr/nl.php qui va bien
<ul>
[(#CONFIG{langues_utilisees}|lang_plat)]
</ul>
</div>

- mes_fonctions:

// menu_lang plat sans URL sur la langue en cours
// Voir http://www.spip-contrib.net/Formulaire-menu-lang-plat-sans-URL et
FORUM
function lang_plat ($langues) {
    include_spip('inc/charsets');
    $list_lang = '';
    $tab_langues = explode(",",$langues);
    while ( list($clef, $valeur) = each($tab_langues) )
  if ($valeur == $GLOBALS['spip_lang']) {
  $list_lang .='<li lang="'.$valeur.'" xml:lang="'.$valeur.'" dir="ltr"
class="on"><span>['.traduire_nom_langue($valeur).']</span></li> ';
} else {
        $list_lang .='<li lang="'.$valeur.'" xml:lang="'.$valeur.'" dir="ltr"
class="off"><a href="'.parametre_url(self(true), 'lang', ''.
$valeur.'').'"><span>['.traduire_nom_langue($valeur).']</span></a></li> ';
  }
    return $list_lang;
}
//fin

Depuis quelques jours, je regarde les plugins... Mais c'est trop dur pour moi.
S'il se trouvait quelqu'un pour me coacher sur les pipelines et astuces à
utiliser pour faire ça proprement... Sinon, je propose à un as inconnu de
faire ça: je suis sûr que cette "tactique" a beaucoup d'avenir dans les sites
belges, sauf explosion interne-nationale :slight_smile:

Voilà, voilà. J'essaye d'apporter ma petite pierre mais c'est vraiment dur, le
niveau est haut et ma courte et ancienne approche de php 4.0 ne m'est déjà
plus d'une grande utilité :slight_smile:

A plus,

--
Suske
+32-476-764629

Bonjour,

Je donne un coup de main pour un site qui sera intégralement et uniquement
bilingue (Fr/Nl). Le choix tactique qui est fait:
- langue et liens de traduction sur les articles uniquement
- rubriques, auteurs, etc. seront donc en champs multi
- pas de brèves

Je suis exactement sur la même problématique dans un cadre perso, et j'avoue n'avoir pas trop avancé depuis des mois, tes retours m'intéressent donc !

cf <http://charlotte.hoizey.com/&gt;

Justification: comme toute page doit être traduite dès sa publication, cette
disposition permet de suivre plus facilement les choses dans la "salle de
rédaction" (une seule structure et les articles et leur traductions seront
toujours quasi simultanés => sinon pas de publication !)

Par contre, je suis parti sur des arborescences distinctes pour le français et le néerlandais, mais avec aussi des multi, par exemple pour le titre de la rubrique des contenus en français : <multi>[fr]Français[nl]Frans</multi>

Qu'est-ce que cela apporte de tout mélanger ?

Dans cette configuration, pas de problème particulier pour l'application du
contexte de langue (merci spip !): les lang_select et variables "lang" dans
l'URL permettent de s'y retrouver. On n'emploie pas le cookie de lang car il
entraînerait des affichages bilingues ou... une certaine complication dans le
squelette (que j'espère mettre sur spip-contrib au début 2008).

Moi c'est la rubrique qui donne le contexte, du coup, donc pas besoin de variable d'URL ni de cookie.

Depuis quelques jours, je regarde les plugins... Mais c'est trop dur pour moi.

Tu devrais pourtant t'intéresser à l'un des miens, « langue_preferee », qui détermine automatiquement quelle est la langue préférée (probable) de l'Internaute, afin de l'envoyer directement sur la bonne version du site :
<http://files.spip.org/spip-zone/langue_preferee.zip&gt;
<Connexion · GitLab;

Il n'est pas encore actif sur mon site qui est encore en dist intégrale.

J'ai juste mis des URL propres arborescentes, dans lesquelles j'ai un soucis, puisqu'un même contenu devrait être visible aux deux adresses suivantes selon la langue dans laquelle on navigue :
<http://charlotte.hoizey.com/francais/mangez-des-pommes.html&gt;
<http://charlotte.hoizey.com/frans/mangez-des-pommes.html&gt;

Pour l'instant, puisque mes URL propres ne gèrent pas les multi, c'est ça :
<http://charlotte.hoizey.com/fr-francais-nl-frans/mangez-des-pommes.html&gt;

Je crois que je vais devoir oublier les multi dans les titres, si je veux profiter de la nouvelle gestion des URL propres dans une table à part, où un contenu ne peut avoir qu'une seule URL.

-Nicolas

--
Nicolas "Brush" HOIZEY
Clever Age : http://www.clever-age.com/
Gastero Prod : http://www.gasteroprod.com/
Photos : http://www.flickr.com/gp/38608514@N00/M1c002

Oups, j'ai fait un svn up au mauvais endroit, les URL du site ne fonctionnent plus, désolé... :frowning:

Le 5 nov. 07 à 12:04, Nicolas Hoizey a écrit :

Bonjour,

Je donne un coup de main pour un site qui sera intégralement et
uniquement
bilingue (Fr/Nl). Le choix tactique qui est fait:
- langue et liens de traduction sur les articles uniquement
- rubriques, auteurs, etc. seront donc en champs multi
- pas de brèves

Je suis exactement sur la même problématique dans un cadre perso, et
j'avoue n'avoir pas trop avancé depuis des mois, tes retours
m'intéressent donc !

cf <http://charlotte.hoizey.com/&gt;

Justification: comme toute page doit être traduite dès sa
publication, cette
disposition permet de suivre plus facilement les choses dans la
"salle de
rédaction" (une seule structure et les articles et leur traductions
seront
toujours quasi simultanés => sinon pas de publication !)

Par contre, je suis parti sur des arborescences distinctes pour le
français et le néerlandais, mais avec aussi des multi, par exemple
pour le titre de la rubrique des contenus en français : <multi>[fr]
Français[nl]Frans</multi>

Qu'est-ce que cela apporte de tout mélanger ?

Dans cette configuration, pas de problème particulier pour
l'application du
contexte de langue (merci spip !): les lang_select et variables
"lang" dans
l'URL permettent de s'y retrouver. On n'emploie pas le cookie de
lang car il
entraînerait des affichages bilingues ou... une certaine
complication dans le
squelette (que j'espère mettre sur spip-contrib au début 2008).

Moi c'est la rubrique qui donne le contexte, du coup, donc pas besoin
de variable d'URL ni de cookie.

Depuis quelques jours, je regarde les plugins... Mais c'est trop
dur pour moi.

Tu devrais pourtant t'intéresser à l'un des miens, « langue_preferee
», qui détermine automatiquement quelle est la langue préférée
(probable) de l'Internaute, afin de l'envoyer directement sur la
bonne version du site :
<http://files.spip.org/spip-zone/langue_preferee.zip&gt;
<Connexion · GitLab
langue_preferee>

Il n'est pas encore actif sur mon site qui est encore en dist intégrale.

J'ai juste mis des URL propres arborescentes, dans lesquelles j'ai un
soucis, puisqu'un même contenu devrait être visible aux deux adresses
suivantes selon la langue dans laquelle on navigue :
<http://charlotte.hoizey.com/francais/mangez-des-pommes.html&gt;
<http://charlotte.hoizey.com/frans/mangez-des-pommes.html&gt;

Pour l'instant, puisque mes URL propres ne gèrent pas les multi,
c'est ça :
<http://charlotte.hoizey.com/fr-francais-nl-frans/mangez-des-
pommes.html>

Je crois que je vais devoir oublier les multi dans les titres, si je
veux profiter de la nouvelle gestion des URL propres dans une table à
part, où un contenu ne peut avoir qu'une seule URL.

-Nicolas

--
Nicolas "Brush" HOIZEY
Clever Age : http://www.clever-age.com/
Gastero Prod : http://www.gasteroprod.com/
Photos : http://www.flickr.com/gp/38608514@N00/M1c002

_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

-Nicolas

--
Nicolas "Brush" HOIZEY
Clever Age : http://www.clever-age.com/
Gastero Prod : http://www.gasteroprod.com/
Photos : http://www.flickr.com/gp/38608514@N00/M1c002

On Monday 05 November 2007 12:04:49 Nicolas Hoizey wrote:

> Je donne un coup de main pour un site qui sera intégralement et
> uniquement bilingue (Fr/Nl). Le choix tactique :
> - langue et liens de traduction sur les articles uniquement
> - rubriques, auteurs, etc. seront donc en champs multi
> - pas de brèves

Qu'est-ce que cela apporte de tout mélanger ?

Une approche "intuitive" pour les rédacteurs (bilingues): quand un article est
prêt, sa traduction est "forcément" juste au-dessus dans la file des articles
de l'espace privé, même en page de rubrique, pas besoin de changer de
secteur. Cela me semble opportun dans le mesure où les articles doivent être
toujours publiés dans les deux langues simultanément. Un contrôle visuel
intuitif. Les pages de suivi des traductions deviennent un plus, pas une
nécessité.

Moi c'est la rubrique qui donne le contexte, du coup, donc pas besoin
de variable d'URL ni de cookie.

Oui, c'est plus simple en SPIP, mais moins intuitif dans l'espace privé, me
semble-t-il.

Vu mon choix de ne pas dédoubler la structure des rubriques, le contexte ne
donne pas forcément de langue. Du coup, je n'opte pas pour le cookie vu que
cela me semble plus aléatoire au niveau du résultat affiché que je veux
unilingue: un visiteur à cookie qui viendrait (newsletter, google,...) sur un
article dans l'autre langue pourrait avoir des éléments dans les deux langues
(j'utilise lang_select=non dans les entêtes, etc. pour éviter que la langue
du site ne s'impose en page de rubriques).
Résultat: des paramètres de langue dans l'URL (sauf pour les articles...) et
mon besoin d'avoir des liens de "traduction de page identiques" à ceux des
articles mais sur toutes les autres pages.

> Depuis quelques jours, je regarde les plugins... Mais c'est trop
> dur pour moi.

Tu devrais pourtant t'intéresser à l'un des miens, « langue_preferee
», qui détermine automatiquement quelle est la langue préférée
(probable) de l'Internaute, afin de l'envoyer directement sur la
bonne version du site :

Mais je m'intéresse ! Et comme j'ai reçu un vrai coup de main de Jean-Marc, je
crois que je vais commiter bientôt, pôvres de vous :slight_smile:

J'ai juste mis des URL propres arborescentes, dans lesquelles j'ai un
soucis, puisqu'un même contenu devrait être visible aux deux adresses
suivantes selon la langue dans laquelle on navigue :
<http://charlotte.hoizey.com/francais/mangez-des-pommes.html&gt;
<http://charlotte.hoizey.com/frans/mangez-des-pommes.html&gt;

Les URL propres, mon site s'en passera, au moins pour l'instant :-/

Pour l'instant, puisque mes URL propres ne gèrent pas les multi,
c'est ça :
<http://charlotte.hoizey.com/fr-francais-nl-frans/mangez-des-
pommes.html>
Je crois que je vais devoir oublier les multi dans les titres, si je
veux profiter de la nouvelle gestion des URL propres dans une table à
part, où un contenu ne peut avoir qu'une seule URL.

Ce que je ne comprends pas bien c'est pourquoi tu utilises les multi si tu a
des secteurs linguistiques homogènes... Ah si, sur les auteurs, mots-clés,
etc.

Merci pour les avis en tout cas. Je mettrai bientôt mon brouillon de premier
plugin sur la zone avec une TODO/améliorations kilométrique : genre "parser"
les multi effectivement présents du titre de la page courante, ce serait
mieux que d'afficher d'office toutes les langues du site, point de
vue "portabilité" du plugin dans d'autres utilisations des champs multi...

--
Suske
+32-476-764629

Qu'est-ce que cela apporte de tout mélanger ?

Une approche "intuitive" pour les rédacteurs (bilingues): quand un article est
prêt, sa traduction est "forcément" juste au-dessus dans la file des articles
de l'espace privé, même en page de rubrique, pas besoin de changer de
secteur.

OK

Moi c'est la rubrique qui donne le contexte, du coup, donc pas besoin
de variable d'URL ni de cookie.

Oui, c'est plus simple en SPIP, mais moins intuitif dans l'espace privé, me
semble-t-il.

C'est une question d'organisation je suppose, et de volume de contenus.

Vu mon choix de ne pas dédoubler la structure des rubriques, le contexte ne
donne pas forcément de langue.

Effectivement.

Du coup, je n'opte pas pour le cookie vu que
cela me semble plus aléatoire au niveau du résultat affiché que je veux
unilingue: un visiteur à cookie qui viendrait (newsletter, google,...) sur un
article dans l'autre langue pourrait avoir des éléments dans les deux langues
(j'utilise lang_select=non dans les entêtes, etc. pour éviter que la langue
du site ne s'impose en page de rubriques).
Résultat: des paramètres de langue dans l'URL (sauf pour les articles...) et
mon besoin d'avoir des liens de "traduction de page identiques" à ceux des
articles mais sur toutes les autres pages.

OK

Depuis quelques jours, je regarde les plugins... Mais c'est trop
dur pour moi.

Tu devrais pourtant t'intéresser à l'un des miens, « langue_preferee
», qui détermine automatiquement quelle est la langue préférée
(probable) de l'Internaute, afin de l'envoyer directement sur la
bonne version du site :

Mais je m'intéresse ! Et comme j'ai reçu un vrai coup de main de Jean-Marc, je
crois que je vais commiter bientôt, pôvres de vous :slight_smile:

Super !

J'ai juste mis des URL propres arborescentes, dans lesquelles j'ai un
soucis, puisqu'un même contenu devrait être visible aux deux adresses
suivantes selon la langue dans laquelle on navigue :
<http://charlotte.hoizey.com/francais/mangez-des-pommes.html&gt;
<http://charlotte.hoizey.com/frans/mangez-des-pommes.html&gt;

Les URL propres, mon site s'en passera, au moins pour l'instant :-/

C'est ça de moins à gérer, au moins, mais ça diminue la pertinence du référencement...

Pour l'instant, puisque mes URL propres ne gèrent pas les multi,
c'est ça :
<http://charlotte.hoizey.com/fr-francais-nl-frans/mangez-des-
pommes.html>
Je crois que je vais devoir oublier les multi dans les titres, si je
veux profiter de la nouvelle gestion des URL propres dans une table à
part, où un contenu ne peut avoir qu'une seule URL.

Ce que je ne comprends pas bien c'est pourquoi tu utilises les multi si tu a
des secteurs linguistiques homogènes... Ah si, sur les auteurs, mots-clés,
etc.

Sur les rubriques aussi. L'idée est qu'un néerlandais/ophone voit la rubrique des contenus en français sous le nom « frans » et non « français ».

Mais vu comme ça m'embête avec les URL, je vais peut-être abandonner cette idée, ou prendre dans l'URL le nom correspondant à la langue du contenu.

Merci pour les avis en tout cas. Je mettrai bientôt mon brouillon de premier
plugin sur la zone avec une TODO/améliorations kilométrique : genre "parser"
les multi effectivement présents du titre de la page courante, ce serait
mieux que d'afficher d'office toutes les langues du site, point de
vue "portabilité" du plugin dans d'autres utilisations des champs multi...

Si tu penses qu'un unique plugin de gestion du multilinguisme est envisageable, on pourra fusionner ton travail avec langue_preferee

-Nicolas

--
Nicolas "Brush" HOIZEY
Clever Age : http://www.clever-age.com/
Gastero Prod : http://www.gasteroprod.com/
Photos : http://www.flickr.com/gp/38608514@N00/M1c002