Sådan rettes tvivlsomme oversættelser i WordPress .po-filer

Du oversatte hver eneste streng. Du gemte filen, uploadede .mo-filen og genindlæste din side. Og alligevel er en håndfuld etiketter stadig stædigt på engelsk. Du åbner .po-filen, finder strengen, og der er den, perfekt oversat. Så hvorfor ignorerer WordPress den?

Svaret er næsten altid et lille flag, der gemmer sig over posten: #, fuzzy. En tvivlsom oversættelse er gettext's måde at sige "denne oversættelse kan være forkert, så stol ikke på den endnu." på. Og afgørende er, at WordPress nægter at vise tvivlsomme strenge på den live side og falder i stedet tilbage til det originale engelsk. Dette er en af de mest misforståede årsager til problemet "min oversættelse vises ikke".

Denne guide forklarer præcis, hvad flagget for tvivlsom oversættelse betyder, hvorfor det bliver ved med at dukke op i dine kataloger, og hvordan du finder og rydder tvivlsomme strenge i Poedit, på kommandolinjen og i stor skala på tværs af en hel efterslæb. Når du først forstår mekanismen, forsvinder mysteriet om de manglende oversættelser.

Hvad betyder Fuzzy-flagget egentlig?

Fuzzy-flagget er en markør, som gettext tilføjer til en oversættelsespost for at indikere, at oversættelsen er usikker og kræver menneskelig gennemgang. I den rå .po-fil vises det som en speciel kommentar direkte over strengen.

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

Den linje #, fuzzy fortæller ethvert gettext-kompatibelt værktøj, inklusive WordPress, at msgstr nedenunder er foreløbig. Oversættelsen eksisterer, men gettext betragter den ikke som bekræftet.

Hvorfor WordPress ignorerer tvivlsomme strenge

Her er den adfærd, der tager alle på sengen. Når WordPress kompilerer eller læser en .mo-fil, behandler den tvivlsomme poster som uoversatte. Strengen er teknisk set til stede i filen, men WordPress ignorerer den bevidst og viser i stedet den originale msgid.

Så fra dit perspektiv er oversættelsen "færdig", den er lige der i filen. Men fra WordPress' perspektiv har den streng ingen troværdig oversættelse, så den viser den engelske kildetekst. Dette er netop grunden til, at et færdigt udseende katalog stadig kan vise uoversat tekst på frontenden.

Dette design er forsætligt og, ret skal være ret, fornuftigt. Hele pointen med fuzzy-flagget er at forhindre uverificerede, potentielt forkerte oversættelser i at blive offentliggjort uden varsel. Forestil dig en streng, der oprindeligt lød "Slet konto" og senere blev ændret til "Deaktiver konto". Hvis gettext blindt beholdt den gamle oversættelse, ville dine brugere muligvis se en knap mærket "Slet konto", som faktisk kun deaktiverer, en farlig uoverensstemmelse. Ved at skjule tvivlsomme strenge tvinger gettext et menneske til at bekræfte, at oversættelsen stadig matcher den nye betydning, før den når ud til nogen. Flagget er en sikkerhedsmekanisme, ikke en fejl.

Hvorfor bliver tvivlsomme flag ved med at dukke op?

Tvivlsomme flag er ikke tilfældige. De genereres automatisk af gettext-værktøjer i to hovedsituationer, og forståelse af begge fortæller dig, hvordan du forhindrer dem.

Kildestrengen ændret

Den mest almindelige årsag er en kildeopdatering. Forestil dig, at udvikleren ændrer en streng i den næste plugin-version fra "Læg i kurv" til "Læg i indkøbskurv". Når du fletter den nye skabelon ind i din eksisterende oversættelse, ser gettext, at kilden ikke længere matcher det, du oprindeligt oversatte. I stedet for at smide din gamle oversættelse væk, beholder den den, men markerer den som tvivlsom og siger i det væsentlige: "det engelske er ændret, så tjek venligst igen, om din oversættelse stadig passer."

Auto-matchning via oversættelseshukommelse og msgmerge

Den anden årsag er tvivlsom matchning under en fletning. msgmerge-værktøjet opdaterer en gammel oversættelsesfil mod en ny skabelon, og når det finder en kildestreng, der er lignende, men ikke identisk med en tidligere, kopierer det den gamle oversættelse over og markerer den som tvivlsom.

# 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

Oversættelseshukommelse i desktop-editorer opfører sig på samme måde: når den automatisk udfylder et forslag fra et nært match, markerer den resultatet som tvivlsomt, så du husker at verificere det. I begge tilfælde udfører flagget sit arbejde. Problemet er blot, at de tvivlsomme poster derefter forbliver uanmeldte, og WordPress skjuler dem stille og roligt.

Der er en tredje, mere snedig kilde, der er værd at kende til: copy-paste og masseudfyldningsværktøjer. Nogle oversættelsesplatforme og importskripter markerer som standard hver post som tvivlsom som en forsigtighedsforanstaltning, idet de forventer, at et menneske bekræfter hver enkelt efterfølgende. Hvis du importerer et katalog fra et andet system og finder, at hver eneste streng pludselig er tvivlsom, er dette normalt årsagen. Oversættelserne kan være helt fine, men indtil flaggene er ryddet, vil ingen af dem vises på din side. At kende kilden til flaggene fortæller dig, om du virkelig har brug for at gennemgå hver post, eller om en sikker massefjernelse er tryg.

