Använda msgctxt: Lägga till kontext till Gettext-översättningar

Du översätter det engelska ordet "Book" till tyska, och din översättare returnerar självsäkert "Buch". Tre veckor senare kommer en buggrapport: knappen "Book a table" på ditt bokningsformulär läser nu "Buch a table" – substantivet, inte verbet. Ordet var rätt. Kontexten saknades. Detta är ett av de vanligaste tysta felen inom mjukvarulokalisering, och lösningen har funnits i Gettext i årtionden: msgctxt.

Om du någon gång har släppt en översättning där en enskild engelsk sträng var korrekt på ett ställe och nonsens på ett annat, har du stött på tvetydighetsproblemet. Samma källord mappas till olika översättningar beroende på var det förekommer. Utan msgctxt har översättaren (människa eller AI) inget sätt att skilja dessa fall åt, eftersom allt de ser är den rena strängen msgid "Book". Denna guide förklarar hur msgctxt fungerar i Gettext, hur du markerar din källkod med _x() och _ex(), hur det visas i dina .po-filer, och varför en kontextmedveten översättningspipeline är det enda pålitliga sättet att få dessa strängar rätt i stor skala.

Tvetydighetsproblemet: Ett ord, många betydelser

Naturligt språk är fullt av ord som kondenseras till ett enda engelskt token men delas upp i flera ord på andra språk. Översättaren ser bara källsträngen, så när två orelaterade UI-element delar samma engelska ord, delar de samma msgid – och Gettext slår samman dem till en post.

Ord som delas upp mellan språk

Tänk på tre klassiska exempel:

• "Book" - substantivet (ett föremål på en hylla) kontra verbet ("Boka en flygning"). Tyska: Buch kontra buchen.
• "Post" - publicera innehåll kontra skicka e-post. Franska: publier kontra courrier.
• "Order" - en sekvens/sortering kontra ett köp. Spanska: orden kontra pedido.

På engelska använder din kod samma bokstavliga sträng på båda ställena:

// Somewhere in a library catalog screen
echo __( 'Book', 'mytextdomain' );

// Somewhere in a reservation form button
echo __( 'Book', 'mytextdomain' );

Hur identiska strängar slås samman till en post

När du kör wp i18n make-pot eller xgettext slås båda anropen samman till en enda .po-post:

#: catalog.php:42 reservation-form.php:88
msgid "Book"
msgstr ""

Det finns exakt en msgstr att fylla i. Oavsett vad översättaren väljer kommer en av de två skärmarna att vara fel. Översättaren kan inte åtgärda detta även om de förstår problemet, eftersom själva formatet inte tillåter dem att tillhandahålla två översättningar för en msgid. Tvetydigheten är inbakad i datan.

Vad är msgctxt och hur löser det tvetydighet?

msgctxt är en kontextsträng som är kopplad till en översättningspost. Det korta svaret: det lägger till en andra nyckel vid sidan av msgid, så Gettext behandlar (context, msgid) som ett unikt par. Två poster med samma msgid men olika msgctxt blir två separata, oberoende översättningsbara strängar.

I Gettexts uppslagsmodell är en översättning normalt sett endast nycklad av källsträngen. Med msgctxt blir nyckeln kombinationen av kontext plus källa. Det är hela mekanismen, och det är därför det fungerar så rent: du ändrar inte den visade texten, bara den interna uppslagsnyckeln.

msgctxt-raden i en .po-fil

I en .po-fil visas kontexten på en egen rad direkt ovanför msgid:

#: catalog.php:42
msgctxt "noun"
msgid "Book"
msgstr "Buch"

#: reservation-form.php:88
msgctxt "verb"
msgid "Book"
msgstr "Reservieren"

Nu finns det två poster. De har identiska msgid-värden men distinkta msgctxt-värden, så varje får sin egen msgstr. Katalogen renderar Buch; reservationsknappen renderar Reservieren. Runtime väljer den rätta eftersom din kod talade om vilken kontext som skulle användas.

Jämför det med den trasiga enskilda postversionen ovan. Skillnaden är inte översättningskvaliteten – det är om datamodellen ens tillåter det korrekta svaret att existera.

Markera din kod: _x() och _ex()

För att mata ut msgctxt till din .po-mall, anropar du en kontextmedveten översättningsfunktion istället för den vanliga. I WordPress är dessa _x() och dess ekande syskon _ex(); i ren Gettext mappas de till pgettext().

Välja mellan _x() och _ex()

Den vanliga __()-funktionen tar strängen och textdomänen. Kontextvarianten infogar kontexten som det andra argumentet:

// Without context - ambiguous
__( 'Book', 'mytextdomain' );

// With context - the second argument is the msgctxt
_x( 'Book', 'noun', 'mytextdomain' );        // returns the translated string
_ex( 'Book', 'verb', 'mytextdomain' );       // echoes it directly

// Real-world disambiguation
_x( 'Post', 'verb: publish content', 'mytextdomain' );
_x( 'Post', 'noun: mail item', 'mytextdomain' );
_x( 'Order', 'sequence or sorting', 'mytextdomain' );
_x( 'Order', 'customer purchase', 'mytextdomain' );

Det andra argumentet är kontextetiketten. Den visas aldrig för dina användare – den finns enbart för att lösa tvetydighet, både för Gettext-uppslagningen och för den som (eller det som) utför översättningen. Skriv kontexter som korta, beskrivande ledtrådar: 'substantiv', 'verb', 'knappetikett', 'adminmeny'. En vag kontext som '1' är tekniskt giltig men värdelös för en översättare.

