Re-bonjour,
On peut ajouter une traduction à un article avec un titre, un texte, ...
dans une autre autre langue, cool ! mais qu'en est-il des rubriques et de
leur descriptif? Faut-il dupliquer et traduire l'arborescence des rubriques
pour ainsi avoir les articles traduits du français à l'englais dans une
rubrique dont le titre est aussi en anglais ?
Merci
Michael
J'ai déjà posé cette question. Voici la réponse que j'ai obtenue:
Salut,
Ce point mérite une explication.
Vous savez tous que SPIP n'a pas été conçu dès l'origine pour gérer le
multilinguisme. C'est une fonctionnalité "nouvelle" qu'offrira la 1.7.
Cela à l'inverse, par exemple, d'un système comme Glasnost (dans lequel
le multilinguisme a été pensé et intégré dès l'origine).
http://glasnost.entrouvert.org/
Il faut donc différencier:
- les produits "massivement" multilingues: tout, absolument tout, est
multilingue, et cela à l'intérieur même de chaque objet (on crée une
rubrique, et chaque élément de la rubrique peut-être directement
traduit; on créé un mot-clé, idem; on créé un auteur, rebelotte...);
- un produit où le multilinguisme est une fonctionnalité "ajoutée": cela
amène d'énormes risques et/ou des contraintes importantes.
De fait, le multilinguisme de SPIP n'est pas "massif", on y va plus ou
moins mollo (avec prudence en tout cas), et on essaie d'intégrer cela
sans nuire à la facilité d'utilisation et en respectant la cohérence du
système. Il y a donc des inconvénients, mais aussi d'énormes
avantages...
- Relative simplicité de l'implémentation (pour le code): passer en
"massivement" multilingue aurait obligé à une reprogrammation entière du
truc, et même à une refonte de la structure dans la base de données. On
y serait encore pour très longtemps, et on s'arracherait les cheveux
pour assurer la compatibilité avec les sites existants et les squelettes
déjà développés;
-> là, on peut livrer un produit très fonctionnel dans des délais
décents, avec une compatibilité absolue pour les sites réalisés avec les
versions précédentes, et même avec les squelettes.
- L'interface, même en activant le multilinguisme, reste très
accessible. La création d'un site multilingue reste évidente et
cohérente. A l'inverse, l'interface pour gérer un site massivement
multilingue (tout, absolument tout, doit être traduit en permanence),
est résolument différente, et plus lourde. Les étapes, conceptuellement
très différentes, qui consistent à écrire un texte original, et à le
traduire, ont tendance à se mélanger et à rendre l'interface moins
évidente.
-> Dans le cas de SPIP, "traduire" revient simplement à créer un nouvel
article, et à indiquer sa langue (si l'option est activée, à lier
l'article traduit à l'article de référence).
- De l'observation des sites multilingues déjà existants, il me semble
que le système retenu dans SPIP permet de répondre à la plupart des
besoins, malgré les limitations. Il y a certainement des choses à
améliorer progressivement, mais déjà on peut choisir des types de sites
multilingues extrêmement diversifiés (langues par rubriques, langues par
articles...), cela en conservant des méthodes de travail très simples.
A l'inverse, dans un système massivement multilingue, il n'est
absolument pas certain qu'on obtienne cette souplesse, car la logique
pousse à ce que tout soit absolument traduit. La hiérarchie des
rubriques devient par exemple unique, les traductions étant intégrées à
cette hiérarchie; avec le système actuel de SPIP, on peut soit faire
ainsi, soit faire des hiérachies séparées (solution d'ailleurs la plus
simple, on peut même travailler avec le système d'admins restreints pour
gérer différentes langues facilement).
- Le système de SPIP, avec ses limites, est actuellement très facile à
gérer au niveau des squelettes. Et cela avec une souplesse surprenante.
Dans un système massivement multilingue, cela devient nettement plus
difficile à obtenir simplement dans les squelettes.
Pour résumer: oui, il y a des limites, et SPIP n'est pas massivement
multilingue. Mais en contrepartie, on obtient:
- la cohérence avec les versions précédentes, et le maintien des
méthodes de travail auxquelles on est habitués;
- la cohérence de l'interface graphique est maintenue, tant au niveau de
la création/traduction d'articles que des usages de navigation dans
l'interface privée;
- la cohérence, la souplesse et la relative simplicité au niveau des
squelettes.
Du coup, on y va très progressivement. D'autant que, pour l'instant, ça
permet déjà de réaliser des sites qui sont entièrement multilingues
(spip.net notamment), des sites avec quelques éléments traduits
ponctuellement (sur uZine, le Manifeste du Web indé est publié en
plusieurs langues, avec des formulaires adaptés automatiquement, depuis
on a désactivé le multilinguisme parce qu'on ne l'utilise pas par
ailleurs; sur le Scarabée j'ai une rubrique en anglais, avec liens vers
les articles d'origine, donc encore une structure différente, puis j'ai
désactivé le multilinguisme...), etc. sans aucune difficulté, ni au
niveau des squelettes, ni au niveau de l'interface "traditionnelle" de
SPIP. Mine de rien, quand on s'est lancés dans le multilinguisme,
obtenir ce résultat n'était absolument pas garanti...
Amicalement,
ARNO*
En lisant ça, j'ai eu une idée, peut être complètement à coté de la
plaque (je me suis pas encore intéressé au multi langue en fait), mais
je la soumet quand même.
Apparemment, certains aimeraient avoir des rubriques multilingues,
dans le sens "une rubrique avec n noms, n descriptions ...".
C'est peut être tordu à faire, mais avec un squelette adapté et une
modif du parseur, on arriverait peut être à faire ça :
<boucle_rub ...>
<:#TITRE:>
...
</boucle_rub>
On pourrait alors avoir une rubrique nommée MaRubrique et un fichier
de langue contenant les traductions de ce titre.
C'est un peu pénible à manipuler, mais ça permettrait d'avoir une
solution au problème de certains.
Nan ?
À+, Pif.
Salut
Salut,
Ce point mérite une explication.
[zap]
Du coup, on y va très progressivement. D'autant que, pour l'instant, ça
permet déjà de réaliser des sites qui sont entièrement multilingues
(spip.net notamment), des sites avec quelques éléments traduits
ponctuellement (sur uZine, le Manifeste du Web indé est publié en
plusieurs langues, avec des formulaires adaptés automatiquement, depuis
on a désactivé le multilinguisme parce qu'on ne l'utilise pas par
ailleurs; sur le Scarabée j'ai une rubrique en anglais, avec liens vers
les articles d'origine, donc encore une structure différente, puis j'ai
désactivé le multilinguisme...), etc. sans aucune difficulté, ni au
niveau des squelettes, ni au niveau de l'interface "traditionnelle" de
SPIP. Mine de rien, quand on s'est lancés dans le multilinguisme,
obtenir ce résultat n'était absolument pas garanti...Amicalement,
ARNO*
Et on ne peut qu'applaudir très sincèrement la cohérence que garde Spip au
niveau de son développement et de ses évolutions !!!!!!!!
A+ Yann
C'est peut être tordu à faire, mais avec un squelette adapté et une
modif du parseur, on arriverait peut être à faire ça :
<boucle_rub ...>
<:#TITRE:>
...
</boucle_rub>
GASP !!
On pourrait alors avoir une rubrique nommée MaRubrique et un fichier
de langue contenant les traductions de ce titre.
C'est un peu pénible à manipuler, mais ça permettrait d'avoir une
solution au problème de certains.
Pense aux filtres, camarade... ils ont le droit de faire appel aux variables
globales... en fouillant un peu on trouve rapidement la langue contexte, et
on traduit comme on le sent (à partir d'un dictionnaire au format fichier de
langue, ou fichier texte, ou même stocké dans un recoin de la base MySQL...)
-- Fil