Cette page est destinée à noter des idées pour faire de WikiNi un outil pour des collaborations multilingues.
Voir aussi :

• WakkaMultilingue (dont la version française semble plus récente que la traduction WakkaLocalization, malgré l'avertissement "la version anglaise est désormais la version de référence")
• WakkaLocalization
• DavidDelon

Besoins

• aider une communauté multilingue à collaborer, notamment en facilitant le travail de traduction des pages
• exemples (cas concrets dont je dois m'occuper ou bien que je vis) :
  1. site réticulaire pour la préparation d'un forum international
     • il faut présenter des comptes-rendus, des motions, en plusieurs langues
     • il faut discuter en plusieurs langues
     • il faut que le système aide pour la mise à jour de ces traductions
  2. communauté technique internationale
     • il faut présenter des comptes-rendus... [... etc : c'est la même chose.]

Réflexions sur la notion d'internationalisation

L'internationalisation de WikiNi se pose suivant plusieurs axes :

• choix d'une langue préférée pour les indications de navigation (le "Vous êtes" en haut à droite de la page, les messages d'erreur, etc)
• typage linguistique des pages : pages en français, en anglais, etc pour le contenu, dont il est logique que les indications de navigation annexes soient dans la même langue. Note : si un allemand arrive sur une page dont le contenu est en français, voit-il les indications de navigation en allemand (sa préférence) ou en français (la langue du contenu) ? Ca peut être l'objet d'une option de plus à lier à un compte.

• Et si la collaboration à travers un WikiWikiWeb s'étendait à la traduction :
  • du contenu des pages (bien sûr)
  • mais aussi aux indications de navigation ? c 'est-à-dire que les indications de navigation ne seraient pas "statiques", mais redéfinissables dans le cadre du travail collaboratif.

Cas d'utilisation

1. Publication d'un nouveau document
2. Ai-je du travail de traduction à faire ?

Commentaires divers

• Ce n'est pas évident... la traduction n'est pas évidente dans un wiki, les contenus évoluent trop vite pour laisser le temps aux traducteurs de faire le boulot. Ce qui ne veut pas dire qu'il n'y a pas la place pour plusieurs langues. (Je t'encourage néanmoins fortement dans ta réflexion. Je suis sensible au sujet.) -- CharlesNepote. Idem -- DavidDelon

• Sans doute, ce n'est pas évident. En fait, il y a deux aspects à mon avis :
  1. Avoir la possibilité de fournir du contenu dans plusieurs langues, et de maintenir une certaine liaison entre les pages qui sont traductions les unes des autres.

1. Aller plus loin avec des mécanismes de notification, etc. Mais bon, ces mécanismes (notion de changement mineur/majeur d'une page, notification d'abonnés à une page après modification majeure, ...) n'existent pas dans le WikiNi de base, donc je laisse tomber ici ce deuxième aspect "processus de développement du site". -- jexOm.

Idées pour la conception

Il apparaît assez rapidement que :

1. il est nécessaire d'avoir un attribut "langue" supplémentaire pour une page
2. et qu'il faut savoir gérer un groupe de pages qui sont les traductions les unes des autres.

Sur le premier point, voici une proposition :

• attribut "langue" (utiliser la combinaison fr-FR ou en-US par exemple) associé au site : c'est la langue par défaut
• attribut "langue" associé à la page ; la valeur pour le site est utilisée par défaut.

Pour le codage des langues, voir IdentificationDesNomsDeLangue.

Plus exactement :

• une langue, dite "langue par défaut", est associée au site
• une langue, dite "par défaut préférée", pour la navigation du site : possibilité de cliquer sur un drapeau pour changer la langue par défaut pour un visiteur (soit le temps de la session, soit ad vitam aeternam par cookie client) => cas d'utilisation : essayer de s'inscrire sur WackoWiki => va trouver ce qu'il faut remplir dans le 4ème champ sans lire le russe... avec un drapeau : je clique puis après je sais enfin où aller pour m'inscrire -- BenoitAudouard 20031217
• une langue, dite "langue préférée", est associée au visiteur identifié
• (le visiteur anonyme a pour langue préférée la langue par défaut)
• le contenu d'une page est dans une langue, dite "langue du contenu"

et en plus :

• un utilisateur choisit si, pour les indications de navigation d'une page, il préfère :
  • sa langue préférée
  • la langue du contenu de la page.

Alors :

• les indications de navigation de la page s'affichent dans une langue choisie dynamiquement :
  • si la page a une langue de contenu, cette langue est dite "langue courante", sinon la langue courante est la langue par défaut du site
  • si le visiteur préfère la langue du contenu de la page, c'est donc la langue courante qui est choisie pour afficher les indications de navigation
  • (on est aussi dans ce cas pour un utilisateur anonyme)
  • sinon, c'est la langue préférée de l'utilisateur qui est utilisée pour les indications de navigation
• Note : ici on a un problème pour les liens de l'en-tête - à résoudre :
  • il faudrait que la liste des liens (ceux de la propriété "navigation_links" de wakka.config.php) dépende bien sûr du site, mais aussi d'une langue.

Le problème de la liste des liens pourrait être résolu grace aux MacroWikiNi. Il suffirait d'avoir une page wiki pour le menu qui serait utilisé comme "include" dans la proprété "navigation_link". Il y aurait plusieurs page menu : "MenuFr_fr" et "MenuEN_US" par exemple. Le nom final de la page serait obtenu en concaténant le mot "Menu" et une macro Wiki renvoyant le code langue courant. On aurait alors :
"navigation_links" => "{{include page=\"Menu{{var name="langue"}}\"}}", par exemple. Cela suppose que le paramètre page de l'action include soit interprété avant son utilisation, ce qui n'est pas le cas.
--GarfieldFr


Si vous avez besoin d'un exemple pour réfléchir : voir la FaqEagle : l'objectif est d'avoir un même document (plusieurs pages) dans plusieurs langues...

• il me manque surtout une navigation dans la langue de l'utilisateur (plus des drapeaux - visuel - pour l'utilisateur non enregistrés qui veut afficher la navigation dans une autre langue, regarder sur WackoWiki pour comprendre : quand on arrive dans un site tout en russe, on cherche des mots soit en anglais soit dans sa langue ou une icône connue... et s'enregistrer alors que tout est en russe n'est pas évident...)
• pour la dispo des pages d'autres langues, une ligne avec le nom des pages des autres langues suffit à identifier celles qui sont faites, celles qui restent à faire (c'est manuel, mais ça suffit : ya pas forcément besoin de toujours tout traduire... l'anglais et le Français pouvant suffire comme pivot...)
• pour la traduction de la navigation par tout un chacun, je serais moins catégorique que "tout utilisateur doit pouvoir enrichir continuellement le texte et ses traductions" : " le (ou les) administrateurs " se réserve(nt) la(les) page(s) utilisée(s) par wikini (au cas où il y aurait du vandalisme), les propositions de traduction sont faites sur une autre page... (faut résoudre le problème de l'édition des caractères dans la langue si c'est du cyrillique, mais autant le garder pour plus tard... disons qu'on fait le Français, l'anglais, l'espagnol, l'italien dans un premier temps : il est toujours possible de nommer un administrateur grec, russe ou polonais pour qui le problème de l'édition ne se posera pas...).
• voilà quelques pistes en vrac (après, pour la réalisation... bin je testerai !), commentaires les bienvenus pour que je vous précise mon besoin ;-)

-- BenoitAudouard 20040420

• ce dont j'aurais surtout besoin c'est dans un 1er temps la navigation des menus ;-) (je sais je me répète...)
• après pour la navigation de liens en liens (dans le contenu) c'est pas forcément si simple mais j'ai une proposition (en termes de besoins) pour le cas de l'utilisateur Anglais qui surfe sur un site avec quelques contenus en anglais (mais pas encore tout) :
  • s'il est sur une page en anglais : cliquer sur un LienWiki? l'envoie vers
    • la page en anglais si elle existe,
    • sinon prendre la page dans la langue dispo, éventuellement en tenant compte d'une 2ème préférence de l'utilisateur...)
  • s'il est sur une page en Français : le LienWiki? envoie vers une page en Français mais si la page en Anglais est dispo, il faudrait rajouter un lien "[en]" juste à côté du LienWiki? qui permettrait à l'utilisateur de reprendre directement sa navigation en Anglais...