När du genererar om mallen känner extraktorn igen dessa anrop och matar ut msgctxt-raden. Verktyg som Poedit och andra PO-redigerare grupperar sedan posterna synligt efter kontext, så att en mänsklig översättare omedelbart ser att "Book (substantiv)" och "Book (verb)" är två olika uppgifter. Om du fortfarande kopplar samman din extraktionsverktygskedja eller kämpar med hur variabler interagerar med dessa strängar, täcker vår guide om att översätta PO-filer utan att bryta kodvariabler det omgivande arbetsflödet i detalj.

Varför naiva översättare – och många AI-verktyg – missuppfattar detta

Här är den obekväma delen. Att lägga till msgctxt i din källa är nödvändigt men inte tillräckligt. Kontexten hjälper bara om det som utför översättningen faktiskt läser den.

Felmodellen för kasserad kontext

Ett naivt batchöversättningsskript gör så här: det loopar över poster, hämtar varje msgid, skickar det till ett översättnings-API och skriver resultatet till msgstr. Det tittar aldrig på msgctxt-raden. Så även om du noggrant skrev _x( 'Book', 'noun' ) och _x( 'Book', 'verb' ), skickar skriptet två identiska förfrågningar – "översätt Book" – och klistrar in samma svar i båda. All din markeringsinsats kasseras i sista steget.

Många allmänna AI-översättningsverktyg har samma blinda fläck. De är byggda för att översätta text, och msgctxt är metadata, inte text. Om verktyget plattar ut din .po till en lista med strängar innan den skickas till modellen, når kontexten aldrig modellens prompt. Modellen, som saknar signaler, faller tillbaka på ordets mest statistiskt sett vanligaste betydelse – vanligtvis substantivet för "Book", publicera-betydelsen för "Post" – och översätter tyst felaktigt minoritetsfallet. Du kommer inte att se ett fel. Du kommer att se en buggrapport från en tysk användare veckor senare.

Kontext och pluraler delar samma grundorsak

Det är också här hantering av plural och kontext korsar varandra, eftersom båda beror på att verktyget förstår Gettexts struktur snarare än att behandla filen som platt text. Om dina strängar också involverar räknebaserade former, spelar samma strukturella medvetenhet roll – vi förklarar det i förstå Gettext-pluraler.

Hur en kontextmedveten pipeline använder msgctxt

En översättningspipeline som respekterar msgctxt gör motsatsen till det naiva skriptet. Den tolkar .po-filen som strukturerad data, behåller varje posts kontext kopplad till dess källsträng, och skickar denna kontext till AI:n som en del av prompten – så att modellen vet att den översätter "Book" specifikt som ett verb, inte i abstrakt form.

Kontext som en förstklassig signal

Detta är exakt hur SimplePoTranslate närmar sig problemet. Dess kontextmedvetna AI läser msgctxt-raden som en förstklassig signal: när två poster delar en msgid men skiljer sig åt i kontext, översätts de som de distinkta strängar de faktiskt är, och kontextledtråden informerar modellens ordval. Resultatet är att "Book (substantiv)" återkommer som Buch medan "Book (verb)" återkommer som buchen eller reservieren – automatiskt, utan att du manuellt korrigerar varje tvetydig term.

Lika viktigt är att pipelinen bevarar msgctxt-raden i utdata. Ett svagare verktyg kan ta bort kontext under tur-och-retur-resan, tyst kollapsa dina två poster tillbaka till en och återinföra tvetydigheten vid nästa sammanslagning. Fullt Gettext-stöd innebär att kontexten överlever översättningen, .mo-kompileringen och eventuella senare återimporter – så din disambiguering är hållbar, inte en engångs manuell patch. Kombinerat med Syntaxlåsning för platshållare inuti dessa strängar får du översättningar som är både kontextuellt korrekta och strukturellt intakta.

Du äger fortfarande markeringsbeslutet – bara du vet att en given "Book" är ett verb. Men när du väl har kommenterat din källa med _x() och _ex(), förvandlar en kontextmedveten pipeline den kommentaren till korrekta översättningar i varje målspråk utan att du behöver "passa" varje sträng.

Slutsats

Tvetydighetsproblemet – ett engelskt ord, många betydelser – är inte en egenhet du kan ignorera; det är en strukturell egenskap för hur Gettext lagrar strängar. Lösningen är msgctxt: kommentera tvetydiga strängar i din källa med _x() och _ex(), ge varje förekomst en tydlig kontextetikett, och låt Gettext nyckla översättningen på paret (kontext, msgid). Den delen ligger på dig, och det tar minuter.

Den svårare delen är att se till att ditt översättningssteg faktiskt respekterar den kontexten istället för att kasta bort den. Naiva skript och textbaserade AI-verktyg kasserar msgctxt och återinför exakt den bugg du försökte förhindra. En kontextmedveten pipeline läser kontexten, översätter varje tvetydighetslöst inlägg korrekt och bevarar den genom kompilering och återimporter.

Redo att sluta leverera kontextblinda felöversättningar? Prova SimplePoTranslate gratis — inget kreditkort krävs. Den kostnadsfria nivån hanterar riktiga .po- och .pot-filer med fullt msgctxt-kontextstöd, så dina tvetydighetslösta strängar översätts korrekt första gången.