Wikini:SystemeDeTraductionProprietaire1

Tous les textes à traduire sont placés :

entre balises /**/ et /*/*/ lorsqu'ils sont dans du code PHP
entre balises  et  lorsqu'ils sont dans du code HTML

Un outil parse le fichier ainsi balisé et génére toutes les balises à traduire.
Les balises sont traduites et un autre outil permet alors la génération du fichier Php traduit.

Exemple avec /actions/footer.php


<div class="footer">
<?php echo  $this->FormOpen("", /**/"RechercheTexte"/*/*/, "get");
    echo  ($this->HasAccess("write") ? "<a href=\"".$this->href("edit")."\" title=\""./**/"Cliquez pour editer cette page"/*/*/.".\">"./**/"Editer cette page"/*/*/."</a> ::\n" : "");
    echo  $this->GetPageTime() ? "<a href=\"".$this->href("revisions")."\" title=\""./**/"Cliquez pour voir les dernières modifications sur cette page"/*/*/.".\">".$this->GetPageTime()."</a> ::\n" : "";

        // if this page exists
        if ($this->page)
        {
            // if owner is current user
            if ($this->UserIsOwner())
            {
                print(/**/"Propriétaire"/*/*/." :: <a href=\"".$this->href("acls")."\">"./**/"Editer 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>

J'aime beaucoup cette solution qui me paraît très bien pour générer une version traduite du code au moment de l'installation. Grâce à cela il n'y a aucun impact sur les performances (ce n'est pas comme si la traduction étaient faite dynamiquement en fonction du visiteur).
Je propose plutôt les balises /*$*/ et , avec le même tag pour la fermeture que pour l'ouverture. De toutes façon il ne serait pas logique de pouvoir permettre d'imbriquer les textes à traduire.
J'ai commencé à coder une classe PHP qui lit un fichier et fait ces remplacements. Je cherche maintenant à générer le le code traduit à partir des modèles au moment de l'installation (setup).
-- 2004-03-03 OlivierMengu?é

J'avoue que c'est également la solution que je préfère (ce sujet à déja fait beaucoup couler d'encre virtuelle dans WikiNi), si tu peux avancer sur ce sujet, je te soutiens, après il faut reussir à "vendre" l'idée à tous le monde ;-) !
-- DavidDelon

Je lis: "Un outil parse le fichier ainsi balisé et génére toutes les balises à traduire. Les balises sont traduites et un autre outil permet alors la génération du fichier Php traduit". "générer une version traduite du code au moment de l'installation". "J'ai commencé à coder une classe PHP qui lit un fichier et fait ces remplacements. Je cherche maintenant à générer le le code traduit à partir des modèles au moment de l'installation (setup)."
Si je comprends bien, on crée des fichiers php dans chaque langue. Donc, en trois langues, rien que pour les actions, on a 21x3=63 fichiers générés... <partie à effacer>Puis, un francophone améliore "listpages.php": il lui faut transposer ses modifs dans 2 fichiers pour adapter l'action dans les 2 autres langues. Kesskisspass quand on aura 12 langues? Kesskisspass s'il oublie ou s'en fout: plusieurs versions de WikiNi, chaque langue avec ses fonctionnalités? A moins que ce ne soient les développeurs de WikiNi qui ne doivent se charger de ce boulot! Et tout le monde qui doit utiliser l'outil propriétaire? [Non, non ! en fait, tout le monde modifie une seule version de WikiNi, qui est la version "générique" avec les tags de remplacement de chaîne. Si aucune traduction n'est faite, c'est le fichier de chaines par défaut qui est utilisé. -- CharlesNepote]</partie à effacer> Dites-moi si je me plante, mais j'ai l'impression qu'on sacrifie la cohérence de WikiNi pour des performances d'affichage pour le visiteur qui, en l'état actuel de mes tests sur http://quilombo.collectifs.net (je sais, c'est facile, le site est vide!), ne sont pas démontrées. Je développe (cf. AureLie) une solution, certes bancale, mais qui évite ce que je vois comme un écueil. En fait, je suis en demande de plus d'explications quant aux performances. Je vois le système de fichiers de langues fonctionner dans spip, et je n'ai pas l'impression que cela entraîne des lenteurs... Mais c'est sûr qu'il n'y a pas, comme dans wiki, génération de versions pour chaque page... --AureLie

En fait, c'est plus simple que ça :

Il existe une version "générique" de WikiNi (= la version actuelle)
Dans cette version "générique", on balise les textes à traduire, par exemple : echo(/**/"Propriétaire : "/*/*/.$this->Format($owner));
Dans un fichier (ou plusieurs fichiers) sont saisies les traductions, exemple :
- Anglais : Propriétaire --> Owner
- Allemand : Propriétaire --> Besitzer
- Français : Propriétaire --> Propriétaire
A partir de ces fichiers sont générés les wikini traduits.
On peut ensuite distribuer wikini.fr.tar.gz, wikini.de.tar.gz etc... Pour une utilisation conjointe de plusieurs langues, une idée serait de faire plusieurs installation utilisant les mêmes fichiers de paramêtre : http://www.wikini.net/fr/wakka.php et http://www.wikini.net/de/wakka.php par exemple, si on veut faire simple.

Quant aux performances ... Spip est un logiciel que j'admire, mais il est quasiment impossible de le faire fonctionner chez un hebergeur surchargé comme free par exemple, même chose pour phpwiki, qui propose également le multilinguisme. A mes yeux c'est important que Wikini puisse fonctionner partout, c'est même une des raisons qui a motivé mon implication initiale dans ce projet.
-- DavidDelon

Je ne suis pas sûr que la diffusion de versions localisées soit la meilleure solution. Je voyais plutôt la diffusion d'une seule version, le WikiNi générique, les localisation étant générées à l'installation. Cela permet à l'administrateur technique, s'il le souhaite, de hacker la version générique et de générer lui-même ces fichiers localisés. J'ai oublié de mentionner un point important de mon système : la version générique est fonctionnelle et ne sert pas seulement à la génération, ce qui fait que les développeurs peuvent développer sur la version générique et tester en temps réel leurs modifications... une fois que leurs développements sont stabilisés ils peuvent générer les fichiers localisés pour de meilleures performances. Mieux, il est possible de générer des fichiers dégraissés c'est-à-dire : sans les commentaires PHP ; en supprimant les espaces et les retours de lignes inutiles ; en renommant les variables avec des noms les plus court possible "a", "b", "c", etc. : ces techniques de dégraissage permettent de faire perdre entre 15 et 40 % de taille de fichier et améliorent légèrement les performances. L'inconvénient de ce système c'est qu'il complexifie un peu la recette de WikiNi, il faut générer les fichiers pour chaque langue... -- CharlesNepote

Pour la diffusion de wikini il y a donc plusieurs stratégies :

un wikini qui contient tout et qui est parametré à l'installation :
- Avantage : un seul source
- Inconvénient : un gros source (ca me rappelle la stratégie de certains logiciels propriétaires)
plusieurs distributions, pré-générées
- Avantage : un petit source, rapide
- Inconvénient : plein de sources
Entre les deux (solution ci dessus proposée par CharlesNepote)
- Avantage : les deux avantages ci dessus
- Inconvénient : difficulté à lire le code + inconvénients des stratégies ci dessus ?

OK, je comprends mieux. Quant aux performances de SPIP, j'avais "oublié" qu'il y a un système de cache performant qui fait que les chaînes ne sont pas traduites lors de chaque affichage mais uniquement lors du calcul de la page pour la mise en cache... ça change tout. Alors comment je dois faire pour participer à ce développement? --AureLie

Il faut que tu contacte OlivierMengu?é... je pense qu'il lira ces pages... -- CharlesNepote

un petit grain de sel

J'ai l'impression que vous cherchez à construire des wiki nationaux. En tant qu'utilisateur-webmestre et utilisateur tout court, je vois cela comme ça : un fichier Wikini source modifié ou non qui est proposé à des utilisateurs de toute langue. Chacun fait savoir sa langue (ou son système se charge de nous le dire). Tous les dialogues lui sont proposés dans cette langue (ou une par défaut). Sur hypercard, j'avais résolu en faisant appel systématique à une fonction. Autant de dialogues, autant d'appel à la fonction ! ;-( Autre possibilité : le choix de la langue fait en une fois changer la valeur des constantes que chaque dialogue appelle. Une sorte de langue.config.php que l'usersettings appelerait en utilisant un fichier texte par langue. Nous respectons alors la modularité de wiki !
Question : Chaque nouvelle action devrait modifier ce fichier ???? Dans ce cas, je bricole : chaque créateur d'action définit ses propres constantes de dialogue, et inclut en début d'action, une fonction de traduction. Un seul fichier avec traductions incorporée. ceci évite la multiplicité des fichiers.--FidelioEspoir

autre grain de sel

Vous connaissez gettext ? C'est un outil d'internationalisation des applications qui concerne un très grand nombre de langages informatiques très utilisé sous Linux, donc pourquoi pas PHP ? (mais j'ai pas regardé !) Le principe est excessivement simple. Avant dans le code on avait des chaînes de caractères de langue fixe :
Text = "my tailor is rich";
Lorsque l'application est à distribuer dans plusieurs langues, avec gettext, on ajoute l'appel à une fonction dont le nom est simplement le caractère souligné. On a donc après internationalisation (!) :
Text = _("my tailor is rich");
Ensuite il existe tout un tas d'outils pour analyser des séries de scripts, extraire les chaînes à traduire, comparer ces extractions avec d'anciennes extractions pour ne pas faire 10 fois le travail, etc. Évidemment il y a des interfaces utilisateurs pour réaliser les traductions... Bref, pourquoi pas gettext ? -- JmPhilippe