Wikini

WakkaMultilingue

PagePrincipale :: DerniersChangements :: DerniersCommentaires :: ParametresUtilisateur :: Vous êtes ec2-44-222-149-13.compute-1.amazonaws.com
[ In English ] (la version anglaise est désormais la version de référence)


Je pense que cet aspect est fondamental si nous voulons faire grossir le projet.
Sur le site du WakkaWiki originel il y a pas mal de bonnes volontés, de bonnes idées, mais l'auteur n'est pas très réactif... une version multilingue de WakkaWiki permettrai de mieux fédérer toutes les initiatives actuellement sans réponse.

J'ai publié sur le site wakkawiki mes idées sur la question du multilinguisme.

Pour résumer, je parts de l'observation suivante : pourquoi générer dynamiquement des pages traduites alors que la traduction ne change jamais ?
Je propose donc un système pour générer les pages php en plusieurs langues à partir d'une version "source" et d'un tableau de traduction.








Je travaille actuellement à la transformation du Wikini que je monte (http://esperanto.toulouse.free.fr/wakka.php?, inaccessible ce matin, est-ce dû à free ?) en version bilingue, espéranto-français. Lorsque j'aurai finalisé cela proprement je le ferai savoir ici. ArnoLagrange.


Résumé des 3 différentes possibilités


1. Génération des pages localisées à la volée.
Pour : nombre de fichiers réduits ; possibilité de regrouper les traductions en un seul tableau.
Contre : requiert un traitement supplémentaire côté serveur à chaque requête de l'utilisateur ; page de code difficiles à lire.
Dans notre cas cette solution n'est pas retenue car nous voulons garder WikiNi le plus véloce possible.
Outils possibles :

2. Etablir une version traduite de chaque page pour chaque langue.
Pour : bonne performances (équivalentes à 3) ; système simple : pas de formation nécessaire pour la mise en oeuvre.
Contre : multiplication du nombre de fichiers ; maintenance difficile : lorsqu'un fichier est modifié, il faut modifier toutes ses déclinaisons dans les autres langues.

3. Génération hors ligne des pages localisées par un outil.
Pour : bonne performances (équivalentes à 2).
Contre : il faut trouver un outil, ou le développer (ce qui n'est pas l'objectif du projet).
Outils possibles :


-- CharlesNepote

J'ai regardé cet outil, c'est interessant. Si j'ai bien compris, il s'agit de mettre des balises speciales pour identifier
les champs à "localiser" dans chaque document source. Un inconvénient : il faut aller dans chaque fichier pour ajouter
une nouvelle langue. Je préfère la solution que tu as proposé avec le tag (###Message1###). Mais peut être que je n'ai pas saisi tout l'interêt de la chose ...
-- DavidDelon

Pour ce qui est des outils de gestion multilangue en PHP, je pense que jeter un oeil à PEAR::Translation2? (voir http://cambiano.onlinein.it/pearzone/Translation2/example.html) pourrait être intéressant.
-- NicolasHoizey

Vous pourriez aussi utiliser le module d'internationalisation de SPIP... puisque les spipeurs aiment bien wikini, et que, en plus, nos outils sont vraiment très pratiques :-) -- FiL?


J'ai proposé une explication de la solution I sur ma page (AureLie), inspirée de WackoWiki. Effectivement, ça pose des questions de performances: les chaînes de texte sont recalculées (remplacées par la chaîne traduite) à chaque affichage de la page (j'avais fait ici une comparaison scabreuse avec SPIP qui ne tient pas, étant donné que SPIP a un système de mise en cache des pages). Je ne sais pas encore pour quel système je vais opter, mais je ne demande pas mieux que de m'inscrire dans les développements actuels de WikiNi. Le problème, c'est de savoir comment participer à un travail en cours, où trouver les codes? Donc, si je peux investir le temps que j'investis dans quelque chose de cohérent avec le projet WikiNi, faites-moi signe. WiciEtMaintenant?! --AureLie
On est encore en phase de réflexion, il doit bien avoir des bouts de code par ci par là chez les uns et les autres mais rien de montrable ... Je crois que quand on sera tous d'accord sur une méthode on pourra foncer, en attendant tes idées sont les bienvenues -- DavidDelon


Cas d'utilisation UML


Pour avoir votre avis et voir si nous sommes d'accord sur le principe, j'ai rédigé les CasDUtilisation "métier" (c'est-à-dire non-informatique) du système multilingue. (Vous excuserez mon vocabulaire.)
I. -- Choix des langues à l'installation
  1. - l'utilisateur transfère en ftp l'archive décompressé de WakkaWiki sur son site web
  2. - l'utilisateur ouvre la page d'accueil dans son navigateur
  3. - le système détecte que c'est la première consultation du site
  4. - le système propose à l'utilisateur de choisir une langue pour la configuration de son site
  5. - l'utilisateur choisi une langue
  6. - le système propose à l'utilisateur de renseigner les différents paramètres de configuration dont les langues disponibles pour la consultation du site et la langue par défaut
  7. - l'utilisateur renseigne les différents paramètres dont les langues disponibles et la langue par défaut
    1. - [Cas alternatif] l'utilisateur ne renseigne pas tous les paramètres (dont les langues disponibles et la langue par défaut)
    2. - le système signale à l'utilisateur qu'il n'a pas tout renseigné [retour à l'avant dernière action]
  8. - le système enregistre la configuration

II. -- Choix de la langue par défaut pour un utilisateur
  1. - l'utilisateur ouvre sa page de configuration ParametresUtilisateurs?
  2. - le système détecte toutes les langues disponibles pour l'interface du site
  3. - le système propose à l'utilisateur de renseigner ses paramètres personnels dont la langue utilisée pour l'interface du site (parmi un choix donné)
  4. - l'utilisateur renseigne ces paramètres dont la langue utilisée pour l'interface du site
    1. - [Cas alternatif] l'utilisateur ne renseigne pas la langue utilisée pour l'interface du site

III. -- Consultation du site
  1. - l'utilisateur demande une page du site
  2. - le système reconnaît l'utilisateur
    1. - [Cas alternatif] le système ne reconnaît pas l'utilisateur
    2. - le système sert à l'utilisateur la page demandée avec une interface dans la langue par défaut (ou bien dans la langue par défaut du navigateur de l'utilisateur ?) (Dans la langue par defaut du navigateur ou, si elle n'existe pas, dans la langue par défaut -- DavidDelon)
  3. - le système retrouve la langue par défaut de l'utilisateur
    1. - [Cas alternatif] le système ne trouve pas de langue par défaut de l'utilisateur
    2. - le système sert à l'utilisateur la page demandée avec une interface dans la langue par défaut (ou bien dans la langue par défaut du navigateur de l'utilisateur ? (Dans la langue par defaut du navigateur ou, si elle n'existe pas, dans la langue par défaut -- DavidDelon)
  4. - le système sert à l'utilisateur la page demandée avec une interface dans la langue de l'utilisateur par défaut

-- CharlesNepote

D'accord avec ce fonctionnement, il y a déja un fond de source que l'on peut récuperer dans phplang, downloadable ici :
phplang
-- DavidDelon

Vu phplang. Es-tu sûr qu'on puisse récupérer grand chose hors la détection de la langue du navigateur... peut-être qu'il y a des choses que j'ai loupé... je suis plutôt niveau débutant en php. Je vais tester phplang plus en profondeur et on pourra peut-être l'utiliser au moins pour les formulaires de configuration. Je vais essayer de faire le formulaire qui correspond à I.4. Je vais essayer aussi de faire des propositions d'implémentation.
-- CharlesNepote

Si vous avez besoin d'aide pour comprendre ce que fait phpLang, il y a un tutoriel en ligne (voir http://www.phpheaven.net/projects/phplang/documentation/tutorial_article8.html [en]), mais je peux aussi apporter directement des réponses, c'est moi qui l'ai fait ... ;)
-- NicolasHoizey

J'ai fait un petit test multilangue, (Point II et III mais sans enregistrement de la configuration par l'utilisateur), les modifications dans
wakka.php sont vraiment minimes :

<?php
// start session
session_start();

// Ajout du paragraphe suivant : (et d'un default_lang dans wakka.config.php)

if(!$lg=$_REQUEST["lang"]) $lg=$_SESSION["lang"];
if(!
$lg$lg $wakkaConfig["default_lang"];
$_SESSION["lang"]=$lg;
if(
$lg){
    
$wakkaConfig["action_path"]  .= "/"$lg;
    
$wakkaConfig["handler_path"] .= "/"$lg;
}


Avec, par exemple une restructuration de actions en actions/de/ , actions/fr et actions/en
et de handlers/page en handlers/de/page handlers/fr/page et handlers/en/page.
On peut voir ce que ça donne ici : david.delon.free.fr/wakka, je n'ai traduit que l'entete (Vous etes ..., You are ..., Du bist ...)
Qu'en pensez vous ?
-- DavidDelon

Je viens de rajouter une gestion complete du bandeau en multilingue (navigations links ...) au moyen de fichiers de configs spécifiques
pour chaque langue définie dans wakka. Pour voir ce que ça donne , toujours la même adresse : david.delon.free.fr/wakka ! Yapluka mettre en place un systeme de génération de page !
Principe retenu :
  1. - l'utilisateur demande une page du site
  2. - L'utilisateur a choisi une langue
    1. - [Cas alternatif] l'utilisateur n'a pas choisi de langue
    2. - le système considère que la langue de l'utilisateur est la langue par défaut
  3. - Le système affiche la page demandée, l'entete de la page s'affiche dans la langue de l'utilisateur.
    1. - [Cas alternatif] la langue choisie par l'utilisateur n'est pas définie dans le système
    2. - le système affiche l'entete de la page dans la langue par defaut
-- DavidDelon

Bon. ces histoires de traduction ce n'est pas si simple... j'ai regardé toutes les solutions... aucune ne me séduit complètement.
Je propose donc d'y aller progressivement.

1. Premier constat : le balisage.
Une chose est sûre, c'est qu'il faut baliser les chaînes à traduire.
Je propose donc un premier balisage suffisament souple pour nous permettre d'en changer à l'avenir si les solutions choisies ne nous conviennent pas.
Il s'agit donc de baliser chaque chaîne avec le préfixe "txt_" : par exemple txt_chaine_a_traduire.

2. Deuxième constat : génération a priori ou génération en temps réel ?
Les deux mon capitaine !
La génération de page a priori est un système qui ne conviendra peut-être pas à tout le monde (il y a beaucoup de moyens de gérer les problèmes de performance ; il y a des gens qui maîtrisent par exemple le hard ou le côté "système" de leur serveur et qui préfèreront agir là-dessus). Je propose donc un système qui permette d'employer les deux solutions : au choix de l'utilisateur. A partir de là il y a plusieurs solutions. Je vous livre celle qui a ma préférence (je détaillerai les autres plus tard si nécessaire).

Exemple (incomplet) pour footer.php
(sachant que je n'ai pas pris le plus facile)
<?php
switch ($lang) {
    case 
"" :
        
define ("txt_Text_search""TextSearch");
        
define ("txt_clic_to_edit""Clic to edit page");
        
define ("txt_edit_this_page""Edit this page");
        
define ("txt_clic_to_see_modifications""Clic to see last page modifications");
        
define ("txt_owner""Owner");
        
define ("txt_edit_acls""Edit ACLs");
        break;
    case  
"fr" :
        
define ("txt_Text_search""RechercheTexte");
        
define ("txt_clic_to_edit""Cliquez pour editer cette page");
        
define ("txt_edit_this_page""&Eacute;ditez cette page");
        
define ("txt_clic_to_see_modifications""Cliquez pour voir les dernières modifications sur cette page");
        
define ("txt_owner""Propri&eacute");
        
define ("txt_edit_acls""&Eacute;diter ACLs");
        break;
    }
?>

<div class="footer">
<?php echo  $this->FormOpen(""txt_Text_search"get");
    echo  
$this->HasAccess("write") ? "<a href=\"".$this->href("edit")."\" title=\"".txt_clic_to_edit."\">".txt_edit_this_page."</a> ::\n" "";
    echo  
$this->GetPageTime() ? "<a href=\"".$this->href("revisions")."\" title=\"".txt_clic_to_see_modifications."\">".$this->GetPageTime()."</a> ::\n" "";
        
// if this page exists
        
if ($this->page)
        {
            
// if owner is current user
            
if ($this->UserIsOwner())
            {
                print 
txt_owner " :: <a href=\"".$this->href("acls")."\">".txt_edit_acls."</a> :: <a href=\"".$this->href("deletepage")."\">Supprimer</a> :: ";
            }
            else
            {
                if (
$owner $this->GetPageOwner())
                {
                    print 
"Propriétaire : ".$this->Format($owner);
                }
                else
                {
                    print(
"Inconnu".($this->GetUser() ? " (<a href=\"".$this->href("claim")."\">Take Ownership</a>)" ""));
                }
                print(
" :: ");
            }
        }
    
?>
    <a href="<?php echo  $this->href("referrers"?>" title="Cliquez pour voir les URLs faisant référence à cette page.">
    References</a> ::
    Recherche : <input name="phrase" size="15" class="searchbox" />
<?php echo  $this->FormClose(); ?>
</div>


<div class="copyright">
<a href="http://validator.w3.org/check/referer">Valid XHTML 1.0</a> ::
<a href="http://jigsaw.w3.org/css-validator/check/referer">Valid CSS</a> ::
-- powered by <?php echo  $this->Link("WakkaWiki:WakkaWiki""""Wakka ".$this->GetWakkaVersion()) . "\n" ?>
</div>


<?php
    
if ($this->GetConfigValue("debug"))
    {
        print(
"<span class=\"debug\"><b>Query log:</b><br />\n");
        foreach (
$this->queryLog as $query)
        {
            print(
$query["query"]." (".$query["time"].")<br />\n");
        }
        print(
"</span>");
    }
?>


</body>
</html>

Qu'en penses-tu David ?
-- CharlesNepote

Ma seule crainte c'est que les fichiers ne grossissent exagérement, mais c'est un bon compromis. Pour moi c'est OK, d'autant plus que,
comme tu l'as dit "rien n'empêche de développer ultérieurement un outil qui prenne chaque fichier et remplace les constantes par des chaînes".

-- DavidDelon

J'avais laissé ce sujet en jachère ... La solution que tu proposes Charles est séduisante, mais plus j'y réfléchis, plus je pense que ça va être impossible à maintenir par la suite :


Codages des caractères


Dans le cas où aucun codage de caractères n'est sélectionné, il semble que l'ISO-8859-1 (ou ISO-Latin-1, correspondant à l'essentiel de l'alphabet français) soit pris par défaut.
On peut alors écrire correctement les caractères russes mais pas les rééditer car ils sont transformés en entité SGML.
Par exemple : Привет это прсот тест. Помогите ктонить решить проблему.

Il est possible de gérer sommairement les caractères russes, japonais ou autres en ajoutant dans le header de /actions/header.php :

Note : <meta http-equiv="Content-Type" content="text/html; charset=utf-16"> ne fonctionne pas semble-t-il.

http://www.w3.org/International/O-charset.html


Questions. (On essaye de se poser les bonnes questions relatives à ce problème.)

-- CharlesNepote

Quelques réponses sur UTF-8 :
- pour ma part je suis sous Linux en environnement UTF-8 depuis un an (voir plus)
- concernant la production de contenu UTF-8, on peut soit partir d'un document encodé dans un autre codage et le recoder en UTF-8 (avec iconv --from=iso-8859-1 --to=utf-8 ou recode l1..u8, ou autres), soit produire directement de l'UTF-8 avec un éditeur aproprié
- concernant les éditeurs compatibles UTF-8, il y en a plusieurs sous Linux (j'utilise surtout vi et yudit), et sous Windows il doit en exister (je n'utilise plus Windows) mais attention au fait que Windows utilise l'UCS-2 et non UTF-8 (codage de la même information mais d'une manière différente)
- je pense cependant que la question de l'édition ne se pose pas avec les Wiki : en effet, l'édition passe par le navigateur web et la conversion entre le jeu de caractère local (poste client navigant) et le jeu de caractère de stoquage (serveur Wiki) est donc à sa charge ; et c'est effectivement ce que je constate de mon coté avec le navigateur Galeon au moins (de souche Mozilla)
- concernant la lecture des contenus en UTF-8, c'est essentiellement un problème de police installée sur le poste client navigant ; tous les navigateurs modernes supportent (à peu près) correctement UTF-8 au niveau affichage à condition qu'ils trouvent les caractères à afficher dans l'une des polices disponibles sur le système ; sous Linux il faut installer les polices iso-10646-1 et sous Windows il faut installer les versions Unicode des classiques Arial, Times New Roman et Courrier New.

-- ProgFou

http://www.mysql.com/doc/en/Charset-Unicode.html MySql 4.1 est prêt pour l'utf8 -- BenoitAudouard 20031221

Je suis en train de modifier WikiNi pour la langue vietnamienne en utilisant UTF-8. Ca marche sans problème avec MySQL 3.x.
-- NguyenDaiQuy

Tu veux dire que les requêtes du moteur de recherche de WikiNi fonctionnent bien ??? Est-ce que tu as une URL de test pour voir ? Ou tu peux éventuellement me la communiquer par mail si tu ne souhaites pas qu'elle soit publique. -- CharlesNepote

Ah, non, pour le moteur de recherche je ne l'ai pas encore essayé :) --NguyenDaiQuy

C'est justement là que le bas blaisse ! La doc de MySQL précise : "Full-text searches cannot be used with UCS-2 (but it works with UTF8 as of MySQL 4.1.1).". N'hésite pas à nous faire part de tes tests. -- CharlesNepote

Un gars m'avait fait la remarque que l'utf-8 ne contient que des caractères ASCII non accentués dans ses 256 premiers caractères (un truc d'anglophone encore !). Ainsi il n'est pas possible d'afficher correctement du texte français enregistré en iso-8859-1 ou iso-8859-15 si on le lit en tant que utf-8, il faut le convertir au préalable sur le serveur. Bien sûr, si tout le monde est en utf-8 dès le départ, pas de problème. Donc vraisemblablement, s'il fallait passer Wikini en utf-8 un jour, il faudrait aussi fournir un outil de conversion en utf-8 pour les base de données existantes... Le mieux me paraît donc de laisser à l'administrateur le soin de choisir son encodage en connaissance de cause. -- JmPhilippe
Il n'y a pas de commentaire sur cette page. [Afficher commentaires/formulaire]