Jak skompilować pliki .po do .mo (4 Metody)

Spędziłeś popołudnie na doskonaleniu niemieckiego tłumaczenia. Każdy ciąg znaków w pliku de_DE.po wygląda pięknie, symbole zastępcze są nienaruszone, a formy liczby mnogiej są poprawne. Przesyłasz go na swoją stronę, zmieniasz język na niemiecki i... nic. Strona nadal jest po angielsku. Sprawdzasz nazwę pliku, folder, domenę tekstową. Wszystko wygląda w porządku. Dlaczego więc WordPress nie wyświetla Twojego tłumaczenia?

W dziewięciu przypadkach na dziesięć odpowiedź jest taka sama: edytowałeś .po, ale nigdy nie skompilowałeś go do .mo. WordPress nie odczytuje plików .po w czasie wykonania — ładuje skompilowany plik binarny .mo. Jeśli chcesz, aby Twoje tłumaczenia faktycznie się pojawiły, musisz kompilować po do mo za każdym razem, gdy zmieniasz tekst. Plik .po to Twoje edytowalne źródło; .mo to to, co wyświetla strona.

Ten przewodnik wyjaśnia, dlaczego ten krok kompilacji istnieje, a następnie przedstawia cztery niezawodne sposoby na jego wykonanie: WP-CLI, klasyczne polecenie msgfmt, Poedit oraz narzędzie chmurowe, które automatycznie generuje plik .mo za Ciebie. Omówimy również najczęstszą pułapkę — zapominanie o ponownej kompilacji — oraz nowszy format .l10n.php, który WordPress preferuje obecnie ze względu na szybkość.

Dlaczego WordPress ładuje .mo, a nie .po?

WordPress ładuje pliki .mo, ponieważ są to skompilowane pliki binarne zoptymalizowane pod kątem szybkiego wyszukiwania, podczas gdy pliki .po to zwykłe pliki tekstowe stworzone do czytania i edytowania przez ludzi. Parsowanie tekstu przy każdym ładowaniu strony byłoby wolne; odczytanie gotowej binarnej tablicy mieszającej jest niemal natychmiastowe.

Plik .po jest zorientowany liniowo i przyjazny dla człowieka. Każdy wpis łączy źródłowe msgid z przetłumaczonym msgstr, plus komentarze wskazujące, skąd pochodzi dany ciąg znaków. Jest to świetne do edycji, ale okropne dla wydajności — serwer musiałby ponownie parsować cały plik tekstowy przy każdym żądaniu.

#: includes/cart.php:88
msgid "Your cart is empty"
msgstr "Ihr Warenkorb ist leer"

Plik .mo pakuje te same pary ciągów znaków w format binarny z wewnętrzną tabelą wyszukiwania, dzięki czemu WordPress może przejść bezpośrednio do tłumaczenia bez skanowania tekstu. Kompromisem jest to, że .mo jest nieczytelny dla ludzi i musi być regenerowany za każdym razem, gdy zmienia się .po. Jeśli rozróżnienie między .po a .mo jest nadal niejasne, nasz artykuł objaśniający .po vs .mo vs .pot files szczegółowo opisuje każdy format i ich wzajemne powiązania.

Cztery sposoby kompilacji po do mo

Nie ma jednego "poprawnego" narzędzia — najlepszy wybór zależy od tego, jak już pracujesz. Poniżej przedstawiamy cztery niezawodne metody, od polecenia jednowierszowego po w pełni zautomatyzowany przepływ pracy w chmurze. Wszystkie cztery generują identyczny plik binarny .mo, który WordPress ładuje w czasie wykonania.

Metoda 1: WP-CLI

Najczystszym nowoczesnym podejściem jest WP-CLI, które może skompilować cały folder plików .po za pomocą jednego polecenia. Jeśli już zarządzasz WordPressem z wiersza poleceń, pasuje to naturalnie do Twojego przepływu pracy.

# Compile every .po file in the languages folder to .mo
wp i18n make-mo languages/

# Compile into a specific destination directory
wp i18n make-mo languages/ build/languages/

Polecenie make-mo skanuje katalog docelowy, kompiluje każdy znaleziony plik .po i zapisuje pasujący plik .mo obok niego (lub w określonej przez Ciebie lokalizacji docelowej). Obsługuje partie w sposób elegancki, co czyni go idealnym rozwiązaniem, gdy utrzymujesz wiele języków jednocześnie. Jest to zalecane narzędzie dla każdego projektu, który już używa WP-CLI.

