Carnet Wiki

DiscussionExtraiteDeLaFAQ

Version 4 — September 2018 Jacques

Mortimer: Ici il y a pas mal de choses qui ont été reporté de la FAQ parce qu’elle ne m’y paraissaient pas pertinente. Il faudrait faire un peu le tri.


Discussions et hésitations :)

Désirant commencer à travailler sur du multilinguisme j’ai consulté les différentes infos disponibles et j’ai constaté qu’il y à trop de façons de l’intérpreter et que les infos à dispositions m’informent plus sur la gestion de l’arabe que sur la mise en place concrète du multilinguisme....

LA STRUCTURE: Jusqu’à présent les rubriques principales se créaient à la racine du site permettant ainsi d’avoir des brèves pour chaque section principale. Avec la venue du multilinguisme je constate que de nombreuses personnes ont commencé à abandonner cette structure pour créer des secteurs par langue (fr,anglais). Et même spip.net on dirait! Une solution intéressante mais qui va contre la propre fonctionnalité de SPIP d’avoir des brèves dans chaque secteur!


Ajout du 22/4/2004 par Suske: SPIP 1.7.1. gère dorénavant un critère lang si j’ai bien vu... Avec la balise #LANG, cela permet probablement une foule d’autres manières d’organiser le mulitlinguisme... Vu que j’ai adopté la structure en secteurs linguistiques, je n’ai pas encore testé/réfléchi aux possibilités. Mais cela doit être bien... Quoique côté rédacteurs, cela doit compliquer le choix de la rubrique: si on récupère une aborescence thématique avec sous-rubriques de traduction, c’est bon pour le rédacteur en langue principale mais le traducteur...


