Getting translation strings right/fr

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

Cette page contient quelques notes de base sur la façon de traduire des chaînes de caractère correctement dès le début , du point de vue des auteurs originaux (e.g. le plus souvent des programmeurs ).

"To get it right" in this context means that the translation strings have been prepared properly for easier further translation, and the original version adapted to the basic requirements for using them.

Although it is tried to be as language neutral as possible, there is in fact a slight bias towards English in particular. Feel free to extend or discard the ones which do not apply to your situation (and maybe add them to this page?).

Généralités

Pour éviter des problèmes , s'assurer simplement que les chaînes originales sont okay en premier lieu - il y a plusieurs raisons de faire ainsi :

• les chaines originales sont habituellement employées comme traduction par défaut, faire une mauvaise impression à l'utilisateur finale fait qu'il emploiera les chaines par défaut .
• une plus mauvaise fabrication encore fait que le traducteur travail inutilement plus dur, qui est responsable de donner l'information originale à une autre langue. Se rappeler juste que "Ordures dedans, Ordures dehors" principe qui s'applique parfaitement ici.

Essayer ainsi de s'assurer que votre l'épellation est correcte - employer un dictionnaire si vous êtes incertain.

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, essayer de mettre d'autres programmes dans la même situation et d'examiner leurs réponses. Les fichiers de littérature et d'aide sont également souvent une bonne ressource pour les termes spéciales ou des expressions, ou de modèle. Essayer d'être conforme dans le choix des expressions aussi. Par exemple les questions

Supprimer le dossier ?
Effacer le dossier ?
Enlever le dossier ?
Zap le dossier ?

all have a somewhat similar meaning, but when used interchangably for no apparent reason the one or other reader may start interpreting weird things into it. Especially translators are very prone to this error, since they often do not know the exact context of a particular message (e.g. information about the origin of the message) and may interpret simple word variations as indication of important differences, and will likely be tempted to choose uncommon (bad) translations.

Especially for error messages to the user: try to describe the problem itself in appropriate words. This is never the state of the program which led to the error message. This is only useful for the person debugging the program, but not for the user. Users will either simply shrug their shoulders and ignore it in the best case, or choose another program in the worst case because without a proper problem description the user will not be able to fix the problem and continue his work - all that only because the program was not able to give a proper problem description.

Give (easily) understandable descriptions. Do not try to impress your audience with foreign or very technical words only for telling that the current work has not yet been saved if not really necessary.

Especially try to avoid multiple negations within a single sentence in your wordings, they are nearly always harder to read than their non-negated counterparts. An example could be

This component can not be dropped on non-TControls.

which, in its non-negated form

This component can only be dropped on TControls.

is certainly easier to read and understand.

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

• Lazarus a un outil pour créer facilement des resourcestrings de chaine. Voir Faire des ResourceStrings

• Pour chaque section resourcestring FPC crée un fichier .rst, mais il n'y a aucun éditeur pour ces fichiers. Lazarre peut automatiquement créer un fichier .po du fichier .rst. Il y a beaucoup d'outils d'éditionde 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 chaines.

• 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 .

The format() function

To not only allow completely static strings in translations, you can use the format() method of the sysutils unit. It is able to replace placeholders within a given text by their actual value given as secondary parameter in a set. Example:

format('Tomorrow on %0:s there will be %1:s.', ['Sunday', 'sunshine']);

returns

Tomorrow on Sunday there will be sunshine.

In this case the %0:s is a placeholder for the first (index 0) argument in the set of actual values (Sunshine), and likewise %1:s. For an exact definition of the allowed placeholders and their syntax see the FPC reference manual.

Some guidelines for the usage of the format() function

• Try to use indexed placeholders in the original strings, even if they are optional. When used, they allow the translator to move the arguments easily within the sentence allowing him more natural expressions (and actually sometimes moving sentence parts is required to create proper sentences in that language).

• Never compose a sentence out of more than one string. Always use the format() method from the sysutils unit to construct the correct string using placeholders during runtime. Translators will usually not be able to reconstruct the whole sentence, therefore not able to give a good translation; only consider that there are often hundreds of such strings within a single translation database...

• Do not format using whitespaces. Simply move your label to the appropriate position in the first place. There may be problems with font changes, and seemingly superfluous spaces will be in danger of being trimmed by the translator.

Note: Since format() does not interpret escaped control characters (e.g. like C's "\n", "\t", etc) and GNU gettext for any reason being the translation system of choice (and the tools based on it not being able to interpret non-escaped control characters), it is required to programmatically insert linebreaks.In the current lazarus version, "\n" and "\t" in translated strings are replaced by newline and tab.

Converting the translation into the right character set

For example: converting a file from ISO-8859-1 to UTF-8:

 iconv --from-code=ISO-8859-1 --to-code=UTF-8 oldfile.po > newfile.po

Do not forget to change the line

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

to

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

English related

This section contains notes which particularly apply when using English as the base language for translations.

• Make sure to reserve enough space where the text is output: English is a language in which texts are almost always shorter (in characters) than their respective translations, so plan ahead by reserving enough space. Experience shows that very short strings of a few characters length often almost double in size; this difference decreases as the strings get longer.

• Avoid abbreviations in English; in addition to the fact that this shortens the already short strings even more, there are severe problems with e.g. languages that use ideographic characters where these abbreviations simply do not exist at all.

• Since this is often an issue: In English punctuation marks (full stop, comma, ...) are part of the previous words, or form some sort of words themselves if there is no previous word (in case of an enumeration). Especially after a semicolon there should always be a trailing space.

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

has horrible punctuation and therefore simply looks bad and is harder to read than usual. Consider that common line break algorithms break the line on whitespaces, possibly resulting in a single stop at the beginning of a line...

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

would probably be okay only considering punctuation.