Bonsoir,
Je reponds sur les deux dernières reactions de Simon ; effectivement il y a de nombreuses différences conceptuelles…
mais je reviens plutot sur le mode « pratique » comme le pose marcimat !!et j’ai envie de dire :
- soit la structure est totalement dupliquée (et dans ce cas, il y a encore plus simple :
=> définir des SQL VIEW « {lang} » tout SQL est fait pour cela :un "simple PHP-FILTER qui ré-interprete le nom de table SQL pré-définit la view dans la bonne langue !
Dans cette configuration, si j’ai bien compris le fonctionnement des SQL_VIEW, je n’ose pas imaginer le bazar pour gérer les liens de traduction entre les objets.
Je vois comment monter un site parallèle pour chaque langue, oui, mais je ne vois pas comment le faire communiquer facilement avec les autres versions pour maintenir des liens de traduction.
Pourquoi ne pas gérer les langues par la mutualisation des squelettes seuls ? Une base par langue et basta…
- soit elle est bancale, et je crains que toute solution ne soit qu’un emplatre, car la base serait pratiquement à DéNormaliser !
Autant que je puisse dire, quand on fait du générique (et un CMS l’est par définition), on n’est jamais dans une situation optimale pour tout. Or spip pousse quand même très fort dans le sens du multilinguisme, il n’y a qu’à voir la quantité de langues dans lesquelles spip.net ou l’espace privé sont traduits et les levées de bouclier pour ne pas oublier les autres langues quand on demande d’améliorer la doc en anglais…
Il me paraît donc dommage qu’il s’arrête en si bon chemin pour être le roi des CMS internationalisés.
La prochaine étape dans cette direction, à mon avis, c'est internationaliser le langage des squelettes, mais c'est un autre débat qui va de pair avec la réflexion sur les nouvelles syntaxes...
Je rêve d'un : ... :)
Avec ensuite des scripts permettant de traduire automatiquement un squelette d’une langue dans une autre, en maintenant des fichiers d’alias pour les mots-clés de la même manière que les chaînes de langue, par exemple.
Mais j’y pense, si on rajoutait juste la VUE-langue, cela ne pourrait-il pas aussi s’appliquer à l’interface privée,
et donc faciliter l’usage de la barre multi-lingue (à moins que tes utilisateurs gerent plus de 5 langues…)
Comme je le disais : la barre multilingue génère des blocs multi partout, c’est crade, ça génère des erreurs, ça limite les possibilités d’édition et ça rame.
Ce qui voudrait dire que la barre multi-langue devrait pouvoir etre paramétrée par chaque redacteur, avec l’indication des quelques langues qu’il veut gérer ?
Bon, je ne parlais pas du tout d’interface mais de modèle de donnée dans ma proposition car ça n’a finalement pas grand-chose à voir, mais allons sur ce terrain :
Actuellement, les utilisateurs voient toutes les langues parce qu’ils peuvent être amenés à traduire un article depuis une langue qu’ils ne maîtrisent pas => comment tu fais si tu restreints ? A mon avis une meilleure interface de sélection des langues / traduction serait mieux que de restreindre le champ d’édition auquel ils ont accès à priori.
Dans ma proposition, les objets seraient de fait confondus par leur id_xxx, ils n’auraient alors plus besoin que d’une seule vue principale avec la possibilité de switcher entre les langues (liste déroulante ? autre ?), mais ce n’est pas l’objectif principal.
Et sans doute l’expérience de Simon nous rajouterait quelques autres améliorations…
Les manques que j’ai constatés, bien avant de parler d’interface d’édition, se situent au niveau de la conception même des sites multilingues avec des soucis (dans l’ordre) :
- de liberté de structure de données
- de performances
- de liberté de traitement séparé des différentes langues sans les isoler totalement (cf. urls)
- de saisie plus facile / souple pour les utilisateurs (leur éviter d’avoir recours à des hacks)
- de concordance de la base de données avec les objets conceptuels réels qu’elle indexe, parce que si tout n’est qu’un souci d’interface, alors on n’a qu’à faire une grosse table de nodes et hop, on renomme en druspipal
En conclusion, meme si je galère pour le multi-langues, pas sur que de faire reposer tout SPIP sur cela
facilite bcp tant la tache de migration que le travail des webmestres mono-lingues !
C’est pourquoi j’ai proposé une solution qui n’impacterait normalement que peu les sites monolingues.
Par contre, c’est vrai qu’elle demande de revoir une bonne partie de l’organisation des données générées par spip, et donc des scripts qui les manipulent.
Il y aurait peut-être des solutions intermédiaires possibles en modifiant un peu le fonctionnement du id_trad et en le généralisant à tous les objets :
- initialisé à id_objet pour le premier objet plutôt qu’à 0
- les tables des objets se verraient ajouter un index unique (pas primary) sur (id_trad,lang)
- les liens entre les objets se feraient tous dans des tables de liens (id_xxx, id_objet, type_objet), mais pour respecter l’architecture conceptuelle des données (et non pas technique), il faudrait alors que ces liaisons se fassent entre les id_trad plutôt que les id_objets
=> c’est peut-être pluginisable, je sais pas, mais il faudrait alors surcharger tous les critères par défaut qui génèrent des jointures, oulà le travail…
En plus ce fonctionnement serait beaucoup plus compliqué à comprendre pour un non initié, alors que justement l’une des qualités essentielles qu’a, à mon avis, spip par rapport à d’autres, c’est que son modèle de base de données est compréhensible immédiatement par un humain même sans lire les docs, donc extensible facilement.
Bon, sur ce, à bientôt
Simon
Mais lancer un tel truc, cela veut dire qu'on est certain que ça résolve tous les problèmes de multilinguisme... et je ne suis pas certain que cette solution ne crée pas plus de problèmes qu'elle n'en enlève.
