1. Introduction

Ce chapitre explique les objectifs recherchés par la création de GNU gettext et du Projet de Traduction Libre (ndt free Translation Project). Ensuite il explique quelques concepts généraux autour du Support des Langues Nationales et la position des traductions de message en regard d'autres aspects des variations culturelles telle qu'elles s'appliquent pour les programmes. Il étudie aussi ces fichiers qui transmettent les traductions. Il explique comment les divers outils interagissent dans la génération initiale de ces fichiers et ensuite comment le cycle de maintenance doit normalement prendre place.

Dans ce manuel, nous utilisons le singulier masculin quand nous parlons du programmeur ou du mainteneur, nous utilisons le singulier féminain quand nous parlons du traducteur (ndt, pardon de la traductrice :-) et nous utilisons le pluriel quand nous parlons des installateurs ou des utilisateurs finaux des programmes traduits. Ceci est fait uniquement pour le souci pratique de clarifier la documentation. Il ne s'agit en aucun cas de signifier que certains rôles seraient plus appropriés pour les hommes ou pour les femmes. D'autres parts, comme vous l'aurez peut être déjà deviné, la suite d'utilitaires GNU gettext a pour objectif d'être utile pour toute personne utilisant un ordinateur, quelque soit son sexe, son origine, sa religion ou sa nationalité !

Merci d'envoyer les suggestions ou corrections (ndt en anglais) à :

Internet address:
    bug-gnu-gettext@gnu.org

Merci d'inclure le numéro d'édition du manuel et de mise à jour dans vos messages.

1.1 L'objectif de la suite d'utilitaire GNU gettext

Habituellement, les programmes sont écrits et documentés en anglais et l'anglais est utilisé pour inter-agir avec l'utilisateur au moment de l'exécution.Ceci n'est pas seulement vrai pour les logiciels GNU, mais aussi pour un grand nombre de logiciels libres ou propriétaires. L'utilisation d'un language commun est assez pratique pour la communication entre les développeurs, les mainteneurs de programme et les utilisateurs de tous les pays. Mais d'un autre côté, la plupart des gens sont moins à l'aise avec l'anglais qu'aver leur propre langue maternelle et préfèreraient utiliser leur langue maternelle pour leur travail du jour-le-jour autant que faire ce peut. Beaucoup adoreraient simplement de voir leur écran d'ordinateur montrer un peu moins d'anglais et beaucoup plus de leur propre langue.

Cependant pour beaucoup de personnes ce rêve peut paraître tant hors de portée, qu'elles ne pensent même pas qu'il soit utile de passer du temps à y réfléchir.Elles ne pensent qu'en aucune manière ce rêve puisse un jour se réaliser.Mais cependant quelques unes n'ont pas perdu espoir et se sont organisées.Le projet de traduction (ndt Translation Project) est une formalisation de cet espoir en une structure pour y travailler, qui a une bonne chance de nous rapprocher tous de l'achèvement d'un véritable jeu de programmmes multilingues.

GNU gettext is an important step for the Translation Project, as it is an asset on which we may build many other steps. This package offers to programmers, translators and even users, a well integrated set of tools and documentation. Specifically, the GNU gettext utilities are a set of tools that provides a framework within which other free packages may produce multi-lingual messages. These tools include

• Un jeu de conventions définissant comment les programmes doivent être écrits pour supporter des catalogues de messages.
• Une orgainisation de répertoire et de noms de fichiers pour les catalogues de messages eux-même;
• Une bibliothèque supportant la récupération des messages traduits pendant le temps d'exécution.
• Quelques programmes indépendants pour maquiller de différentes façons les jeux de chaînes à traduire ou de chaîne déjà traduites.
• Une bibliothèque supportant l'analyse syntaxique et la création de fichiers contenant les messages traduits.
• Un mode dédié pour Emacs(1), qui aide à préparer ces jeux et à les maintenir à jour.

GNU gettext est conçu pour minimiser l'impact de l'internationalisation des programmes sources, gardant cet impact aussi discret que possible. L'internationalisation a de meilleures chances de succès si elle reste légère, ou du moins semble l'être quand on regarde les codes sources.

La Projet de Traduction utilise aussi la distribution GNU gettex comme un vecteur pour documenter sa structure et ses méthodes. Ceci va au delà de la stricte technicité de documenté proprement GNU gettext. Ce faisant, les traducteurs trouveront à un endoit unique, autant que possible, tout ce qu'ils doivent savoir pour faire correctement leur tâche de traduction. Bien qu'en fait, cette documentation supplémentaire puisse aussi aider les programmeurs comme les utilisateurs curieux à comprendre comment GNU gettext est lié au reste du Projet de Traduction et d'avoir par conséquent un aperçu de l'image d'ensemble.

1.2 I18n, L10n et autres

Les longs mots apparaissent sans cesse quand nous parlons des diverses langues dans les programmes et ces mots ont des significations précises, qu'il convient d'expliquer ici une bonne fois pour toutes dans ce documents. Ces mots sont internationalisation et localisation. Beaucoup de personnes, lasses de les écrire et ré-écrire, ont pris l'habitude de les remplacer par i18n et l10n, citant la première la première et la dernière lettre de chacun de ces mots et remplaçant les lettres intermédiaires par un nombre ne vous donnant que le nombre de lettres qu'il devrait y avoir. Mais dans ce manuel, pour plus de clareté, nous écrirons patiemment les noms en entiers à chaque fois…

Par internationalisation, on réfère à l'opération par laquelle un programme, ou un ensemble de programmes groupés un progiciel, tient compte des multiples langues et est capable de les supporter. C'est un procédé de généralisation, par lequel un programme n'est plus contraint d'utiliser des phrases uniquement en anglais ainsi que des habitudes spécifiquement anglaises, mais fait à la place le même chose de manière générique.Les développeurs de programmes peuvent utiliser plusieures techniques pour internationaliser leurs programmes. Quelques unes d'entre elles ont été standardisées. GNU gettext offre l'un de ces standards. Voir la section Le point de vue du programmeur.

Par localisation on signifie l'opération par laquelle, dans un ensemble de programmes déjà internationalisés, on donne au programme toute l'information nécessaire pour qu'il puisse s'adapter pour gérer son entrée et sa sortie d'une façon qui soit correcte pour la langue et les habitudes culturelles choisies. C'est un procédé de particularisation, par lequel des méthodes génériques déjà implémentées dans un programme internationalisé sont utilisées de manières spécifiques. L'environnement de programmation met à disposition du programmeur plusieurs fonctions qui permettent la configuration pendant le temps d'execution. La description formelle d'un jeu d'habitudes culturelles pour quelque pays associés avec toutes les traductions visant une même langue est appelée la localisation pour cette langue ou pays. Les utilisateurs conservent les programmes localisés en définissant avant d'exécuter ces programmes, leur propres valeurs dans des variables d'environnement et en identifiant quelle localisaton doit être utilisée.

En fait le support des messages locaux de localisation n'est qu'un composant des données culturelles qui font un mode particulier. Il y a tout un serveur présentant des routines et de fonctions qui sont mises à disposition pour aider les programmeurs à développer des logiciels internationalisé et qui leur permet d'accéder aux données conservées sous une localisation particulière. Quand quelqu'un fait actuellement référence à une localisation particulière, il fait évidemment référence aux données stockées dans cette localisation particulière. De manière analogue, si un programmeur fait référence à « l'accès aux routines localisées » il fait en fait référence à la suite complète de routines, qui accèdent à toutes les informations de localisation.

On utilise l'expression Support des Langues Nationales ou plutôt SLN pour parler des activités générales ou des fonctionalités qui couvrent l'ensemble internationalisation et localisation, permettant les interactions multilingues dans un programme. En condensé, on pourrait dire que l'internationalisation et l'opération par laquelle les futures localisations sont rendues possibles.

On peut aussi dire de manière très sommaire, que quand il s'agit de message multilingues, l'internationalisation et la plupart du temps pris en charge par les programmeurs et la localisation par les traductrices.

1.3 Les aspects du Support des Langues Nationales

Pour arriver à une distribution complètement multilingue, il y a beaucoup de choses à traduire qui vont au delà des messages de sortie.

• Aujourd'hui, GNU gettext offre un jeu d'outils complet pour traduire les messages de sortie des programmes en C. Les scripts Perl et Shell auront aussi besoin d'être traduits. Même s'il y a aujourd'hui quelques trucs par lesquel ceci peut être fait, ces trucs ne sont pas aussi bien intégrés à ce qu'ils devraient.
• Certains programmes, comme autoconf ou bison, sont capables de produire d'autres programmes (ou scripts). Même si les programmes de génération sont eux mêmes internationalisés, les programmes générés qu'ils produisent peuvent avoir besoin eux-mêmes d'être internationalisés et cette internationalisation indirecte pourrait être internationalisée directement depuis le programme de génération. En fait, habituellement, les programmes de génération et les programmes générés peuvent être internationaliés indépendamment car les efforts requis sont plutôt divergents.
• Quelques programmes incluent des tableaux textuels qui peuvent avoir besoin eux-mêmes de traduction, indépendamment des chaînes de caractères incluses dans le programme lui-même. Par exemple, la norme RFC 1345 donne la description française pour chaque caractère, que le programme de recodage et capable de reconstruire à l'exécution. Comme ces descriptions sont extraites de la norme RFC par des moyens mécaniques, leur traductions correctes demanderait de traduire d'abord le tableau de la RFC lui-même.
• Presque tous les programemes accèptent des options, qui sont souvent formulées de manière auto descriptive pour les lecteurs anglais ; on peut vouloir aussi offrir des versions traduites des options du programme.
• Beaucoup de programmes, lisent, interprètent, compilent ou sont plus ou moins guidés par des fichiers d'entrée qui sont des textes qui contiennent des mots clés, des identifiants ou des réponses qui sont traduisibles de manière inhérente. Par exemple, on peut vouloir que gcc permette les caractères diacritiques dans des les identifiant ou utilise des mots clés traduits ; ‘rm -i’ pourrait accepter quelque chose d'autre que ‘y’ ou ‘n’ comme réponse etc… Même si le programme va finalement écrire la majorité de ses sorties en langue non-anglaise, on doit décider si la syntaxe d'entrée, les valeurs d'options etc… sont localisées ou non.
• Le manuel accompagnant un progiciel, comme tous les fichiers de documentation dans la distribution, pourraient sûrement être aussi traduits. La traduction d'un manuel, avec l'intention de le garder ensuite à jour, est générallement une tâche majeure par elle-même.

Comme nous l'avons souligné, la traduction n'est qu'un aspect de la localisation. D'autres aspects de l'internationalisation sont les services du système qui sont gérés par GNU libc. Il y a beaucoup d'attributs qui sont requis pour définir les conventions culturelles d'un pays. Ces attributs incluent à côté de la langue nationale du pays, le formattage des dates et des temps, la représentation des nombres, les symboles monétaires etc… Ces règles locales déterminent les paramètres de localisation du pays. Cette localisation représente un connaissance requise pour supporter les attributs nationaux du pays.

Il quelques domaines majeurs, qui peuvent varier selon les pays et qui définissent donc ce que les paramètres de localisation doivent décrire. La liste qui suit aide à metter les messages multilingues dans leur contexte propre et sur d'autres tâches liées à la localisation. Voir le manuel GNU libc pour plus de détails.

Characters and Codesets

Le jeu de codes les plus couramment utilisés aux États Unis d'Amérique etpour la plupart des régions anglophones dans le monde est le jeu de code ASCII. Cependant, il y a beaucoup de caractères requis par différentes localisations qui ne sont pas compris dans ce jeu de code. Le jeu de codes sur 8-bits ISO 8859-1 a la plupart des caractères spéciaux requis pour la plupart des langues européennes. Cependant, dans beaucoup de cas, choisir l'ISO 8859-1 n'est néanmoins pas adéquat : il ne gère même pas la monaie principale de l'Europe. Ainsi chaque localisation devra avoir une routine de gestion des caractères appropriée pour s'en sortir avec le jeu de code.

Monnaie

Le symbole utilisé varie d'un pays à l'autre comme la position utilisée par ce symbole. Les logiciels ont besoin de pouvoir afficher les nombres monétaires de manière transparent dans le mode national de chaque localisation.

Dates

Le format des dates varie entre les différentes localisations. Par exemple, le jour de Noël en 1994 est écrit 12/25/94 aux États Unis d'Amérique et25/12/94 en Australie. D'autres payus peuvent utiliser des dates 8601 etc…

L'heure du jour peut être notée hh:mm, hh.mm ou encore autrement. Certaines localisations requièrent que le temps soit spécifié sur vingt quatre heures plutôt que d'utiliser les matin (ndt AM)et après-midi (ndt PM). D'autre part la nature et la répartition annuelle de la correction d'heure d'été et d'heure d'hivers peut varier beaucoup entre les pays.

Les nombres

Les nombres peut être représentés différemment selon les localisation. Par exemple le nombre suivant sont tous écrits correctement dans leurs localisatons repectives :

12,345.67 anglais 12.345,67 allemand 12 345,67 français 1,2345.67 asie

Quelques programme peuvent aller plus loin et utiliser différents systèmes d'unités, comme les unités anglaises ou le système métrique ou encore tenir compte de variantes dans la façon dont les nombres sont épelés en entier.

Messages

Le domaine le plus évident dans une localisation est le support des langues. C'est là que GNU gettext procure le moyen aux développeurs et aux lecteurs de changer facilement la langue qu'utilise le logiciel pour communiquer avec l'utilisateur.

Ces domaines de conventions culurelles sont appelées les catégorie de localisation. C'est un terme assez malheureux ; les aspects de localisation ou les catégories des fonctionalités de localisation seraient de meilleures expressions, car chaque « catégorie de localisation » décrit un domaine ou une tâche qui demande une localisation. La donnée concrète qui décrit les conventions culturelles pour ce domaine et pour une culture particulière est aussi appelée une catégorie de localisation. En ce sens,une localisation est composée de plusieures catégories de localisation : la catégorie de localisation qui décrit le jeu de caractères,la catégorie de localisation qui décrit le formatage des nombre, la catégorie de localisation qui contient les messages traduits et ainsi de suite…

Les composants de la localisation en dehors de la gestion des messages sont standardisés le standard C ISO le standard POSIX:2001 (aussi connu comme la spécificatin SUSV3). La bibliothèque GNU lbc implémente ceci totalement et la plupart des autres systèmes modernes procurent un support plus ou moins raisonable pour au moins une partie des composants manquants.

1.4 Les fichiers transmettant les traductions

Les lettres PO dans les fichiers ‘.po’ signifient Objet Portable pour les dinstinguer des fichiers ‘.mo’, où MO signifie Object pour la Machine. Ce paradigme comme le format des fichiers PO est inspiré du standard SLN (ndt NLS) développé par Uniform et implémenté la première fois par Sun sur leur système Solaris.

Les fichies PO sont prévus pour être lus et édités par des humains et associent chaque chaîne originale à traduire d'un progiciel donné avec sa traduction dans la langue cible particulière. Un fichier unique PO et dédié à une langue cible particulière. Si un progiciel supporte beaucoup de langues, il n'y aura qu'un fichier PO de ce type par langue supportée et chaque progiciel a son propre jeu de fichiers PO. Ces fichiers PO seront crées préférentiellemnt avec le programme xgettext et par la suite mise à jour ou rajeunis par le programme msmerge. Le programme gettext extrait tous les messages marqués dans un groupe de fichiers C et initie un fichier PO avec des traductions vides. Le programme msmege fait attention d'ajuster les fichiers PO entre les différentes révisions des fichiers sources correspondants, commentant les entrées devenues obsolètes, initialisant les nouvelles et mettant à jour toutes les références des lignes sources. Les fichiers terminant par ‘.pot’ sont des sortes de fichier de traduction de base qui se trouvent dans les distributions sous le format des fichiers PO.

Les fichiers MO sont prévus pour être lus par des programmes et sont de nature binaire. Quelques systèmes offrent déjà des outils pour créer et gérer les fichiers MO comme partie du Support des Langues Nationales venant avec le système, mais le format de ces fichiers MO est souvent différent d'un système à l'autre et est non-portable. Les outils déjà fournis avec ces systèmes ne supportent pas toutes les fonctionalités du programme GNU gettext. C'est pourquoi GNU gettext utilise son propre format pour les fichiers MO. Les fichiers terminant par ‘.gmo’ sont réellement des fichiers MO, quand il est su que ces fichiers sont dans le format GNU.

1.5 Vue générale de la suite d'utilitaires GNU gettext

Le diagamme suivant synthétise les relations entre les fichiers gérés par GNU gettext et les outils agissant sur ces fichiers. Il est suivi par des explications passablement détaillées, que vous devriez lire en gardant un Å“il sur ce diagramme. Avoir une compréhension claire de ces interactions aidera sûrement les programmeurs, les traductrices et les mainteneurs.

Sources d'origine en C ───> Préparation ───> Sources C marqués ───╮
                                                                  │
              ╭─────────<─── bibliothèque GNU gettext             │
╭─── make <───┤                                                   │
│             ╰─────────<────────────────────┬────────────────────╯
│                                            │
│   ╭─────<─── PACKAGE.pot <─── xgettext <───╯    ╭───<─── PO Compendium
│   │                                             │             ↑
│   │                                             ╰───╮         │
│   ╰───╮                                             ├───> éditeur PO ───╮
│       ├────> msgmerge ──────> LANG.po ────>──── ────╯                   │
│   ╭───╯                                                                 │
│   │                                                                     │
│   ╰─────────────<───────────────╮                                       │
│                                 ├─── nouveau LANG.po <──────────────────╯
│   ╭─── LANG.gmo <─── msgfmt <───╯
│   │
│   ╰───> install ───> /.../LANG/PACKAGE.mo ───╮
│                                              ├───> "Bonjour le monde !"
╰───────> install ───> /.../bin/PROGRAM ───────╯

Pour le programmeur, la première étape pour amener GNU gettext dans votre progiciel est d'identifer, déjà depuis le fichier source en C, ces chaînes qui sont prévues pour être traduites et celles qui ne le seront pas. Ce travail fastidieux peut être fait de manière un peu plus confortable en utilisant le mode PO d'Emacs, mais vous pouvez utiliser tous les moyens qui vous sont familliers pour modifier les fichiers sources en C. À côté de ceci, quelques autres changements simples et standards sont requis pour initialiser proprement la bibliotèque de traduction.@xref{Sources},pour plus d'information sur tout ceci.

Pour le nouveaux logiciels en développement, bien sûr les chaînes peuvent et devraient être marquées pendant qu'on l'écrit. L'approche de gettext rend ceci très facile. Il suffit de mettre les lignes suivantes au début de chaque fichier ou dans un fichier d'en-tête centralisé.

#define _(Chaîne) (Chaîne)
#define N_(Chaîne) Chaîne
#define textdomain(Domaine)
#define bindtextdomain(Progiciel, Répertoire)

Faire ainsi vous permet de préparer les sources pour l'internationalisation. Plus tard, quand vous vous senterez prêt pour utiliser la bibliothèque gettext remplacez simplement ces définitions par :

#include <libintl.h>
#define _(Chaîne) gettext (Chaîne)
#define gettext_noop(Chaîne) Chaîne
#define N_(Chaîne) gettext_noop (Chaîne)

et liez de nouveau avec ‘libintl.a’ ou ‘libintl.so’. Notez que sur les systèmes GNU, nous n'avez pas besoin de lier à libintl car les fonctions de la bibliothèque gettext sont déjà contenues dans la bibliothèque GNU libc. C'est tout ce que vous avez à changer.

Une fois que les sources C ont été modifiées, le programme xgettext est utilisé pour trouver et extraire toutes les chaînes à traduire et crée un fichier PO de référence avec tout ceci. Ce fichier ‘progiciel.pot’ contient toutes les chaînes originales du programme.Il conserve un jeu de pointeurs désignant exactement où chacune des chaînes est utilisées dans le source C. Chaque traduction est vide. La lettre t dans le .pot indique qu'il s'agit d'un fichier PO modèle, pas encore orienté vers une langue particulière. Voir la section Invocation le programme msginit, pour plus de détails sur comment on appelle le programme xgettext. Si vous être vraiment flémard, vous serez peut être intéressé de travailler beaucoup plus directement et de préparer la définition de la distribution complète (@pxref{mainteneurs}).En faisant ainsi, vous vous économisez de taper les commandes xgettext car make devrait générer maintenant les choses correctement et automatiquement pour vous !

Néanmoins, la première fois il n'y a pas encore de ‘lan.po’, donc l'étape msmerge peut être sautée et remplacée par seulement une copie de ‘package.pot’ vers ‘lang.po’, où lang représente la langue voulue. Voir @ref{création}< pour les détails.

Vient ensuite la traduction initiales des messages. La traduction par elle même est un sujet complet, uniquement dédiée aux humains, et dont la complexité dépasse largement le niveau de ce manuel. Néanmoins, quelques conseils sont donnés dans d'autres chapitres de ce manuel (@pxref{traducteurs}). Vous trouverez aussi ici des indications sur la façon de contacter les équipes de traduction, ou sur la façon d'en devenir membre pour partager vos soucis de traduction avec d'autres traducteurs qui traduisent vers la même langue nationale que vous.

Quand vous ajoutez un message traduit dans un fichier PO ‘lang.po’, si vous n'utilisez pas un éditeur de fichiers PO dédié (@pxref{édition}), vous devez vous en remettre à vous seul pour que votre effort respecte complètement le format des fichiers PO et les conventions de cotations (@pxref{fichiers PO}). Ce n'est sûrement pas une tâche impossible, car c'est ainsi que beaucoup de personnes ont gérés les fichiers PO autour des années 1995. D'un autre côté, en utilisant un éditeur de fichier PO, la plupart des détails du format des fichiers PO sont traités pour vous, mais vous devez acquérir quelques familiarités avec l'éditeur de fichier PO lui même.

Si quelques traductions communes ont déjà été sauvegardées dans un fichier PO compendium, les traductrices peuvent utiliser le mode PO pour intialiser les entrées non traduites du compendium et aussi d'avoir une sélection de traductions dans la mise à jour du compendium (@pxref{compendium}). Les fichiers compendium ont pour objectif d'être échangés entre les membres d'une équipe de traduction donnée.

