Hur man åtgärdar otydliga översättningar i WordPress .po-filer

Du översatte varje sträng. Du sparade filen, laddade upp .mo-filen och uppdaterade din webbplats. Och ändå är en handfull etiketter envist kvar på engelska. Du öppnar .po-filen, hittar strängen, och där är den, perfekt översatt. Så varför ignorerar WordPress den?

Svaret är nästan alltid en liten flagga som döljer sig ovanför posten: #, fuzzy. En otydlig översättning är gettext sätt att säga "denna översättning kan vara fel, så lita inte på den ännu." Och avgörande är att WordPress vägrar att visa otydliga strängar på den live webbplatsen, och återgår istället till originalengelskan. Detta är en av de mest missförstådda orsakarna till problemet "min översättning visas inte".

Den här guiden förklarar exakt vad flaggan för otydlig översättning betyder, varför den fortsätter att dyka upp i dina kataloger, och hur man hittar och rensar otydliga strängar i Poedit, på kommandoraden och i stor skala över en hel eftersläpning. När du väl förstår mekanismen försvinner mysteriet med de saknade översättningarna.

Vad betyder egentligen otydlighetsflaggan?

Otydlighetsflaggan är en markör som gettext lägger till i en översättningspost för att indikera att översättningen är osäker och behöver granskas manuellt. I den råa .po-filen visas den som en speciell kommentar direkt ovanför strängen.

#: includes/cart.php:88
#, fuzzy
msgid "Add to cart"
msgstr "Im Warenkorb"

Den #, fuzzy-raden talar om för alla gettext-medvetna verktyg, inklusive WordPress, att msgstr nedanför är provisorisk. Översättningen finns, men gettext anser den inte bekräftad.

Varför WordPress hoppar över otydliga strängar

Här är beteendet som överraskar alla. När WordPress kompilerar eller läser en .mo-fil behandlar den otydliga poster som oöversatta. Strängen är tekniskt sett närvarande i filen, men WordPress ignorerar den medvetet och visar istället den ursprungliga msgid.

Så ur ditt perspektiv är översättningen "klar", den finns där i filen. Men ur WordPress perspektiv har den strängen ingen tillförlitlig översättning, så den renderar den engelska källan. Det är just därför en färdig katalog fortfarande kan visa oöversatt text på frontend.

Denna design är avsiktlig och, rättvist nog, förnuftig. Hela poängen med otydlighetsflaggan är att förhindra att obekräftade, potentiellt felaktiga översättningar tyst publiceras. Tänk dig en sträng som ursprungligen löd "Delete account" och senare ändrades till "Deactivate account." Om gettext blint behöll den gamla översättningen, skulle dina användare kunna se en knapp märkt "Delete account" som egentligen bara avaktiverar, en farlig missmatchning. Genom att dölja otydliga strängar tvingar gettext en människa att bekräfta att översättningen fortfarande matchar den nya betydelsen innan den når någon. Flaggan är en säkerhetsmekanism, inte en bugg.

Varför fortsätter otydlighetsflaggor att dyka upp?

Otydlighetsflaggor är inte slumpmässiga. De genereras automatiskt av gettext-verktyg i två huvudsakliga situationer, och att förstå båda berättar hur du förhindrar dem.

Källsträngen ändrades

Den vanligaste orsaken är en källuppdatering. Tänk dig att utvecklaren ändrar en sträng i nästa pluginversion från "Add to cart" till "Add to basket." När du slår samman den nya mallen med din befintliga översättning, ser gettext att källan inte längre matchar det du ursprungligen översatte. Istället för att kasta bort din gamla översättning, behåller den den men markerar den som otydlig, vilket i princip säger: "engelskan ändrades, så vänligen kontrollera om din översättning fortfarande passar."

Automatisk matchning med översättningsminne och msgmerge

Den andra orsaken är otydlig matchning under en sammanslagning. Verktyget msgmerge uppdaterar en gammal översättningsfil mot en ny mall, och när det hittar en källsträng som är liknande men inte identisk med en tidigare, kopierar det över den gamla översättningen och flaggar den som otydlig.

# Merge a new template into an existing translation.
# Similar-but-changed strings get marked #, fuzzy automatically.
msgmerge --update awesome-plugin-de_DE.po awesome-plugin.pot

Översättningsminne i skrivbordsredigerare beter sig på samma sätt: när det automatiskt fyller i ett förslag från en nästan-matchning, markerar det resultatet som otydligt så att du kommer ihåg att verifiera det. I båda fallen gör flaggan sitt jobb. Problemet är bara att de otydliga posterna sedan förblir orecenserade, och WordPress döljer dem tyst.

Det finns en tredje, mer förrädisk källa som är värd att känna till: kopiera-klistra in och massimportverktyg. Vissa översättningsplattformar och importskript markerar varje post som otydlig som standard som en konservativ åtgärd, och förväntar sig att en människa ska bekräfta varje efteråt. Om du importerar en katalog från ett annat system och upptäcker att varje enskild sträng plötsligt är otydlig, är det oftast därför. Översättningarna kan vara helt okej, men tills flaggorna är rensade kommer ingen av dem att visas på din webbplats. Att känna till flaggornas källa talar om för dig om du verkligen behöver granska varje post eller om en säker massrensning är säker.

Hur hittar och åtgärdar du otydliga strängar?