Hvordan finder og retter du tvivlsomme strenge?

At rydde tvivlsomme strenge betyder at gennemgå hver enkelt, og når du har bekræftet, at oversættelsen er korrekt, fjerner du flagget. Der er tre praktiske måder at gøre dette på, afhængigt af opgavens størrelse.

Ret tvivlsomme strenge i Poedit

Poedit gør dette til det nemmeste. Åbn .po-filen og brug søge- og filterkontrollerne til kun at vise tvivlsomme poster; de er farvekodede (normalt orange), så de skiller sig straks ud. Klik på hver enkelt, bekræft eller ret oversættelsen, og slå derefter den tvivlsomme tilstand fra med tastaturgenvejen (Rediger og derefter "Oversættelsen er tvivlsom," eller den genvej, der vises i menuen). Når du gemmer, genkompilerer Poedit en ren .mo-fil, og de nu bekræftede strenge vil blive vist på din side. Hvis du er ny til denne editor, dækker den komplette Poedit-guide filter- og gennemgangsarbejdsgangen i detaljer.

Ret tvivlsomme strenge på kommandolinjen

Til automatisering eller store kataloger er kommandolinjen hurtigere. Du kan tælle tvivlsomme poster, og når du har verificeret dem i bulk, fjerne flaggene, så WordPress vil indlæse 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

Vær forsigtig med massefjerning. At fjerne tvivlsomme flag uden at gennemgå oversættelserne modarbejder flaggets formål og kan sende ægte forkert tekst til dine brugere. Brug kommandolinje-tilgangen, når du stoler på oversættelsernes kilde, og den manuelle Poedit-vej, når du ikke gør.

En sikker mellemvej er at eksportere de tvivlsomme strenge til en separat fil, gennemgå kun dem og flette dem tilbage. Dette holder dine bekræftede oversættelser uberørte, mens du kun fokuserer på de poster, der faktisk kræver opmærksomhed.

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

At gennemgå halvtreds isolerede strenge er langt mindre fejlbehæftet end at scrolle et tusind-linjers katalog på jagt efter orange rækker, og det giver dig en ren oversigt over præcis, hvad der blev ændret i den sidste opdatering.

Efter at have ryddet flaggene, skal du altid gemme eller genkompilere .mo-filen igen. Den tvivlsomme tilstand lever i .po-filen, men WordPress læser den binære .mo-fil, så indtil du regenererer den, vil din frontend blive ved med at vise engelsk, selvom .po-filen ser ren ud. Poedit genkompilerer automatisk ved lagring; på kommandolinjen kører du msgfmt awesome-plugin-de_DE.po -o awesome-plugin-de_DE.mo. At glemme dette sidste kompileringstrin er en af de mest almindelige årsager til, at et nyrenset katalog stadig ikke vises; oversættelsen er bekræftet i kildefilen, men den binære fil, som siden faktisk indlæser, er forældet.

Bemærk, at tvivlsomme poster ofte vises sammen med flertalstrenge, hvor en ændret msgid_plural kan markere hele flertalsblokken som tvivlsom. Hvis din tvivlsomme efterslæb er tung med tællinger og mængder, forklarer vores guide til Gettext flertal og kompleks pluralisering, hvorfor disse poster er særligt skrøbelige under fletninger.

Rydning af den tvivlsomme efterslæb i stor skala

En enkelt tvivlsom streng er en tredive-sekunders løsning. Et katalog med fire hundrede tvivlsomme strenge efter en større plugin-opdatering er et andet problem, og på tværs af et dusin sprog bliver det en ægte flaskehals. Fristelsen til at massefjerne flaggene uden gennemgang er præcis, hvordan ødelagte oversættelser når produktion.

En renere løsning er at genoversætte de tvivlsomme poster friske snarere end at blindt godkende forældede match. Når du kører et katalog gennem SimplePoTranslate, producerer den kontekstbevidste AI en aktuel, bekræftet oversættelse for hver ændret streng, så du fjerner ikke kun et advarselsflag, du erstatter usikre match med rigtige oversættelser. Syntakslåsning holder hver %s, %1$s, {count} og HTML-tag intakt under behandlingen, og Smart Batching behandler store kataloger efter opdatering i én omgang. Du får en ren ZIP-fil tilbage med .po, .mo, .json, .php og .xliff, ingen dvælende tvivlsom efterslæb, klar til at blive implementeret fra skyen.

Det er værd at skelne dette fra det bredere spørgsmål om, hvorfor oversættelser overhovedet ikke vises. Tvivlsomme flag er én specifik årsag, men manglende .mo-filer, forkerte filnavne og locale-uoverensstemmelser forårsager det samme symptom. For den komplette diagnostiske tjekliste, se vores fejlfindingsguide for oversættelser, der ikke vises i WordPress, som behandler tvivlsomme strenge som ét element på en større liste.

Klar til at rydde en hel tvivlsom efterslæb og få hver streng vist på din side? Prøv SimplePoTranslate gratis — intet kreditkort påkrævet. Det gratis niveau genoversætter din .po-fil frisk og erstatter usikre tvivlsomme match med rene, bekræftede oversættelser.