section bilingue
Dans l'optique de faciliter la création d'un site bilingue, j'aimerais savoir s'il est difficile de créer une section adaptée :
ce serait alors à Yacs de gérer une arborescence de la forme
www.monsite.dom/biling/fr
www.monsite.dom/biling/en
Même s'il faut simplifier les fonctions offertes par Yacs pour la partie bilingue, juste pour créer une section bilingue, je pense que cela en vaut la peine,
1. stratégiquement, c'est une option qui n'est pas très facile à mettre en oeuvre dans les divers produits du marché...
2. pratiquement, ça permettrait de tester les besoins des utilisateurs et de voir quelle mise en oeuvre est possible
- définie comme bi (ou multi) lingue d'entrée
- chaque création d'article en son sein proposant les champs à compléter dans les langues prévues L1, L2 ...
- au résultat, une bascule entre les versions par clic sur une icone de drapeau
- on peut choisir de ne pas proposer le texte systématiquement dans chacune des langues, et alors le contenu est remplacé par un message du type "pas encore disponible en ...", un rappel de l'intitulé et un lien vers la version autre
- une zone de mise à disposition de fichiers selon le même schéma
- un tableau récapitulatif des documents appariés dans les langues, pour suivre les lacunes, aider à l'écriture et à la maintenance
ce serait alors à Yacs de gérer une arborescence de la forme
www.monsite.dom/biling/fr
www.monsite.dom/biling/en
Même s'il faut simplifier les fonctions offertes par Yacs pour la partie bilingue, juste pour créer une section bilingue, je pense que cela en vaut la peine,
1. stratégiquement, c'est une option qui n'est pas très facile à mettre en oeuvre dans les divers produits du marché...
2. pratiquement, ça permettrait de tester les besoins des utilisateurs et de voir quelle mise en oeuvre est possible
Je me permets d'insister sur ce topic qui revient chaque fois que quelqu'un découvre YACS et sur l'urgence d'offrir
- la possibilité de traduire YACS (avec une page centralisée de messages par langage, par exemple)
- des fonctions de gestion de site multilingue, avec des parties répétées dans les diverses langues et des parties spécialisées avec des contenus différents
ce sont deux aspects différents, complémentaires mais bien différents
- la traduction dépend pour beaucoup du travail des programmeurs
- la mise en forme d'un site multilingue aussi, mais les créateurs de sites peuvent sans doute préfigurer l'organisation à partir des sections, sous sections, catégories ou overlays et autres fonctionnalités de YACS
On avait démarré comme ça avec les Zaniroli, et en pratique c'est extrêmement difficile à maintenir. Et puis, la frustration de se retrouver devant un 'page non encore traduite' peut être assez importante... D'où le modèle plus souple implanté aujourd'hui, qui nous a conduit à créer des sections pour le contenu en français, et d'autres pour celui en anglais, avec des skins particuliers. Les pages similaires peuvent être reliées explicitement si besoin, soit au niveau d'une section, soit au niveau de l'article lui-même. Ainsi les internautes conservent la possibilité de changer de langue s'ils le souhaitent, et les gestionnaires savent quelles pages n'ont pas été traduites (elles n'ont pas de lien).
Le côté bilingue est un point qui m'intéresse car ici, avec les multi-nationalités, nous sommes tous obligé de faire au moins Français/Anglais et parfois Espagnol et Hollandais.
Je pense, par rapport à la conception de YACS, qu'il faut prendre le problème sous deux angles:
A - Les traductions internes propres aux scripts. B - Les traductions de contenus.
Pour éviter les "non dispo", une horreur de la même série que les pages "en construction", il faudrait avoir plusieurs outils.
Un premier (je suis en train d'étudier PoEdit que tu as cité) pourrait convenir aux scripts avec des fichiers .po en include quelque part.
Un second permettrait (à voir en plugin Java) de donner à YACS une vue "linguistique" des différentes versions des articles et pourquoi pas sous forme de tableau comme tu le suggérais.
Le point (A) devrait alors avoir été révisé avant chaque mise à jour de YACS.
Le point (B) peut être déjà réalisable:
- Créer une section "Langues"
- Créer autant de sous-sections que de langues.
- Créer des articles correspondants dans chaque sous-section avec pour particularité, une codification dans le champ "Surnom". Le sélecteur de pages, une table ou une catégorie permettent de visualiser quels articles sont en quelles langues.
Ces sections n'ayant aucun affichage au sein du site, elles servent uniquement à stocker les articles. Les vraies sections y font alors référence pour l'affichage que l'on souhaite.
Bon, c'est une idée comme une autre ...
Je réponds rapidement (après deux jours d'absence les mails s'accumulent et les messages de forum aussi
) à Bertrand et à GnapZ :1. merci pour les témoignages et les pistes,
2. je comprends la lourdeur du processus, et je n'imagine cette solution que pour une part limitée d'un site: le renseignement sur un sujet précis (les modalités d'accueil des étudiants étrangers par exemple) et non sur tout le site. Même les responsabilités de gestion de contenu ne concerneraient qu'une faible partie de la structure administrative, une ou deux personnes tout au plus.
3. à la limite, vous avez raison, ça peut figurer le langue étrangère uniquement...
4. pour la traduction des scripts, je ne sais pas quelle est la meilleure solution:
le format compatible avec poedit permet d'utiliser cet outil mais je ne sais pas si c'est la meilleure solution pour que les chaînes soient réparties dans les scripts de YACS
Ghjmora : Je pense que s'il y a une prise en charge multilingue pour une partie de site, elle peut être utilisée partout, non ? Auquel cas il faut "penser" à une gestion multilingue des articles et sections.
Concernant PoEdit, j'ai fais quelques essais et si l'outil semble très performant, je ne le trouve pas vraiment adapté aux scripts tels qu'ils sont conçus. Par contre il semble mieux adapté pour traiter des articles en plusieurs langues.
Deux aspects:
- rédaction multilingue
- multilinguisme de l'interface (de Yacs)
" Ghjmora : Je pense que s'il y a une prise en charge multilingue pour une partie de site, elle peut être utilisée partout, non ? Auquel cas il faut "penser" à une gestion multilingue des articles et sections.
"
Pour la rédaction multilingue ,je crois qu'il faut une solution "modeste" et une aide à la rédaction:
- ne pas viser (forcément) le multilinguisme d'un site entier
- mais faciliter la gestion bilingue d'une sous partie "utile" avec des utilitaires de création de documents (dans la section bilingue, on propose d'office les deux champs à compléter pour le titre, le contenu, etc) et de gestion (un état des documents réellement proposés dans les deux langues et ceux pour lesquels on a choisi provisoirement ou définitivement de ne pas le faire)
"
Concernant PoEdit, j'ai fait quelques essais et si l'outil semble très performant, je ne le trouve pas vraiment adapté aux scripts tels qu'ils sont conçus. Par contre il semble mieux adapté pour traiter des articles en plusieurs langues. "
je suis d'accord avec toi pour Poedit
- c'est utilisé pour des logiciels compilés et non des rafales de scripts en gestation permanente (aspect positif de Yacs)
- pratique pour gérer les correspondances entre textes quand on peut les apparier (on parle de bitextes d'ailleurs, et il y a des exemples entiers sur le web, surtout au Canada pour les documents juridiques, mais on s'égare...)
On avait parlé un jour avec Bernard (et Fernand) de la manière de traduire Yacs, des problèmes que ça pose et des solutions d'autres CMS
- il y a des questions linguistiques et de charge de travail (près de 12000 chaines, la dernière fois que j'ai jeté un oeil)
- qui ne permettent pas l'amateurisme : on peut le faire une fois par plaisir, mais avec des mises à jour fréquentes, il faut pour voir suivre et que les lacunes de traduction ne gênent pas le fonctionnement
- il y a aussi des questions de performance du logiciel sur lesquelles ils faudrait un audit
- est-ce que le remplacement des chaines de caractères par un code et leur rangement dans un fichier textuel par langue ralentit le logiciel?
- ou est-ce qu'il vaut mieux faire générer des versions linguistiques différentes par remplacement des chaines dans les scripts...
bref, je m'éloigne du sujet.
Et pour revenir sur ces deux questions, très brièvement, c'est de la tactique et de la stratégie
- pouvoir gérer des documents en plusieurs langues dès la rédaction, sans contorsions dans les mots-clés ni autres paramètres d'interface, à la portée d'un secrétariat sans formation informatique, c'est un outil absent des autres CMS [surtout en pas chercher à faire un outil parfait, informatiquement parlant]
- offrir une version localisable de YACS, c'est ouvrir sur d'autres marchés linguistiques, et il y en a, où on connait l'anglais mais où on développe dans la langue du pays : internet permet ce genre d'investissements même pour les langues qui ont un marché limité commercialement [vilain mots du bizness mais recyclés aussi par les sociologues pour décrire ces situations, excusez...]
Ghjmora : Le multilingue est un sujet qui me concerne et tes écarts de sujet sont fort intéressants.
- "ne pas viser (forcément) le multilinguisme d'un site entier": Au vu de la conception de YACS FR/EN intégré, je pense au contraire qu'il faut voir le problème dans son ensemble. C'est à dire, trouver une solution de gestion des langues au sein même de la structure des articles et sections. Ton idée de suivi arborescent ("yacs/fr", "yacs/en", etc) était un bon départ.
- "près de 12000 chaines": pour ce qui est des scripts, cela touche la conception et donc les phases de développement. Un outil externe à Yacs dans la manipulation des scripts serait, à mon avis, la meilleure solution pour les développeurs. Inutile d'intégrer quoi que ce soit à Yacs pour cette partie du problème.
- "il y a aussi des questions de performance du logiciel": OUI, c'est un des points forts de YAcs alors il ne faut pas y toucher. D'un autre côté, la mise en variable des termes permettrait l'utilisation de fichiers de langues (toujours pour les scripts, pas le contenu qui reste à la charge de l'utilisateur).
Bonjour,
je vient d'installer yacs, et je commençe a l'aprecier toujours plus bien que beacoup de chose me soit encore obscure.
Par contre, j'aurai aprecié avoir un choix plus ample pour ce qui est des langues.
En ayant le plaisir de localiser le site en italien j'aurais aussi volontier pris la peine de le traduire moi méme. Mais je me trouve en difficulté vù que je n'ai aucune connaissance en php.
En tant q'utilisateur j'aprecie toujours pouvoir choisir la langue d'affichage.
Là solution proposée par Gmcms (gettext) semblait interessante a un profane.
En conclusion ne pouvant vous soutenir aux niveaux pratique tant que la traduction ne se reduirà a la simple traduction de chaine dans un fichier bien defini, je voulais juste vous soutenir dans votre quéte vers le multilingue.
Fw_crocodile : Merci beaucoup pour votre soutien. Nous y travaillons de façon à ce que Yacs utilise un fichier de langue. Quand ce sera prêt, nous ne manquerons pas de faire appel à vos compétences pour la version Italienne.
GnapZ : Je viens également à la charge sur ce sujet, et c'est totalement intéressé : un de nos client, bien content de notre travail (avec yacs, bien sûr), nous demande d'étudier la prise en charge multilangue. Anglais pour le début, mais ensuite 2 ou 3 autres langues.
Pour la transcription en anglais, on devrait pas avoir trop de soucis, partant du fait que yacs est nativement anglais/français, et que pour le contenu, on va créer des sections en anglais, miroir des sections en français. Mais pour la suite, il va falloir qu'on trouve une solution acceptable, pour que l'affichage de navigaion, lui aussi, s'adapte à la langue choisie.
Bon, ben voilà qui va nous donner matière à travailler ! On a pas prévu de s'y mettre avant le dernier trimestre, mais... ça sera vite là, c'est sûr.
Par contre, on est pas des habitués de la chose, et si on veut bien prendre place dans ce boulot, ce sera très appréciable d'avoir d'autres regards/compétences pour boucler tout ça.
Agnès
Il n'y a pas de problèmes, que des solutions.
Agnès: De toute façon, l'impact du changement vers gettext ou équivalent va être tel que toutes les bonnes volontés seront nécessaires. je voudrais stabiliser les comportements et paiement paypal avant... Donc démarrage des travaux pour la 6.10 à vue de nez, avec trois mois pour rentrer dans votre planning ?
Rate this page
Posted by Ghjmora on Apr. 23 2006, commented by Bernard on Apr. 23 2006, (popular)
