Getting translation strings right/fr

│ Deutsch (de) │ English (en) │ español (es) │ français (fr) │ 日本語 (ja) │ русский (ru) │

Cette page contient quelques notes sur la manière d'avoir dès le début les chaînes à traduire correctes, à l'usage de leurs auteurs originaux (le plus souvent des programmeurs).

Dans ce contexte, cela signifie que les chaînes à traduire ont été prévues pour une traduction facile. et que la version originale est adaptée aux exigences de base pour leur usage.

Bien que cette page essaie d'être neutre par rapport au langage initial, elle est en fait légèrement orientée vers l'anglais. Vous êtes libre de compléter, ou d'ignorer ce qui ne s'applique pas à votre situation, et éventuellement de mettre à jour la page.

Généralités

Pour éviter des problèmes, assurez-vous en premier lieu que les chaînes originales sont correctes. Il y a plusieurs raisons de les vérifier :

• Les chaînes originales sont habituellement employées comme traduction par défaut, et cela peut donner une mauvaise impression à l'utilisateur final s'il lui arrive de tomber sur des chaînes fautives.
• Au pire, cela rendra inutilement difficile le travail du traducteur. Se rappeler le principe "Garbage in, garbage out", qui s'applique parfaitement ici.

Essayez donc de vous assurer que votre orthographe est correcte. Consultez un dictionnaire si vous n'êtes pas sûr de vos compétences en la matière.

Utilisez des expressions compréhensibles, d'utilisation courante et de manière cohérente. Si vous avez des doutes, essayez de mettre d'autres programmes dans la même situation et d'examiner leurs réponses. Les fichiers de documentation et d'aide sont souvent un bon modèle pour les expressions ou termes particuliers. Essayez d'être cohérent dans le choix des expressions. Par exemple, les questions :

Supprimer le dossier ?
Effacer le dossier ?
Enlever le dossier ?
Retirer le dossier ?

ont toutes une signification semblable, mais si elles sont échangées sans raison apparente, le lecteur peut en faire des interprétations étranges. Les traducteurs sont particulièrement enclins à cette erreur, puisqu'ils ne connaissent souvent pas le contexte exact d'un message : ils peuvent interpréter de simples variations de vocabulaire comme l'indication de différences importantes, et par conséquent être tentés de choisir une mauvaise traduction.

Particulièrement pour des messages d'erreur destinés à l'utilisateur, essayez de décrire le problème avec les mots appropriés. Ce n'est jamais l'état du programme qui a mené au message d'erreur (ceci est seulement utile au programmeur, mais pas à l'utilisateur). Sinon, les utilisateurs vont soit hausser les épaules en ignorant les messages (dans le meilleur cas), soit choisir un autre programme (dans le pire des cas) : l'utilisateur ne pourra pas résoudre le problème et continuer son travail, et tout cela parce que le programme n'en aura pas donné une description appropriée.

Donnez une description compréhensible. N'essayez pas d'impressionner vos utilisateurs avec des mots étrangers ou très techniques, juste pour dire que le travail en cours n'a pas encore été enregistré.

Essayez particulièrement d'éviter des négations multiples dans un message : elles sont presque toujours plus difficiles à lire que leurs équivalents positifs. Exemple :

Ce composant ne peut pas être déposé sur des contrôles non visuels.

Sous sa forme non-niée :

Ce composant peut seulement être déposé sur des contrôles visuels.

La dernière formulation est sans doute plus facile à lire et à comprendre.

Questions techniques

Dans cette section, nous donnons une vue d'ensemble des questions techniques, tout particulièrement des possibilités existantes. Celles-ci incluent la construction de resourcestring, GNU gettext() et la fonction format().

Resourcestrings, et GNU gettext

Free Pascal dispose de quelques fonctions de langue intégrées de manière à manipuler les chaînes. Il y a une section spéciale d'une unité appelée "resourcestring" qui a été spécifiquement étudiée pour cette raison. Voir la section appropriée du manuel de FPC (prog.pdf, pg. 89ff ou ici ) pour les détails.

GNU gettext est un ensemble spécial d'utilitaires pour fournir des traductions de vos programmes : voir le manuel de FPC une fois de plus (prog.pdf, pg. 91ff ou ici).

Note: GNU gettext a une faille conceptuelle qui ne permet pas de faire correspondre une chaîne originale simple à de multiples chaînes traduites.

ResourceStrings dans l'IDE

• Lazarus a un outil pour créer facilement des chaînes de ressources. Voir Faire des ResourceStrings

• Pour chaque section resourcestring, FPC crée un fichier .rst, mais il n'y a aucun éditeur pour ces fichiers. Lazarus peut automatiquement créer un fichier .po du fichier .rst. Il y a beaucoup d'outils d'édition de fichier .po (par exemples: kbabel et poEdit).

Pour créer les fichiers .po pour un paquet, opérez ainsi :

 * Créez un sous-répertoire languages (ou locale, ou autre chose) ;
 * Ouvrez le composant. Puis Options -> Intégration de l'EDI -> Répertoire des fichiers .po que vous fixerez à languages (ou tout répertoire adapté).

La prochaine fois que vous compilerez le paquet, l'EDI créera les fichiers .po. Note: Les fichiers .rst doivent appartenir aux unités de paquet. Sinon, l'EDI ignore les autres fichiers .rst.

