← Concepten

Overeenstemming van geslacht

Sommige talen verbuigen werkwoorden en bijvoeglijke naamwoorden naar het geslacht van de persoon over wie een zin gaat. In het Engels is dat meestal niet zo, dus een zin die je schrijft als {username} has been invited is in het Engels één zin en in het Spaans, Frans of Russisch twee of drie. Langsys regelt dat tijdens het vertalen — op dezelfde manier als het meervoudsvormen genereert — en jij geeft één argument mee.

Wat de pipeline oplevert

Als een doeltaal congruentie vereist, herschrijft Langsys de string van die locale naar de takken die nodig zijn: een ICU-select. Je bronzin verandert nooit en je schrijft de takken nooit met de hand.

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

Twee gevolgen die het onthouden waard zijn. Het argument is vernoemd naar de variabele waarop het wordt vervoegd, met _gender erachter — {username} levert username_gender op — en de takken zijn altijd male, female, other. Daarnaast verschijnt het alleen in de talen die het nodig hebben: dat merk je pas wanneer iemand de app laadt in een taal met grammaticaal geslacht.

Doorgeven

Geef het argument mee zodra je het weet, en de lezer krijgt de correct verbogen zin:

// 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',
});

Weet je het geslacht niet? Geef 'other' expliciet mee — dat is de neutrale tak. Wat een ontbrekend argument oplevert, verschilt per SDK; elke SDK-pagina vermeldt dit. Elke SDK-pagina toont de aanroep ook in de eigen idioomstijl.

Welke zinnen hebben dat nodig?

Je kunt het niet aan je eigen code zien, en dat is inherent: het argument wordt tijdens het vertalen toegevoegd, per doellocale, dus niets in de brontekst of je codebase wijst erop. Er zijn drie manieren om erachter te komen.

Lees de catalogus. De vertalingen die je app ophaalt zijn de gepromoveerde strings, dus het antwoord staat al op de client. Haal de catalogus op voor een locale die je ondersteunt (elke SDK biedt dit) en zoek naar items die , select, bevatten. Dat geeft je de exacte frases en argumentnamen, en het is licht genoeg om in CI uit te voeren voor elke locale die je uitlevert.

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

Zet debug aan (JavaScript-SDK's). Geef debug: true mee in je init-configuratie en blader door de app in een locale met grammaticaal geslacht: de SDK logt één Langsys Warning per phrase waarvan de vertaling een argument verwacht dat je niet hebt meegegeven, met vermelding van het argument. Eén keer per phrase per locale, en stil in productie. Eén kanttekening: binnen de contentblok- en phrase-componenten wordt een voorzichtigheidshalve meegegeven _gender zelf als niet-overeenkomende parameter gemeld, omdat die controle wordt uitgevoerd op je brontekst — waarin de select nooit voorkomt.

Twijfel je? Geef het mee. Een waarde voor een argument dat de tekenreeks niet heeft, wordt tijdens het renderen genegeerd. Het is dus veilig om _gender mee te sturen voor elke variabele die een persoon voorstelt, en zo dek je ook de locales af die je nog niet hebt bekeken.