[
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.
- For example (may be not so correct) :
- $Message1 (fr) = "Un message";
- $Message1 (en_alternative) = "A text";
- <?php /* ###Message1### */ echo "A message"; ?>
- A parser should analyse this code and generate a php file in the language wanted (even in english if someone don't like the standard messages).
- For example :
- <?php echo "Un message"; ?>
- (The tag (###Message1###) used to mark up the message is in comment so the coder can use the non-generated code for his test.)
- (This system could also generate some datas where there is generic variables : for example, the name of the Wikki should be filled by the generation. If the name of the Wikki is "HelloWikki?" this code :
- <?php echo $WakkaName; ?> should become :
- <?php echo "HelloWikki"; ?>
- Pro: Speed of view for the end-user.
- Con: Produces many files (each file produce n files for n languages). (Is it really a problem ?)
- -- CharlesNepote
- I would suggest using a template system, like ETS (see: http://ets.sourceforge.net/). This might be seen as an extension to the idea of using stylesheets stated above.
- Pro: Strings and outfit could be made fit.
- Con: Another level of abstraction and for every change in the main (distributed) template, each and every other template has to be changed, too
- N.ickk (Just my 0.02 EUR :) )
- Instead of ETS, I suggest Smarty. It is much more feature rich therefore allowing the user to style every page EXACTLY to his/her liking. Template systems like ETS require certain amount of structure to be hardcoded in the PHP SourceCode? meaning that some aspects of the final page rendering cannot be customized by editing the template alone.
- [Je me permet de citer un courriel privé de David sur cette question -- CharlesNepote]
- Un truc facile à adapter, par exemple : http://lhebergeur.net/perl/script.cgi?script=./rempc.pl.
- Je propose que toutes les nouvelles traductions adoptent ce format et que l'on reprenne les modifications existantes.
- La premiere étape est la création d'un repertoire locale/fr/messages.txt dans l'arborescence CVS, qui ne sera pas distribué, mais qui permettra de generer les différentes versions de wikini.
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 :
- Gettext, très utilisé dans le projet GNU (utilisé par PhpWiki semble-t-il)
- solution propriétaire
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?
- C'est en effet plutôt sympa comme solution, à regarder ! ;-) -- NicolasHoizey
- Et on le voit où ce système ??? Il y a de la doc. ? Une explication du fonctionnement technique ? -- CharlesNepote
- Il y a plusieurs aspects:
- les outils que les traducteurs utilisent pour coordonner leur travail (je pense que c'est ce à quoi FiL? fait allusion): le point de départ est là: l'espace des traducteurs (il faut s'inscrire à l'espace privé pour voir le fonctionnement -c'est ouvert). Le download de . Je ne sais pas s'il y a une documentation plus précise...
- les codes qui permettent l'internationalisation en live de spip sont dans spip: ici pour downloader et ici pour une consultation en ligne. LE fichier le plus intéressant est ecrire/inc_lang.php3. Dites-moi si ça vaut la peine de faire une explication plus détaillée des autres fichiers concernés... D'une part, l'interface privée de spip est accessible en plusieurs langues, d'autre part, les pages publiques du site peuvent être internationalisées (ou localisées, je ne sais pas). Le meilleur exemple est le . En ce qui concerne l'utilisation finale des langues dans spip (pour le webmestre et les rédacteurs d'un spip), il y a quelques articles (dans le désordre): Internationaliser les squelettes, , Les langues de SPIP et SPIP 1.7. Je ne sais pas s'il y a plus de documentation pour les développeurs. J'imagine qu'on trouve pas mal d'infos dans les archives des listes. --AureLie
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.)
- bon ça va le faire sur la navigation déjà ? ce qui serait bien : en fonction de la langue du navigateur (au pire l'anglais) l'inscription utilisateur permet d'afficher la navigation dans la bonne langue (charge à l'administrateur fonctionnel de créer les bonnes pages...) et un drapeau (=changement de langue utilisateur) ce qui permet de changer le cookie pour prendre en compte la navigation localisée ; après le contenu existe ou n'existe pas (dans ce cas afficher la langue par défaut de l'utilisateur ou de l'administrateur), s'il existe : chaque langue disponible apparaît pour faciliter le travail des traducteurs comme je l'ai fait sur FaqEagle pour donner accès à un contenu localisé -- BenoitAudouard 20040324
I. -- Choix des langues à l'installation
- - l'utilisateur transfère en ftp l'archive décompressé de WakkaWiki sur son site web
- - l'utilisateur ouvre la page d'accueil dans son navigateur
- - le système détecte que c'est la première consultation du site
- - le système propose à l'utilisateur de choisir une langue pour la configuration de son site
- - l'utilisateur choisi une langue
- - 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
- - l'utilisateur renseigne les différents paramètres dont les langues disponibles et la langue par défaut
- - [Cas alternatif] l'utilisateur ne renseigne pas tous les paramètres (dont les langues disponibles et la langue par défaut)
- - le système signale à l'utilisateur qu'il n'a pas tout renseigné [retour à l'avant dernière action]
- - le système enregistre la configuration
II. -- Choix de la langue par défaut pour un utilisateur
- - l'utilisateur ouvre sa page de configuration ParametresUtilisateurs?
- - le système détecte toutes les langues disponibles pour l'interface du site
- - 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é)
- - l'utilisateur renseigne ces paramètres dont la langue utilisée pour l'interface du site
- - [Cas alternatif] l'utilisateur ne renseigne pas la langue utilisée pour l'interface du site
III. -- Consultation du site
- - l'utilisateur demande une page du site
- - le système reconnaît l'utilisateur
- - [Cas alternatif] le système ne reconnaît pas l'utilisateur
- - 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)
- - le système retrouve la langue par défaut de l'utilisateur
- - [Cas alternatif] le système ne trouve pas de langue par défaut de l'utilisateur
- - 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)
- - 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 :
- - l'utilisateur demande une page du site
- - L'utilisateur a choisi une langue
- - [Cas alternatif] l'utilisateur n'a pas choisi de langue
- - le système considère que la langue de l'utilisateur est la langue par défaut
- - Le système affiche la page demandée, l'entete de la page s'affiche dans la langue de l'utilisateur.
- - [Cas alternatif] la langue choisie par l'utilisateur n'est pas définie dans le système
- - 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).
- les chaînes qui ont une portée globale sont définies sous la forme de constantes dans wakka.php
- les autres chaines sont traduites sous forme de constantes à l'intérieur de chaque fichier (ainsi, par exemple, un utilisateur qui développe une nouvelle page "action", peut réaliser lui-même les traductions)
- les traductions sont données en début de fichier
- la traduction fonctionne en dynamique
- la traduction peut se faire petit à petit
- pas besoin d'outils supplémentaire
- rien n'empêche de développer ultérieurement un outil qui prenne chaque fichier et remplace les constantes par des chaînes
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", "Éditez cette page");
define ("txt_clic_to_see_modifications", "Cliquez pour voir les dernières modifications sur cette page");
define ("txt_owner", "Proprié");
define ("txt_edit_acls", "É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 :
- Le code de chaque programme va grossir, ok on peut le nettoyer ensuite, mais ceux qui vont intervenir dessus vont avoir du mal à le comprendre et à le maintenir.
- Selon le contexte, il va avoir des dérives : certains vont coder des switch, d'autres autres choses, il va falloir passer derrière pour contrôler.
- Des dérives dans les traductions sont égalements possible, puisqu'il n'y a pas de point central : chaines traduites plusieurs fois, des traductions différentes.
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 :
- <meta http-equiv="Content-Type" content="text/html; charset=utf-8">.
- Les caractères autres que ceux de la norme ISO-8859-1 sont pris en compte en lecture et en édition
- Les caractères accentués préalablement entrés (par exemple : éàè) sont alors remplacés bizarement par des points d'interrogation.
- Les recherches en texte intégral (via le champ "Recherche") ne fonctionnent pas sur les termes contenant des caractères autres que ceux de la norme ISO-8859-1
- Les recherches en texte intégral (via le champ "Recherche") fonctionnent sur les termes contenant les caractères de la norme ISO-8859-1 (la norme UTF-8 contient ISO-8859-1)
- Les mots Wiki (par exemple CharlesNepote) ne fonctionnent pas avec les caractères autres que ceux de la norme ISO-8859-1
- Tout cela fonctionne et a été testé à l'identique au moins sur : Mozilla 1.1 Win, Internet Explorer 5.0 Win, Netscape 4.7 Win.
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.)
- comment produit-on des contenus en UTF-8 ?
- quelles applications produisent des contenus en UTF-8 ? (Jext, Notepad ?)
- comment lit-on des contenus en UTF-8 ?
--
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