Modif du 10/3/2004 par François (“Suske”): Pour un site qui pratique le multilinguisme intégral et vu les possibilités de SPIP1.7, cette perte de finesse au niveau des brèves est un désavantrage minime par rapport à la facilité de gestion que cette structure permet. C’est du moins la conclusion à laquelle je suis arrivé après avoir testé plusieurs solutions dont la gestion de la langue par mots-clés, la coexistence de plusieurs SPIP sur une seule base de données et la traduction élément pas élément sans regroupement par secteur linguistique... Par ailleurs, cette perte de finesse au niveau des brèves peut-être compensée par l’association de mots clés aux brèves. Elles se trouvent toutes à la racine mais avec les mot-clé “ma sous-rubrique de niveau X”, je ne l’affiche que dans la rubrique en question (et sur la page d’accueil Voilà ma petite contrib...


A ce point voici mes affirmations:

-  Je ne concoit donc pas cette solution correcte et pense devoir continuer à suivre la structure qu’on à toujours utilisé.


10/3/2004 par Stéphane Deschamps : Tu as raison, la perte d’une fonctionnalité “native” de spip est un peu gênante, mais en même temps on comprend bien qu’au niveau gestion, les brèves risquent de s’éparpiller dans toutes les rubriques et qu’un admin aura du mal à les retrouver (et j’imagine que c’est la raison première de la restriction par spip des brèves au niveau secteur).



Modif du 15/3/2004 par Fulvio:
Bon alors on baisse les bras :-( , il est clair que cette solution semble plus facile, mais faut aussi avouer que jusqu’à présent les brèves par secteur existaient bel et bien et je pense que les personnes ne se cassaient pas la tête à attribuer à chaque brève un mot clé.
Alors ok, je veux bien abandonner cette idée, mais reste toutefois dans l’incompréhension qu’on doit perdre une fonctionnalité naturelle au passage. Bon alors autant qu’on spécifie au plus vite ici la marche à suivre correcte pour réaliser un site multilingue avec un secteur par langue.


-  Dans cette optique il devient impératif que l’on puisse afficher des images (par ex: drapeaux pour choix des langues, un slogan en format image selon la langue... ) selon la langue dans laquelle on navigue (et pas que du texte,comme on peut le faire très bien actuellement ( :: texte) (là je crois que la solution nous la donne Fil sur la liste “développement” , le 26.1.04 “! lang dans le contexte, l’inclusion...” que je n’ai pas encore bien étudié de près)

-  Je pense que ce n’est pas logique qu’on doit utiliser du php pour gérer du multilinguisme!!!!!

Constatations: Les articles peuvent avoir un lien sur leur traduction Les rubriques NE PEUVENT MALHEUREUSEMENT pas avoir de lien sur leur traduction

A ce point, en tenant compte des éléments ci-dessus qu’il faudrait respecter, il est nécessaire de savoir comment on envisage le multilinguisme sur le site. Plusieures personnes auront leur façon de présenter un site multilingue, mais je pense que si l’on se met d’accord sur la façon de faire une version de base correctement, les adaptations pour les autres versions viendront par la suite.




10/3/2004 par Stéphane Deschamps : la version “de base” existe déjà : ele considère que le site n’est pas massivement multilingue et elle ne force pas à avoir une arborescence séparée... C’est un choix comme un autre...


Grégoire :

Je pense que si le filtre lang fonctionne quand la variable lang est définie dans l’url, alors nous ne serons pas obligé de créer un squellete article par langue.

Peut-être qu’il faudrait revoir le filtre traduction?

Je conçois un site multilingue de la façon suivante:

  • Tous les articles pour toutes les langues sont ensemble. (permet de passer d’un site monolingue à multilingue en changeant uniquement les squelettes, on conserve la structure des rubriques...)
  • Le listage des articles se fait d’abord en sélectionnant les articles selon la langue définie dans l’url, on affiche entre crochet ensuite la langue pour les liens de traductions.
  • Si un article n’a pas été traduit, tant pis, son titre s’affiche seul, sans les liens de traductions.

Cela est possible par un jeu d’exclusions. (mais, il y a des interactions avectraduction)

  • Afficher tous les article de la langue langue.
    • dans la boucle, afficher les noms des langues disponible pour l’article, sauf la langue actuelle .
  • Afficher les articles restants (sans traductions, ou dans une autre langue)
    • dans la boucle, afficher les noms des langues disponible pour l’article.

On devrait y arricer avec la version CVS.
Je ferais les essais dimanche 14 mars 2004, je vous tiens au courant.

C’est avec la version 1.7.1 que j’ai pu y arriver, et, les nouvelles fonctionnalités de cette version ont bien simplifié le problème.

Grégoire


15/3/2004 par Fulvio:
Tu nous diras ce qu’ont donné tes essais!
Pour ce qui concerne les articles non traduits on ne peux pas dire “tant pis”. Si un site est fait correctement, avec un joli drapeau
intégré dans le design pour la deuxième langue, je ne vois pas pourquoi si la traduction n’existe pas, il faudrait faire disparaitre le drapeau.
Un vrai site multilingue doit pouvoir permettre de sauter d’une langue à une autre à tout moment et toujours avec le même lien.
J’ai visité des tonnes de sites multilingues et c’est que depuis le lancement de spip multilingue que je vois des sites avec la traduction des articles selon si la traduction existe ou moins! Normalement chaque page du site doit contenir un lien vers l’autre langue, c’est la moindre des choses pour ne pas confondre le visiteur. Il est fondamental, de trouver une solution plus cohérente. Une de celles-ci est celle que j’ai exposée. S’il y à lien sur une traduction de l’article tant mieux, sinon tous les liens vers l’autre langue menent au sommaire de l’autre langue.


(Pascale) En réponse à la proposition de Fil sur la liste des traducteurs, j’ouvre une page nouvelle pour essayer d’envisager les réponses techniques à différents usages/besoin possibles de gestion d’un site utilisant le multilinguisme de SPIP. Elle se trouve ici DocMulti. L’idée est de refaire une doc claire à plusieurs pour la sortie de la 1.7.2/ 1.8 :) ?


Paolo:
Problème de l’indexation des langues comme le chinois, japonais, coréen, ...
Quelques liens:
http://zope.org/Members/bjorn/CJKSp...
http://www.mnogosearch.org/board/me...

Entretemps : un méthode pour empêcher le moteur de recherche à indexer l’information des langues qu’il ne peut pas utiliser ...