Les programmes ou les progiciels sont par nature dynamiques : les utilisateurs écrivent des rapports de bogues et des suggestions d'amélioration, les mainteneurs réagissent en modifiant les programmes de manières diverses. Le fait qu'un progiciel ait déjà été internationalisé ne devrait pas rendre le mainteneur timoré pour ajouter de nouvelles chaînes ou modifier celles qui ont déjà été traduites. Ils font juste leur travail le mieux qu'ils peuvent. Pour que le Projet de Traduction puisse fonctionner sans heurt, il est important que les mainteneurs n'aient pas à porter sur leurs épaules, déjà bien chargées, les préoccupations de traduction et que les traductrices soient aussi libre que possible des préoccupations de programmation.

La seule préoccupation que les mainteneurs devraient avoir est de marquer consciencieusement les nouvelles chaînes comme traduisibles quand elles le doivent sans se préoccuper ensuite si elles sont ou non traduite, ce qui viendra en temps utile. En conséquence, quand les programmes et leurs chaînes sont ajustés de différentes façons par les mainteneurs et pour des sujets qui n'ont la plupart du temps aucune relation avec la traduction, xgettext construira les fichiers ‘package.pot’ qui évoluent au cours du temps, quand les traductions faites par ‘lang.po’ deviennent progressivement obsolètes.

Il est important pour les traductrices (et même les mainteneurs) de comprendre que la traduction des progiciels un processus continu dans la durée de vie d'un progiciel et non pas quelque chose qui est fait une fois pour toute au début.Après l'explosion initiale de l'activité de traduction pour un progiciel donné, des interventions sont nécessaires de temps en temps, car par ci par là, les entrées traduites deviennent obsolètes et de nouvelles entrées non-traduites apparaissent et qui ont besoin de traduction.

Le programme msmerge a pour objectif de rafraîchir un fichier ‘lang.po’ déjà existant en le comparant avec un nouveau fichier modèle ‘package.pot’ extrait par xgettext du source C récent. L'opération de rafraîchissement ajuste toutes les références aux positions des chaines dans les fichiers sources C, car ces chaînes bougent quand les programmes sont changés. msgmerge commente aussi comme obsolète dans le fichier ‘lang.po’, ces entrées déjà traduites qui ne sont plus utilisées dans les sources du programme (@pxref{entrées obsolètes}). Il découvre finalement de nouvelles chaînes et les insèrent dans le fichier PO résultant comme des entrées non traduites (@pxref{entrées non traduites}). @xref{invocation de msgmerge}, pour avoir plus d'informations sur ce que msgmerge fait réellement.

Quelque soit la route ou moyens pris, la but est d'obtenir un fichier ‘lang.po’ mise à jour donnant des traductions pour toutes les chaînes.

La mobilité temporelle, ou fluidité, des fichiers PO est une part intégrale du jeu de traduction et doit être bien comprise et acceptée. Les personnes qui y resistent auront du mal à participer à un Projet de Traduction ou donneront du mou à retordre aux autres participants ! En particulier, les mainteneurs devraient rester souples et inclure dans distriutions tous les fichiers PO officiels disponibles, même s'ils ne n'ont pas été mis à jour récemment et ne pas exercer de pression sur les équipes de traduction pour obtenir un travail achevé. La pression devrait plutôt venir de la communauté des utilisateurs parlant une langue particulière et les mainteneurs devraient se considérer eux mêmes plutot déchargés de tous soucis sur l'adéquation des fichiers de traduction. D'un autre côté, les traducteurs devraient essayer de mettre à jour raisonnablement les fichiers PO dont ils sont responsables, quand le progiciel est en train d'être pré-testé, avant une distribution officielle.

Une fois qu'un fichier PO est complet et fiable, le programme msgfmt est utilisé pour traduire le fichier PO en un format oritenté machine, qui peut permettre de récupérer les traductions d'un programme, à chaque fois que c'est demandé pendant l'exécution (@pxref{MO Files}). @ref{msgfmt Invocation}, pour plus d'information sur tous les modes d'exécution du programme msgfmt.

Finalement les sources C modifiés et marqués sont compilés et liés avec la bibliothèque GNU gettext, habituellement par la commande make en supposant qu'un ‘Makefile’ adéquat existe pour le projet. Les fichiers exécutables résultants sont installés à un endroit ou les utilisateurs vont les trouver. Les fichiers MO eux mêmes doivent être installés correctement. En supposant que les variables d'environnement sont définies (@pxref{définir la localisation POSIX}), le programme devrait se localiser de lui même automatiquement, à chaque fois qu'il s'exécute.

La suite de ce manuel a pour objet l'explication en profondeur des différentes étapes que nous avons décrites ci dessus.

2. Le point de vue de l'utilisateur

De nos jours, quand les utilisateurs démarrent leur session sur un ordinateur, ils trouvent habituellement que tous leur programmes envoient des messages dans leur langue nationale — au moins pour les utilisateurs dont les langues ont une communauté active pour les logiciels libres, comme les français ou les allemands et dans une moindre mesure, des langues avec une plus faible participation dans les logiciels libres et le projet GNU, comme l'hindi et le philipin.

Comment cela fonctionne ? Commet l'utilisateur peut-il influencer la langue qui est utilisée par les programmes ? Ce chapitre va y répondre.

2.1 Installation du système d'exploitation

La langue par défaut est souvent déjà spécifiée pendant l'installation du système d'exloitation. Quand le système d'exploitation est installé, le programme d'installation demande habituellement la langue à utiliser pour le processus d'installation lui même et séparément, pour la langue à utiliser sur le système installé. Quelques programmes d'installation ne demande la langue qu'une seule fois.

Ceci détermine la langue par défaut sur tout le système pour tous les utilisateurs.Mais les installateurs donnent souvent la possibilité d'installer des localisationset langues additionnelles. Par exemple, les localisations sur KDE (l'environnementde bureau K) ou sur OpenOffice.org sont souvent empaquettés séparément comme unpaquatage installable par langue.

À ce point, est il est bon de considérer l'utilisaton voulue de la machine : si c'est une machine à vocation d'utilisation personnelle, les localisations additionnelles ne sont sûrement pas nécessaires. Par contre si la machine doit être utilisée dans une organisation ou une entreprise qui a des relations internationales, on peut alors prendre en compte le besoin d'utilisateurs hôtes. Si vous avez un hôte venant de l'étranger pour une semaine, quelles seraient ses localisatons préférées ? Cela peut valoir le coup d'installer ces localisations additonnelles en avance, car elles ne coûtent qu'un peu d'espace disque à cette étape.

La langue par défaut de tout le système et la configuration locale, qui estutilisée quant un compte utilisateur est crée. Mais l'utilisateur peut avoirses propres configurations de localisation, qui sont différentes de cellesd'autres utilisateurs sur la même machine. Il peut le spécifier, typquementaprès sa prémière connexion sur le système, comme décrit dans la section suivante.

2.2 Régler la localisation utilisée par les programmes avec interface utilisateur graphique

Les programmes immédiatement disponibles sur le bureau de l'utilisateur formentun groupe de programmes appelé « environnement du bureau » ; il inclue habituellementle gestionnaire de fenêtres, un navigateur internet, un éditeur de texte et plus… Les environnements de bureau libres les plus communs sont KDE, GNOME et XFce.

La localisation utilisée par un programme avec interface utilisateur graphique (IUG)sur une environnement de bureau peut être spécifié par un écran de configurationappelé « centre de contrôle », « réglage de la langue » ou « réglage du pays ».

Les programmes IUG individuels, qui ne font pas partie de l'environnement de bureau, peuvent avoir leur propre localisation spécifiée soit dans le panneau de contrôle, soit dans les variables d'environnement.

Pour quelques programmes, il est possible de définir la localisation à traversdes variables d'environnement, parfois même avec une autre localisation que celledu bureau lui même. Ceci signifie que vous pouvez démarrer ce programme depuis laligne de commande, après avoir défini quelques variables d'environnement à laplace de démarrer le programme par un menu ou par le système de gestion de fichiers.Les variables d'environnement peuvent être celles qui sont spécifiées dans la sectionsuivante (@ref{définir la localisation POSIX}); cependant pour quelques versions de KDE, la localisation est définie par la variable KDE_LANG plutôt que LANG ouLC_ALL.

2.3 Définir la localisation par les variables d'environnement

Comme utilisateur, si votre langue a été installée pour ce progiciel, dans le cas le plus simple, vous n'avez qu'à définir la variable d'environnement LANG sur la combinaison appropriée de ‘ll_CC’. Par exemple, supposons que vous parliez allemand et viviez en Allemagne. À l'invite du Shell, exécutez simplement ‘setenv LANG de_DE’ (dans csh), ‘export LANG; LANG=de_DE’ (dans sh)ou ‘export LANG=de_DE’ (dans bash). Ceci peut être fait dans votre fichier ‘.login’ ou ‘.profile’ une bonne fois pour toutes.

2.3.1 Noms de localisations

Un nom de localisation a habituellement la forme ‘ll_CC’. Ici ‘ll’ est code à deux lettres donnant la langue selon la normeISO 639 et ‘CC’ est la code à deux lettres donnant le pays selon la norme ISO 3166. Par exemple, pour l'allemand en allemagne, ll est de et CC est DE. Vous trouverez une liste de codes de langues dans l'appendice @ref{codes des langues} et la liste des codes des pays dans l'appendice @ref{codes des pays}.

Vous pourriez penser que la spécifications des codes des pays est redondante.Mais en fait, certaines langues ont des dialectes selon les pays. Par exemple, ‘de_AT’ est utilisé pour l'Autriche et ‘pt_BR’ pour le Brésil.Le code du pays permet de distinguer ces différences.

Beaucoup de noms de localisation ont une syntaxe étendue ‘ll_CC.encoding’ qui spécifie aussi l'encodage des caractères. Ceci est utilisé car entre 2000 et 2005, la plupart des utilisateurs sont passés aux localisations avec un encodage UTF-8. Par exemple, la localisation allemande sur les systèmes glibc est maintenant ‘de_DE.UTF-8’. L'ancien nom ‘de_DE’ refère toujours à la localisation allemande comme en 2000, qui sauvegardait les caractères dans l'encodage ISO-8859-1, un encodage de texte qui ne peut même pas accomoder le signe monétaire de l'Euro.

Quelques noms de localisation utilise ‘ll_CC.@variante’ à la place de ‘ll_CC’. La ‘@variante’ peut signifier n'importe quelle caractéristique qui n'est pas déjà impliquée par la langue ll et le pays CC. Ceci peut indiquer une unité monétaire particulière. Par exemple sur les systèmes glibc, ‘de_DE@euro’ signifie une localisation qui utilise la monaie Euro, en contraste avec l'ancienne localisation ‘de_DE’ qui implique l'utilisation de l'ancienne monnaie d'avant 2002. Ceci peut aussi signifier un dialecte de la langue ou un type d'écriture utilisé pour écrire le texte (par exemple, ‘sr_RS@latin’ utilise l'écriture latine, alors que ‘sr_RS’ utilise l'écriture cyrillique pour écrire le serbe) ou encore des règles orthographiques ou tout autre chose similaire.

Sur d'autres systèmes, quelques variations de ce schéma sont utilisées, comme ‘ll’. Vous pouvez obtenir la liste des localisationssupportées par votre système pour votre langue en lançant la commande‘locale -a | grep '^ll'’.

