Des fichiers PO, avec l'en-tête de pluriel écrit pour vous

L'en-tête de pluriel dépend de la langue, et il n'est pas facultatif

Un fichier PO porte sa propre règle de pluriel dans l'en-tête : combien de formes a la langue, et une expression qui associe un nombre à l'une d'elles. Si elle est fausse, l'application choisit le mauvais texte pour le bon nombre, et personne ne le remarque avant d'avoir deux exemplaires de quelque chose.

Le tchèque est l'exemple où tout le monde se trompe. Les anciens catalogues déclarent trois formes ; CLDR en compte quatre, car une quantité décimale a sa propre forme. Linguiqo écrit nplurals=4; plural=(n >= 2 && n <= 4 ? 1 : n == 1 ? 0 : 3); et affiche les quatre cases correspondantes dans l'éditeur.

Le japonais a une forme, l'arabe six. L'en-tête est généré à partir de la langue, jamais recopié du fichier reçu.

msgctxt fait la différence entre deux textes qui s'écrivent pareil

« Open » le verbe et « Open » l'état ne font qu'une entrée dans un format sans contexte, et le traducteur doit deviner lequel est à l'écran. Gettext règle cela avec msgctxt, et Linguiqo le garde comme partie de la clé au lieu de l'écarter.

Les deux textes survivent ainsi à l'aller-retour comme deux textes, et le traducteur voit lequel est lequel.

Ce qui ressort

Un catalogue avec les mêmes entrées dans le même ordre, l'en-tête réécrit pour la langue cible et msgstr[0] à msgstr[n] remplis dans l'ordre qu'attend la règle de cette langue.

Les entrées fuzzy gardent leur marque. Une ébauche automatique arrivée en fuzzy repart en fuzzy, car cet état signifie qu'aucun humain ne l'a encore relue, et un import n'est pas un humain qui relit.