Carnet Wiki

[TrogloSpip] Echange autour du multilinguisme dans SPIP

Version 2 — Mai 2011 Déesse A.

Prise de note collaborative réalisée à plusieurs mains dont celles de :

  • LPg
  • Davux
  • JLuc
  • Loiseau2nuit

grâce à Gobby, notre nouveau pote pour la rédaction collaborative !

Livré « en l’état » ! Les notes un peu hasardeuses et les fautes de frappe sont authentiques et d’origine !

(Prise de note non verrouillée à cette heure, le présent doc pourra donc subir quelques modifs...)

Multilinguisme

présenté par Kent1

[kent1] Constat de départ : montée du multilinguisme dans les demandes + changements dans le dev.

retour sur le fonctionnement du multilinguisme dans spip

TradLang (plugin)

Edition des fichiers lang de SPIP depuis le back-office.
SVN : svn co svn://zone.spip.org/spip-zone/_plugins_/trad-lang (Pas dispo sur files.spip.org)

Un plugin au code qui commence sévèrement à dater !!!
trad lang date un peu. Pourquoi ne pas utiliser les outils d’édition existants du style crayon

Pour la suite...

kent1 : bcp de plugins à faire traduire sur des projets - le système de trad pourrait être un plugin lui même. -> travail sur les chaines de langues
autres plugins en travail ?????

Il y a autant de méthodes pour faire un site multilangue avec SPIP qu’il y a de sites multilangues sous SPIP, voire même plus !

Tour de table :

  • [Kent1] Avoir un vrai plugin qui ... ???
  • [Daniel] traduit/non-traduit, comment gérer tout ça ? La dist actuelle n’est pas au top pour ça « pas vraiment multilangue »
  •  ? sortir une dist multilingue ? <= rajouter lang à ses critères de boucles et utiliser forcer_langue() = true; dans
    config/mes_options.php
  • Trop de trucs trop redondants ! Il semble que de précédentes versions de SPIP géraient mieux certains aspects de ces choses là...
  •  ? Une base documentaire ?
  • Un gros problème redondant : le choix de la structure de base du contenu (secteur or not secteur / trad-rubrique (duplication) ou pas / ...)
  • Les boucles de langue deviennent vite très complexes (cf exemples)
  • [Aurelie] URLs propres ! => pose problème avec l’utilisation des champs multi. Pour une rubrique c’est pas possible d’avoir une url propre par langue si on ne duplique pas la rubrique (toujours le même problème !)
  • [Loiseau2nuit suggestion] Un secteur par langue => Corrige d’un seul coup les problèmes d’URL rewrite par langue ET les soucis liés au référencement des secteurs langues (couplé avec le plugin http://www.spip-contrib.net/Plugin-Multidomaines pour gérer des sous-domaines type http://fr.mon-site.tld/ http://en.mon-site.tld/ ... et le plugin http://www.spip-contrib.net/Plugin-Duplicator pour re-créer une arbo à l’identique dans chaque secteur avec les versions Fr. des articles qu’il n’y a alors plus qu’à traduire ! (perso j’aime pas les )
    Peut fonctionner même encore mieux avec trad-rubrique pour gérer les liens inter-langues.
  • [Paolo] fonctionne avec les secteurs partagés <= comme sur spip-contrib ?
  • urls propres en langues cf http://www.spip.net/
  • Pbm de l’optimisation au chargement des fichiers lang_ => [Kent1]
  • [Klaus++] Un checking des versions d’origine permettant de visualiser les changements à reporter sur les versions traduites ?
  • [Loiseau2nuit] sceptique autour des multi et des contraintes du référencement, testerait bien si :
    • Comment Google gère et affiche les pages contenant du multi ?
    • Est-ce que les différents serveurs (google.fr, .co.uk, .nl, ... ressortent bien la bonne version/la bonne langue de la page ?
  • Conserver une possibilité d’afficher le contenu dans sa langue d’origine si l’objet n’a pas été traduit...
  • -> réutiliser une base existante, commune permet de proposer plus de traductions (pas très clair dit comme ça)
  • idée : un thésaurus, un glossaire, un mémoire collectif
  • tradlang est puissant mais il est encore pas très agréable à utiliser
  • idée : tableau de bord intégrant les différents outils

Une problématique : plein de plugins ont des chaines communes, mais la définissent chacun dans leur espace, avec leur préfixe,
alors qu’ils pourraient faire appel à la version définie dans le spip de base, ou les partager.
ex : valider, enregistrer, oui, non,
ça permettrait aussi d’homogénéïser les textes proposés dans les différents plugins.
Comment différents plugins partager des chaines de langues alors qu’ils ne sont pas forcément installés simultanément ?

Références

Les sites de la communauté à traduire ou en voie d’internationalisation :

présentation de salvatore

<= à préciser, j’ai été un peu largué là...)

En gros : check et versionne les fichiers lang_ existants dans les plugins et les reporte sur le trad-lang de spip.net pour que les traducteurs puisse accéder aux chaines de langues à traduire.

Si je dev un plugin et que je veux le salvatoriser, je dois rajouter (via SVN) une ligne dans salvatore/traductions.txt pour lui indiquer le nom du module de lang_ du plugin ainsi que la langue de référence

comment ajouter ses fichiers à salvatore/ soumettre à traduction ?
sur la zone dans dev/salvatore/

Présentation de Langonet

Eric Sarka

cf sur le wiki [->net/LangOnetPresentation-generale" class="spip_url spip_out auto" rel="nofollow external">http://www.spip-contrib.net/LangOnetPresentation-generale] net/langOnet,3495]

Pour conclure

pas d’intérêt de forcer la présence de toutes ces trads dans tous les sites

il faut encore réfléchir à comment répondre au fait qu’on a un vrai besoin de glossaire

Retour à la version courante

Toutes les versions