Metoda 2: msgfmt

Oryginalnym narzędziem Gettext do tego zadania jest msgfmt, część pakietu GNU gettext. Kompiluje pojedynczy plik .po w pojedynczy plik .mo i jest dostępny praktycznie w każdym systemie Linux i macOS.

# Compile one file
msgfmt my-plugin-de_DE.po -o my-plugin-de_DE.mo

# Add statistics about translated, fuzzy, and untranslated strings
msgfmt --statistics my-plugin-de_DE.po -o my-plugin-de_DE.mo

# Install it first if missing
#   macOS:  brew install gettext
#   Debian: sudo apt-get install gettext

Flaga -o nadaje nazwę plikowi wyjściowemu. Flaga --statistics jest naprawdę przydatna — informuje, ile ciągów znaków jest przetłumaczonych, niepewnych (fuzzy) lub nadal pustych, dzięki czemu wychwytujesz niekompletne tłumaczenie przed jego wdrożeniem. Do skryptowania pojedynczych plików msgfmt jest niezawodnym i prostym wyborem.

Ponieważ msgfmt jest prostym narzędziem wiersza poleceń, doskonale pasuje do automatyzacji. Możesz umieścić je w pętli shellowej, aby skompilować cały folder, lub włączyć do potoku CI, tak aby każdy commit, który dotyczy pliku .po, automatycznie tworzył świeży plik .mo. Popularny wzorzec to for f in languages/*.po; do msgfmt "$f" -o "${f%.po}.mo"; done, który kompiluje każdy język w jednym przebiegu. Flaga --check dodaje walidację, sygnalizując niezgodności ciągów formatujących między msgid a msgstr, zanim trafią one do produkcji — jest to tanie zabezpieczenie przed błędami z uszkodzonymi symbolami zastępczymi, które po cichu psują przetłumaczone układy.

Metoda 3: Poedit (kompiluje przy zapisie)

Jeśli edytujesz tłumaczenia w edytorze graficznym, Poedit kompiluje je dla Ciebie automatycznie. Za każdym razem, gdy zapisujesz plik .po, Poedit zapisuje pasujący plik .mo tuż obok niego — bez osobnego polecenia, bez dodatkowego kroku.

Jest to jeden z powodów, dla których Poedit pozostaje popularny wśród tłumaczy, którzy nie czują się komfortowo z wierszem poleceń. Otwierasz plik .po, wpisujesz tłumaczenia, naciskasz zapisz, a oba pliki aktualizują się razem. Możesz potwierdzić to zachowanie w preferencjach Poedit, gdzie automatyczna kompilacja .mo przy zapisie jest domyślnie włączona. Poedit i podobne narzędzia desktopowe są omówione w top 5 free tools to edit and translate PO files on Mac and Windows.

Wadą edytora desktopowego jest to, że kompilacja następuje tylko wtedy, gdy człowiek otworzy plik i go zapisze. Jest to w porządku dla projektu jednej osoby, ale nie skaluje się do kilkunastu języków ani zespołu przekazującego sobie pliki. Jeśli ktoś edytuje plik .po w innym narzędziu i kopiuje go do repozytorium bez otwierania Poedit, plik .mo nigdy się nie aktualizuje. W przypadku większych projektów lub projektów współpracujących, metoda zautomatyzowana — wiersz poleceń lub chmura — eliminuje tę zależność od pamiętania o naciśnięciu przycisku zapisu.

Metoda 4: Narzędzie chmurowe, które generuje dla Ciebie plik .mo

Czwarta opcja całkowicie eliminuje krok kompilacji: użyj usługi chmurowej, która zwraca skompilowany plik .mo razem z przetłumaczonym .po. Nigdy nie uruchamiasz polecenia ani nie zapisujesz pliku dwukrotnie — przesyłasz, a gotowe, poprawnie nazwane pliki wracają do Ciebie.

SimplePoTranslate działa dokładnie w ten sposób. Przesyłasz plik .po lub .pot, tłumaczy on ciągi znaków za pomocą AI uwzględniającej kontekst, i zwraca pojedynczy plik ZIP zawierający .po i .mo wygenerowane obok siebie — już skompilowane, już nazwane tak, aby pasowały do Twojej domeny tekstowej i lokalizacji. Nie ma osobnego etapu kompilacji i nie ma możliwości zapomnienia o niej.

Obsługuje również szczegóły, które zakłócają ręczne przepływy pracy. Blokowanie składni (Syntax Locking) zamraża symbole zastępcze, takie jak %s, %1$s i {name}, oraz tagi HTML przed tłumaczeniem, dzięki czemu Twoje zmienne pozostają nienaruszone w pliku .mo. Pełne wsparcie dla liczby mnogiej Gettext oznacza, że złożone formy liczby mnogiej również kompilują się poprawnie — temat wart głębokiego zrozumienia, który omawiamy w understanding Gettext plurals. A ponieważ działa w chmurze, nie ma wtyczki do zainstalowania ani narzędzi do kompilacji do utrzymywania.

Najczęstsza pułapka: Zapomniałeś ponownie skompilować

Największym pojedynczym powodem, dla którego tłumaczenia nie pojawiają się, jest edycja pliku .po, ale zapominanie o ponownej kompilacji pliku .mo. WordPress nadal ładuje stary plik binarny, więc Twoje świeże sformułowanie nigdy się nie pojawia — i nie ma komunikatu o błędzie, który by Ci to wyjaśnił.

Model myślowy, który należy zapamiętać: .po to Twój szkic, .mo to to, co jest dostarczane. Każda zmiana w pliku .po jest niewidoczna dla WordPressa, dopóki nie zregenerujesz pliku .mo. Uczyń ponowną kompilację odruchem po każdej edycji lub użyj narzędzia, które kompiluje automatycznie, aby tego kroku nigdy nie można było pominąć.

Ta pułapka jest szczególnie podstępna podczas przekazywania z środowiska testowego na produkcyjne. Deweloper edytuje i ponownie kompiluje lokalnie, widzi działające tłumaczenie, a następnie wdraża tylko plik .po i zapomina o .mo — więc produkcja cicho zachowuje stary tekst. Za każdym razem, gdy przenosisz pliki tłumaczeń między środowiskami, przenoś plik .po i świeżo skompilowany .mo razem, lub kompiluj jako część etapu wdrożenia, tak aby plik binarny był zawsze przebudowywany z aktualnego źródła.

Jeśli Twoje tłumaczenia nadal nie chcą się pojawić po ponownej kompilacji, problemem jest zazwyczaj niezgodność nazewnictwa, niewłaściwy folder lub warstwa cache'u przechowująca stary plik. Pełna lista kontrolna znajduje się w why your translations are not showing up in WordPress.

Uwaga na temat nowszego formatu .l10n.php

Ostatnie wersje WordPressa wprowadziły trzeci format wykonawczy: .l10n.php. Zamiast binarnego pliku .mo, tłumaczenia są przechowywane jako zwykła tablica PHP, którą pamięć podręczna opcode PHP może przechowywać w pamięci, co sprawia, że wyszukiwanie jest jeszcze szybsze niż w przypadku .mo na ruchliwych stronach.

<?php
return [
	'domain'  => 'my-plugin',
	'messages' => [ 'Your cart is empty' => 'Ihr Warenkorb ist leer' ],
];

WordPress generuje pliki .l10n.php automatycznie, gdy ma dostępny pasujący plik .mo, więc nie musisz ich budować ręcznie. Na razie kompilacja poprawnego .mo pozostaje podstawą — format wydajnościowy jest od niego pochodny.

Podsumowanie

Aby niezawodnie kompilować po do mo, wybierz metodę, która pasuje do Twojego sposobu pracy: WP-CLI dla operacji wsadowych w wierszu poleceń, msgfmt dla pojedynczych plików ze statystykami, Poedit do automatycznej kompilacji przy zapisie, lub narzędzie chmurowe, które buduje plik .mo za Ciebie, tak aby ten krok nigdy nie został pominięty. Wszystkie cztery metody produkują ten sam plik binarny, którego WordPress potrzebuje w czasie wykonania.

Niezależnie od wybranej drogi, pamiętaj o złotej zasadzie: edytuj .po, a następnie kompiluj do .mo — za każdym razem. Ten jeden nawyk zapobiega najbardziej frustrującym błędom tłumaczeniowym w WordPressie, tym, w których wszystko wygląda poprawnie, ale strona uparcie pozostaje po angielsku.

Gotowy na trwałe pominięcie ręcznego etapu kompilacji? Wypróbuj SimplePoTranslate za darmo — karta kredytowa nie jest wymagana. Prześlij swój plik .po i pobierz gotowy do wdrożenia pakiet .po + .mo w darmowej wersji w ciągu kilku minut.