Il y a aussi une localisation spéciale, appelée ‘C’. Quand elle est utilisée, elle desactive toutes les localisations : dans cette localisation, tous les programmes standardisés par POSIX utilisent des messages en anglais et un encodage de caractères non spécifié (souvent US-ASCII, mais quelque fois aussi ISO-8859-1 ou UTF-8, selon le système d'exploitation).

2.3.2 Variables d'envrionnement pour la localisation

A locale is composed of several locale categories, see @ref{Aspects}. When a program looks up locale dependent values, it does this according to the following environment variables, in priority order:

2. LANGUAGE
3. LC_ALL
4. LC_xxx, selon la catégorie locale sélectionnée : LC_CTYPE, LC_NUMERIC, LC_TIME, LC_COLLATE, LC_MONETARY, LC_MESSAGES, ...
5. LANG

Les variables dont les valeurs sont définies, mais vides, sont ignorées dans cet aperçu.

LANG est la variable d'environnement normale pour spécifier une localisation.Comme utilisateur, vous réglez normalement cette variable (sauf si d'autres variables ont déjà été réglées par le système, dans ‘/etc/profile’ ou des fichiers d'initialisation similaires).

LC_CTYPE, LC_NUMERIC, LC_TIME, LC_COLLATE, LC_MONETARY, LC_MESSAGES, etc… sont les variables d'environnement prévues pour remplacer LANG et affecter une catégorie locale unique. Par exemple, supposons que vous êtes un utilisateur Suédois en Espagne et que vous voulez voulez que vos programmes gèrent les nombres et les dates selon les conventions espagnoles et seulement les messages devraient utiliser le Suédois. Alors vous pourriez créer une localisation nommée ‘sv_ES’ ou ‘sv_ES.UTF-8’ en utilisant le programme localedef. Mais il est plus simple et cela donne le même effet de définir la variable LANG à es_ES.UTF-8 et la variable LC_MESSAGES à sv_SE.UTF-8; ces deux localisations arrivent pré-installées avec le système d'explotation.

LC_ALL est la variable d'environnement qui les remplace toutes. C'est habituellement utilisé dans les scripts qui lancent des programmes particuliers.Par exemple, le script configure généré par GNU autoconf utilise LC_ALL pour s'assurer que les tests de configuration n'opèreront en dépendant de la localisation.

Malheureusement quelques systèmes définissent LC_ALL dans le fichier ‘/etc/profile’ ou dans des fichiers d'initialisation similaires. Comme utilisateurs, vous devez donc ré-intialiser cette variable si vous voulez régler LANG et optionnellement quelques unes des autres variables LC_xxx.

La variable LANGUAGE est décrite dans la prochaine sous section.

2.3.3 Spécification d'une liste de priorité des langues

Tous les programmes n'ont pas de traduction pour toutes les langues. Par défaut, un message en anglais est montré à la place des traductions non-existante. Si vous comprenez les autres langues, vous pouvez définir un liste de priorité des langues. Ceci est fait à travers différentes variables d'environnement appelées LANGUAGE. GNU gettext donne la préférence à LANGUAGE sur LC_ALL et LANG pour la gestion des messages, mais vous avez toujours besoin d'avoir LANG (or LC_ALL) réglée sur la première langue ; ceci est requis par les autres parties des bibliothèques systèmes.Par exemple, des utilisateurs suédois liraient plutôt des traductions en allemand qu'en anglais quand le suédois n'est pas disponible, ils définiraient alors LANGUAGE à ‘sv:de’ en laissant LANG sur ‘sv_SE’.

Conseil spécifique pour les utilisateurs norvégiens : le code linguistique pour le glyphe norvégien bokmål à changé de ‘no’ à ‘nb’ récemment (en 2003).Pendant cette période de transition, alors que certains catalogues de message pour cette langue ont été installé avec ‘nb’ et d'autres plus anciens sous ‘no’, il est recommandé pour les utilisateurs norvégiens de définir LANGUAGE à ‘nb:no’ de telle façon que les nouvelles et les anciennes traductions soient utilisées.

Dans la variable d'environnement LANGUAGE, mais pas dans les autres variables d'environnement, les combinaisons ‘ll_CC’ peuvent être abrégées en ‘ll’ en signifiant le dialecte principale de la langue. Par exemple, ‘de’ est équivalent à ‘de_DE’ (L'allemand comme parlé en Allemagne) et ‘pt’ pour ‘pt_PT’ (le portugais comme parlé au Portugal) dans ce contexte.

Note : la variable LANGUAGE est ignorée si la localisation est réglée à ‘C’.En d'autres termes, vous devez d'abord activer la localisation en définissant LANG (ou LC_ALL) à une valeur différente de ‘C’, avant de pouvoir utiliser une liste de priorité des langues à travers la variable LANGUAGE.

2.4 Installing Translations for Particular Programs

Les langues ne sont pas supportées de manières égales dans tous les progiciels utilisant gettext et plus de traductions sont ajoutées au cours du temps.Habituellement, vous utilisez les traductions qui sont livrées avec le système d'exploitation ou avec des progiciels particuliers que vous avez installés par après. Mais vous pouvez aussi installer de nouvelles localisations directement.Pour faire ceci, vous aurez besoin de comprendre où sont stockés chaque fichier de localisation sur le système d'exploitation.

Pour les programmes qui participent au Projet de Traduction, vous pouvezcommencer à chercher des traductions ici :http://translationproject.org/team/index.html. Un extrait de cette information peut aussi être trouvé dans le fichier ‘ABOUT-NLS’ qui est livré avec GNU gettext.

Pour les programmes qui font partie du projet KDE, le point de départ est :http://i18n.kde.org/.

Pour les programmes qui font partie du projet GNOME, le point de départ est :http://www.gnome.org/i18n/.

Pour les autres programmes, vous pouvez vérifier si le paquet du code source du programme contient quelques fichiers ‘ll.po’; souvent, ils sont gardés ensemble dans un répertoire appelé ‘po/’. Chaque fichier ‘ll.po’ contient les traductions de messages pour la langue dont l'abréviation est ll.

3. Le format des fichiers PO.

La suite d'outils GNU gettext aide les programmeurs et les traductrices pour produire, mettre à jour et utiliser les fichiers de traduction, principalement les fichiers PO, qui sont des fichiers textuels et éditables. Ce chapitre explique le format des fichiers PO.

Un fichier PO est fait de beaucoup d'entrées, chacune d'entre elle gardant une relation entre une chaîne originale non traduite et sa traduction correspondante.Chaque entrée d'un fichier PO font normalement partie d'un seul projet et toutes les traductions sont exprimées dans une seule langue cible. Un entrée d'un fichier PO a la structure schématique suivante :

white-space
#  translator-comments
#. extracted-comments
#: reference…
#, flag…
#| msgid previous-untranslated-string
msgid untranslated-string
msgstr translated-string

La structure générale d'un fichier PO devrait être bien comprise par la traductrice. En utilisant le mode PO, peu de choses doivent être sûes sur les détails du format, car le mode PO fait attention à eux pour elle.

Un entrée simple peut ressembler à ceci :

#: lib/error.c:116
msgid "Unknown system error"
msgstr "Error desconegut del sistema"

Les entrées débutent par quelques espaces blancs optionnels. Habituellement, quand la génération est faite par les outils GNU gettext, il y a exactement une ligne blanche entre les entrées. Ensuite suivent les commentaires, sur des lignes qui commencent toutes par le caractère #. Il y a deux sortes de commentaires : ceux qui ont des espaces blancs suivant immédiatement le # -les commentaires de la traductrice - et qui sont des commentaires crées et maintenus exclusivement par la traductrice et ceux qui ont des caractères non-blancs suivant immédiatement le # — les commentaires automatiques — et qui sont des commentaires crées et maintenus automatiquement par les outils GNU gettext. Les lignes de commentaires débutant par #. contiennent des commentaires donnés par le programmeur, dirigés vers la traductrice ; ces commentaires sont appelés commentaires extraits car le programme gettext les extrait du code source du programme. Les lignes de commentaires débuttant avec #: contiennent des références au code source du programme. Les lignes de commentaires débutant par #, contiennent des marques ; on en dira plus plus loin. Les lignes de commentaires débutant par #| contiennent les chaînes précédemment non traduites pour lesquelles la traductrice a donné une traduction.

Tous les commentaires, de quelque sortes qu'ils soient, sont optionnels.

les entrées montrent deux chaînes, nommément la première donne la chaîne non traduite telle qu'elle apparaît dans le source original du programme et ensuite la traduction de cette chaîne.La chaîne originale est introduite par le mot clé msgid et la traduction par msgstr. Les deux chaînes, la non-traduite et la traduite, sont entre guillemets de différentes façons dans le fichier PO, en utilisant les délimiteurs \" et les échappements \\, mais le traducteur n'a pas vraiment à faire attention pour préciser la forme du format des guillemets car le mode PO les gère pour elle.

Les chaînes msgid, comme les commentaires automatique, sont produits et gérés par les autres outils GNU gettext et le mode PO ne donne pas de moyens à la traductrice pour les altérer. Tout ce qu'elle peut faire est simplement de les effacer et seulement en enlevant l'entrée entière. D'un autre côté, la chaîne msgstr, comme les commentaires de la traductrice, sont vraiment pour la traductrice et le mode PO lui donne le contrôle dont elle a besoin.

Les lignes de commentaires débutant par #, sont spéciales car elles ne sont pas complètement ignorées par le programme comme le sont généralement les commentaires. La liste séparée par des virgules des marques est utilisée par le programme msgfmt pour donner à l'utilisateur des messages de diagnostiques améliorés. Il y a couramment deux formes de marques définies :

fuzzy

msgmerge ou peut être inséré par la traductrice elle même. Il montre que la chaîne msgstr peut ne pas être une traduction correcte (ne plus l'être). Seule la traductrice peut juger si une traduction nécessitera d'autres modifications ou si elle est acceptable. Une fois satisfaite avec la traduction, elle peut enlever cet attribut fuzzy. Le programme msgmerge insère ceci quand il combine les entrées msgid et msgstr seulement après une recherche floue (ndt fuzzy). @xref{entrées floues -ndt fuzzy}.

c-format

no-c-format

par un humain. À la place, seul le programme xgettext les ajoute. Avec un système automatisé de traitement des fichiers PO, comme proposé ici, les changements de l'utilisateur seront rejettés dès que le programme xgettext génèrera un nouveau fichier modèle.

La marque c-format dit que la chaînes non-traduite et la traduction sont supposées être des chaînes en format C. La marque no-c-format dit qu'elles ne sont pas des chaînes en format C, même s'il s'avère que la chaîne non-traduite ressemble à une chaîne en format C (avec des directives ‘%’).

Au cas où la marque c-format est donné pour une chaîne le programme msgfmt fera d'autres tests pour vérifier la validité de la traduction. @xref{invocation de msgfmt}, @ref{marque c-format} et Format des chaînes en C.

format objc

no-objc-format

De façon identique pour Objective C, voir @ref{format-objc}.

format Shell

no-sh-format

@ref{format-sh}.

format python

no-python-format

De façon identique pour Python, voir @ref{format-python}.

format Lisp

no-lisp-format

@ref{format-lisp}.

format ELisp

no-elisp-format

De façon identique pour Emacs Lisp, voir @ref{format-elisp}.

format librep

no-librep-format

De façon identique pour librep, voir @ref{format-librep}.

format scheme

no-scheme-format

De façon identique pour Scheme, voir @ref{format-scheme}.

format smalltalk

no-smalltalk-format

De façon identique pour Smalltalk, voir @ref{format-smalltalk}.

format java

no-java-format

De façon identique pour Java, voir @ref{format-java}.

format csharp

no-csharp-format

De façon identique pour C#, voir @ref{format-csharp}.

format awk

no-awk-format

De façon identiquer pour awk, voir @ref{format-awk}.

format object pascal

no-object-pascal-format

De façon identique pour Object Pascal, voir @ref{format-object-pascal}.

format ycp

no-ycp-format

De façon identique pour YCP, voir @ref{format-ycp}.

format tcl

no-tcl-format

De façon identique Tcl, voir @ref{format-tcl}.

format perl

no-perl-format

DE façon identique pour Perl, voir @ref{format-perl}.

perl-brace-format

no-perl-brace-format

De façon identique pour les parenthèses Perl, voir @ref{format-perl}.

format php

no-php-format

De façon identique pour PHP, voir @ref{format-php}.

format interne de gcc

no-gcc-internal-format

De façon identique pour les sources GCC, voir @ref{format-interne-gcc}.

format qt

no-qt-format

De façon identique pour Qt, voir @ref{format-qt}.

format kde

no-kde-format

De façon identique pour KDE, voir @ref{format-kde}.

format boost

no-boost-format

De façon identique pour Boost, voir @ref{format-boost}.

Il est aussi possible d'avoir des entrées avec un spécificateur du contexte. Ellesressemblent à ceci :

white-space
#  commentaire-traductrice
#. commentaires-extraits
#: référence…
#, marque…
#| msgctxt context-précédent
#| msgid chaîne-non-traduite-précédente
msgctxt contexte
msgid chaîne-non-traduite
msgstr chaîne-traduite

Le contexte sert à lever les ambiguïtés des messages avec la même chaîne non-traduite. Il est possible d'avoir plusieurs entrées avec la même chaîne non-traduite dans un fichier PO, en supposant qu'elles ont chacune un contexte différent. Notez qu'une chaîne vide de contexte et que l'absence d'une ligne msgctxt ne signifient pas la même chose.

Une forme différente d'entrées est utilisée pour les traductions qui impliquent des formes plurielles.

white-space
#  translator-comments
#. extracted-comments
#: reference…
#, flag…
#| msgid previous-untranslated-string-singular
#| msgid_plural previous-untranslated-string-plural
msgid untranslated-string-singular
msgid_plural untranslated-string-plural
msgstr[0] translated-string-case-0
...
msgstr[N] translated-string-case-n

Une telle entrée ressemble à ceci :

#: src/msgcmp.c:338 src/po-lex.c:699
#, c-format
msgid "found %d fatal error"
msgid_plural "found %d fatal errors"
msgstr[0] "s'ha trobat %d error fatal"
msgstr[1] "s'han trobat %d errors fatals"

Ici aussi, un contexte msgctxt peut être spécifié avant msgid comme vu plus haut.

La chaîne non-traduite (ndt previous-untranslated-string)peut éventuellement être insérée par le programme msgmerge en même temps qu'il marque une traduction fuzzy (-ndt floue). Cela aide la traductrice à voir quels ont été les changements qui ont été faits par les développeurs sur la chaîne non-traduite.

Il arrive que certaines lignes, habituellement des espaces blanc ou des commentaires suivent la dernière entrée d'un fichier PO. De telles lignes ne font partie d'aucune entrée et seront rejetées quand le fichier PO sera traité par les outils, ou cela pourrait aussi déranger certains éditeurs de fichiers PO.

Le reste de cette section peut être sauté sans risque pour ceux qui utilisent un éditeur de fichier PO, bien qu'elle puisse être intéressante pour toute personne désireuse d'avoir une meilleure idée du format précis d'un fichier PO.Par contre les personnes désirant modifier des fichiers PO à la main devraient continuer de lire avec attention.

Chacune des chaînes non-traduites et des chaînes traduites respectent la syntaxe C pour les chaînes de caractères, incluant les guillemets encadrantes et les séquences d'échappement par barres obliques inversées incorporées. Quand il faut écrire des chaînes à lignes multiples, on ne devrait pas utiliser les nouvelles lignés échappées. À la place, des guillemets fermantes devraient suivre le dernier caractère sur la ligne à continuer et des guillemets ouvrantes devraient reprendre la chaîne au début de la prochaine ligne du fichier PO. Par exemple :

msgid ""
"Here is an example of how one might continue a very long string\n"
"for the common case the string represents multi-line output.\n"

Dans cet exemple, la chaîne vide est utilisée sur la première ligne pour permettre un meilleur alignement du I du mot ‘Ici’ sur le p du mot ‘pour’. Dans cet exemple, le mot clé msgid est suivi de trois chaînes, qui doivent être concaténées. La concaténation de la ligne vide ne change pas la chaîne générale résultante , mais c'est un moyen pour nous de satisfaire la nécessité pour msgid d'être suivi par une chaîne sur la même ligne, tout en conservant la présentation sur plusieurs lignes justifiées à gauche car nous trouvons que c'est une disposition plus claire. La chaîne vide aurait pu être omise, mais seulement si la chaîne débutant par ‘Ici’ aurait été promue sur la première ligne, juste après msgid.(2) Il n'était pas vraiment nécessaire de changer entre les deux dernières chaînes entre guillemets, immédiatement après la nouvelle ligne ‘\\n’, le changement aurait pu avoir lieu après n'importe quel autre caractère, nous l'avons juste fait de cette façon pour être plus propre.

On devrait distinguer avec soin entre des fins de ligne marquées par ‘\\n’à l'intérieur des guillemets, qui font parties de la chaîne représentée,et les fins de lignes dans le fichier PO lui même, à l'extérieur des guillemets,qui n'ont aucune incidence sur la chaîne représentée.

À l'extérieur des chaînes, les lignes blanches et les commentaires peuvent être utilisées librement. Les commentaires commence au début d'une ligne avec un ‘#’ et s'étendent jusqu'à la fin de ligne du fichier PO. Les commentaires qui sont écrits par les traductrices devraient avoir le signe ‘#’ initial suivi immédiatement par quelques espaces blancs. Si le ‘#’ n'est pas immédiatement suivi par un espace blanc, ce commentaire a vraisemblablement été généré et géré par les outils GNU spécialisés et peut disparaître ou être remplacé de manière impromptue quand le fichier PO est donné à msgmerge.

4. La préparation des fichiers source d'un programme.

Pour le programmeur, les changements dans le source C peuvent être classés en trois catégories. Premièrement, vous devez porter à la connaissance de tous les modules ayant besoin de traduction de messages les fonctions de localisation.Deuxièmement, vous devriez activer activer correctement les opérations de GNU gettext quand le programmes n'initialise, habituellement avec par la fonction main. Enfin, vous devriez identifier, ajuster et marquer toutes les chaînes constantes qui auront besoin de traduction dans votre programme.

4.1 Importation de la déclarations de gettext

Dans l'hypothèse que votre ensemble de programmes, ou progiciels, ont été ajustés de telle façon que tous les fichiers GNU gettext sont disponibles et que vos fichiers ‘Makefile’ sont ajusté (@pxref{mainteneurs}), chaque module C qui a des chaînes traduites en C devraient avoir la ligne :

#include <libintl.h>

De manière similaire, chaque module C contenant des appels printf()/fprintf()/...avec des chaînes formatées qui pourraient être traduites en chaîne C (même si les chaînes C viennent d'un module différent) devraient contenir la ligne :

#include <libintl.h>

4.2 Sollicitation des operations de gettext

L'initialisation des données locales devraient être faite avec à peu prêt le même code dans chaque programme, comme démontré plus bas :

int
main (int argc, char *argv[])
{
 …
 setlocale (LC_ALL, \"\");
 bindtextdomain (PACKAGE, LOCALEDIR);
 textdomain (PACKAGE);
 …
}

PACKAGE et LOCALEDIR devraient être fournies soit par ‘config.h’ soit par la Makefile. Pour le moment, consultez les sources de gettext ou de hello pour plus d'informations.

L'utilisation de LC_ALL peut ne pas être approprié pour vous. LC_ALL inclut toutes les catégories locales et spécialement LC_CTYPE. Cette dernière catégorie est responsable de la détermination des classes de caractères avec isalnum etc… les fonctions de ‘ctype.h’, qui pourraient être non adéquates, spécifiquement pour les programme, qui traitent des sortes d'entrée pour les langues. Par exemple, ceci voudrait dire qu'un code source utilisant le ç (le caractère c-cédille) peut fonctionner en France mais pas aux États-Unis.

Quelques systèmes d'exploitation ont aussi des problèmes avec la reconnaissance syntaxique des chiffres qui utilise la fonction scanf si une autre catégorie que LC_ALL est utilisée. Les standards disent que des formats additionnels excepté celui en local \"C\" peuvent être reconnus. Mais certains systèmes semblent rejeter les nombres qui sont dans le format locale \"C\". Dans certaines situations, il peut aussi y avoir un problème avec la notation elle même, qui rend impossible de savoir reconnaître si le nombre dans la locale \"C\" ou dans le format local. Ceci peut arriver sur des milliers de caractères de séparation sont utilisés. Quelques localisations définissent ce caractère selon la convention nationale du '.', qui est le même caractère utilisé par la localisation \"C\" pour noter le point séparant les décimaux.

Donc il est parfois nécessaire de remplacer la ligne LC_ALL dans le code ci dessus par une séquence de lignes setlocale

{
 …
 setlocale (LC_CTYPE, "");
 setlocale (LC_MESSAGES, "");
 …
}

Sur tous les systèmes conformes à la norme POSIX, les catégories locales LC_CTYPE, LC_MESSAGES, LC_COLLATE, LC_MONETARY, LC_NUMERIC et LC_TIME sont disponibles. Sur certains systèmes, qui ne sont que compatibles à l'ISO C, LC_MESSAGES est absent, mais un substitut est défini dans la bibliothèque GNU gettext <libintl.h> et la bibliothèque GNU <locale.h>.

Notez que changer le LC-TYPE affecte aussi les fonctions déclarées dans l'en-tête standard <ctype.h> et quelques fonctions déclarées dans les en-têtes standards <string.h> et <stdlib.h>. Si ceci n'est pas souhaitable pour votre application (par exemple l'outil de reconnaissance syntaxique d'un compilateur), vous pouvez utiliser un ensemble de fonctions de substitutions qui ont la localisation C codé en dur, comme on le trouve dans les modules ‘c-ctype’,‘c-strcasestr’, ‘c-cstrtod’, ‘c-strtold’ dans la distributiondes sources de GNU gnulib.

Il est aussi possible de changer la localisation et de revenir entre la localisation dépendant de l'environnement et la localisation C, mais cette approche est normalement évitée car les appels à setlocale sont coûteux, parce qu'il est fastidieux de déterminer les positions où le changement de la localisation est requis dans le source d'un gros programme et parce que change de localisation n'est sécurisé pour les fonctionnements en multi-activité (ndt multithread).

4.3 Préparation des chaînes à traduire

Avant qu'une chaîne puisse être marquée pour des traductions, elles ont parfois besoin d'être ajustées. Habituellement la préparation des chaînes pour la traduction est faite juste avant de les marquer, phase de marquage qui va être décrite dans la section suivante. Vous devez garder ceci en mémoire pour la suite.

• Style anglais décent.
• Phrases entières.
• Division des paragraphes.
• Utilisation des formats de chaîne à la place de la concaténation de chaînes.
• Éviter les marquage et les caractères de contrôle inusuels.

Regardons quelques exemples d'application de ces conseils.

Les chaîne à traduire devraient être dans un style anglais correct. Si de l'argot avec des abréviations et des ellipses sont utilisés, la plupart du temps les traductrices ne comprendront pas les messages et produiront des traductions très inapropriées.

"%s: est paramètre \n"

Ceci est presque intraduisible : est-ce que l'item affiché est un paramètre ou le paramètre ?

"pas de correspondance"

L'ambiguïté de ce message le rend inintelligible : est-ce que le programme cherche de définir quelque chose dans le feu de l'action ? Est-ce que cela signifie "l'objet donné ne correspond pas au modèle"? Est-ce que cela signifie "le modèle ne correspond pas pour aucun de ces objets" ?

Dans les deux cas, ajouter plus de mots dans le message aiderait à la fois la traductrice et l'utilisateur de langue anglaise.

Les chaînes à traduire devraient être des phrases entières. Il est souvent impossible de traduire des verbes ou des adjectifs isolés de manière convenable.

printf ("Le fichier %s est %s protégé", filename, rw ? "write" : "read");

Le plupart des traductrices ne regarderont pas le source et verront simplement la chaîne "Le fichier %s est %s protégé", qui est inintelligible. Changez ceci en

printf (rw? "Le fichier %s est protégé contre l'écriture" : "Le fichier %s
est protégé contre la lecture",
           filename:

De cette façon la traductrice ne fera pas que comprendre le message, elle sera aussi capable de trouver la construction grammaticale appropriée. Un traductrice française par exemple traduit "write protected" en 'protégé contre l'écriture".

Les phrases entières sont aussi importantes, car dans beaucoup de langues, la déclinaison de certains mots dans la phrase dépends du genre ou du nombre (singulier/pluriel) d'une autre partie de la phrase. Il y a habituellement plus d'inter-dépendance entre les mots qu'il y a en anglais. En conséquence, demander à une traductrice de traduire deux êmoitiés de phrase et les combiner ensuite en une seule phrase ne marchera pas pour beaucoup de langue, même si cela marcherait en anglais. C'est pourquoi les traductrices doivent travailler sur des phrases entières.

Souvent les phrases ne rentrent pas sur une seule ligne. Si une phrase est sortie en utilisant deux expressions printf successives comme celles ci :

printf ("Locale charset \"%s\" is different from\n", lcharset);
printf ("input file charset \"%s\".\n", fcharset);

la traductrice devrait traduire les deux moitiés de phrases, mais rien dans le fichier PO ne lui dira que les deux moitiés de phrases vont ensemble. Il est nécessaire de fusionner les deux expressions printf, de telle manière que la traductrice puisse travailler sur la phrase entière en une seule fois et décider à quel endroit il faut insérer une rupture de ligne dans la traduction (s'il y en a une) :

printf ("Locale charset \"%s\" is different from\n\
input file charset \"%s\".\n", lcharset, fcharset);

Vous pourriez maintenant demander : et comment fait-on avec les phrases adjacentes ? Comme dans ce cas :

puts ("Apollo 13 scenario: Stack overflow handling failed.");\n"
puts ("On the next stack overflow we will crash!!!");

Ces deux expressions doivent-elles être fusionnées en une seule ? Je recommanderais de les fusionner, si les deux phrases ont une relation entre elles, car cela facilite la compréhension de la traductrice pour les traduire toutes deux. D'un autre côté, si l'un des messages est stéréotypé et qu'il intervient à d'autres endroits, vous faciliterez la tâche de la traductrice en ne les fusionnant pas. (les messages identiques qui interviennent à plusieurs endroits sont combinés par xgettext, de telle manière que la traductrice ne les travaille qu'un seule fois).

les chaînes traduisibles devrait être limitées à un paragraphe ; ne laisser pas un message devenir plus long que dix lignes. La raison en est que quand la chaîne à traduire change, la traductrice doit alors modifier la chaîne traduite entièrement. Peut-être seulement un mot aura changé dans la chaîne en anglais, mais la traductrice ne le voit pas (avec les outils de traduction actuels), c'est pourquoi elle devra vérifier le message en entier.

Beaucoup de programme GNU ont une sortie ‘--help’ qui s'étend sur plusieurs pages. C'est une courtoisie envers la traductrice de scinder ces messages en plusieurs pages de cinq à dix lignes chacunes. Ce faisant, vous pouvez aussi scinder les options documentées en groupes, comme le groupe des options d'entrée, celui des options de sortie et celui des options de sorties informatives. Cela aidera tous les utilisateurs à trouver l'option qu'ils recherchent.

On utilise parfois des concaténations de chaînes codées en dur pour construire des phrases anglaise :

strcpy (s, "Replace ");
strcat (s, object1);
strcat (s, " with ");
strcat (s, object2);
strcat (s, "?");

Pour ne présenter que des phrases entières à la traductrice et aussi parceque dans certaines langues, la traductrice peut vouloir inverser l'ordre de object1 et object2, il est nécessaire de changer ceci pour utiliser une chaîne formatée :

sprintf (s, "Replace %s with %s?", object1, object2);

Un cas similaire est la concaténation des chaînes à la compilation. Le fichier ISO C 99 à en-tête <inttypes.h contient une macro PRId64 qui peut être utilisée comme une directive de formatage pour écrire un entier ‘int64_t’ avec printf. Il se développe en une chaîne constante, habituellement "d" ou "ld" ou "lld" ou quelque chose d'approchant, en fonction de la plateforme. Supposons que vous ayez un code comme celui ci

printf ("La quantité est %0" PRId64 "\n", number);

Les outils et bibliothèques de gettext ont un support particulier pour ces macros <inttypes.h>. C'est pourquoi vous pouvez simplement écrire

printf (gettext ("La quantité est %0" PRId64 "\n"), number);

Le fichier PO contiendra la chaîne "La quantité est %0<PRId64>\n". La traductrice donnera une traduction contenant aussi "%0<PRId64>" et au moment de l'exécution le résultat de la fonction gettext contiendra la chaîne constante appropriée, "d", "ld" ou "lld".

Ceci fonctionne pour les macros prédéfinie de <inttypes.h>. Si vous avez défini vos propres macros similaires, prenons par exemple ‘MYPRId64’, qui qui ne sont pas connues de gettext, la solution du problème est alors de changer le code de la façon suivante :

char buf1[100];
sprintf (buf1, "%0" MYPRId64, number);
printf (gettext ("La quantité est %s\n"), buf1);

Ceci signifie que vous avez mis le code dépendant de la plateforme dans une déclaration et le code d'internationalisation dans une déclaration différente. Notez qu'un tampon de longueur 100 est sûr, car tous les types entiers codés en dur sont limités à 128 bits et pour imprimer un entier codé en 128 bit, on a besoin d'au plus 54 caractères, indépendamment du fait qu'il soit en décimal, octal ou hexadécimal.

Tout ceci s'applique aussi aux autres langages de programmation. Par exemple en Java et C#, les concaténations de chaînes sont utilisées très fréquement, car c'est un opérateur intégré au compilateur. Comme en C, en Java vous changeriez

System.out.println("Replace "+object1+" with "+object2+"?");

en une déclaration utilisant une chaîne de formatage :

System.out.println(
    MessageFormat.format("Replace {0} with {1}?",
                         new Object[] { object1, object2 }));

De manière identique, en C# vous changeriez

Console.WriteLine("Replace "+object1+" with "+object2+"?");

en une déclaration utilisant une chaîne de formatage :

Console.WriteLine(
    String.Format("Replace {0} with {1}?", object1, object2));

Les balises et caractères de contrôle inhabituels ne devraient pas être utilisés dans le chaînes ) traduire. Il y a de fortes chances que Les traductrices ne comprendront pas la signification particulière de ces marquages et caractères de contrôle.

Par exemple, si vous avez une convention que ‘|’ délimite la partie main droite et main gauche d'un élément de l'Interface Utilisateur Graphique, sans commentaires spécifiques, les traductrices ne le comprendront pas la plupart du temps. Il serait peut être mieu que la traductrice traduise la partie main gauche et main droite séparemment.

Un autre exemple est la convention ‘argp’ pour utiliser un seul caractère ‘\v’ (tabulation verticale) pour délimiter deux sections à l'intérieur d'une chaîne. Ceci est défectueux. Certaines traductrices pourront convertir ceci en un simple nouvelle ligne, d'autre en une ligne blanche. Avec certains éditeurs de fichier PO, ceci ne sera même peut être pas facile d'entrer un caractère de contrôle pour une tabulation verticale. Donc vous ne pourrez pas être sûr que la traduction contiendra un caractère ‘\v’ à la position correspondante. La solution est encore une fois de laisser la traductrice traduire deux chaînes séparrées et de les combiner au moment de l'exécution avec le ‘\v’ requis par la convention.

Cependant les balises HTML sont communes et il est problablement acceptable de les utiliser dans les chaînes à traduire. Mais gardez néanmoins en mémoire que les outils GNU gettext ne vérifient pas que les traductions sont des expressions HTML bien formées.

4.4 Comment les marquages apparaissent dans les fichiers source

Toutes les chaînes requérant une traduction devraient être balisées dans les sources C. Le balisage est fait de telle manière que chaque chaîne à traduire apparaisse comme le seul paramètre de quelque fonction ou macro du pré-processeur. Il n'y a que quelques fonctions ou macros qui sont concernées par les traduction et leurs noms sont faits pour être des clés de balisage. Le balisage est attaché aux chaînes elles-mêmes plutôt qu'à ce que nous en faisons avec. Cette approche a plusieures utilités. Un exemple évident est un message d'erreur produit par formatage. La chaîne de format a besoin d'une traduction comme les quelques chaînes qui sont insérées par la spécification ‘%s’ dans le format alors que le résultat de sprintf peut avoir tellement d'instances différentes qu'il n'est pratiquement impossible de les lister toutes, disons dans quelque routine ‘error_string_out()’.

Cette opération de balisage a deux objectifs. Le premier objectif du balisage est de déclencher la récupération de la traduction au moment de l'exécution. Le mot clé peut être résolu en une routine capable de retourner dynamiquement la traduction correcte, autant que possible ou autant que voulu, pour la chaîne en paramètre. La plupart des chaînes à rendre dans l'idiome national sont trouvées dans les positions d'exécution, c'est-à-dire attachées à des variables ou données comme des paramètres aux fonctions. Mais ce n'est pas un usage universel et quelques chaînes à traduire apparaissent dans des initialisations structurées. @xref{cas spéciaux}.

Le second objectif de l'opération de balisage est d'aider xgettext à extraire correctement toutes les chaînes à traduire, quand il parcourt un ensemble de sources de programmes et produit des fichiers PO modèles.

Le mot clé canonique pour baliser une chaîne à traduire est ‘gettext’, ceci donne d'ailleurs son nom au progiciel GNU gettext en son entier. Pour les progiciels ne faisant qu'une utilisation légère du mot clé ‘gettex’, macro et fonction, il est facilement utilisé tel que. Cependant, pour les progiciels utilisant l'interface gettext de façon plus intensive, il est souvent plus pratique de donner au mot clé principal un nom plus court et moins voyant. En fait, le mot clé peut apparaître dans beaucoup de chaîne à travers le progiciel et les programmeurs ne veulent pas habituellement ni n'ont besoin que leur programme source les rappelle énergiquement à chaque fois qu'ils ont internationalisés. De plus un long mot clé à le désavantage d'utiliser plus d'espace, forçant un plus gros travail d'indentation sur les sources de ceux qui essaient de les garder entre 79 et 80 colonnes.

Beaucoup de progiciel utilisent ‘_’ (un simple soulignement) comme mot clé et écrive ‘_("chaîne à traduire")’ à la place de ‘gettext ("chaîne à traduire")’. De plus, la règle de programmation des standards GNU voulant qu'il y ait un espace entre le mot clé et la parenthèse ouvrante est oubliée en pratique, pour cet usage particulier. Ainsi l'entête textuel pour les chaînes à traduire est réduit à seulement trois caractères : le soulignement et les deux parenthèses. Cependant, même si GNU gettext utilise cette convention en interne, il ne l'offre pas officiellement. Le mot clé véritable et authentique est vraiment en réalité ‘gettext’. Il est assez facile pour ceux qui veulent utiliser ‘_’ à la place de ‘gettext’ de déclarer :

#include <libintl.h>
#define _(String) gettext (String)

à la place de n'utiliser que ‘#include <libintl.h>’.

Les balises ‘gettext’ et ‘_’ prennent les chaînes à traduire comme seul argument. Il est aussi possible de définir des fonctions de balisage qui les prennent comme argument à d'autres positions. Il est même possible de faire dépendre la position de l'argument balisé du nombre total d'arguments de l'appel de la focntion ; ceci est utile en C++. Tout ceci est obtenu en utilisant l'option gettext ‘--keyword’.

Notez aussi que les longues chaînes peuvent être coupées à travers les lignes, en multiples morceaux de chaînes adjacents. La concaténation automatique de chaîne est faite au moment de la compilation en accord avec l'ISO C ou l'ISO C++ ; xgettext permet aussi cette syntaxe.

Plus tard, la maintenant est relativement simple. Si, en tant que programmeur, vous ajoutez ou modifiez une chaîne, il faudra vous poser la question si le nouvelle chaîne, ou la chaîne modifiée, requiert une traduction et l'inclure avec ‘_()’, si vous pensez qu'elle doit être traduite. Par exemple, ‘"%s"’ est un exemple de chaîne de requérant pas de traduction. Mais ‘"%s: %d"’ requiert une traduction, car en français, à la différence de l'anglais, l'usage veut qu'on place un espace avant les deux points.

4.5 Marquage des chaînes à traduire

balisage

Dans le mode PO, un jeu de fonctionalités est prévu plus pour le programmeur que pour la traductrice et lui permet de baliser interactivement dans un jeu de programmes sources les chaînes qui doivent être traduites et celles qui ne le doivent pas. Même si c'est une tâche plutôt simple pour un programmeur que de trouver et de baliser de telles chaînes par d'autres moyens en utilisant un éditeur de son choix, le mode PO rend cette tâche plus confortable. De plus, ceci donne aux traductrices qui se sentent un peu programmeur ou au programmeurs qui se sentent un peu traductrice, un outil qui leur permet de travailler à baliser les chaînes à traduire dans les sources du programme, tout en produisant simultanément un jeu de traduction dans une langue, pour que le progiciel soit internationalisé.

programmes sources visé par les commandes du mode PO décrites ici, devrait avoir une table de balises construites pour votre projet, avant d'utiliser ces commandes de fichier PO. C'est facile à faire. Dans n'importe quel fenêtre de Shell, changer le répertoire pour aller à la racine de votre projet et exécuter une commande ressemblant à :

etags src/*.[hc] lib/*.[hc]

en présumant ici que vous vouliez traiter tous les fichiers ‘.h’ et ‘.c’ depuis les répertoires ‘src/’ et ‘lib/’. Cette commande explorera tous les dits fichiers et créera un fichier ‘TAGS’ dans votre répertoire racine, résumant à peu prêt les contenus en utilisant un fichier avec un format particulier qu'Emacs peut comprendre.

progiciels qui suivent les standards de codage GNU, il existe un fichier make ayant pour objectif tags ou TAGS, qui construit le fichier de balises dans tous les répertoires et pour tous les fichiers contenant du code source.

Une fois que votre fichier ‘TAGS’ est prêt, les commandes suivantes aident le programmeur à baliser les chaînes traduisibles dans son jeu de sources. Mais ces commandes sont nécessairement dirigées depuis une fenêtre d'un fichier PO et il est probable que vous n'ayez même pas encore un tel fichier PO. Ceci n'est pas un problème du tout, car vous pouvez en ouvrir un nouveau en toute sécurité, un fichier PO vide, principalement pour utiliser ces commandes. Ce fichier PO vide va se remplir lentement en même temps que vous marquez des chaînes comme chaînes à traduire dans les sources de votre programme.

,

@efindex, , commande mode PO Recherche à travers les sources du programme une chaîne, qui ressemble à une chaîne pouvant être traduite (po-tags-search).

M-,

‘_()’ (po-mark-translatable).

M-.

mot clé pris dans les mots clés possibles. Cette commande avec un préfixe permet une certaine gestion de ces mots clés (po-select-mark-and-mark).

(po-tags-search) cherche les prochaines occurrences d'un chaîne qui ressemble à une chaîne pouvant être traduite et affiche le programme source dans une autre fenêtre Emacs, positionné de façon à ce que la chaîne soit proche du bord supérieur de cette autre fenêtre. Si la chaîne est trop longue pour tenir entièrement dans cette fenêtre, elle est positionnée de façon à ce que seule sa fin soit montrée. Dans tous les cas, le curseur est laissé dans la fenêtre du fichier PO. Si la chaîne montrée serait mieux présentée différement dans d'autres langues nationales, vous pourriez le marquer en utilisant M-, ou M-.. Autrement vous pouvez tout autant l'ignorer et passez à la prochaine chaîne en répétant juste la commande ,.

Une chaîne est une chaîne bonne à traduire si elle contient une séquence de trois lettres ou plus. Un chaîne contenant au plus deux lettres dans une rangée sera considérée comme une chaîne à traduire s'il elle a plus de lettres que de non-lettres. La commande ne considère pas les chaînes qui ne contiennent pas de lettres, ou seulement des lettres isolées. Elle ne considère pas non plus les chaînes à l'intérieur des commentaires ou les chaînes déjà balisée avec quelques mots clés que le mode PO connait (voir ci dessous).

Si vous n'avez jamais donné à Emacs quelques fichiers ‘TAGS’ à utiliser, la commande demandera que vous en spécifiez un dans la mini zone tampon, la première fois que vous utiliserez la commande. Vous pourrez changer votre fichier ‘TAGS’ plus tard en utilisant la commande habituelle d'Emacs M-x visit-tags-table, qui vous demandera de nommer le fichier ‘TAGS’ précis que vous voulez utiliser. Voir (Emacs)balises section `tables de balises' dans l'éditeur Emacs.

Chaque fois que vous utilisez la commande ,, la recherche démarre depuis là où vous l'aviez arrêté la fois précédente et elle parcourt tous les sources du programme, obéissant au fichier ‘TAGS’ jusqu'à ce que tous les sources aient été traités. Cependant en donnant un argument en préfixe à la commande (C-u ,), vous pouvez demander que la recherche complètement de nouveau depuis le premier programme source ; mais dans ce cas, les chaînes que vous avez récemment balisées comme des chaînes à traduire seront passées automatiquement.

L'utilisation de la commande , ne vous empèche pas d'utiliser les autres commandes de balisage d'Emacs. Par exemple, les commandes habituelles tags-search ou tags-query-replace peuvent être utilisées sans interrompre la séquence de recherche indépendante de la commande {,. Cependant, comme implémenté, la commande initiale , (ou la commande , qui est utilisée avec un préfixe) peut aussi ré-intialiser la recherche habituelle d'Emacs au premier fichier de balises, cette ré-intialisation peut être non désirée.

La commande M-, (po-mark-translatable) marquera les chaînes récemment trouvée avec le mot clé ‘_’. La commande M-. (po-select-mark-and-mark) vous demandera de taper un mot-clé depuis la mini zone tampon et d'utiliser ce mot-clé pour marquer la chaîne. Les deux commandes créeront automatiquement un nouveau fichier PO des entrées non traduites pour les chaînes qui auront été marquée et en fera l'entrée courante (vous rendant facile le traitement immédiat de sa traduction, si vous vous sentez d'attaque de l'entreprendre immédiatement). Il est posssible que les modifications faites au programme source par M-, ou M-. rendent les lignes du sources plus longues que 80 colonnes, vous forçant de les ré-indenter et de les couper différement. Vous pouvez utiliser la commande O du mode PO ou n'importe quelle autre commande affectant les fenêtres dans Emacs, pour couper dans la fenêtre du programme source et d'y faire tous les ajustements nécessaires. Vous devrez utiliser quelques commandes habituelles d'Emacs pour renvoyer le curseur à la fenêtre du fichier PO, disons si vous voulez utiliser la commande , pour la prochaine chaîne.

La commande M-. a quelques fonctionalités intégrées de rapididé, de façon à ce que vous n'ayez pas à taper explicitement tous les mots-clés à chaque fois. La première de ces fonctionalités de rapidité est que que les mots-clés préférés vous sont présentés, que vous pouvez accepter en tapant simplement <RET> à l'invite de commande. La seconde fonctionalité de rapidité est que vous pouvez tapez les préfixes non-amiguës des mots-clés que vous voulez vraiment et la commande les complètera automatiquement pour vous. Ceci veut aussi dire que le mode PO doit connaître tous les mots-clés possibles et qu'il n'accèptera pas les mots clés tapés incorrectement.

Si vous répondez ? à la demande de mot-clé, la commande vous donnera une liste de tous les mots-clés connus, dans laquelle vous pourrez choisir. Quand la commande est préfixée par un argument (C-u M-.), ceci empêche la mise à jour de tout programme source ou de zone tampon PO et ne fait qu'une gestion de mot-clé à la place. Dans ce cas, la commande demande un mot-clé, écrit en entier, qui devient un nouveau mot-clé permis pour les futures utilisaton de la commande M-.. De plus, ce nouveau mot-clé devient automatiquement le mot-clé préféré pour les prochaines commandes. En tapant un mot-clé déjà connu en réponse à C-u M-., on change juste le mot-clé préféré et rien de plus.

Quand les chaînes sont scruttées, tous les mots clés connus par M-. sont reconnu par la commande , et les chaînes déjà marquées par n'importe lequel de ces mots-clés connus sont automatiquement sautées. Si beaucoup de fichier PO sont ouverts simultanément, chacun a son jeu de mots-clés connus indépendant. Il n'y a —pour le moment— aucune disposition dans le mode PO pour effacer un mot-clé connu. Vous devez quitter le fichier (par exemple en utilisant q) et le ré-ouvrir tout frais. Quand un fichier PO est juste ouvert dans une fenêtre Emacs, les seuls mots-clés connus sont ‘gettext’ et ‘_’ et ‘gettext’ est préféré pour la commande M-.. En fait, il n'est pas utile de préférer ‘_’, car celui ci est déjà intégré dans la commande M-,.

4.6 Les commentaires spéciaux précédants les mots-clés

Dans les programmes C, les chaînes sont souvent utilisées à l'intérieur d'appels de fonctions de la famille des printf. La spécialité de ces chaînes formattées est qu'elles contiennent des spécifications de format introduites par %. Suppsons que nous ayons le code

printf (gettext ("String `%s' has %d characters\n"), s, strlen (s));

Une traduction possible en allemand pour la chaîne ci dessus serait:

"%d Zeichen lang ist die Zeichenkette `%s'"

Un programmeur C, même s'il ne parle pas allemand, reconnaitra qu'il y a quelque chose qui ne va pas ici. L'ordre des deux spécifications de formats précédant est changée, mais bien sûr les arguments dans la fonctions printf ne le sont pas. Ceci conduira probablement à des problèmes car maintenant la

longueur de la chaîne est considérée comme l'adresse.

Pour prévenir les erreurs au moment de l'exécution causée par les traductions, l'outil msgfmt peut vérifier statiquement si les arguments dans la chaîne originale et sa traduction correspondent en genre et en nombre. Si ce n'est pas le cas et que l'option ‘-c’ a été passée à msgfmt, msgfmt donnera une erreur et refusera de produire le fichier MO. L'utilisation avisée de ‘msgfmt -c’ interceptera l'erreur, de façon à ce qu'elle ne cause pas de problème au moment de l'exécution.

Si l'ordre les mots dans la traducitons allemande ci dessus avait été correcte, on aurait eu à écrire

"%2$d Zeichen lang ist die Zeichenkette `%1$s'"

Les routines dans msgfmt connaissent ce genre de notation spéciale.

Parceque toutes les chaînes dans un programme ne sont pas des châînes formattées, il n'est pas utile pour msgfmt de tester toutes le chaînes dans un fichier ‘.po’. Ceci peut être la source de problème car la chaîne peut contenir ce quu peut ressembler à une spécification de format, sans que la chaîne ne soit utilisée dans printf.

C'est pourquoi xgettext ajoute une balise spéciale pour ces messages qu'il croit être des chaînes formattées. Il n'y a pas de règle absolue pour cela, seulement une heuristique. Dans le fichier ‘.po’, l'entrée est marquée en utilisant le marquer de c-format dans la ligne commentée #, (@pxref{fichiers PO}).

Le lecteur attentif pourrait maintenant dire, que c'est ceci peut encore causer des problèmes. L'heuristique peut l'interpréter de manière erronnée. Ceci est vrai et c'est pourquoi xgettext connait un certain type de commentaire qui laisse le programmeur prendre la décision. Si programme xgettext trouve un commentaire contenant les mots xgettext:c-format sur la même ligne que le mot-clé gettext, ou la ligne la précédant immédiatement, il marquera la chaîne dans tous les cas avec la marque c-format. Cette sorte de commentaire devrait être utilisé quand xgettext ne reconnait pas la chaîne comme une chaîne formattée, mais qu'elle en ai vraiment une et que cela devrait être vérifié.

Cette situation arrive assez souvent. La fonction printf est souvent appelée avec des chaînes qui ne contiennent pas de spécification de format. Bien sûr on devrait normalement utiliser fputs, mais ceci arrive tout de même. Dans ce cas xgettext ne reconnait pas la chaîne comme une chaîne formattée, mais qu'arrive-t-il si la traduction introduit une spécification de format valide. ? La fonction printf cherchera à accéder à l'un des paramètres, mais aucun n'existe parceque le code original ne passe aucun paramètre.

xgettext pourrait bien sûr prendre une mauvaise décision dans le sens contraire, i.e. une chaîne marquée comme une chaîne formattée ne serait pas en réalité une chaîne formatté. Dans ce cas le programme msgfmt pourrait donner trop d'avertissements et empêcherait de traduire le fichier ‘.po’. La méthode pour empêcher cette mauvaise décision est identique à celle utilisée ci dessus, seul le commentaire à utiliser doit contenir la chaîne xgettext:no-c-format.

Si une chaîne est marquée avec c-format et que ce n'est pas correct, l'utilisateur peut retrouver qui est responsable de cette décision. Voir Invocation le programme msginit pour voir comme l'option --debug peut être utilisé pour régler ce problème.

4.7 Cas spéciaux de chaînes à traduire

Le lecteur attentif pourrait maintenant objecter qu'il n'est pas toujours possible de marquer les chaînes à traduire avec gettext ou quelque chose d'analogue. Considérez le cas suivant :

{
 static const char *messages[] = {
   "some very meaningful message",
   "and another one"
 };
 const char *string;
 …
 string
   = index > 1 ? "a default message" : messages[index];

 fputs (string);
 …
}

Alors que ce n'est pas un problème de marquer la chaîne "a default message", il n'est pas possible de marquer les initialisateurs de chaines pour messages. Que faut-il faire ? Nous devons réaliser deux tâches. Tout d'abord, nous devons marquer les chaînes de façon à ce que le programme xgettext (voir la section Invocation le programme msginit puisse les trouver et ensuite nous devons traduire les chaînes au moment de l'exécution avant de les imprimer.

La première tâche peut être réalisée en créant un nouveau mot clé, qui nomme une no-op. Pour la seconde, nous devons marquer tous les points d'accès à une chaîne depuis le vecteur. Donc une solution pourrait ressembler à ceci :

#define gettext_noop(String) String

{
 static const char *messages[] = {
   gettext_noop ("some very meaningful message"),
   gettext_noop ("and another one")
 };
 const char *string;
 …
 string
   = index > 1 ? gettext ("a default message") : gettext "
(messages[index]);

 fputs (string);
 …
}

Vous devez vous convaincre que la chaîne, qui est écrite par fputs est traduite dans tous les cas. La façon d'obtenir que xgettext connaisse le mot-clé additionel gettext_noop est expliqué dans Invocation le programme msginit.

Ce qui est décrit ci dessus n'est bien sûr pas la seule solution. Vous auriez pu aussi vous en sortir avec la façon suivante :

#define gettext_noop(String) String

{
 static const char *messages[] = {
   gettext_noop ("some very meaningful message",
   gettext_noop ("and another one")
 };
 const char *string;
 …
 string
   = index > 1 ? gettext_noop ("a default message") : messages[index];

  fputs (gettext (string));
  …
}

Mais ceci a un inconvénient. Le programmeur doit prendre garde d'utiliser gettext_noop pour la chaîne "a default message". L'utilisation de gettext pourrait avoir dans des cas rares des résultats imprévisibles.

Un avantage est que vous n'avez pas besoin de faire du contrôle d'analyse de flux pour vous assurer que la sortie est traduite dans tous les cas. Mais cette analyse est générallement pas très difficile. Si ça devait l'être, dans ce cas vous pourrez utiliser cette seconde méthode en toute situation.

4.8 Laisser les utilisateurs rapporter les bogues de traduction

Le code a parfois des bogues, mais les traductions ont aussi parfois des bogues. L'utilisateur doit pouvoir les rapporter. Rapporter les bogues de traduction au programmeur ou au mainteneur d'un progiciel n'est pas très utile, parceque le mainteneur ne doit jamais changer une traduction, excepté pour le compte de la traductrice. C'est pourquoi les bogues de la traduction doivent être rapportés aux traductrices.

Voici un moyen d'organiser ceci, de façon à ce que le mainteneur n'ait pas besoin de faire suivre les rapports de bogues de traduction et même pas de garder une liste des adresses des traductrices ou de leurs équipes de traduction.

Tous les programmes ont une place où ils montrent les adresses de rapport de bogues. Pour les programmes GNU, c'est le code qui gère l'option “–help”, typiquement dans une fonction appelée “usage”. Instruisez les traductrices d'ajouter à cette place leur propre adresse de rapport de bogue. Par exemple, si le code a une instruction

printf (_("Report bugs to <%s>.\n"), PACKAGE_BUGREPORT);

vous pouvez ajouter quelques instructions de traductrice comme ceci :

/* TRANSLATORS: The placeholder indicates the bug-reporting address
  for this package.  Please add _another line_ saying
  "Report translation bugs to <...>\n" with the address for translation
  bugs (typically your translation team's web or email address).  */
printf (_(\"Report bugs to <%s>.\n"), PACKAGE_BUGREPORT);

Ceci sera extrait par ‘xgettext’, conduisant à un fichier .pot qui contiendra ceci :

#. TRANSLATORS: The placeholder indicates the bug-reporting address
#. for this package.  Please add _another line_ saying
#. "Report translation bugs to <...>\n" with the address for "
translation
#. bugs (typically your translation team's web or email address).
#: src/hello.c:178
#, c-format
msgid "Report bugs to <%s>.\n"
msgstr ""

4.9 Marquage des noms correctement pour les traductions

Est-ce que le nom des personnes, villes, localisation etc ... doit être marqué pour les traductions ou non ? Les personnes, qui ne connaissent que les langues, qui peuvent s'écrire avec les lettres latines (l'anglais, l'espagnol, le français, l'allemant etc@dots) sont tentées de dire “non”, car les noms souvent ne changent pas quand ils sont transportés entre ces langues. Cependant, en général quand on traduit d'une écriture à une autre, les noms sont aussi traduit, habituellement phonétiquement ou par translitération. Par exemple, les noms russes ou grec sont convertis dans l'alphabet latin quand ils sont traduits en anglais et les noms anglais ou français sont convertis en écriture katana quand ils sont traduits en japonais. Ceci est nécessaire car les locuteurs de la langue cible ne savent pas, en général, lire l'écriture dans laquelle le nom était écrit à l'origine.

En tant que programmeur, vous devriez donc vous assurer que les noms soient marqués pour traduction avec un commentaire spécial disant aux traductrices que c'est un nom propre et comment le prononcer. Comme ceci :

printf (_("Written by %s.\n"),
       /* TRANSLATORS: This is a proper name.  See the gettext
          manual, section Names.  Note this is actually a non-ASCII
          name: The first name is (with Unicode escapes)
          "Fran\u00e7ois" or (with HTML entities) "François".
          Pronunciation is like "fraa-swa pee-nar".  */
       _("Francois Pinard"));

Comme traductrice, vous devriez faire attention quand vous traduisez les noms, car il est frustrant pour les personnes de voir leur noms mutilés ou distordus. Si votre langue utiliser l'alphabet latin, tout ce dont bous avez besoin est de reproduire le nom aussi parfaitement que possible avec les jeux de caractères habituels de votre langue. Dans ce cas particulier, ceci signifie de donner une traduction contenant le caractère c-cédille. Si votre langue utilise une autre écriture et les personnes parlant cette langue ne lisent pas habituellement les mots latin, cela signifie une translitération ; mais vous devriez toujours donner, entre paranthèses, l'écriture original du nom —pour l'usage des personnes sachant lire les écritures latines. Voici une exemple, utilisant le grec comme langue cible :

#. This is a proper name.  See the gettext
#. manual, section Names.  Note this is actually a non-ASCII
#. name: The first name is (with Unicode escapes)
#. "Fran\u00e7ois" or (with HTML entities) "François".
#. Pronunciation is like "fraa-swa pee-nar".
msgid "Francois Pinard"
msgstr "\phi\rho\alpha\sigma\omicron\alpha "
\pi\iota\nu\alpha\rho"
      " (Francois Pinard)"

Parceque la traduction des noms est un sujet sensible, c'est une bonne idée de tester votre traduction avant de la soumettre.

Le projet de traduction http://sourceforge.net/projects/translation a défini un fichier POT et un domaine de traduction qui est consitués des noms des auteurs de programmes, avec de meilleures fonctionalités pour les traductrices que celles présentées ici. Nommément, il y a le nom original écrit directement en unicode (plutôt qu'avec des échappements unicode ou des entités HTML) et la prononciation est notée en utilisant l'alphabet phonétique international (voir http://www.wikipedia.org/wiki/International_Phonetic_Alphabet).

Cependant, nous ne recommendons pas cette approche pour tous les fichier POT dans tous les progiciels, car cela forcerait les traductrices d'utiliser des fichiers PO avec l'encodage UTF-8, qui est — dans l'état actuel du logiciel (en 2003) — un harrassement majeur pur les traductrices utilisant GNU Emacs ou XEmacs avec po-mode.

4.10 Préparation des fichiers source d'une bibliothèque

Quand vous êtes en train de préparer une bibliothèque, pas un programme, pour l'utilisation de gettext, seulement quelques détails sont différents. Ici nous assumons que la bibliothèque a un domaine de traduction et un fichier POT pour elle même. (si elle utilise le domaine de traduction et le fichier POT du programme principal, alors la section précédentes s'applique sans changement.)

1. Le code de la bibliothèque n'appelle pas setlocale (LC_ALL, ""). C'est la responsabilité du programmeur principal, que de définir la localisation. La documentation de la bibliothèque devrait en fait le mentioner, de façon à ce que les développeurs de programmes utilisant cette bibliothèque en soient conscient.
2. Le code de la bibliothèque n'appelle pas textdomain (PACKAGE), car cela interfèrerait avec le domaine de texte défini par le programme principal.
3. Le code d'initialisation pour le programme était

   setlocale (LC_ALL, ""); bindtextdomain (PACKAGE, LOCALEDIR); textdomain (PACKAGE);

   Pour une bibliothèque il est réduit à

   bindtextdomain (PACKAGE, LOCALEDIR);

   Si l'API (-ndt Interface de Programmation de l'Application) de votre bibliothèque n'a pas déjà une fonction d'initialisation, vous aurez besoin d'en créer une, contenant au moins l'invocation de bindtextdomain. Cependant vous n'aurez pas besoin habituellement d'exporter et de documenter cette fonction d'initialisation : il est suffisant que tous les points d'entrée de la bibliothèque appèlent la fonction d'initialisation si elle n'a pas été appelée avant. L'idiome type pour parvenir à ceci est une variable booléenne statique, qui indique si la fonction d'initialisation a été appelée, comme ceci :

   static bool libfoo_initialized; static void libfoo_initialize (void) { bindtextdomain (PACKAGE, LOCALEDIR); libfoo_initialized = true; } /* This function is part of the exported API. */ struct foo * create_foo (...) { /* Must ensure the initialization is performed. */ if (!libfoo_initialized) libfoo_initialize (); ... } /* This function is part of the exported API. The argument must be non-NULL and have been created through create_foo(). */ int foo_refcount (struct foo *argument) { /* No need to invoke the initialization function here, because create_foo() must already have been called before. */ ... }

4. La déclaration habituelle de la macro ‘_’ dans chaque fichier source était

   #include <libintl.h> #define _(String) gettext (String)

   pour un programme. Pour une bibliothèque, qui a son propre domaine de traduction, ceci ce lit comme ceci :

   #include <libintl.h> #define _(String) dgettext (PACKAGE, String)

   En d'autres termes, dgettext est utilisé à la place de gettext. De manière similaire, la fonction dngettext devrait être utilisée à la place de la fonction ngettext.

5. La fabrication du fichier modèle PO.

Après avoir préparer les sources, le programmeur crée un fichier PO modèle (-ndt template file). Cette section explique comment utiliser xgettex dans ce but.

xgettext crée un fichier nommé ‘nomdomaine.po’. Vous devriez le renommer en ‘nomdomaine.pot’. (Pourquoi xgettext ne le crée pas tout de suite sour le nom ‘nomdomaine.pot’ ? La réponse est : pour des raisons historiques. Quand xgettext a été spécifié, la distinction entre les fichiers PO et les modèle (-ndt template) de fichier PO était floue et le suffixe ‘.pot’ n'était pas utilisé à cette époque.)

5.1 Invocation le programme msginit

xgettext [option] [inputfile] …

Le programme xgettext extrait les chaînes à traduire depuis un fichier entrée donné.

5.1.1 Input file location

‘inputfile …’

Input files.

‘-f file’

‘--files-from=file’

Read the names of the input files from file instead of getting them from the command line.

‘-D directory’

‘--directory=directory’

Add directory to the list of directories. Source files are searched relative to this list of directories. The resulting ‘.po’ file will be written relative to the current directory, though.

If inputfile is ‘-’, standard input is read.

5.1.2 Output file location

‘-d nom’

‘--default-domain=nom’

Use ‘name.po’ for output (instead of ‘messages.po’).

‘-o file’

‘--output=file’

Write output to specified file (instead of ‘name.po’ or ‘messages.po’).

‘-p rép’

‘--output-dir=rép’

Output files will be placed in directory dir.

Si le fichier de sortie est ‘-’ ou ‘/dev/stdout’, la sortie est écrite sur la sortie standard.

5.1.3 Choix du language d'entrée

‘-L nom’

‘--language=nom’

Spécifie le langage du fichier d'entrée. Les langages supportés sont C, C++, ObjectiveC, PO, Python, Lisp, EmacsLisp, librep, Scheme, Smalltalk, Java, JavaProperties, C#, awk, YCP, Tcl, Perl, PHP, GCC-source, NXStringTable, RST, Glade.

‘-C’

‘--c++’

This is a shorthand for --language=C++.

Par défaut, le langage est déduit de l'extension du nom du fichier.

5.1.4 Input file interpretation

‘--from-code=nom’

Specifies the encoding of the input files. This option is needed only if some untranslated message strings or their corresponding comments contain non-ASCII characters. Note that Tcl and Glade input files are always assumed to be in UTF-8, regardless of this option.

Par défaut les fichiers d'entrée sont considérés avoir été codés en ASCII.

5.1.5 Operation mode

‘-j’

‘--join-existing’

Join messages with existing file.

‘-x fichier’

‘--exclude-file=fichier’

Entries from file are not extracted. file should be a PO or POT file.

‘-c [balise]’

‘--add-comments[=balise]’

Place comment block with tag (or those preceding keyword lines) in output file.

5.1.6 Options spécifiques sur les languages

‘-a’

‘--extract-all’

Extract all strings.

Cette option fonctionne avec la plupart des langages, nommément C, C++, ObjectiveC, Shell, Python, Lisp, EmacsLisp, librep, Java, C#, awk, Tcl, Perl, PHP, GCC-source, Glade.

‘-k specmotclé’

‘--keyword[=specmotclé]’

Additional keyword to be looked for (without keywordspec means not to use default keywords).

If keywordspec is a C identifier id, xgettext looks for strings in the first argument of each call to the function or macro id. If keywordspec is of the form ‘id:argnum’, xgettext looks for strings in the argnumth argument of the call. If keywordspec is of the form ‘id:argnum1,argnum2’, xgettext looks for strings in the argnum1st argument and in the argnum2nd argument of the call, and treats them as singular/plural variants for a message with plural handling. Also, if keywordspec is of the form ‘id:contextargnumc,argnum’ or ‘id:argnum,contextargnumc’, xgettext treats strings in the contextargnumth argument as a context specifier. And, as a special-purpose support for GNOME, if keywordspec is of the form ‘id:argnumg’, xgettext recognizes the argnumth argument as a string with context, using the GNOME glib syntax ‘"msgctxt|msgid"’.
Furthermore, if keywordspec is of the form ‘id:…,totalnumargst’, xgettext recognizes this argument specification only if the number of actual arguments is equal to totalnumargs. This is useful for disambiguating overloaded function calls in C++.
Finally, if keywordspec is of the form ‘id:argnum...,"xcomment"’, xgettext, when extracting a message from the specified argument strings, adds an extracted comment xcomment to the message. Note that when used through a normal shell command line, the double-quotes around the xcomment need to be escaped.

Cette option fonctionne avec la plupart des langages, nommément C, C++, ObjectiveC, Shell, Python, Lisp, EmacsLisp, librep, Java, C#, awk, Tcl, Perl, PHP, GCC-source, Glade.

The default keyword specifications, which are always looked for if not explicitly disabled, are language dependent. They are:

• For C, C++, and GCC-source: gettext, dgettext:2, dcgettext:2, ngettext:1,2, dngettext:2,3, dcngettext:2,3, gettext_noop, and pgettext:1c,2, dpgettext:2c,3, dcpgettext:2c,3, npgettext:1c,2,3, dnpgettext:2c,3,4, dcnpgettext:2c,3,4.
• For Objective C: Like for C, and also NSLocalizedString, _, NSLocalizedStaticString, __.
• For Shell scripts: gettext, ngettext:1,2, eval_gettext, eval_ngettext:1,2.
• For Python: gettext, ugettext, dgettext:2, ngettext:1,2, ungettext:1,2, dngettext:2,3, _.
• For Lisp: gettext, ngettext:1,2, gettext-noop.
• For EmacsLisp: _.
• For librep: _.
• For Scheme: gettext, ngettext:1,2, gettext-noop.
• For Java: GettextResource.gettext:2, GettextResource.ngettext:2,3, GettextResource.pgettext:2c,3, GettextResource.npgettext:2c,3,4, gettext, ngettext:1,2, pgettext:1c,2, npgettext:1c,2,3, getString.
• For C#: GetString, GetPluralString:1,2, GetParticularString:1c,2, GetParticularPluralString:1c,2,3.
• For awk: dcgettext, dcngettext:1,2.
• For Tcl: ::msgcat::mc.
• For Perl: gettext, %gettext, $gettext, dgettext:2, dcgettext:2, ngettext:1,2, dngettext:2,3, dcngettext:2,3, gettext_noop.
• For PHP: _, gettext, dgettext:2, dcgettext:2, ngettext:1,2, dngettext:2,3, dcngettext:2,3.
• For Glade 1: label, title, text, format, copyright, comments, preview_text, tooltip.

To disable the default keyword specifications, the option ‘-k’ or ‘--keyword’ or ‘--keyword=’, without a keywordspec, can be used.

‘--flag=word:arg:flag’

Specifies additional flags for strings occurring as part of the argth argument of the function word. The possible flags are the possible format string indicators, such as ‘c-format’, and their negations, such as ‘no-c-format’, possibly prefixed with ‘pass-’.
The meaning of --flag=function:arg:lang-format is that in language lang, the specified function expects as argth argument a format string. (For those of you familiar with GCC function attributes, --flag=function:arg:c-format is roughly equivalent to the declaration ‘__attribute__ ((__format__ (__printf__, arg, ...)))’ attached to function in a C source file.) For example, if you use the ‘error’ function from GNU libc, you can specify its behaviour through --flag=error:3:c-format. The effect of this specification is that xgettext will mark as format strings all gettext invocations that occur as argth argument of function. This is useful when such strings contain no format string directives: together with the checks done by ‘msgfmt -c’ it will ensure that translators cannot accidentally use format string directives that would lead to a crash at runtime.
The meaning of --flag=function:arg:pass-lang-format is that in language lang, if the function call occurs in a position that must yield a format string, then its argth argument must yield a format string of the same type as well. (If you know GCC function attributes, the --flag=function:arg:pass-c-format option is roughly equivalent to the declaration ‘__attribute__ ((__format_arg__ (arg)))’ attached to function in a C source file.) For example, if you use the ‘_’ shortcut for the gettext function, you should use --flag=_:1:pass-c-format. The effect of this specification is that xgettext will propagate a format string requirement for a _("string") call to its first argument, the literal "string", and thus mark it as a format string. This is useful when such strings contain no format string directives: together with the checks done by ‘msgfmt -c’ it will ensure that translators cannot accidentally use format string directives that would lead to a crash at runtime.
This option has an effect with most languages, namely C, C++, ObjectiveC, Shell, Python, Lisp, EmacsLisp, librep, Scheme, Java, C#, awk, YCP, Tcl, Perl, PHP, GCC-source.

‘-T’

‘--trigraphs’

Understand ANSI C trigraphs for input.
This option has an effect only with the languages C, C++, ObjectiveC.

‘--qt’

Recognize Qt format strings.
This option has an effect only with the language C++.

‘--kde’

Recognize KDE 4 format strings.
This option has an effect only with the language C++.

‘--boost’

Recognize Boost format strings.
This option has an effect only with the language C++.

‘--debug’

Use the flags c-format and possible-c-format to show who was responsible for marking a message as a format string. The latter form is used if the xgettext program decided, the format form is used if the programmer prescribed it.

By default only the c-format form is used. The translator should not have to care about these details.

This implementation of xgettext is able to process a few awkward cases, like strings in preprocessor macros, ANSI concatenation of adjacent strings, and escaped end of lines for continued strings.

5.1.7 Output details

‘--force-po’

Always write an output file even if no message is defined.

‘-i’

‘--indent’

Write the .po file using indented style.

‘--no-location’

Do not write ‘#: filename:line’ lines. Note that using this option makes it harder for technically skilled translators to understand each message's context.

‘-n’

‘--add-location’

Generate ‘#: filename:line’ lines (default).

‘--strict’

Write out a strict Uniforum conforming PO file. Note that this Uniforum format should be avoided because it doesn't support the GNU extensions.

‘--properties-output’

Write out a Java ResourceBundle in Java .properties syntax. Note that this file format doesn't support plural forms and silently drops obsolete messages.

‘--stringtable-output’

Write out a NeXTstep/GNUstep localized resource file in .strings syntax. Note that this file format doesn't support plural forms.

‘-w number’

‘--width=number’

Set the output page width. Long strings in the output files will be split across multiple lines in order to ensure that each line's width (= number of screen columns) is less or equal to the given number.

‘--no-wrap’

Do not break long message lines. Message lines whose width exceeds the output page width will not be split into several lines. Only file reference lines which are wider than the output page width will be split.

‘-s’

‘--sort-output’

Generate sorted output. Note that using this option makes it much harder for the translator to understand each message's context.

‘-F’

‘--sort-by-file’

Sort output by file location.

‘--omit-header’

Don't write header with ‘msgid ""’ entry.

This is useful for testing purposes because it eliminates a source of variance for generated .gmo files. With --omit-header, two invocations of xgettext on the same files with the same options at different times are guaranteed to produce the same results.

Note that using this option will lead to an error if the resulting file would not entirely be in ASCII.

‘--copyright-holder=string’

Set the copyright holder in the output. string should be the copyright holder of the surrounding package. (Note that the msgstr strings, extracted from the package's sources, belong to the copyright holder of the package.) Translators are expected to transfer or disclaim the copyright for their translations, so that package maintainers can distribute them without legal risk. If string is empty, the output files are marked as being in the public domain; in this case, the translators are expected to disclaim their copyright, again so that package maintainers can distribute them without legal risk.

The default value for string is the Free Software Foundation, Inc., simply because xgettext was first used in the GNU project.

‘--foreign-user’

Omit FSF copyright in output. This option is equivalent to ‘--copyright-holder=''’. It can be useful for packages outside the GNU project that want their translations to be in the public domain.

‘--package-name=package’

Set the package name in the header of the output.

‘--package-version=version’

Set the package version in the header of the output. This option has an effect only if the ‘--package-name’ option is also used.

‘--msgid-bugs-address=email@address’

Set the reporting address for msgid bugs. This is the email address or URL to which the translators shall report bugs in the untranslated strings:

• - Les chaînes qui ne sont pas des phrases entières, voir les directives du mainteneur dans @ref{préparation des chaînes}.
• - Les chaînes, qui utilisent des termes obscures ou demande un contexte supplémentaire pour être comprises.
• - Les chaînes qui font des hypothèses invalides sur les notations des dates, des temps ou la monaie.
• - Problèmes de mise au pluriel
• - Épellement anglais incorrect.
• - Formatage incorrect.

It can be your email address, or a mailing list address where translators can write to without being subscribed, or the URL of a web page through which the translators can contact you.

The default value is empty, which means that translators will be clueless! Don't forget to specify this option.

‘-m [string]’

‘--msgstr-prefix[=string]’

Use string (or "" if not specified) as prefix for msgstr entries.

‘-M [string]’

‘--msgstr-suffix[=string]’

Use string (or "" if not specified) as suffix for msgstr entries.

5.1.8 Sortie informative

‘-h’

‘--help’

Display this help and exit.

‘-V’

‘--version’

Output version information and exit.

6. La création d'un nouveau fichier PO.

Quand vous débuttez une nouvelle traduction, la traductrice crée un fichier appelé ‘LANG.po’, comme une copie du fichier modèle ‘package.pot’ avec des modifications dans les commentaires initiaux (au début du fichier) et dans les entrées de l'en-tête (la première entrée, près du début du fichier).

La façon la plus simple de faire ceci est d'utilisr le programme ‘msginit’. Par exemple :

$ cd PACKAGE-VERSION
$ cd po
$ msginit

La façon alternative de faire ceci est de copier les modifications à la main. Pour ce faire, la traductrice copie ‘package.pot’ dans ‘LANG.po’. Ensuite elle modifie les commentaires initiaux et l'entrée de l'en-tête de ce fichier.

6.1 Invocation du programme msginit

msginit [option]

The msginit program creates a new PO file, initializing the meta information with values from the user's environment.

6.1.1 Input file location

‘-i inputfile’

‘--input=inputfile’

Input POT file.

If no inputfile is given, the current directory is searched for the POT file. If it is ‘-’, standard input is read.

6.1.2 Output file location

‘-o file’

‘--output-file=file’

Write output to specified PO file.

If no output file is given, it depends on the ‘--locale’ option or the user's locale setting. If it is ‘-’, the results are written to standard output.

6.1.3 Input file syntax

‘-P’

‘--properties-input’

Assume the input file is a Java ResourceBundle in Java .properties syntax, not in PO file syntax.

‘--stringtable-input’

Assume the input file is a NeXTstep/GNUstep localized resource file in .strings syntax, not in PO file syntax.

6.1.4 Output details

‘-l ll_CC’

‘--locale=ll_CC’

Set target locale. ll should be a language code, and CC should be a country code. The command ‘locale -a’ can be used to output a list of all installed locales. The default is the user's locale setting.

‘--no-translator’

Declares that the PO file will not have a human translator and is instead automatically generated.

‘-p’

‘--properties-output’

Write out a Java ResourceBundle in Java .properties syntax. Note that this file format doesn't support plural forms and silently drops obsolete messages.

‘--stringtable-output’

Write out a NeXTstep/GNUstep localized resource file in .strings syntax. Note that this file format doesn't support plural forms.

‘-w number’

‘--width=number’

Set the output page width. Long strings in the output files will be split across multiple lines in order to ensure that each line's width (= number of screen columns) is less or equal to the given number.

‘--no-wrap’

Do not break long message lines. Message lines whose width exceeds the output page width will not be split into several lines. Only file reference lines which are wider than the output page width will be split.

6.1.5 Sortie informative

‘-h’

‘--help’

Display this help and exit.

‘-V’

‘--version’

Output version information and exit.

6.2 Remplissage de l'en-tête

Les commentaire initiaux "SOME DESCRIPTIVE TITLE", "YEAR" et "FIRST AUTHOR <EMAIL@ADDRESS>, YEAR" devrait être remplacé par de l'information raisonnable. Ceci peut être fait dans n'importe éditeur de texte ; si Emacs est utilisé et est placé dans le mode PO automatiquement (parcecqu'il a reconnu l'extension du fichier), vous pouvez le désactiver en tapant M-x fundamental-mode.

La modification de l'entrée de l'en-tête peut déjà être faire en utilisant le mode PO : dans Emacs, tapez "M-x po-mode RET et ensuite RET de nouveau pour démarrer l'édition de l'entrée. Vous devriez remplir les champs suivant.

Project-Id-Version

Ceci est le nom et la version du progiciel (-ndt package). Remplissez le, si cela n'a pas déjà été rempli par xgettext.

Report-Msgid-Bugs-To

Ceci a déjà été rempli par xgettext. Il contient une adresse de courriel ou une URL, où vous pouvez rapporter les bogues dans les chaînes non-traduites :

• - Les chaînes qui ne sont pas des phrases entières, voir les directives du mainteneur dans @ref{préparation des chaînes}.
• - Les chaînes, qui utilisent des termes obscures ou demande un contexte supplémentaire pour être comprises.
• - Les chaînes qui font des hypothèses invalides sur les notations des dates, des temps ou la monaie.
• - Problèmes de mise au pluriel
• - Épellement anglais incorrect.
• - Formatage incorrect.

POT-Creation-Date (-ndt Date de création POT)

Ceci a déjà été remplis par xgettext.

PO-Revision-Date

Vous n'avez pas besoin de remplir ceci. Ceci sera rempli par l'éditeur de fichier PO, quand vous sauverez le fichier.

Last-Translator

Remplissez votre nom et votre adresse courriel (sans les doubles guillemets).

Language-Team

Remplissez ici le nom anglais de la langue et l'adresse courriel ou du portail de l'équipe de langue dont vous faites partie.

Avant de démarrer une traduction, c'est une bonne idée de prendre contact avec votre équipe de traduction, non seulement pour être sûr que vous ne dupliquerez pas le travail, mais aussi pour coordonner les sujets liguistiques difficiles.

Dans le projet de traduction libre, chaque équipe de traduction a sa propre liste de courriel. La liste mise à jour des équipes peut se trouver sur la portail du projet de traduction libre, http://translationproject.org/, dans l'espace "Teams".

Content-Type

Remplacer ‘CHARSET’ avec l'encodage de caractère utilisé par votre langue, dans votre localisation ou UTF-8. Ce champs est nécessaire pour l'opération correcte des programmes msmerge et msgfmt, comme pour les utilisateurs dont l'encodage de caractère local diffère de la vôtre (voir @ref{conversion de jeu de caractères}).

Vous pouvez obtenir l'encodage de caractères de votre localisaton en lançant la commande en ligne de commande ‘locale charmap’. Si le résultat est ‘C’ ou ‘ANSI_X3.4-1968’, qui est équivalent à ‘ASCII’ (= ‘US-ASCII’), ceci signifie que votre localisation n'est configurée correctement. Dans ce cas, demandez à votre équipe de traduction, quel encodage ils utilisent. ‘ASCII’ n'est pas utilisable pour aucune langue excépté le latin.

Parceque les fichiers PO doivent être portables pour les systèmes d'exploitation avec moins de fonctionalitée avancée d'internationalisation, les encodages de caractères qui peuvent être utilisés sont limités à ceux qui sont supportés à la fois par GNU libc et GNU libiconv. Ces codes sont : ASCII, ISO-8859-1, ISO-8859-2, ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7, ISO-8859-8, ISO-8859-9, ISO-8859-13, ISO-8859-14, ISO-8859-15, KOI8-R, KOI8-U, KOI8-T, CP850, CP866, CP874, CP932, CP949, CP950, CP1250, CP1251, CP1252, CP1253, CP1254, CP1255, CP1256, CP1257, GB2312, EUC-JP, EUC-KR, EUC-TW, BIG5, BIG5-HKSCS, GBK, GB18030, SHIFT_JIS, JOHAB, TIS-620, VISCII, GEORGIAN-PS, UTF-8.

Dans le système GNU, les encodages suivant sont fréquemment utilisés pour les langue correspondantes.

• ISO-8859-1 pour afrikaans, albanien, basque, breton, catalan, cornish, danois, néerlandais, anglais, estonien, faroïen, finnois, français, galican, allemand, grooenlandais, islandais, indonesien, irlandais, italien, malais, manx, norvégien, occitan,

  portugais, espagnol, suédois, tagalog, ouzbek, walloon,

• ISO-8859-2 pour bosniaque, croatien, tchèque, hongrois, polonais, roumain, serbe, slovaque, " slovène,
• ISO-8859-3 pour la maltais
• ISO-8859-5 pour le macédonie, le serbe,
• ISO-8859-6 pour l'arabe,
• ISO-8859-7 pour le grec,
• ISO-8859-8 pour l'hébreux,
• ISO-8859-9 pour le turc,
• ISO-8859-13 pour le latvian, lituanien, maori,
• ISO-8859-14 pour le galois,
• ISO-8859-15 pour basque, catalan, néerlandais, anglais, finois, français, galicien, allemand, irlandais, " italien, portugais, espagnlos, suédois, wallon,
• KOI8-R pour le russe,
• KOI8-U pour l'ukrainien,
• KOI8-T pour le tajik,
• CP1251 pour le bulgare, le biélorusse,
• GB2312, GBK, GB18030 pour l'écriture simplifiée du chinois,
• BIG5, BIG5-HKSCS pour l'écriture traditionnelle du chinois,
• EUC-JP pour le japonais,
• EUC-KR pour le coréen,
• TIS-620 pour le thaïlandais,
• GEORGIAN-PS pour le géorgien,
• UTF-8 pour toutes langues, incluant celles listées ci dessus.

Quand des caractères de quotation simples ou des caractères de quotation doubles sont utilisés dans les traductions pour votre langue et que votre encodage local est l'un des jeux de caractères ISO-8859-*, il vaut mieux que vous créeiez votre fichier PO en utilisant l'encodage UTF-8 à la place de votre encodage local. Ceci parceque les caractères réels de quotation peuvent être représentés en UTF-8 (les caractères de simple quotation : U+2018, U+2019, les caractères de quotation double : U+201C, U+201D) alors qu'aucun des jeux de caractères ISO-8859-* ne les a tous. Les utilisateurs de localisation en UTF-8 veront les caractères réels de quotation alors que les utilisateurs des localisation en ISO-8859-* veront l'apostrophe verticalle et la double quotation verticale à la place (parceque c'est que la translitération définira pour les traduire).

Pour entrer ces caractères de quotation sous X11, vous pouvez changer le l'arrangement des correspondances des touches de votre clavier en utilisant le programme xmodmap. Les noms X11 des caractères de quotation sont "leftsinglequotemark", "rightsinglequotemark", "leftdoublequotemark", "rightdoublequotemark", "singlelowquotemark", "doublelowquotemark".

Notez que seules les versions récentes de GNU Emacs supportent l'encodage UTF-8 : Emacs 20 avec Mule-UCS et Emacs 21. En janvier 2001, XEmacs ne supportait pas encore l'encodage UTF-8.

Les noms d'encodages des caractères peuvent être écrit soit en majuscules soit en minuscules. Habituellement, les majuscules sont préférées.

Content-Transfer-Encoding

Définir ceci en 8bit.

Plural-Forms (-ndt Formes-Plurielles)

Ce champ est optionnel. Il est seulement nécessaire si le fichier PO a des formes plurielles. Vous pouvez les trouver en cherchant le mot-clé ‘msgid_plural’. Le format des champs de formes plurielles et décrit dans @ref{formes plurielles}.

7. La mise à jour d'un fichier PO existant

7.1 Invocation du promgramme msgmerge

msgmerge [option] def.po ref.pot

The msgmerge program merges two Uniforum style .po files together. The def.po file is an existing PO file with translations which will be taken over to the newly created file as long as they still match; comments will be preserved, but extracted comments and file positions will be discarded. The ref.pot file is the last created PO file with up-to-date source references but old translations, or a PO Template file (generally created by xgettext); any translations or comments in the file will be discarded, however dot comments and file positions will be preserved. Where an exact match cannot be found, fuzzy matching is used to produce better results.

7.1.1 Input file location

‘def.po’

Translations referring to old sources.

‘ref.pot’

References to the new sources.

‘-D directory’

‘--directory=directory’

Add directory to the list of directories. Source files are searched relative to this list of directories. The resulting ‘.po’ file will be written relative to the current directory, though.

‘-C file’

‘--compendium=file’

Specify an additional library of message translations. Voir la section Utiliser un compendia de traduction. This option may be specified more than once.

7.1.2 Operation mode

‘-U’

‘--update’

Update def.po. Do nothing if def.po is already up to date.

7.1.3 Output file location

‘-o file’

‘--output-file=file’

Write output to specified file.

The results are written to standard output if no output file is specified or if it is ‘-’.

7.1.4 Output file location in update mode

The result is written back to def.po.

‘--backup=control’

Make a backup of def.po

‘--suffix=suffix’

Override the usual backup suffix.

The version control method may be selected via the --backup option or through the VERSION_CONTROL environment variable. Here are the values:

‘none’

‘off’

Never make backups (even if --backup is given).

‘numbered’

‘t’

Make numbered backups.

‘existing’

‘nil’

Make numbered backups if numbered backups for this file already exist, otherwise make simple backups.

‘simple’

‘never’

Always make simple backups.

The backup suffix is ‘~’, unless set with --suffix or the SIMPLE_BACKUP_SUFFIX environment variable.

7.1.5 Operation modifiers

‘-m’

‘--multi-domain’

Apply ref.pot to each of the domains in def.po.

‘-N’

‘--no-fuzzy-matching’

Do not use fuzzy matching when an exact match is not found. This may speed up the operation considerably.

‘--previous’

Keep the previous msgids of translated messages, marked with ‘#|’, when adding the fuzzy marker to such messages.

7.1.6 Input file syntax

‘-P’

‘--properties-input’

Assume the input files are Java ResourceBundles in Java .properties syntax, not in PO file syntax.

‘--stringtable-input’

Assume the input files are NeXTstep/GNUstep localized resource files in .strings syntax, not in PO file syntax.

7.1.7 Output details

‘--force-po’

Always write an output file even if it contains no message.

‘-i’

‘--indent’

Write the .po file using indented style.

‘--no-location’

Do not write ‘#: filename:line’ lines.

‘--add-location’

Generate ‘#: filename:line’ lines (default).

‘--strict’

Write out a strict Uniforum conforming PO file. Note that this Uniforum format should be avoided because it doesn't support the GNU extensions.

‘-p’

‘--properties-output’

Write out a Java ResourceBundle in Java .properties syntax. Note that this file format doesn't support plural forms and silently drops obsolete messages.

‘--stringtable-output’

Write out a NeXTstep/GNUstep localized resource file in .strings syntax. Note that this file format doesn't support plural forms.

‘-w number’

‘--width=number’

Set the output page width. Long strings in the output files will be split across multiple lines in order to ensure that each line's width (= number of screen columns) is less or equal to the given number.

‘--no-wrap’

Do not break long message lines. Message lines whose width exceeds the output page width will not be split into several lines. Only file reference lines which are wider than the output page width will be split.

‘-s’

‘--sort-output’

Generate sorted output. Note that using this option makes it much harder for the translator to understand each message's context.

‘-F’

‘--sort-by-file’

Sort output by file location.

7.1.8 Sortie informative

‘-h’

‘--help’

Display this help and exit.

‘-V’

‘--version’

Output version information and exit.

‘-v’

‘--verbose’

Increase verbosity level.

‘-q’

‘--quiet’

‘--silent’

Suppress progress indicators.

8. L'édition d'un fichier PO

8.1 Éditeur de fichier PO sous KDE

8.2 Éditeur de fichier PO sous GNOME

8.3 Éditeur Emacs pour les fichiers PO

Pour ceux d'entres-vous qui sont les heureux utilisateurs d'Emacs, le mode PO a été spécialement crée pour procurer un environnment confortable pour éditer ou modifier les fichiers PO. Quand vous éditez un fichier PO, le mode PO vous permet un parcours facile des fichiers compendium et des fichiers PO auxiliaires, comme il vous aide à suivre les références dans un jeu de source de programme C, depuis lesquels les fichiers PO ont été dérivés. Il a quelques fonctionalités spéciales, parmis lesquelles le marquage interactif des chaînes à traduire et la validation des fichiers PO avec un repositionnement facile sur la ligne du fichier PO qui montre l'erreur.

Pour débutter, à côté des commandes principales du mode PO (@pxref{commandes PO principales}), vous devriez savoir comment bouger entre les entrées (@pxref{positionnnement de l'entrée}) et comme gérer les entrées non traduites (@pxref{entrées non traduites}).

8.3.1 Achever l'installation de GNU gettext

Une fois que vous avez reçu, désempacté, configuré et compilé la distribution GNU gettext, la commande ‘make install’ met les programmes xgettext; msgfmt, gettext et msgmerge à leur place comme leur catalogues de messages disponibles. Pour démarrer en plus avec une installation confortable, vous voudrez aussi rendre le mode PO disponible pour les utilisateurs d'Emacs.

Pendant l'installation du mode PO, vous pouvez vouloir modifier votre fichier ‘.emacs’, une fois pour toute, de façon à ce qu'il contienne quelques lignes qui ressemblentt à ceci :

(setq auto-mode-alist
     (cons '("\\.po\\'\\|\\.po\\." . po-mode) auto-mode-alist))
(autoload 'po-mode "po-mode" "Major mode for translators to edit PO "
files" t)

Ensuite, à chaque fois que vous éditerez un fichier ‘.po’ ou tout fichier qui aura la chaîne ‘.po’ dans son nom, Emacs chargera ‘po-mode.elc’ (ou ‘po-mode.el’) selon les besoins et activera automatiquement les commandes du mode PO pour la zone tampon associée. La chaîne PO apparaît dans la ligne modale pour toute zone tampon, pour laquel le mode PO est actif. Beaucoup de fichier PO peuvent être actifs en même temps dans une seule session Emacs.

Si vous utilisez Emacs version 20 ou plus et si vous avez déjà installé les polices appropriées de caractères internationaux sur votre système, vous pourriez aussi demander à Emacs de savoir déterminer automatiquement le système de codage sur chaque fichier PO. Cela chargera le plus souvent (mais pas toujours) les polices de caractères nécessaires pour les utliliser pour afficher les traductions sur votre fenêtre Emacs. Pour que ceci se passe, ajoutez les lignes :

(modify-coding-system-alist 'file "\\.po\\'\\|\\.po\\."
                            'po-find-file-coding-system)
(autoload 'po-find-file-coding-system "po-mode")

à votre fichier ‘.emacs’. Si malgré ceci, vous voyez toujours des boites vides à la place de vos caractères internationaux, essayer un autre jeu de polices de caractères (via shift et bouton de la souri 1).

8.3.2 Main PO mode Commands

in Achever l'installation de GNU gettext, PO mode is activated for a window when Emacs finds a PO file in that window. This puts the window read-only and establishes a po-mode-map, which is a genuine Emacs mode, in a way that is not derived from text mode in any way. Functions found on po-mode-hook, if any, will be executed.

When PO mode is active in a window, the letters ‘PO’ appear in the mode line for that window. The mode line also displays how many entries of each kind are held in the PO file. For example, the string ‘132t+3f+10u+2o’ would tell the translator that the PO mode contains 132 translated entries (@pxref{Translated Entries}, 3 fuzzy entries (@pxref{Fuzzy Entries}), 10 untranslated entries (@pxref{Untranslated Entries}) and 2 obsolete entries (@pxref{Obsolete Entries}). Zero-coefficients items are not shown. So, in this example, if the fuzzy entries were unfuzzied, the untranslated entries were translated and the obsolete entries were deleted, the mode line would merely display ‘145t’ for the counters.

The main PO commands are those which do not fit into the other categories of subsequent sections. These allow for quitting PO mode or for managing windows in special ways.

_

(po-undo).

Q

(po-quit).

q

(po-confirm-and-quit).

0

(po-other-window).

?

h

about PO mode (po-help).

=

(po-statistics).

V

file (po-validate).

command _ (po-undo) interfaces to the Emacs undo facility. Voir (emacs)Undo section `Undoing Changes' dans The Emacs Editor. Each time U is typed, modifications which the translator did to the PO file are undone a little more. For the purpose of undoing, each PO mode command is atomic. This is especially true for the <RET> command: the whole edition made by using a single use of this command is undone at once, even if the edition itself implied several actions. However, while in the editing window, one can undo the edition work quite parsimoniously.

po-quit, PO Mode command command The commands Q (po-quit) and q (po-confirm-and-quit) are used when the translator is done with the PO file. The former is a bit less verbose than the latter. If the file has been modified, it is saved to disk first. In both cases, and prior to all this, the commands check if any untranslated messages remain in the PO file and, if so, the translator is asked if she really wants to leave off working with this PO file. This is the preferred way of getting rid of an Emacs PO file buffer. Merely killing it through the usual command C-x k (kill-buffer) is not the tidiest way to proceed.

command The command 0 (po-other-window) is another, softer way, to leave PO mode, temporarily. It just moves the cursor to some other Emacs window, and pops one if necessary. For example, if the translator just got PO mode to show some source context in some other, she might discover some apparent bug in the program source that needs correction. This command allows the translator to change sex, become a programmer, and have the cursor right into the window containing the program she (or rather he) wants to modify. By later getting the cursor back in the PO file window, or by asking Emacs to edit this file once again, PO mode is then recovered.

po-help, PO Mode command The command h (po-help) displays a summary of all available PO mode commands. The translator should then type any character to resume normal PO mode operations. The command ? has the same effect as h.

The command = (po-statistics) computes the total number of entries in the PO file, the ordinal of the current entry (counted from 1), the number of untranslated entries, the number of obsolete entries, and displays all these numbers.

The command V (po-validate) launches msgfmt in checking and verbose mode over the current PO file. This command first offers to save the current PO file on disk. The msgfmt tool, from GNU gettext, has the purpose of creating a MO file out of a PO file, and PO mode uses the features of this program for checking the overall format of a PO file, as well as all individual entries.

program msgfmt runs asynchronously with Emacs, so the translator regains control immediately while her PO file is being studied. Error output is collected in the Emacs ‘*compilation*’ buffer, displayed in another window. The regular Emacs command C-x` (next-error), as well as other usual compile commands, allow the translator to reposition quickly to the offending parts of the PO file. Once the cursor is on the line in error, the translator may decide on any PO mode action which would help correcting the error.

8.3.3 Positionnement de l'entrée

always part of an entry. The only exceptions are the special case when the cursor is after the last entry in the file, or when the PO file is empty. The entry where the cursor is found to be is said to be the current entry. Many PO mode commands operate on the current entry, so moving the cursor does more than allowing the translator to browse the PO file, this also selects on which entry commands operate.

of the cursor in a specialized way. A few of those special purpose positioning are described here, the others are described in following sections (for a complete list try C-h m):

.

(po-current-entry).

n

(po-next-entry).

p

(po-previous-entry).

<

(po-first-entry).

>

(po-last-entry).

m

later use (po-push-location).

r

(po-pop-location).

x

previously saved one (po-exchange-location).

command Any Emacs command able to reposition the cursor may be used to select the current entry in PO mode, including commands which move by characters, lines, paragraphs, screens or pages, and search commands. However, there is a kind of standard way to display the current entry in PO mode, which usual Emacs commands moving the cursor do not especially try to enforce. The command . (po-current-entry) has the sole purpose of redisplaying the current entry properly, after the current entry has been changed by means external to PO mode, or the Emacs screen otherwise altered.

It is yet to be decided if PO mode helps the translator, or otherwise irritates her, by forcing a rigid window disposition while she is doing her work. We originally had quite precise ideas about how windows should behave, but on the other hand, anyone used to Emacs is often happy to keep full control. Maybe a fixed window disposition might be offered as a PO mode option that the translator might activate or deactivate at will, so it could be offered on an experimental basis. If nobody feels a real need for using it, or a compulsion for writing it, we should drop this whole idea. The incentive for doing it should come from translators rather than programmers, as opinions from an experienced translator are surely more worth to me than opinions from programmers thinking about how others should do translation.

command The commands n (po-next-entry) and p (po-previous-entry) move the cursor the entry following, or preceding, the current one. If n is given while the cursor is on the last entry of the PO file, or if p is given while the cursor is on the first entry, no move is done.

The commands < (po-first-entry) and > (po-last-entry) move the cursor to the first entry, or last entry, of the PO file. When the cursor is located past the last entry in a PO file, most PO mode commands will return an error saying ‘After last entry’. Moreover, the commands < and > have the special property of being able to work even when the cursor is not into some PO file entry, and one may use them for nicely correcting this situation. But even these commands will fail on a truly empty PO file. There are development plans for the PO mode for it to interactively fill an empty PO file from sources. @xref{Marking}.

The translator may decide, before working at the translation of a particular entry, that she needs to browse the remainder of the PO file, maybe for finding the terminology or phraseology used in related entries. She can of course use the standard Emacs idioms for saving the current cursor location in some register, and use that register for getting back, or else, use the location ring.

command Mode command PO mode offers another approach, by which cursor locations may be saved onto a special stack. The command m (po-push-location) merely adds the location of current entry to the stack, pushing the already saved locations under the new one. The command r (po-pop-location) consumes the top stack element and repositions the cursor to the entry associated with that top element. This position is then lost, for the next r will move the cursor to the previously saved location, and so on until no locations remain on the stack.

If the translator wants the position to be kept on the location stack, maybe for taking a look at the entry associated with the top element, then go elsewhere with the intent of getting back later, she ought to use m immediately after r.

command The command x (po-exchange-location) simultaneously repositions the cursor to the entry associated with the top element of the stack of saved locations, and replaces that top element with the location of the current entry before the move. Consequently, repeating the x command toggles alternatively between two entries. For achieving this, the translator will position the cursor on the first entry, use m, then position to the second entry, and merely use x for making the switch.

8.3.4 Normalisation des chaînes de caractères en entrée

There are many different ways for encoding a particular string into a PO file entry, because there are so many different ways to split and quote multi-line strings, and even, to represent special characters by backslashed escaped sequences. Some features of PO mode rely on the ability for PO mode to scan an already existing PO file for a particular string encoded into the msgid field of some entry. Even if PO mode has internally all the built-in machinery for implementing this recognition easily, doing it fast is technically difficult. To facilitate a solution to this efficiency problem, we decided on a canonical representation for strings.

A conventional representation of strings in a PO file is currently under discussion, and PO mode experiments with a canonical representation. Having both xgettext and PO mode converging towards a uniform way of representing equivalent strings would be useful, as the internal normalization needed by PO mode could be automatically satisfied when using xgettext from GNU gettext. An explicit PO mode normalization should then be only necessary for PO files imported from elsewhere, or for when the convention itself evolves.

So, for achieving normalization of at least the strings of a given PO file needing a canonical representation, the following PO mode command is available:

M-x po-normalize

entries more uniform.

The special command M-x po-normalize, which has no associated keys, revises all entries, ensuring that strings of both original and translated entries use uniform internal quoting in the PO file. It also removes any crumb after the last entry. This command may be useful for PO files freshly imported from elsewhere, or if we ever improve on the canonical quoting format we use. This canonical format is not only meant for getting cleaner PO files, but also for greatly speeding up msgid string lookup for some other PO mode commands.

M-x po-normalize presently makes three passes over the entries. The first implements heuristics for converting PO files for GNU gettext 0.6 and earlier, in which msgid and msgstr fields were using K&R style C string syntax for multi-line strings. These heuristics may fail for comments not related to obsolete entries and ending with a backslash; they also depend on subsequent passes for finalizing the proper commenting of continued lines for obsolete entries. This first pass might disappear once all oldish PO files would have been adjusted. The second and third pass normalize all msgid and msgstr strings respectively. They also clean out those trailing backslashes used by XView's msgfmt for continued lines.

Having such an explicit normalizing command allows for importing PO files from other sources, but also eases the evolution of the current convention, evolution driven mostly by aesthetic concerns, as of now. It is easy to make suggested adjustments at a later time, as the normalizing command and eventually, other GNU gettext tools should greatly automate conformance. A description of the canonical string format is given below, for the particular benefit of those not having Emacs handy, and who would nevertheless want to handcraft their PO files in nice ways.

Right now, in PO mode, strings are single line or multi-line. A string goes multi-line if and only if it has embedded newlines, that is, if it matches ‘[^\n]\n+[^\n]’. So, we would have:

msgstr "\n\nHello, world!\n\n\n"

but, replacing the space by a newline, this becomes:

msgstr ""
"\n"
"\n"
"Hello,\n"
"world!\n"
"\n"
"\n"

We are deliberately using a caricatural example, here, to make the point clearer. Usually, multi-lines are not that bad looking. It is probable that we will implement the following suggestion. We might lump together all initial newlines into the empty string, and also all newlines introducing empty lines (that is, for n > 1, the n-1'th last newlines would go together on a separate string), so making the previous example appear:

msgstr "\n\n"
"Hello,\n"
"world!\n"
"\n\n"

There are a few yet undecided little points about string normalization, to be documented in this manual, once these questions settle.

8.3.5 Entrées traduites

Each PO file entry for which the msgstr field has been filled with a translation, and which is not marked as fuzzy (@pxref{Fuzzy Entries}), is said to be a translated entry. Only translated entries will later be compiled by GNU msgfmt and become usable in programs. Other entry types will be excluded; translation will not occur for them.

related to translated entry processing.

t

(po-next-translated-entry).

T

(po-previous-translated-entry).

Mode command po-previous-translated-entry, PO Mode command The commands t (po-next-translated-entry) and T (po-previous-translated-entry) move forwards or backwards, chasing for an translated entry. If none is found, the search is extended and wraps around in the PO file buffer.

usually result from the translator having edited in a translation for them, @ref{Modifying Translations}. However, if the variable po-auto-fuzzy-on-edit is not nil, the entry having received a new translation first becomes a fuzzy entry, which ought to be later unfuzzied before becoming an official, genuine translated entry. @xref{Fuzzy Entries}.

8.3.6 Entrées floues

Each PO file entry may have a set of attributes, which are qualities given a name and explicitly associated with the translation, using a special system comment. One of these attributes has the name fuzzy, and entries having this attribute are said to have a fuzzy translation. They are called fuzzy entries, for short.

Fuzzy entries, even if they account for translated entries for most other purposes, usually call for revision by the translator. Those may be produced by applying the program msgmerge to update an older translated PO files according to a new PO template file, when this tool hypothesises that some new msgid has been modified only slightly out of an older one, and chooses to pair what it thinks to be the old translation for the new modified entry. The slight alteration in the original string (the msgid string) should often be reflected in the translated string, and this requires the intervention of the translator. For this reason, msgmerge might mark some entries as being fuzzy.

mark an entry as fuzzy for her own convenience, when she wants to remember that the entry has to be later revisited. So, some commands are more specifically related to fuzzy entry processing.

z

(po-next-fuzzy-entry).

Z

(po-previous-fuzzy-entry).

<TAB>

entry (po-unfuzzy).

command po-previous-fuzzy-entry, PO Mode command The commands z (po-next-fuzzy-entry) and Z (po-previous-fuzzy-entry) move forwards or backwards, chasing for a fuzzy entry. If none is found, the search is extended and wraps around in the PO file buffer.

<TAB> (po-unfuzzy) removes the fuzzy attribute associated with an entry, usually leaving it translated. Further, if the variable po-auto-select-on-unfuzzy has not the nil value, the <TAB> command will automatically chase for another interesting entry to work on. The initial value of po-auto-select-on-unfuzzy is nil.

The initial value of po-auto-fuzzy-on-edit is nil. However, if the variable po-auto-fuzzy-on-edit is set to t, any entry edited through the <RET> command is marked fuzzy, as a way to ensure some kind of double check, later. In this case, the usual paradigm is that an entry becomes fuzzy (if not already) whenever the translator modifies it. If she is satisfied with the translation, she then uses <TAB> to pick another entry to work on, clearing the fuzzy attribute on the same blow. If she is not satisfied yet, she merely uses <SPC> to chase another entry, leaving the entry fuzzy.

command The translator may also use the <DEL> command (po-fade-out-entry) over any translated entry to mark it as being fuzzy, when she wants to easily leave a trace she wants to later return working at this entry.

Also, when time comes to quit working on a PO file buffer with the q command, the translator is asked for confirmation, if fuzzy string still exists.

8.3.7 Entrées non traduites

When xgettext originally creates a PO file, unless told otherwise, it initializes the msgid field with the untranslated string, and leaves the msgstr string to be empty. Such entries, having an empty translation, are said to be untranslated entries. Later, when the programmer slightly modifies some string right in the program, this change is later reflected in the PO file by the appearance of a new untranslated entry for the modified string.

The usual commands moving from entry to entry consider untranslated entries on the same level as active entries. Untranslated entries are easily recognizable by the fact they end with ‘msgstr ""’.

(quite naively) seen as the process of seeking for an untranslated entry, editing a translation for it, and repeating these actions until no untranslated entries remain. Some commands are more specifically related to untranslated entry processing.

u

(po-next-untranslated-entry).

U

(po-previous-untransted-entry).

k

one (po-kill-msgstr).

Mode command po-previous-untransted-entry, PO Mode command The commands u (po-next-untranslated-entry) and U (po-previous-untransted-entry) move forwards or backwards, chasing for an untranslated entry. If none is found, the search is extended and wraps around in the PO file buffer.

An entry can be turned back into an untranslated entry by merely emptying its translation, using the command k (po-kill-msgstr). @xref{Modifying Translations}.

Also, when time comes to quit working on a PO file buffer with the q command, the translator is asked for confirmation, if some untranslated string still exists.

8.3.8 Entrées obsolètes

By obsolete PO file entries, we mean those entries which are commented out, usually by msgmerge when it found that the translation is not needed anymore by the package being localized.

The usual commands moving from entry to entry consider obsolete entries on the same level as active entries. Obsolete entries are easily recognizable by the fact that all their lines start with #, even those lines containing msgid or msgstr.

Commands exist for emptying the translation or reinitializing it to the original untranslated string. Commands interfacing with the kill ring may force some previously saved text into the translation. The user may interactively edit the translation. All these commands may apply to obsolete entries, carefully leaving the entry obsolete after the fact.

specifically related to obsolete entry processing.

o

(po-next-obsolete-entry).

O

(po-previous-obsolete-entry).

<DEL>

an obsolete entry (po-fade-out-entry).

command po-previous-obsolete-entry, PO Mode command The commands o (po-next-obsolete-entry) and O (po-previous-obsolete-entry) move forwards or backwards, chasing for an obsolete entry. If none is found, the search is extended and wraps around in the PO file buffer.

PO mode does not provide ways for un-commenting an obsolete entry and making it active, because this would reintroduce an original untranslated string which does not correspond to any marked string in the program sources. This goes with the philosophy of never introducing useless msgid values.

command However, it is possible to comment out an active entry, so making it obsolete. GNU gettext utilities will later react to the disappearance of a translation by using the untranslated string. The command <DEL> (po-fade-out-entry) pushes the current entry a little further towards annihilation. If the entry is active (it is a translated entry), then it is first made fuzzy. If it is already fuzzy, then the entry is merely commented out, with confirmation. If the entry is already obsolete, then it is completely deleted from the PO file. It is easy to recycle the translation so deleted into some other PO file entry, usually one which is untranslated. @xref{Modifying Translations}.

Here is a quite interesting problem to solve for later development of PO mode, for those nights you are not sleepy. The idea would be that PO mode might become bright enough, one of these days, to make good guesses at retrieving the most probable candidate, among all obsolete entries, for initializing the translation of a newly appeared string. I think it might be a quite hard problem to do this algorithmically, as we have to develop good and efficient measures of string similarity. Right now, PO mode completely lets the decision to the translator, when the time comes to find the adequate obsolete translation, it merely tries to provide handy tools for helping her to do so.

8.3.9 Modification de traductions

PO mode prevents direct modification of the PO file, by the usual means Emacs gives for altering a buffer's contents. By doing so, it pretends helping the translator to avoid little clerical errors about the overall file format, or the proper quoting of strings, as those errors would be easily made. Other kinds of errors are still possible, but some may be caught and diagnosed by the batch validation process, which the translator may always trigger by the V command. For all other errors, the translator has to rely on her own judgment, and also on the linguistic reports submitted to her by the users of the translated package, having the same mother tongue.

When the time comes to create a translation, correct an error diagnosed mechanically or reported by a user, the translators have to resort to using the following commands for modifying the translations.

<RET>

(po-edit-msgstr).

<LFD>

C-j

Reinitialize the translation with the original, untranslated string (po-msgid-to-msgstr).

k

delete it (po-kill-msgstr).

w

without deleting it (po-kill-ring-save-msgstr).

y

the kill ring (po-yank-msgstr).

command The command <RET> (po-edit-msgstr) opens a new Emacs window meant to edit in a new translation, or to modify an already existing translation. The new window contains a copy of the translation taken from the current PO file entry, all ready for edition, expunged of all quoting marks, fully modifiable and with the complete extent of Emacs modifying commands. When the translator is done with her modifications, she may use C-c C-c to close the subedit window with the automatically requoted results, or C-c C-k to abort her modifications. @xref{Subedit}, for more information.

po-msgid-to-msgstr, PO Mode command The command <LFD> (po-msgid-to-msgstr) initializes, or reinitializes the translation with the original string. This command is normally used when the translator wants to redo a fresh translation of the original string, disregarding any previous work.

arrange so, whenever editing an untranslated entry, the <LFD> command be automatically executed. If you set po-auto-edit-with-msgid to t, the translation gets initialised with the original string, in case none exists already. The default value for po-auto-edit-with-msgid is nil.

a translation with an empty string, or rather with a copy of the original string, is a matter of taste or habit. Sometimes, the source language and the target language are so different that is simply best to start writing on an empty page. At other times, the source and target languages are so close that it would be a waste to retype a number of words already being written in the original string. A translator may also like having the original string right under her eyes, as she will progressively overwrite the original text with the translation, even if this requires some extra editing work to get rid of the original.

command command k (po-kill-msgstr) merely empties the translation string, so turning the entry into an untranslated one. But while doing so, its previous contents is put apart in a special place, known as the kill ring. The command w (po-kill-ring-save-msgstr) has also the effect of taking a copy of the translation onto the kill ring, but it otherwise leaves the entry alone, and does not remove the translation from the entry. Both commands use exactly the Emacs kill ring, which is shared between buffers, and which is well known already to Emacs lovers.

The translator may use k or w many times in the course of her work, as the kill ring may hold several saved translations. From the kill ring, strings may later be reinserted in various Emacs buffers. In particular, the kill ring may be used for moving translation strings between different entries of a single PO file buffer, or if the translator is handling many such buffers at once, even between PO files.

To facilitate exchanges with buffers which are not in PO mode, the translation string put on the kill ring by the k command is fully unquoted before being saved: external quotes are removed, multi-line strings are concatenated, and backslash escaped sequences are turned into their corresponding characters. In the special case of obsolete entries, the translation is also uncommented prior to saving.

The command y (po-yank-msgstr) completely replaces the translation of the current entry by a string taken from the kill ring. Following Emacs terminology, we then say that the replacement string is yanked into the PO file buffer. Voir (emacs)Yanking section `Yanking' dans The Emacs Editor. The first time y is used, the translation receives the value of the most recent addition to the kill ring. If y is typed once again, immediately, without intervening keystrokes, the translation just inserted is taken away and replaced by the second most recent addition to the kill ring. By repeating y many times in a row, the translator may travel along the kill ring for saved strings, until she finds the string she really wanted.

When a string is yanked into a PO file entry, it is fully and automatically requoted for complying with the format PO files should have. Further, if the entry is obsolete, PO mode then appropriately push the inserted string inside comments. Once again, translators should not burden themselves with quoting considerations besides, of course, the necessity of the translated string itself respective to the program using it.

Note that k or w are not the only commands pushing strings on the kill ring, as almost any PO mode command replacing translation strings (or the translator comments) automatically saves the old string on the kill ring. The main exceptions to this general rule are the yanking commands themselves.

illustrate the operation of killing and yanking, let's use an actual example, taken from a common situation. When the programmer slightly modifies some string right in the program, his change is later reflected in the PO file by the appearance of a new untranslated entry for the modified string, and the fact that the entry translating the original or unmodified string becomes obsolete. In many cases, the translator might spare herself some work by retrieving the unmodified translation from the obsolete entry, then initializing the untranslated entry msgstr field with this retrieved translation. Once this done, the obsolete entry is not wanted anymore, and may be safely deleted.

When the translator finds an untranslated entry and suspects that a slight variant of the translation exists, she immediately uses m to mark the current entry location, then starts chasing obsolete entries with o, hoping to find some translation corresponding to the unmodified string. Once found, she uses the <DEL> command for deleting the obsolete entry, knowing that <DEL> also kills the translation, that is, pushes the translation on the kill ring. Then, r returns to the initial untranslated entry, and y then yanks the saved translation right into the msgstr field. The translator is then free to use <RET> for fine tuning the translation contents, and maybe to later use u, then m again, for going on with the next untranslated string.

When some sequence of keys has to be typed over and over again, the translator may find it useful to become better acquainted with the Emacs capability of learning these sequences and playing them back under request. Voir (emacs)Keyboard Macros section `Keyboard Macros' dans The Emacs Editor.

8.3.10 Modification de commentaires

Any translation work done seriously will raise many linguistic difficulties, for which decisions have to be made, and the choices further documented. These documents may be saved within the PO file in form of translator comments, which the translator is free to create, delete, or modify at will. These comments may be useful to herself when she returns to this PO file after a while.

Comments not having whitespace after the initial ‘#’, for example, those beginning with ‘#.’ or ‘#:’, are not translator comments, they are exclusively created by other gettext tools. So, the commands below will never alter such system added comments, they are not meant for the translator to modify. @xref{PO Files}.

The following commands are somewhat similar to those modifying translations, so the general indications given for those apply here. @xref{Modifying Translations}.

#

(po-edit-comment).

K

ring, and delete it (po-kill-comment).

W

ring, without deleting it (po-kill-ring-save-comment).

Y

new from the kill ring (po-yank-comment).

These commands parallel PO mode commands for modifying the translation strings, and behave much the same way as they do, except that they handle this part of PO file comments meant for translator usage, rather than the translation strings. So, if the descriptions given below are slightly succinct, it is because the full details have already been given. @xref{Modifying Translations}.

command The command # (po-edit-comment) opens a new Emacs window containing a copy of the translator comments on the current PO file entry. If there are no such comments, PO mode understands that the translator wants to add a comment to the entry, and she is presented with an empty screen. Comment marks (#) and the space following them are automatically removed before edition, and reinstated after. For translator comments pertaining to obsolete entries, the uncommenting and recommenting operations are done twice. Once in the editing window, the keys C-c C-c allow the translator to tell she is finished with editing the comment. @xref{Subedit}, for further details.

po-subedit-mode-hook, if any, are executed after the string has been inserted in the edit buffer.

command po-kill-ring-save-comment, PO Mode command command (po-kill-comment) gets rid of all translator comments, while saving those comments on the kill ring. The command W (po-kill-ring-save-comment) takes a copy of the translator comments on the kill ring, but leaves them undisturbed in the current entry. The command Y (po-yank-comment) completely replaces the translator comments by a string taken at the front of the kill ring. When this command is immediately repeated, the comments just inserted are withdrawn, and replaced by other strings taken along the kill ring.

On the kill ring, all strings have the same nature. There is no distinction between translation strings and translator comments strings. So, for example, let's presume the translator has just finished editing a translation, and wants to create a new translator comment to document why the previous translation was not good, just to remember what was the problem. Foreseeing that she will do that in her documentation, the translator may want to quote the previous translation in her translator comments. To do so, she may initialize the translator comments with the previous translation, still at the head of the kill ring. Because editing already pushed the previous translation on the kill ring, she merely has to type M-w prior to #, and the previous translation will be right there, all ready for being introduced by some explanatory text.

On the other hand, presume there are some translator comments already and that the translator wants to add to those comments, instead of wholly replacing them. Then, she should edit the comment right away with #. Once inside the editing window, she can use the regular Emacs commands C-y (yank) and M-y (yank-pop) to get the previous translation where she likes.

8.3.11 Details of Sub Edition

The PO subedit minor mode has a few peculiarities worth being described in fuller detail. It installs a few commands over the usual editing set of Emacs, which are described below.

C-c C-c

(po-subedit-exit).

C-c C-k

(po-subedit-abort).

C-c C-a

(po-subedit-cycle-auxiliary).

po-subedit-exit, PO Mode command The window's contents represents a translation for a given message, or a translator comment. The translator may modify this window to her heart's content. Once this is done, the command C-c C-c (po-subedit-exit) may be used to return the edited translation into the PO file, replacing the original translation, even if it moved out of sight or if buffers were switched.

command If the translator becomes unsatisfied with her translation or comment, to the extent she prefers keeping what was existent prior to the <RET> or # command, she may use the command C-c C-k (po-subedit-abort) to merely get rid of edition, while preserving the original translation or comment. Another way would be for her to exit normally with C-c C-c, then type U once for undoing the whole effect of last edition.

po-subedit-cycle-auxiliary, PO Mode command The command C-c C-a (po-subedit-cycle-auxiliary) allows for glancing through translations already achieved in other languages, directly while editing the current translation. This may be quite convenient when the translator is fluent at many languages, but of course, only makes sense when such completed auxiliary PO files are already available to her (@pxref{Auxiliary}).

Functions found on po-subedit-mode-hook, if any, are executed after the string has been inserted in the edit buffer.

While editing her translation, the translator should pay attention to not inserting unwanted <RET> (newline) characters at the end of the translated string if those are not meant to be there, or to removing such characters when they are required. Since these characters are not visible in the editing buffer, they are easily introduced by mistake. To help her, <RET> automatically puts the character < at the end of the string being edited, but this < is not really part of the string. On exiting the editing window with C-c C-c, PO mode automatically removes such < and all whitespace added after it. If the translator adds characters after the terminating <, it looses its delimiting property and integrally becomes part of the string. If she removes the delimiting <, then the edited string is taken as is, with all trailing newlines, even if invisible. Also, if the translated string ought to end itself with a genuine <, then the delimiting < may not be removed; so the string should appear, in the editing window, as ending with two < in a row.

edited, the translator may move the cursor back into the PO file buffer and freely move to other entries, browsing at will. If, with an edition pending, the translator wanders in the PO file buffer, she may decide to start modifying another entry. Each entry being edited has its own subedit buffer. It is possible to simultaneously edit the translation and the comment of a single entry, or to edit entries in different PO files, all at once. Typing <RET> on a field already being edited merely resumes that particular edit. Yet, the translator should better be comfortable at handling many Emacs windows!

any order, regardless of how or when they were started. When many subedits are pending and the translator asks for quitting the PO file (with the q command), subedits are automatically resumed one at a time, so she may decide for each of them.

8.3.12 Contexte des fichiers sources en C

translation

PO mode is particularly powerful when used with PO files created through GNU gettext utilities, as those utilities insert special comments in the PO files they generate. Some of these special comments relate the PO file entry to exactly where the untranslated string appears in the program sources.

When the translator gets to an untranslated entry, she is fairly often faced with an original string which is not as informative as it normally should be, being succinct, cryptic, or otherwise ambiguous. Before choosing how to translate the string, she needs to understand better what the string really means and how tight the translation has to be. Most of the time, when problems arise, the only way left to make her judgment is looking at the true program sources from where this string originated, searching for surrounding comments the programmer might have put in there, and looking around for helping clues of any kind.

Surely, when looking at program sources, the translator will receive more help if she is a fluent programmer. However, even if she is not versed in programming and feels a little lost in C code, the translator should not be shy at taking a look, once in a while. It is most probable that she will still be able to find some of the hints she needs. She will learn quickly to not feel uncomfortable in program code, paying more attention to programmer's comments, variable and function names (if he dared choosing them well), and overall organization, than to the program code itself.

meant to help the translator at getting program source context for a PO file entry.

s

context, or cycle through them (po-cycle-source-reference).

M-s

selected by menu (po-select-source-reference).

S

source files (po-consider-source-path).

M-S

for source files (po-ignore-source-path).

Mode command po-select-source-reference, PO Mode command The commands s (po-cycle-source-reference) and M-s (po-select-source-reference) both open another window displaying some source program file, and already positioned in such a way that it shows an actual use of the string to be translated. By doing so, the command gives source program context for the string. But if the entry has no source context references, or if all references are unresolved along the search path for program sources, then the command diagnoses this as an error.

Even if s (or M-s) opens a new window, the cursor stays in the PO file window. If the translator really wants to get into the program source window, she ought to do it explicitly, maybe by using command O.

When s is typed for the first time, or for a PO file entry which is different of the last one used for getting source context, then the command reacts by giving the first context available for this entry, if any. If some context has already been recently displayed for the current PO file entry, and the translator wandered off to do other things, typing s again will merely resume, in another window, the context last displayed. In particular, if the translator moved the cursor away from the context in the source file, the command will bring the cursor back to the context. By using s many times in a row, with no other commands intervening, PO mode will cycle to the next available contexts for this particular entry, getting back to the first context once the last has been shown.

The command M-s behaves differently. Instead of cycling through references, it lets the translator choose a particular reference among many, and displays that reference. It is best used with completion, if the translator types <TAB> immediately after M-s, in response to the question, she will be offered a menu of all possible references, as a reminder of which are the acceptable answers. This command is useful only where there are really many contexts available for a single string to translate.

command po-ignore-source-path, PO Mode command Program source files are usually found relative to where the PO file stands. As a special provision, when this fails, the file is also looked for, but relative to the directory immediately above it. Those two cases take proper care of most PO files. However, it might happen that a PO file has been moved, or is edited in a different place than its normal location. When this happens, the translator should tell PO mode in which directory normally sits the genuine PO file. Many such directories may be specified, and all together, they constitute what is called the search path for program sources. The command S (po-consider-source-path) is used to interactively enter a new directory at the front of the search path, and the command M-S (po-ignore-source-path) is used to select, with completion, one of the directories she does not want anymore on the search path.

8.3.13 Consultation des fichiers PO auxiliaires

PO mode is able to help the knowledgeable translator, being fluent in many languages, at taking advantage of translations already achieved in other languages she just happens to know. It provides these other language translations as additional context for her own work. Moreover, it has features to ease the production of translations for many languages at once, for translators preferring to work in this way.

meant for the same package the translator is working on, but targeted to a different mother tongue language. Commands exist for declaring and handling auxiliary PO files, and also for showing contexts for the entry under work.

Here are the auxiliary file commands available in PO mode.

a

for the same entry (po-cycle-auxiliary).

C-c C-a

(po-select-auxiliary).

A

(po-consider-as-auxiliary).

M-A

auxiliary files (po-ignore-as-auxiliary).

Mode command po-ignore-as-auxiliary, PO Mode command Command A (po-consider-as-auxiliary) adds the current PO file to the list of auxiliary files, while command M-A (po-ignore-as-auxiliary just removes it.

command The command a (po-cycle-auxiliary) seeks all auxiliary PO files, round-robin, searching for a translated entry in some other language having an msgid field identical as the one for the current entry. The found PO file, if any, takes the place of the current PO file in the display (its window gets on top). Before doing so, the current PO file is also made into an auxiliary file, if not already. So, a in this newly displayed PO file will seek another PO file, and so on, so repeating a will eventually yield back the original PO file.

Mode command The command C-c C-a (po-select-auxiliary) asks the translator for her choice of a particular auxiliary file, with completion, and then switches to that selected PO file. The command also checks if the selected file has an msgid field identical as the one for the current entry, and if yes, this entry becomes current. Otherwise, the cursor of the selected file is left undisturbed.

For all this to work fully, auxiliary PO files will have to be normalized, in that way that msgid fields should be written exactly the same way. It is possible to write msgid fields in various ways for representing the same string, different writing would break the proper behaviour of the auxiliary file commands of PO mode. This is not expected to be much a problem in practice, as most existing PO files have their msgid entries written by the same GNU gettext tools.

by PO mode itself, while marking strings in source files, are normalised differently. So are PO files resulting of the ‘M-x normalize’ command. Until these discrepancies between PO mode and other GNU gettext tools get fully resolved, the translator should stay aware of normalisation issues.

8.4 Utiliser un compendia de traduction

A compendium is a special PO file containing a set of translations recurring in many different packages. The translator can use gettext tools to build a new compendium, to add entries to her compendium, and to initialize untranslated entries, or to update already translated entries, from translations kept in the compendium.

8.4.1 Création d'un compendia

Basically every PO file consisting of translated entries only can be declared as a valid compendium. Often the translator wants to have special compendia; let's consider two cases: concatenating PO files and extracting a message subset from a PO file.

8.4.1.1 Concatenate PO Files

To concatenate several valid PO files into one compendium file you can use ‘msgcomm’ or ‘msgcat’ (the latter preferred):

msgcat -o compendium.po file1.po file2.po

By default, msgcat will accumulate divergent translations for the same string. Those occurrences will be marked as fuzzy and highly visible decorated; calling msgcat on ‘file1.po’:

#: src/hello.c:200
#, c-format
msgid "Report bugs to <%s>.\n"
msgstr "Comunicar `bugs' a <%s>.\n"

and ‘file2.po’:

#: src/bye.c:100
#, c-format
msgid "Report bugs to <%s>.\n"
msgstr "Comunicar \"bugs\" a <%s>.\n"

will result in:

#: src/hello.c:200 src/bye.c:100
#, fuzzy, c-format
msgid "Report bugs to <%s>.\n"
msgstr ""
"#-#-#-#-#  file1.po  #-#-#-#-#\n"
"Comunicar `bugs' a <%s>.\n"
"#-#-#-#-#  file2.po  #-#-#-#-#\n"
"Comunicar \"bugs\" a <%s>.\n"

The translator will have to resolve this “conflict” manually; she has to decide whether the first or the second version is appropriate (or provide a new translation), to delete the “marker lines”, and finally to remove the fuzzy mark.

If the translator knows in advance the first found translation of a message is always the best translation she can make use to the ‘--use-first’ switch:

msgcat --use-first -o compendium.po file1.po file2.po

A good compendium file must not contain fuzzy or untranslated entries. If input files are “dirty” you must preprocess the input files or postprocess the result using ‘msgattrib --translated --no-fuzzy’.

8.4.1.2 Extract a Message Subset from a PO File

Nobody wants to translate the same messages again and again; thus you may wish to have a compendium file containing ‘getopt.c’ messages.

To extract a message subset (e.g., all ‘getopt.c’ messages) from an existing PO file into one compendium file you can use ‘msggrep’:

msggrep --location src/getopt.c -o compendium.po file.po

8.4.2 Utilisation d'un comendia

You can use a compendium file to initialize a translation from scratch or to update an already existing translation.

8.4.2.1 Initialize a New Translation File

Since a PO file with translations does not exist the translator can merely use ‘/dev/null’ to fake the “old” translation file.

msgmerge --compendium compendium.po -o file.po /dev/null file.pot

8.4.2.2 Update an Existing Translation File

Concatenate the compendium file(s) and the existing PO, merge the result with the POT file and remove the obsolete entries (optional, here done using ‘sed’):

msgcat --use-first -o update.po compendium1.po compendium2.po file.po
msgmerge update.po file.pot | msgattrib --no-obsolete > file.po

9. La manipulatin d'un fichier PO

Sometimes it is necessary to manipulate PO files in a way that is better performed automatically than by hand. GNU gettext includes a complete set of tools for this purpose.

When merging two packages into a single package, the resulting POT file will be the concatenation of the two packages' POT files. Thus the maintainer must concatenate the two existing package translations into a single translation catalog, for each language. This is best performed using ‘msgcat’. It is then the translators' duty to deal with any possible conflicts that arose during the merge.

When a translator takes over the translation job from another translator, but she uses a different character encoding in her locale, she will convert the catalog to her character encoding. This is best done through the ‘msgconv’ program.

When a maintainer takes a source file with tagged messages from another package, he should also take the existing translations for this source file (and not let the translators do the same job twice). One way to do this is through ‘msggrep’, another is to create a POT file for that source file and use ‘msgmerge’.

When a translator wants to adjust some translation catalog for a special dialect or orthography — for example, German as written in Switzerland versus German as written in Germany — she needs to apply some text processing to every message in the catalog. The tool for doing this is ‘msgfilter’.

Another use of msgfilter is to produce approximately the POT file for which a given PO file was made. This can be done through a filter command like ‘msgfilter sed -e d | sed -e '/^# /d'’. Note that the original POT file may have had different comments and different plural message counts, that's why it's better to use the original POT file if available.

When a translator wants to check her translations, for example according to orthography rules or using a non-interactive spell checker, she can do so using the ‘msgexec’ program.

When third party tools create PO or POT files, sometimes duplicates cannot be avoided. But the GNU gettext tools give an error when they encounter duplicate msgids in the same file and in the same domain. To merge duplicates, the ‘msguniq’ program can be used.

‘msgcomm’ is a more general tool for keeping or throwing away duplicates, occurring in different files.

‘msgcmp’ can be used to check whether a translation catalog is completely translated.

‘msgattrib’ can be used to select and extract only the fuzzy or untranslated messages of a translation catalog.

‘msgen’ is useful as a first step for preparing English translation catalogs. It copies each message's msgid to its msgstr.

Finally, for those applications where all these various programs are not sufficient, a library ‘libgettextpo’ is provided that can be used to write other specialized programs that process PO files.

9.1 Invocation du programme msgcat

msgcat [option] [inputfile]...

The msgcat program concatenates and merges the specified PO files. It finds messages which are common to two or more of the specified PO files. By using the --more-than option, greater commonality may be requested before messages are printed. Conversely, the --less-than option may be used to specify less commonality before messages are printed (i.e. ‘--less-than=2’ will only print the unique messages). Translations, comments and extract comments will be cumulated, except that if --use-first is specified, they will be taken from the first PO file to define them. File positions from all PO files will be cumulated.

9.1.1 Input file location

‘inputfile …’

Input files.

‘-f file’

‘--files-from=file’

Read the names of the input files from file instead of getting them from the command line.

‘-D directory’

‘--directory=directory’

Add directory to the list of directories. Source files are searched relative to this list of directories. The resulting ‘.po’ file will be written relative to the current directory, though.

If inputfile is ‘-’, standard input is read.

9.1.2 Output file location

‘-o file’

‘--output-file=file’

Write output to specified file.

The results are written to standard output if no output file is specified or if it is ‘-’.

9.1.3 Message selection

‘-< number’

‘--less-than=number’

Print messages with less than number definitions, defaults to infinite if not set.

‘-> number’

‘--more-than=number’

Print messages with more than number definitions, defaults to 0 if not set.

‘-u’

‘--unique’

Shorthand for ‘--less-than=2’. Requests that only unique messages be printed.

9.1.4 Input file syntax

‘-P’

‘--properties-input’

Assume the input files are Java ResourceBundles in Java .properties syntax, not in PO file syntax.

‘--stringtable-input’

Assume the input files are NeXTstep/GNUstep localized resource files in .strings syntax, not in PO file syntax.

9.1.5 Output details

‘-t’

‘--to-code=name’

Specify encoding for output.

‘--use-first’

Use first available translation for each message. Don't merge several translations into one.

‘--color’

‘--color=when’

Specify whether or when to use colors and other text attributes. See @ref{The --color option} for details.

‘--style=style_file’

Specify the CSS style rule file to use for --color. See @ref{The --style option} for details.

‘--force-po’

Always write an output file even if it contains no message.

‘-i’

‘--indent’

Write the .po file using indented style.

‘--no-location’

Do not write ‘#: filename:line’ lines.

‘-n’

‘--add-location’

Generate ‘#: filename:line’ lines (default).

‘--strict’

Write out a strict Uniforum conforming PO file. Note that this Uniforum format should be avoided because it doesn't support the GNU extensions.

‘-p’

‘--properties-output’

Write out a Java ResourceBundle in Java .properties syntax. Note that this file format doesn't support plural forms and silently drops obsolete messages.

‘--stringtable-output’

Write out a NeXTstep/GNUstep localized resource file in .strings syntax. Note that this file format doesn't support plural forms.

‘-w number’

‘--width=number’

Set the output page width. Long strings in the output files will be split across multiple lines in order to ensure that each line's width (= number of screen columns) is less or equal to the given number.

‘--no-wrap’

Do not break long message lines. Message lines whose width exceeds the output page width will not be split into several lines. Only file reference lines which are wider than the output page width will be split.

‘-s’

‘--sort-output’

Generate sorted output. Note that using this option makes it much harder for the translator to understand each message's context.

‘-F’

‘--sort-by-file’

Sort output by file location.

9.1.6 Sortie informative

‘-h’

‘--help’

Display this help and exit.

‘-V’

‘--version’

Output version information and exit.

9.2 Invocation du programme msgconv

msgconv [option] [inputfile]

The msgconv program converts a translation catalog to a different character encoding.

9.2.1 Input file location

‘inputfile’

Input PO file.

‘-D directory’

‘--directory=directory’

Add directory to the list of directories. Source files are searched relative to this list of directories. The resulting ‘.po’ file will be written relative to the current directory, though.

If no inputfile is given or if it is ‘-’, standard input is read.

9.2.2 Output file location

‘-o file’

‘--output-file=file’

Write output to specified file.

The results are written to standard output if no output file is specified or if it is ‘-’.

9.2.3 Conversion target

‘-t’

‘--to-code=name’

Specify encoding for output.

The default encoding is the current locale's encoding.

9.2.4 Input file syntax

‘-P’

‘--properties-input’

Assume the input file is a Java ResourceBundle in Java .properties syntax, not in PO file syntax.

‘--stringtable-input’

Assume the input file is a NeXTstep/GNUstep localized resource file in .strings syntax, not in PO file syntax.

9.2.5 Output details

‘--force-po’

Always write an output file even if it contains no message.

‘-i’

‘--indent’

Write the .po file using indented style.

‘--no-location’

Do not write ‘#: filename:line’ lines.

‘--add-location’

Generate ‘#: filename:line’ lines (default).

‘--strict’

Write out a strict Uniforum conforming PO file. Note that this Uniforum format should be avoided because it doesn't support the GNU extensions.

‘-p’

‘--properties-output’

Write out a Java ResourceBundle in Java .properties syntax. Note that this file format doesn't support plural forms and silently drops obsolete messages.

‘--stringtable-output’

Write out a NeXTstep/GNUstep localized resource file in .strings syntax. Note that this file format doesn't support plural forms.

‘-w number’

‘--width=number’

Set the output page width. Long strings in the output files will be split across multiple lines in order to ensure that each line's width (= number of screen columns) is less or equal to the given number.

‘--no-wrap’

Do not break long message lines. Message lines whose width exceeds the output page width will not be split into several lines. Only file reference lines which are wider than the output page width will be split.

‘-s’

‘--sort-output’

Generate sorted output. Note that using this option makes it much harder for the translator to understand each message's context.

‘-F’

‘--sort-by-file’

Sort output by file location.

9.2.6 Sortie informative

‘-h’

‘--help’

Display this help and exit.

‘-V’

‘--version’

Output version information and exit.

9.3 Invocation du programme msggrep

msggrep [option] [inputfile]

The msggrep program extracts all messages of a translation catalog that match a given pattern or belong to some given source files.

9.3.1 Input file location

‘inputfile’

Input PO file.

‘-D directory’

‘--directory=directory’

Add directory to the list of directories. Source files are searched relative to this list of directories. The resulting ‘.po’ file will be written relative to the current directory, though.

If no inputfile is given or if it is ‘-’, standard input is read.

9.3.2 Output file location

‘-o file’

‘--output-file=file’

Write output to specified file.

The results are written to standard output if no output file is specified or if it is ‘-’.

9.3.3 Message selection

  [-N sourcefile]... [-M domainname]...
  [-J msgctxt-pattern] [-K msgid-pattern] [-T msgstr-pattern]
  [-C comment-pattern]

A message is selected if

• it comes from one of the specified source files,
• or if it comes from one of the specified domains,
• or if ‘-J’ is given and its context (msgctxt) matches msgctxt-pattern,
• or if ‘-K’ is given and its key (msgid or msgid_plural) matches msgid-pattern,
• or if ‘-T’ is given and its translation (msgstr) matches msgstr-pattern,
• or if ‘-C’ is given and the translator's comment matches comment-pattern.

When more than one selection criterion is specified, the set of selected messages is the union of the selected messages of each criterion.

msgctxt-pattern or msgid-pattern or msgstr-pattern syntax:

  [-E | -F] [-e pattern | -f file]...

patterns are basic regular expressions by default, or extended regular expressions if -E is given, or fixed strings if -F is given.

‘-N sourcefile’

‘--location=sourcefile’

Select messages extracted from sourcefile. sourcefile can be either a literal file name or a wildcard pattern.

‘-M domainname’

‘--domain=domainname’

Select messages belonging to domain domainname.

‘-J’

‘--msgctxt’

Start of patterns for the msgctxt.

‘-K’

‘--msgid’

Start of patterns for the msgid.

‘-T’

‘--msgstr’

Start of patterns for the msgstr.

‘-C’

‘--comment’

Start of patterns for the translator's comment.

‘-X’

‘--extracted-comment’

Start of patterns for the extracted comments.

‘-E’

‘--extended-regexp’

Specify that pattern is an extended regular expression.

‘-F’

‘--fixed-strings’

Specify that pattern is a set of newline-separated strings.

‘-e pattern’

‘--regexp=pattern’

Use pattern as a regular expression.

‘-f file’

‘--file=file’

Obtain pattern from file.

‘-i’

‘--ignore-case’

Ignore case distinctions.

‘-v’

‘--invert-match’

Output only the messages that do not match any selection criterion, instead of the messages that match a selection criterion.

9.3.4 Input file syntax

‘-P’

‘--properties-input’

Assume the input file is a Java ResourceBundle in Java .properties syntax, not in PO file syntax.

‘--stringtable-input’

Assume the input file is a NeXTstep/GNUstep localized resource file in .strings syntax, not in PO file syntax.

9.3.5 Output details

‘--force-po’

Always write an output file even if it contains no message.

‘--indent’

Write the .po file using indented style.

‘--no-location’

Do not write ‘#: filename:line’ lines.

‘--add-location’

Generate ‘#: filename:line’ lines (default).

‘--strict’

Write out a strict Uniforum conforming PO file. Note that this Uniforum format should be avoided because it doesn't support the GNU extensions.

‘-p’

‘--properties-output’

Write out a Java ResourceBundle in Java .properties syntax. Note that this file format doesn't support plural forms and silently drops obsolete messages.

‘--stringtable-output’

Write out a NeXTstep/GNUstep localized resource file in .strings syntax. Note that this file format doesn't support plural forms.

‘-w number’

‘--width=number’

Set the output page width. Long strings in the output files will be split across multiple lines in order to ensure that each line's width (= number of screen columns) is less or equal to the given number.

‘--no-wrap’

Do not break long message lines. Message lines whose width exceeds the output page width will not be split into several lines. Only file reference lines which are wider than the output page width will be split.

‘--sort-output’

Generate sorted output. Note that using this option makes it much harder for the translator to understand each message's context.

‘--sort-by-file’

Sort output by file location.

9.3.6 Sortie informative

‘-h’

‘--help’

Display this help and exit.

‘-V’

‘--version’

Output version information and exit.

9.3.7 Examples

To extract the messages that come from the source files gnulib-lib/error.c and gnulib-lib/getopt.c:

msggrep -N gnulib-lib/error.c -N gnulib-lib/getopt.c input.po

To extract the messages that contain the string “Please specify” in the original string:

msggrep --msgid -F -e 'Please specify' input.po

To extract the messages that have a context specifier of either “Menu>File” or “Menu>Edit” or a submenu of them:

msggrep --msgctxt -E -e '^Menu>(File|Edit)' input.po

To extract the messages whose translation contains one of the strings in the file wordlist.txt:

msggrep --msgstr -F -f wordlist.txt input.po

9.4 Invocation du programme msgfilter

msgfilter [option] filter [filter-option]

The msgfilter program applies a filter to all translations of a translation catalog.

9.4.1 Input file location

‘-i inputfile’

‘--input=inputfile’

Input PO file.

‘-D directory’

‘--directory=directory’

Add directory to the list of directories. Source files are searched relative to this list of directories. The resulting ‘.po’ file will be written relative to the current directory, though.

If no inputfile is given or if it is ‘-’, standard input is read.

9.4.2 Output file location

‘-o file’

‘--output-file=file’

Write output to specified file.

The results are written to standard output if no output file is specified or if it is ‘-’.

9.4.3 The filter

The filter can be any program that reads a translation from standard input and writes a modified translation to standard output. A frequently used filter is ‘sed’. A few particular built-in filters are also recognized.

Note: If the filter is not a built-in filter, you have to care about encodings: It is your responsibility to ensure that the filter can cope with input encoded in the translation catalog's encoding. If the filter wants input in a particular encoding, you can in a first step convert the translation catalog to that encoding using the ‘msgconv’ program, before invoking ‘msgfilter’. If the filter wants input in the locale's encoding, but you want to avoid the locale's encoding, then you can first convert the translation catalog to UTF-8 using the ‘msgconv’ program and then make ‘msgfilter’ work in an UTF-8 locale, by using the LC_ALL environment variable.

Note: Most translations in a translation catalog don't end with a newline character. For this reason, it is important that the filter recognizes its last input line even if it ends without a newline, and that it doesn't add an undesired trailing newline at the end. The ‘sed’ program on some platforms is known to ignore the last line of input if it is not terminated with a newline. You can use GNU sed instead; it does not have this limitation.

9.4.4 Useful filter-options when the filter is ‘sed’

‘-e script’

‘--expression=script’

Add script to the commands to be executed.

‘-f scriptfile’

‘--file=scriptfile’

Add the contents of scriptfile to the commands to be executed.

‘-n’

‘--quiet’

‘--silent’

Suppress automatic printing of pattern space.

9.4.5 Built-in filters

The filter ‘recode-sr-latin’ is recognized as a built-in filter. The command ‘recode-sr-latin’ converts Serbian text, written in the Cyrillic script, to the Latin script. The command ‘msgfilter recode-sr-latin’ applies this conversion to the translations of a PO file. Thus, it can be used to convert an ‘sr.po’ file to an ‘sr@latin.po’ file.

The use of built-in filters is not sensitive to the current locale's encoding. Moreover, when used with a built-in filter, ‘msgfilter’ can automatically convert the message catalog to the UTF-8 encoding when needed.

9.4.6 Input file syntax

‘-P’

‘--properties-input’

Assume the input file is a Java ResourceBundle in Java .properties syntax, not in PO file syntax.

‘--stringtable-input’

Assume the input file is a NeXTstep/GNUstep localized resource file in .strings syntax, not in PO file syntax.