Le même fonctionnement pour des projets. Le répertoire est placé dans projet -> Options du Projet -> i18n -> Répertoire des fichiers .po.

• Pour créer une traduction allemande : copier le fichier unit1.po vers unit1.de.po. Employer alors un éditeur de texte ou un éditeur de fichier .po pour traduire toutes les chaînes.

• L'IDE chargera automatiquement des fichiers .po pour les composants installés, s'ils existe. Par exemple voir lazarus/components/projecttemplates/languages/.

• ToDo: Implémenter et documenter la mise à jour du fichier .po traduit quand de nouvelle resourcestrings sont ajoutés .

• ToDo: Implémenter et documenter rassemblement de tous les fichiers .po des paquets statiquement liés .

ResourceStrings dans votre application

Vous pouvez charger les fichiers .po à l'initialisation pour traduire les resourcestrings. Ajoutez ceci à votre fichier .lpr:

...
uses
  ...
  Translations, gettext;

procedure TranslateLCL;
var
  PODirectory, Lang, FallbackLang: String;
begin
  PODirectory:='/path/to/lazarus/lcl/languages/';
  Lang:='';
  FallbackLang:='';
  GetLanguageIDs(Lang,FallbackLang); // in unit gettext
  Translations.TranslateUnitResourceStrings('LCLStrConsts',
                      PODirectory+'lclstrconsts.%s.po',Lang,FallbackLang);
  // ... add here a TranslateUnitResourceStrings call for every po file ...
end;

begin
  TranslateLCL;
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

La fonction format()

Pour ne pas utiliser des chaînes complètement statiques dans les traductions, vous pouvez employer la méthode format() dans l'unité sysutils. Il peut remplacer des paramètres donnés dans un texte par leur valeur réelle donnée comme paramètre secondaire dans un ensemble. Exemple:

 format('Demain %0:s il y aura du %1:s.', ['dimanche', 'soleil']);

restituant Demain dimanche il y aura du soleil. Dans ce cas-ci %0:s est un paramètre pour le premier (index 0) argument dans l'ensemble de valeurs réelles (Soleil), et de même %1:s. Pour une définition exacte des paramètres permis et leur syntaxe voir le manuel de référence de FPC.

Quelques directives pour l'utilisation de la fonction format()

• Essayer d'employer des paramètres classés dans les chaînes originales, même si ils sont facultatifs. Une fois utilisé, ils permettent au traducteur de déplacer les paramètres facilement dans la phrase lui permettant des expressions plus normales(en déplaçant réellement les paramètres dans la phrase vous pouvez créer des phrases appropriées dans cette langue).

• Ne jamais composer une phrase de plus d'une chaine. Employer toujours la méthode format() à partir de l'unité sysutils pour construire la chaine correcte en utilisant des paramètres pendant le temps d'exécution. Les traducteurs ne pourront habituellement pas reconstruire la phrase entière, donc incapable de donner une bonne traduction; considérer seulement qu'il y a souvent des centaines de chaînes dans une base de données de traduction...

• Ne pas composer en utilisant des espaces. Déplacer simplement votre Label à la position appropriée en premier lieu. Il peut y avoir des problèmes avec des changements de police, et les espaces apparemment superflus seront difficile à équilibré par le traducteur.

Note: Puisque format() n'interprète pas les caractères d'échappements (par exemple C's "\n", "\t", etc) et GNU gettext pour toute ses raisons étant le système de traduction de choix (et ses outils ne pouvant pas interpréter non plus les caractères d'échappements), on exige aux programmeurs d'insérer les coupures de ligne.Dans la version courante de Lazarus, "\n" et "\t" dans les chaines traduites sont remplacés par le caractère nouvelle ligne et tabulation.

Convertir le jeu de caractères d'une traduction

Par exemple : convertir un fichier de ISO-8859-1 à UTF-8:

 iconv --from-code=ISO-8859-1 --to-code=UTF-8 ancienfichier.po > nouveaufichier.po

Ne pas oublier de changer la ligne

 "Content-Type: text/plain; charset=ISO-8859-1\n"

par

 "Content-Type: text/plain; charset=UTF8\n"

Particularités liées à l'anglais

Cette section contient les notes qui s'appliquent en particulier quand l'anglais est la langue originale :

• Veillez à réserver assez d'espace pour les textes : en anglais les textes sont presque toujours plus courts (en caractères) que leurs traductions. Prévoyez donc assez d'espace. L'expérience prouve que les chaînes très courtes (quelques caractères) doublent souvent de taille; ce rapport diminue pour les chaînes plus longues.

• Évitez les abréviations en anglais; en plus du fait que ceci raccourcit encore des chaînes déjà courtes, il y a des problèmes graves avec, par exemple, les langues qui emploient les caractères idéographiques, où ces abréviations n'existent pas.

• Puisque c'est souvent une question : Dans les signes de ponctuation anglaise (point, virgule, ...) font partie des mots précédents. Particulièrement après un point-virgule il devrait toujours y avoir un espace. La lecture est plus difficile quand la ponctuation est erronée.

There was an error!Please check file settings,compiler settings,...to fix this issue.

Considérez aussi que les algorithmes prévus pour couper les lignes trop longue provoqueront probablement une coupure arbitraire s'il n'y a pas d'espaces.

There was an error! Please check file settings, compiler settings, ... to fix this issue.

Avec des espaces le résultat sera meilleur.