Att rensa otydliga strängar innebär att granska varje enskild och, när du bekräftat att översättningen är korrekt, ta bort flaggan. Det finns tre praktiska sätt att göra detta beroende på jobbets storlek.

Åtgärda otydliga strängar i Poedit

Poedit gör detta enklast. Öppna .po-filen och använd sök- och filterkontrollerna för att endast visa otydliga poster, de är färgkodade (vanligtvis orange) så att de omedelbart sticker ut. Klicka på varje, bekräfta eller korrigera översättningen, och växla sedan av det otydliga tillståndet med kortkommandot (Redigera och sedan "Översättning är otydlig", eller kortkommandot som visas i menyn). När du sparar, kompilerar Poedit om en ren .mo-fil och de nu bekräftade strängarna kommer att visas på din webbplats. Om du är ny i den redigeraren, täcker den kompletta Poedit-guiden filter- och granskningsflödet i detalj.

Åtgärda otydliga strängar på kommandoraden

För automatisering eller stora kataloger är kommandoraden snabbare. Du kan räkna otydliga poster och, när du har verifierat dem i bulk, ta bort flaggorna så att WordPress laddar dem.

# Count how many fuzzy strings remain
msgattrib --only-fuzzy --no-obsolete awesome-plugin-de_DE.po | grep -c "msgid"

# Clear all fuzzy flags (only after you trust the translations)
msgattrib --clear-fuzzy --empty awesome-plugin-de_DE.po \
  --output-file=awesome-plugin-de_DE.po

Var försiktig med massrensning. Att ta bort otydliga flaggor utan att granska översättningarna motverkar flaggans syfte och kan leverera genuint felaktig text till dina användare. Använd kommandoradsmetoden när du litar på översättningarnas källa, och den manuella Poedit-vägen när du inte gör det.

En säker medelväg är att exportera de otydliga strängarna till en separat fil, granska endast dem och slå samman dem igen. Detta håller dina bekräftade översättningar orörda medan du fokuserar endast på de poster som faktiskt behöver uppmärksamhet.

# Extract only the fuzzy entries for focused review
msgattrib --only-fuzzy --no-obsolete awesome-plugin-de_DE.po \
  --output-file=fuzzy-only.po

Att granska femtio isolerade strängar är betydligt mindre felbenäget än att skrolla igenom en tusenradig katalog och leta efter orange rader, och det ger dig en tydlig registrering av exakt vad som ändrades i den senaste uppdateringen.

Efter att ha rensat flaggorna, spara alltid om eller kompilera om .mo-filen. Det otydliga tillståndet finns i .po-filen, men WordPress läser den binära .mo-filen, så tills du återskapar den kommer din frontend att fortsätta visa engelska trots att .po-filen ser ren ut. Poedit kompilerar om automatiskt vid spara; på kommandoraden kör du msgfmt awesome-plugin-de_DE.po -o awesome-plugin-de_DE.mo. Att glömma detta sista kompileringssteg är en av de vanligaste orsakerna till att en nyligen rensad katalog fortfarande inte visas; översättningen är bekräftad i källfilen, men den binära filen som webbplatsen faktiskt laddar är föråldrad.

Observera att otydliga poster ofta dyker upp tillsammans med pluralsträngar, där en ändrad msgid_plural kan markera hela pluralblocket som otydligt. Om din otydliga eftersläpning är tung på antal och kvantiteter, förklarar vår guide till Gettext-pluraler och komplex pluralisering varför dessa poster är särskilt känsliga under sammanslagningar.

Rensning av otydlig eftersläpning i stor skala

En enda otydlig sträng är en trettio sekunders fix. En katalog med fyrahundra otydliga strängar efter en större plugin-uppdatering är ett annat problem, och över ett dussin språk blir det en verklig flaskhals. Frestelsen att massrensa flaggorna utan granskning är exakt hur trasiga översättningar når produktion.

En renare lösning är att översätta de otydliga posterna på nytt snarare än att godkänna inaktuella matchningar. När du kör en katalog genom SimplePoTranslate, producerar den kontextmedvetna AI:n en aktuell, bekräftad översättning för varje ändrad sträng, så du tar inte bara bort en varningsflagga, du ersätter osäkra matchningar med verkliga översättningar. Syntaxlåsning håller varje %s, %1$s, {count} och HTML-tagg intakt under passet, och Smart Batching bearbetar stora kataloger efter uppdatering i ett svep. Du får tillbaka en ren ZIP-fil med .po, .mo, .json, .php och .xliff, utan kvarvarande otydlig eftersläpning, redo att distribueras från molnet.

Det är värt att skilja detta från den bredare frågan om varför översättningar överhuvudtaget inte visas. Otydlighetsflaggor är en specifik orsak, men saknade .mo-filer, felaktiga filnamn och språkinställningsmissmatchningar orsakar samma symptom. För den fullständiga diagnostiska checklistan, se vår felsökningsguide för översättningar som inte visas i WordPress, som behandlar otydliga strängar som en punkt i en större lista.

Redo att rensa en hel otydlig eftersläpning och få varje sträng att visas på din webbplats? Prova SimplePoTranslate gratis — inget kreditkort krävs. Gratisnivån översätter din .po-fil på nytt, och ersätter osäkra otydliga matchningar med rena, bekräftade översättningar.