• je propose de garder la ligne du haut (comme dans la FaqEagle) avec les liens vers les pages dans les différentes langues dispos) comme ça l'utilisateur peut comparer des versions... (qu'il soit traducteur ou lecteur)

Je suis bien conscient que ces propositions sont parcellaires mais si ça peut préciser les cas d'utilisation... (après il reste à trouver qui le développe)
-- BenoitAudouard 20040420

• Un peu d'algorithmie donc pour la langue :
• Hypothèse 1 : cela ne concerne que le menu de navigation, pas le contenu des pages en dessous... où il y a une autre navigation...
• Hypothèse 1 : la navigation est dispo dans toutes les langues de contenu (sinon afficher dans langue du site ou langue du drapeau sélectionné...
• si utilisateur non enregistré alors
  • utiliser la langue configurée dans son navigateur et afficher dans cette langue - si elle n'existe pas, alorsafficher dans la langue par défaut du site
• si utilisateur enregistré alors
  • afficher la navigation dans la langue de son cookie et
  • si il a demandé une page en précisant la langue, alors afficher la page (contenu) dans cette langue
  • sinon afficher dans la langue de son cookie - si page non dispo dans cette langue, alors l'afficher dans la langue par défaut du site ou dans la langue où la page est dispo (on peut imaginer que la page n'existe pas dans la langue du site : par exemple, un italien voulant voir une page qui n'existe qu'en anglais alors que la langue par défaut du site est le Français...)

