7.3. Localisation des modèles

Note

Utilisez un éditeur gérant UTF-8, comme Gedit, Kate ou Vim pour les systèmes GNU/Linux ou Notepad++ pour les systèmes Windows, et assurez-vous d'enregistrer les modèles en utilisant l'encodage UTF-8.

Les modèles contiennent du code et des chaînes localisables mélangés. La question qui se pose alors est : que faut-il localiser et ne pas localiser ? Voici quelques exemples pour vous aider à localiser les bonnes parties dans chaque fichier.

Au début de chaque fichier de modèle se trouvent les lignes suivantes :

[%# This Source Code Form is subject to the terms of the Mozilla Public
  # License, v. 2.0. If a copy of the MPL was not distributed with this
  # file, You can obtain one at http://mozilla.org/MPL/2.0/.
  #
  # This Source Code Form is "Incompatible With Secondary Licenses", as
  # defined by the Mozilla Public License, v. 2.0.
  #%]

NE traduisez PAS le texte entre [%# et #%]. Il s'agit d'un commentaire.

Voici quelques exemples de ce qui doit être localisé :

[% title = BLOCK %]Delete Component '[% comp.name FILTER html %]'
of Product '[% product.name FILTER html %]'
  [% END %]

[% PROCESS global/header.html.tmpl
  title = title
%]

<table border="1" cellpadding="4" cellspacing="0">
<tr bgcolor="#6666FF">
  <th valign="top" align="left">Field</th>
  <th valign="top" align="left">Value</th>
</tr>

En règle générale, ne jamais localiser les mots en lettres capitales entre [% et %] - ce sont des directives Template Toolkit. Voici la version localisée de l'exemple ci-dessus :

[% title = BLOCK %]Supprimer le composant « [% comp.name FILTER html %] »
du produit « [% product.name FILTER html %] »
  [% END %]

[% PROCESS global/header.html.tmpl
  title = title
%]

<table border="1" cellpadding="4" cellspacing="0">
<tr bgcolor="#6666FF">
  <th valign="top" align="left">Champ</th>
  <th valign="top" align="left">Valeur</th>
</tr>

Vous rencontrerez souvent du texte entre deux balises HTML ou une valuer d'attribut HTML qu'il faudra localiser :

<td valign="top">Description du produit :</td>

<td valign="top">[% IF product.disallow_new %]Oui[% ELSE %]Non[% END %]</td>

  <a title="Liste des [% terms.bugs %] pour le composant « [% comp.name FILTER html %] »"
     href="buglist.cgi?component=[% comp.name FILTER url_quote %]&product=
          [%- product.name FILTER url_quote %]">[% comp.bug_count %]</a>

Il y a aussi beaucoup de libellés de boutons. Cela ressemble à ceci :

  <input type="submit" id="create" value="Add">
  <input type="hidden" name="action" value="new">
  <input type="hidden" name='product' value="[% product.name FILTER html %]">
  <input type="hidden" name="token" value="[% token FILTER html %]">

Chaque fois que vous verrez ceci, la seule ligne qui doit être localisée est celle avec type="submit". NE PAS localiser les lignes avec type="hidden":

  <input type="submit" id="create" value="Ajouter">
  <input type="hidden" name="action" value="new">
  <input type="hidden" name='product' value="[% product.name FILTER html %]">
  <input type="hidden" name="token" value="[% token FILTER html %]">

Certains modèles sont un peu particuliers. /template/en/default/global/variables.none.tmpl en est un exemple. Ce fichier contient plusieurs termes qui seront substitués dans tous les fichiers de modèles. Il contient du code qui permettra à l'administrateur de spécifier facilement et de manière cohérente un terme alternatif utilisé dans son organisation pour bug et aussi pour Bugzilla (c'est-à-dire le nom du système). Chaque fois que vous verrez des expressions comme &terms.ABug ou &terms.bugs dans les modèles, elles seront remplacées dans l'interface utilisateur par les valeurs correspondantes contenues dans ce fichier.

Parce que ce sont des demandes de changement très courantes, vous voudrez certainement conserver cette flexibilité dans votre localisation. Cependant, vous aurez peut-être besoin d'adapter ce fonctionnement car votre langue pourrait ne pas avoir les équivalents exacts pour a et the.

[% terms = {
  "bug" => "bug",
  "Bug" => "Bug",
  "abug" => "a bug",
  "Abug" => "A bug",
  "ABug" => "A Bug",
  "bugs" => "bugs",
  "Bugs" => "Bugs",
  "zeroSearchResults" => "Zarro Boogs found",
  "bit" => "bit",
  "bits" => "bits",
  "Bugzilla" => "Bugzilla"
  }
%]

Vous devrez donc constituer un ensemble de correspondances pour votre langue, et chaque fois que vous parlerez de bogues dans l'interface utilisateur, il faudra utiliser l'équivalent de &terms.ABug ou &terms.bugs et ses déclinaisons.