Getting translation strings right/fr

From Lazarus wiki
Jump to navigationJump to search

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 si elles n'ont pas été bien choisies.
  • une encore plus mauvaise fabrication fait que le traducteur travail plus dur inutilement, il est responsable de donner l'information originale dans une autre langue. Se rappeler le principe "Garbage in, garbage out", qui s'applique parfaitement ici.

Essayer ainsi de vous assurer que votre orthographe est correct - consultez un dictionnaire si vous n'êtes pas sûr.

Expressions compréhensibles et bien connues d'utilisation pour une situation donnée que vous voulez décrire, d'une façon cohérente. Si vous êtes incertain si quelque chose est commun, 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 spéciaux. Essayer d'être conforme dans le choix des expressions aussi. Par exemple les questions

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

Ont toutes une signification semblable, mais une fois utilisé dans l'interchangeable pour aucune raison apparente l'un ou autre lecteur peut commencer à interpréter des choses étranges. Les traducteurs sont particulièrement enclins à cette erreur, puisqu'ils ne connaissent souvent pas le contexte exact d'un message et peuvent interpréter de simples variations de vocabulaire comme l'indication de différences importantes, et seront probablement tentés de choisir une mauvaise traduction.

Particulièrement pour des messages d'erreur à l'utilisateur : essayer de décrire le problème soi-même dans des mots appropriés. Ce n'est jamais l'état du programme qui a mené au message d'erreur. C'est seulement utile pour le programmeur, mais pas pour l'utilisateur. Les utilisateurs veulent l'un ou l'autre et haussent les épaules en les ignorant dans le meilleur cas, ou choisissent 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'a pas donné une description appropriée de problème.

Donner une descriptions compréhensibles . Ne pas essayer 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, Il est presque toujours plus difficile de les lire que leurs équivalents positifs. Exemple :

Ce composant ne peut pas être lâché sur des non-TControls .

sous sa forme non-niée

Ce composant peut seulement être lâché sur des TControls .

il est certainement plus facile de lire et de 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:

<Delphi> ... 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. </Delphi>

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: <delphi>

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

</delphi> 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"

Lié à l'anglais

Cette section contient les notes qui s'appliquent en particulier en utilisant l'anglais comme langue de basse pour des traductions .

  • Veiller à réserver assez d'espace où le texte est produit : L'anglais est une langue dans laquelle les textes sont presque toujours plus courts (en caractères) que leurs traductions respectives, ainsi prévoyez en réservant assez d'espace. L'expérience prouve que les chaînes très courtes de quelques caractères doublent de taille presque souvent; cette différence diminue pendant que les chaînes obtiennent plus longtemps.
  • Éviter les abréviations en anglais; en plus du fait que ceci raccourcit encore les chaînes déjà plus courtes, il y a des problèmes graves avec par exemple les langues qui emploient les caractères idéographiques où simplement ces abréviations n'existent pas du tout.
  • Puisque c'est souvent une question : Dans les signes de ponctuation anglaise (point, virgule, ...) font partie des mots précédents, ou former une sorte de mots elles-mêmes s'il n'y a aucun mot précédent (en cas d'énumération). Particulièrement après un point-virgule il devrait toujours y a un espace.
There was an error!Please check file settings,compiler settings,...to fix this issue.

Une ponctuation horrible et simplement un mauvais regard et il est plus difficile de lire que d'habitude. Considérer qu'un algorithmes sur une ligne commune sans espaces pour casser la ligne, probablement a pour résultat un arrêt simple au début d'une ligne...

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

c'est probablement mieux avec seulement de la ponctuation.