Supplément : si l'utilisateur est non enregistré mais clique sur un drapeau, cela crée un cookie temporaire (non pris en compte si l'utilisateur s'enregistre) pour la langue de navigation. Il faut distinguer la langue " d'habillage du site " et la langue du contenu regardé (qui a sa propre navigation), c'est comme regarder un DVD d'un film anglais acheté en France : la jaquette est en Français et en néerlandais (moins cher de mettre 2 langues) et le film peut être regardé en VO ou en Français voire en néerlandais : contenant / contenu, ça doit être une notion que tu maîtrises à lire ton site ;-)
A tirer au clair : le drapeau permet de passer la navigation dans la langue de la personne (qu'elle s'y retrouve dans le site) et a des impacts sur quelques pages (celle d'inscription par exemple)
Regarder comment ça se passe sur http://mandrakeclub.com pour les forums en plusieurs langues... c'est pas parfait mais c'est pas mal...
............

• ça c'est du ressort de l'implémentation, je pense qu'il faut un lien "traduire" qui permet de garder le même identifiant pour la page même si elle a un nom différent : exemple HomePage PagePrincipale... faudrait voir ce qui a été fait sur WackoWiki. A priori une page par langue c'est mieux (au pire avec un champ supplémentaire identifiant la référence), après le DernierChangements? doit être adapté pour LastChanges c'est une évidence...). Mais - je vais me répéter - ya pas besoin si seule la nav' est changée. Ton idée de reverso est pas mal (même si la traduction reste aléatoire) -- BenoitAudouard

---

Je reprends tout à zéro, tant mes essais sont erronés ! excuses moi de tout chambouler !
Ma solution provisoire, proposée, améliorable... pour la traduction du contenu des pages
Actuellement : solution provisoire : je propose sur le site,, un bouton amenant à Reverso : les liens sont maintenus, et le lecteur reste dans sa langue après l'avoir choisi. Désavantage : traduction automatique très balbutiante !
Mon souhait : Une page unique avec plusieurs traductions incluses dans la même page mais une seule traduction s'affiche conformément au choix du lecteur.
Pourquoi ce choix ? : Conformément à l'esprit Wiki, c'est à l'utilisateur (administrateur ou simple usager) de proposer ou non une traduction de ce qu'il écrit : traduire est une action sociale. Je propose donc que tout usager, ayant la chance d'être multilingue, puisse ajouter une traduction supplémentaire. La traduction s'enrichit au même titre que le texte.
Le fait de faire une page par langue a un désavantage énorme : toute modification sur une de ses pages n'est pas transmise aux autres pages ! tandis que si toutes les traductions se trouvent sur la même page, il est facile au dernier modificateur de le signaler ou de faire lui-même la trad via Reverso. Nous gardons ainsi un texte et un historique homogène. Multiplier les pages, c'est multiplier les liens, empêcher la confrontation des traductions, rendre la maintenance encore plus difficile....
Autre remarque : le fait de construire des menus par l'action include, permet de proposer immédiatement des menus traduits. (Je n'aborde absolument pas ici la traduction de Wikini lui-même, hors de mes compétences...)
Ma solution :

