Difference between revisions of "Getting translation strings right/fr"

From Lazarus wiki
m (Text replace - "delphi>" to "syntaxhighlight>")
m (Text replace - "Delphi>" to "syntaxhighlight>")
Line 67: Line 67:
 
Vous pouvez charger les fichiers .po à l'initialisation pour traduire les resourcestrings. Ajoutez ceci à votre fichier .lpr:
 
Vous pouvez charger les fichiers .po à l'initialisation pour traduire les resourcestrings. Ajoutez ceci à votre fichier .lpr:
  
<Delphi>
+
<syntaxhighlight>
 
...
 
...
 
uses
 
uses
Line 92: Line 92:
 
   Application.Run;
 
   Application.Run;
 
end.
 
end.
</Delphi>
+
</syntaxhighlight>
  
 
==== La fonction format() ====
 
==== La fonction format() ====

Revision as of 00:49, 25 March 2012

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, s'assurer en premier lieu que les chaînes originales sont correctes - il y a plusieurs raisons de faire ainsi :

  • les chaines originales sont habituellement employées comme traduction par défaut, et cela peut faire une mauvaise impression à l'utilisateur final s'il lui arrive de tomber dessus.
  • 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 correct - consultez un dictionnaire si vous n'êtes pas sûr.

Utilisez des expressions compréhensibles et d'utilisation courante, et de manière cohérente. Si vous n'êtes pas sûrs, 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 termes ou expressions particuliers. Essayer d'être cohérent dans le choix des expressions. Par exemple les questions

Supprimer le dossier ?
Effacer le dossier ?
Enlever le dossier ?
Zapper le dossier ?

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

Particulièrement pour des messages d'erreur à l'utilisateur : essayez de décrire le problème vous-mêmes 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, parce que sans description appropriée du problème l'utilisateur ne pourra pas le résoudre et continuer son travail - Tout cela parce que le programme n'en a pas donné une description appropriée.

Donnez une descriptions compréhensibles . N'essayez pas d'impressionner vos utilisateurs avec des mots étrangers ou très techniques, juste pour dire que le travail courant n'a pas encore été sauvé.

Essayer particulièrement d'éviter des négations multiples dans un message, Elles sont presque toujours plus difficile à 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.

est peut-être plus facile à lire et à comprendre.

Questions techniques

Dans cette section une vue d'ensemble courte des questions techniques, fondamentalement une vue d'ensemble des possibilités existants sont données. Ceux-ci incluent la construction de resourcestring, GNU gettext() et la fonction format().

Resourcestrings, et GNU gettext

Free Pascal a quelques fonctions de langue intégrées de manière a manipuler les Chaines. Il y a une section spéciale d'une unité appelée "resourcestring" ce qui a été spécifiquement présenté 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'utilités pour fournir des traductions a vos programmes, voir le manuel de FPC une fois de plus (prog.pdf, pg. 91ff ou ici).

Note: GNU gettext a une paille conceptuelle qui ne permet pas de tracer une chaine originale simple aux chaines multiples traduites, se rendre compte de cela.

ResourceStrings dans l'IDE

  • 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 exemple kbabel).

Pour permettre créer les fichiers .po pour un paquet faire :

 * Créer un sous-répertoire 'languages' (ou 'locale', ou autre chose)
 * Ouvrir le Composant. Puis options -> IDE Intégration -> Répertoire des fichiers .po placer à languages

La prochaine fois que vous compilez le paquet, l'IDE créera les fichiers .po. Note: Les fichiers .rst doivent appartenir aux unités de paquet. Autrement l'IDE ignore les fichiers autres .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.', ['Sunday', 'sunshine']);

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.