Un avis sur la question

La mécanique existante

Traitement de l'interface

Dotclear ne fait appel à aucune librairie externe pour exécuter les traductions translations de texte. Contrairement à d'autres CMS qui utilisent GETTEXT par exemple.

La traduction translation des termes est assurée par la librairie l10n (fichier /inc/libs/lib.l10n.php ) et une série de fichiers de données situés dans les répertoires /l10n/... Une mécanique similaire est implantée dans le logiciel PlumesCMS (Je ne sais qui à copié sur l'autre; Et d'ailleurs c'est pas important.). Il est à noter que la version PlumeCMS de cette librairie comporte deux particularités : l'emplacement du stockage des fichiers de translation est indépendant de l'encodage des caractères, et la fonction de translation inclue la possibilité de lister les termes inconnus.

Le principe dépend de trois éléments :

• l'identification du langage souhaité

  Codé sur deux lettre minuscules (codification selon ISO639 : 'fr' pour le français, 'en' pour l'anglais, 'de' pour l'allemand, ...), eventuellement completées par l'indication du jeux de caractère ('fr' pour l'utilisation du français en ISO-8859-1, 'fr-utf8' pour l'utilisation du français en UTF8).

  Pour l'interface, cette information est déduite par combinaison de la constante dc_default_lang (modifiable par l'interface d'administration) et la constante dc_encoding définie lors de l'installation du script.

• La définition de correspondance de translation dans des fichiers .lang

  Ces fichiers sont classés dans une arborescence de répertoires sous /l10n/.. pour la translation des fonctions du core (partie principale), dans themes/(_nom_|default)/l10n/.. pour les translations des termes introduits par le thème (couche de présentation finale)

  • /l10n/fr/message.lang
  • /l10n/fr/date.lang
  • /l10n/fr-utf8/message.lang
  • /l10n/fr-utf8/date.lang
  • /l10n/en-utf8/message.lang
  • /l10n/en/date.lang
  • /l10n/en-utf8/message.lang
  • /l10n/en-utf8/date.lang
  • /themes/default/l10n/fr/main.lang
  • /themes/default/l10n/fr-utf8/main.lang
  • /themes/default/l10n/en-utf8/main.lang
  • /themes/default/l10n/en-utf8/main.lang

  La lecture de ces fichiers est déclarée dans le fichier /layout/prepend.php . Seuls les fichiers correspondants à l'identification du langage, définie plus haut par la combinaison des constantes dc_default_lang et dc_encoding, sont lus.

  D'autres fichiers .lang peuvent être lus par les plugin, ou par les scripts du thème.

  Les fichiers .lang sont des fichiers au format texte et utilisent une langue pivot (l'anglais). Chaque translation est codée sur trois lignes :

  • La première spécifie l'expression pivot à convertir. Cette expression est précédée d'un point-virgule.
  • La deuxième contient l'expression translatée avec le codage adéquat.
  • La dernière ligne sert de séparateur elle doit être vide.

  Ce format simple de fichier peut être généré avec un simple éditeur de texte.

  A noter : Pour augmenter les performances de la librairie, les fichiers .lang peuvent être convertis en scripts PHP. Un utilitaire permet d'effectuer cette conversion.

• L'utilisation de la fonction __('string') pour executer la translation du texte.

  Cette fonction doit être utilisée pour la génération de tous textes nécessitant une translation. Cela est déjà le cas pour les fonctions d'affichage intégrées aux core. Mais cela est rarement fait pour les thèmes récupérés sur le site de Dotclear. Les modifications à faire sont par exemple pour le menu d'accès rapide aux éléments, du type :

  Avant (ligne 50 du fichier template.php):

  [xml]
  Aller au contenu |
  Aller au menu |
  Aller à la recherche
  

  Après :

  [php]
   | ...
  

  Le fichier /themes/default/l10n/fr/main.lang pouvant contenir :

  ;Go to content
  Aller au contenu
  
  ;Go to menu
  Aller au menu
  
  ;Go to search
  Aller à la recherche
  
  etc...

  C'est cette manipulation qui a été faite pour le thème multilingue diffusé sur le wiki de Dotclear.

Traitement des contenus

Dotclear ne propose pas d'écrire un contenu traduit en plusieurs langues mais permet d'écrire des contenus dans plusieurs langues. Pour être plus clair, il est possible (et même souhaitable) de mentionner lors de la rédaction d'un billet la langue utilisée. Mais il n'est pas possible d'avoir pour un même billet (identifié de façon identique) plusieurs rédactions et traductions.

Un visiteur peut, s'il le désire, obtenir la liste des billets rédigés dans une langue. Ce choix est transmis via l'url (variable $lang dans les scripts).

Nous sommes donc dans la situation d'un site rédigé en plusieurs langues, mais pas d'un site traduit en plusieurs langues.

Comment faire pour avoir un site traduit en plusieurs langues

Plusieurs modifications sont a faire dans les scripts pour modifier le fonctionnement d'origine affin de simuler un site traduit en plusieurs langues.

Déjà il faut d'une manière ou d'une autre, pouvoir sélectionner la langue souhaitée par le visiteur. Cela peut être fait par un menu, ou par l'analyse des paramètres de connexion de l'utilisateur (complété par un menu, on ne sait jamais).

Le paramètre listant les langages supportés par le navigateur peut être une bonne source d'identification du souhait du visiteur. Attention dans ce cas il faut doubler ce mécanisme par l'affichage d'un menu. Ce menu est utile soit quand l'analyse des paramètres transmis par le navigateurs client n'est pas possible ou n'est pas fiable, mais aussi pour les pauvres robots d'indexation qui ne verraient qu'une partie du site sans ce menu.

Le choix validé peut être transmis par la suite par l'URL ou dans une variable session. La variable $lang peut être utilisée.

Attention : il faut pouvoir indiquer une langue par défaut utilisée dans le cas ou la langue demandée n'est pas disponible.

Une fois le langage déterminé il faut traiter à la fois le contenu et l'interface dans la même langue. Nous avons vu plus haut que Dotclear charge les fichiers translation du core dans le fichier /layout/prepend.php , c'est donc celui-ci qu'il faut modifier. (Attention toucher le CORE c'est pas bien). Pour prendre en compte le paramètre $lang si il est défini, à la place de la constante dc_default_lang

Les billets doivent être multipliés (un par traduction) et placés dans des catégories elles aussi multipliées (Pour avoir la traduction des libellés et de la description).

Quelques arrangements des liens dans le thème permettent d'achever cette simulation en spécifiant la langue systématiquement lors de l'appel des pages d'archive, de catégories, etc....

Pour que la recherche s'effectue elle aussi dans la base d'articles traduite dans la bonne langue, il faut ajouter le paramètre 'l' au formulaire.

Dernier obstacle, la génération des flux RSS et ATOM, mais là je n'ai pas encore fini les modifications des fichier rss.php et atom.php