• une modification de waka.config pour y inscrire la langue par défaut.
• une action {{langue choix=languechoisie: fr en de.....}} que l'on peut mettre où l'on veut sous forme de drapeau en haut,bas de page. On peut même l'inscrire dans la page elle-même si besoin est..
• une action traduire fr="texte en français", en="texte en anglais", de="texte en allemand"...}}. Problèmes : texte normal, mais sans saut de ligne et sans texte contenant {{ ou }} ...

Améliorations souhaitables, possibles

• pouvoir traiter un texte-paramètre ayant plusieurs lignes
• pouvoir bien séparer les différents paramètres fr="..." en="..." au besoin en les séparant pat un saut de ligne
• prise en compte de la langue de l'utilisateur enregistré ( l'ajoût d'un champ "langue" dans la table users. dans l'action usersettings.) me parait maintenant inutile
• améliorable le script en enlevant la conditionnelle

Les scripts :

• 
  

Ce matin... Si la solution proposée, pour la traduction d'une page,fonctionne, elle est très, très, trop lourde (temps, écriture, sources d'erreurs, corrections), tant que les paramètres ne pourront prendre qu'une ligne. La solution par le formatage type #GB# me parait plus simple, mais elle n'est pas informatiquement faisable sans grosses modifications (?).
Par rapport à la traduction automatique style Reverso, ce que je propose est donc une fausse bonne idée, style usine à gaz, que j'abandonne ! Reverso maintient l'unicité des pages, l'homogénéité des liens, de l'historique, la rapidité. Qu'en demander de plus ? Certes la traduction est parfois rigolotte ( Realite = Re-confine-to-bed) Mais, le progrès arrangera vite ces défauts. (Pour l'instant, 9 traductions intégrées au site !! )
Reste la traduction propre de Wikini : le choix de constantes php rassemblées dans un fichier propre à chaque langue semble le choix de la plupart des CMS. Mais je ne peux guère en dire plus. Bon courage. (Pour les drapeaux, tu en trouveras à l'intérieur des cms téléchargeables en open-source). --FidelioEspoir

---

oula ça se transforme en forum maintenant ;-) -- BenoitAudouard
Bon la synthèse :

