← Concepts

Accord en genre

Certaines langues accordent les verbes et les adjectifs selon le genre de la personne dont parle la phrase. L’anglais, lui, le fait rarement : une phrase que vous écrivez {username} has been invited n’est qu’une seule phrase en anglais, mais en vaut deux ou trois en espagnol, en français ou en russe. Langsys s’en charge pendant la traduction, comme pour la génération des formes plurielles, et vous ne passez qu’un seul argument.

Ce que produit le pipeline

Lorsqu'une langue cible exige des accords, Langsys réécrit la chaîne de cette locale en autant de branches que nécessaire — un select ICU. Votre phrase source ne change jamais, et vous n'écrivez jamais les branches à la main.

// Your source phrase, unchanged:
"{username} has been invited"

// What the Spanish translation becomes — note invitado / invitada:
"{username_gender, select, male {{username} ha sido invitado} \
female {{username} ha sido invitada} \
other {{username} ha sido invitado/a}}"

Deux conséquences à bien retenir. L'argument porte le nom de la variable dont il dépend, suivi de _gender — {username} donne username_gender — et les branches sont toujours male, female et other. Il n'apparaît que dans les langues qui en ont besoin : c'est invisible tant que personne ne charge l'application dans une langue à genre grammatical.

Le transmettre

Passez l’argument dès que vous le connaissez, et le lecteur obtient une phrase correctement accordée :

// The argument is named after the variable it inflects, + _gender.
// Branches are always male / female / other.
t('{username} has been invited', 'Team', {
  username: user.name,
  username_gender: user.gender ?? 'other',
});

Vous ne connaissez pas le genre ? Transmettez 'other' explicitement — c’est la branche neutre. Le rendu d’un argument manquant varie selon le SDK ; la page de chaque SDK le précise. Chaque page de SDK montre aussi l’appel dans sa propre syntaxe.

Quelles phrases en ont besoin ?

Impossible de le savoir à partir de votre propre code, et c'est inhérent au système : l'argument est ajouté lors de la traduction, pour chaque langue cible, si bien que rien dans la phrase source ni dans votre base de code ne le laisse deviner. Il existe trois façons de le savoir.

Lisez le catalogue. Les traductions que votre application récupère sont les chaînes promues : la réponse se trouve donc déjà côté client. Récupérez le catalogue d'une locale que vous prenez en charge (chaque SDK le propose) et cherchez les entrées contenant , select,. Vous obtenez ainsi les phrases exactes et les noms d'arguments, et c'est assez léger pour être exécuté en CI sur chaque locale que vous livrez.

// The catalog your app fetches IS the promoted strings — grep it.
const wanting = Object.entries(catalog)
  .filter(([, translation]) => translation.includes(', select,'))
  .map(([phrase]) => phrase);
// → every phrase (and, from the string, every argument) this locale needs

Activez le débogage (SDK JavaScript). Passez debug: true dans votre configuration d'initialisation et parcourez l'application dans une langue avec genre : le SDK consigne un Langsys Warning par phrase dont la traduction attend un argument que vous n'avez pas fourni, en nommant cet argument. Une seule fois par phrase et par langue, et sans rien afficher en production. Une subtilité : dans les composants de bloc de contenu et de phrase, un _gender transmis par précaution est lui-même signalé comme paramètre sans correspondance, car cette vérification s'effectue sur votre texte source, où le select n'apparaît jamais.

Dans le doute, passez-le. Une valeur pour un argument que la chaîne ne contient pas est ignorée au moment du rendu ; envoyer _gender pour chaque variable désignant une personne est donc sans risque et couvre les locales que vous n’avez pas encore examinées.