• ce serait pas mal d'avoir une ML sur gna.org https://gna.org/mail/?group=wikini
• ta proposition est clairement intéressante, même s'il nous faudrait quelqu'un de WikiNi pour la partie navigation (ta propale de menu en include me séduit mais tant qu'on n'a pas les templates, c'est du boulot à faire que tout utilisateur l'ajoute)
• le mono-page en plusieurs langue c'est l'avenir ou l'à-venir (quand seules les modifs seront gardées pour chaque mise à jour, sinon la base va grossir à vitesse grand V)
• il faudrait reporter les modifs sur ton site dans wikini (quand c'est possible) sur une page d'exemple servant de référence (quand ce n'est que le contenu qui est concerné), ça m'évitera de regarder 2 sites à la fois...
• ce serait pas mal de scinder cette page en plusieurs (désolé mon métier me rattrappe même le soir) : CollaborationsMultilinguesBesoins? (pour les demandes de fonctionnalités) CollaborationsMultilinguesDev? (pour l'implémentation) CollaborationsMultilinguesPrototype1_2_3_4 (pour les exemples) CollaborationsMultilinguesCasDUtilisation? (pour les tests et précisions de contexte)

Le détail :

• le reverso et kartoo c'est clairement novateur pour WikiNi et ça a une réelle valeur ajoutée, bravo !
• tu mélanges un peu trop besoin / dév sans creuser chacun (cf. proposition) même si ça permet d'avoir une continuité de la pensée (du besoin au dév) ça ne permet pas au final de savoir ce qui est fait / ce que ça fait et si tous les cas sont bien pris en compte... on va y arriver je pense (faudrait un contributeur WikiNi habitué pour la navigation quand même)
• ma propal' sur FaqEagleUsb c'est bien d'avoir une gestion du contenu via la ligne avec tous les noms de page dans chaque langue (et je fais avec l'existant, en manuel en attendant ta solution miracle) d'où mon besoin que ça soit dans des pages séparées => le "gros" défaut c'est qu'il faut choisir un nom de page "signifiant" dans chaque langue et y accoler la langue) mais bon....
• pour moi ton problème de visibilité des changements dans toutes les langues, c'est "simplement" une modif' de l'action associée à DernierChangements? pour tenir compte des langues dispos (ça évite d'avoir une page hyper-grosse qui contient toutes les traductions, et ça évite le syndrome de l'édition en parallèle qui t'empêche de sauver et qui va être un cauchemar pour les traducteurs) => afficher la modif' de la page en précisant la langue concernée et afficher les liens des pages dans les autres langues sur la même ligne
• le fait d'avoir plusieurs pages pour "la même page dans plusieurs langues" c'est l'ajout d'un identifiant de page pour la retrouver dans les différentes langues (l'identifiant "nom de page" est clairement mal choisi vu qu'il a plusieurs sémantiques : identifiant + nom de la page => HomePage / PagePrincipale donc faut ajouter la notion d'identifiant de page... voir ce qui a été fait dans WackoWiki)
• il faut préciser tes CasDUtilisations? pour la visualisation des pages dans "sa" langue (enfin la langue choisie par l'utilisateur) je ne réussis pas à voir si tu es exhaustif, reprend/complète mon découpage proposé précédemment
• si tu raisonnes en terme de "besoin utilisateur" et "d'implémentation" tout va se clarifier => il ne faut pas être "pollué" par l'implémentation actuelle de wikini mais proposer quelque chose de propre, après la migration de l'un à l'autre se fera naturellement (ne pas raisonner solution, mais besoin... pas évident, je sais). ça va nous résoudre "naturellement" le pb "une page/plusieurs pages" et le "plusieurs lignes en paramètre"
• reverso est un contournement pas une solution => cela ne devrait servir que pour les pages non traduites (avec l'indication explicite que c'est reverso qui la fournit et non pas une page traduite). Le problème à traiter c'est la "fraîcheur" de la traduction pour bénéficier des dernières mises à jour (et comparer) => ce que j'ai comme liens en haut de page pour chaque langue sur la FaqEagle? pourrait avoir une date pour voir laquelle est la plus récente (pas forcément la plus à jour vu que ce n'est "que" la date de dernière modification, sans indication qualitative sur le contenu)
• voilà ça suffira pour l'instant ;-)

-- BenoitAudouard

PageSuivieParGarfieldFr

---