Jeden plik wejściowy, pięć formatów wyjściowych: Jak zabezpieczyć swoje tłumaczenia WordPress na przyszłość

Spędziłeś trzy tygodnie tłumacząc swój motyw WordPress na język hiszpański. Plik .po jest idealny — każdy ciąg znaków sprawdzony, każda zmienna nienaruszona, każda forma liczby mnogiej poprawna. Następnie Twój klient decyduje się na migrację z klasycznego motywu PHP do konfiguracji headless z React na frontendzie.

Nagle Twój plik .po jest bezużyteczny. Aplikacja React potrzebuje .json. Starsze widżety PHP nadal potrzebują .mo. Freelancer obsługujący aplikację mobilną chce .xliff. I nikt nie ma czasu, aby ponownie przetłumaczyć 4000 ciągów znaków na trzy różne formaty.

To nie jest przypadek skrajny. To rzeczywistość nowoczesnego rozwoju WordPress, gdzie motywy są dostarczane zarówno z komponentami PHP, jak i JavaScript, wtyczki używają mieszanki Gettext i i18next, a klienci zmieniają zdanie na temat architektury częściej niż zmieniają hasła.

Dlaczego formaty plików tłumaczeń mają większe znaczenie niż kiedykolwiek

Pięć lat temu tłumaczenie WordPress było proste. Miałeś plik .po (źródło czytelne dla człowieka) i plik .mo (skompilowany plik binarny). To wszystko. Każdy motyw, każda wtyczka, każde narzędzie tłumaczeniowe mówiło tym samym językiem.

Dziś ekosystem WordPress używa co najmniej pięciu formatów plików tłumaczeń w środowisku produkcyjnym:

Pięć formatów, które musisz znać

.po (Portable Object) — Źródłowy format czytelny dla człowieka używany przez GNU Gettext. Zawiera oryginalne ciągi znaków (msgid) i ich tłumaczenia (msgstr). To właśnie edytują tłumacze.

msgid "Add to Cart"
msgstr "Anadir al carrito"

msgid "Your order has been shipped to %s"
msgstr "Su pedido ha sido enviado a %s"

.mo (Machine Object) — Skompilowana binarna wersja pliku .po. WordPress odczytuje pliki .mo w czasie wykonywania za pomocą load_textdomain(). Szybsze niż parsowanie .po w czasie wykonywania, ale nieedytowalne przez człowieka.

.json (JavaScript Object Notation) — Używany przez wp_set_script_translations() do tłumaczeń opartych na języku JavaScript w blokach Gutenberga, komponentach React i nowoczesnych motywach. WordPress oczekuje określonej struktury JSON z kluczami locale_data.

{
  "locale_data": {
    "flavor-starter": {
      "Add to Cart": ["Anadir al carrito"],
      "Your order has been shipped to %s": ["Su pedido ha sido enviado a %s"]
    }
  }
}

.php (PHP Array) — Coraz popularniejszy format dla motywów i wtyczek, które używają ładowania tłumaczeń w stylu Laravel. Niektóre nowoczesne motywy WordPress całkowicie pomijają Gettext i ładują tłumaczenia z tablic PHP dla wydajności.

<?php
return [
    'Add to Cart' => 'Anadir al carrito',
    'Your order has been shipped to %s' => 'Su pedido ha sido enviado a %s',
];

.xliff (XML Localization Interchange File Format) — Standard branżowy do wymiany tłumaczeń między różnymi narzędziami i platformami. Używany przez narzędzia CAT (Computer-Assisted Translation), takie jak memoQ, Trados i Memsource. Niezbędny podczas pracy z profesjonalnymi tłumaczami.

<trans-unit id="1">
  <source>Add to Cart</source>
  <target>Anadir al carrito</target>
</trans-unit>

Problem: Uzależnienie od formatu

Większość narzędzi tłumaczeniowych generuje jeden format wyjściowy. Poedit daje .po i .mo. WPML przechowuje tłumaczenia w bazie danych (w ogóle nie w plikach). Weglot przechowuje tłumaczenia na swoich serwerach w zastrzeżonym formacie. Nawet platformy TMS, takie jak Crowdin i Lokalise, wymagają ręcznej konfiguracji formatów eksportu dla każdego projektu.

To tworzy uzależnienie od formatu — Twoje tłumaczenia są uwięzione w formacie, który generuje Twoje obecne narzędzie. Gdy Twoje wymagania się zmieniają, masz dwie opcje:

1. Przetłumaczyć wszystko ponownie w nowym formacie (kosztowne, czasochłonne i tracisz wszelkie ręczne poprawki)
2. Pisać niestandardowe skrypty konwersji (podatne na błędy, szczególnie w przypadku złożonych form liczby mnogiej i zmiennych)

Żadna opcja nie jest dobra. Obie marnują czas i pieniądze. Obie wprowadzają ryzyko.

Rzeczywiste scenariusze, w których uzależnienie od formatu szkodzi

Scenariusz 1: Modernizacja motywu. Motyw klienta jest przebudowywany za pomocą bloków Gutenberga. Stare szablony PHP używały plików .mo. Nowe bloki potrzebują .json dla wp_set_script_translations(). Twoje 3000 przetłumaczonych ciągów znaków musi istnieć w obu formatach podczas przejścia.

Scenariusz 2: Workflow agencji. Zarządzasz 20 witrynami klientów. Niektóre używają klasycznych motywów (.mo). Niektóre używają konfiguracji headless (.json). Jeden używa niestandardowej platformy, która odczytuje tablice PHP. Potrzebujesz tych samych tłumaczeń w różnych formatach dla różnych klientów.

Scenariusz 3: Profesjonalna recenzja. Twoje tłumaczenia AI są dokładne w 95%, ale chcesz, aby native speaker dokonał przeglądu pozostałych 5%. Profesjonalni tłumacze używają narzędzi CAT, które importują .xliff. Musisz wyeksportować swoje tłumaczenia do .xliff, wysłać je do recenzji i scalić poprawki z powrotem.

Scenariusz 4: Migracja platformy. Twój klient przenosi się z WordPress do niestandardowej aplikacji Node.js. Nowa aplikacja używa i18next i potrzebuje plików .json. Twoje 5000 przetłumaczonych ciągów znaków w formacie .po musi zostać przekonwertowane — bez utraty ani jednej zmiennej lub formy liczby mnogiej.

Rozwiązanie: Przetłumacz raz, uzyskaj każdy format

SimplePoTranslate przyjmuje inne podejście. Gdy przesyłasz plik .po, .pot, .json lub .xliff i uruchamiasz tłumaczenie, otrzymujesz z powrotem ZIP zawierający wszystkie pięć formatów:

translations-es_ES.zip
├── flavor-starter-es_ES.po
├── flavor-starter-es_ES.mo
├── flavor-starter-es_ES.json
├── flavor-starter-es_ES.php
└── flavor-starter-es_ES.xliff

To nie jest „funkcja premium” zablokowana za warstwą korporacyjną. Każdy płatny plan — Pro (19 USD miesięcznie) i Lifetime (399 USD jednorazowo) — obejmuje wszystkie pięć formatów wyjściowych w każdym zadaniu tłumaczeniowym.

Dlaczego to ma znaczenie dla zabezpieczenia na przyszłość

Gdy masz od początku wszystkie pięć formatów, nigdy nie musisz tłumaczyć ponownie. Twoje tłumaczenia są zasobem, który dostosowuje się do każdego wymagania technicznego:

• Klient migruje z klasycznego do Gutenberga? Wdróż plik .json.
• Nowy programista woli tablice PHP? Wręcz mu plik .php.
• Profesjonalny tłumacz chce dokonać przeglądu? Wyślij plik .xliff.
• Przechodzisz do innego CMS? Pliki .json i .xliff są niezależne od platformy.

Tłumaczysz raz. Formaty są gotowe, kiedy ich potrzebujesz.

Jak każdy format działa w WordPress

Wiedza, który plik gdzie umieścić, jest niezbędna do czystego wdrożenia.

Wdrażanie plików .mo (klasyczne motywy i wtyczki PHP)

wp-content/languages/plugins/woocommerce-es_ES.mo
wp-content/languages/themes/flavor-starter-es_ES.mo

WordPress ładuje je automatycznie, gdy język witryny pasuje. Nie jest wymagana żadna wtyczka. Zerowy narzut na bazę danych. To podejście zapewnia najlepszą wydajność.

Wdrażanie plików .json (bloki Gutenberga i komponenty JS)

wp-content/languages/plugins/woocommerce-es_ES-{handle}-{md5}.json

Nazwa pliku zawiera uchwyt skryptu i hash MD5. WordPress dopasowuje je, gdy wywołujesz wp_set_script_translations() w swojej wtyczce lub motywie. Jeśli tworzysz bloki Gutenberga, to ten plik sprawia, że Twoje przetłumaczone etykiety i opisy bloków pojawiają się poprawnie.

Używanie plików .xliff (profesjonalny workflow recenzji)

Pliki .xliff nie są wdrażane w WordPress. Są używane jako format wymiany, gdy musisz wysłać tłumaczenia do profesjonalnego recenzenta lub zaimportować je do narzędzia CAT. Workflow wygląda następująco:

1. Prześlij .po do SimplePoTranslate i uzyskaj .xliff w ZIP
2. Wyślij .xliff do tłumacza lub recenzenta
3. Odbierz poprawiony .xliff z powrotem
4. Prześlij poprawiony .xliff do SimplePoTranslate i uzyskaj zaktualizowane .mo i .json

Ten workflow w obie strony zachowuje każdą zmienną i formę liczby mnogiej, ponieważ Blokowanie składni SimplePoTranslate chroni je na każdym etapie.

Test uzależnienia od dostawcy

Oto prosty test, aby ustalić, czy Twój obecny workflow tłumaczeniowy ma problem z uzależnieniem:

1. Czy możesz teraz wyeksportować swoje tłumaczenia jako standardowe pliki .po?
2. Jeśli anulujesz subskrypcję narzędzia tłumaczeniowego dzisiaj, czy zachowasz każdy przetłumaczony ciąg znaków?
3. Czy możesz zaimportować swoje tłumaczenia do zupełnie innego narzędzia lub platformy bez ponownego tłumaczenia?

Jeśli odpowiedź na którekolwiek z tych pytań brzmi „nie”, jesteś uzależniony. Usługi takie jak Weglot i GTranslate nie przechodzą wszystkich trzech pytań — anuluj subskrypcję, a Twoje tłumaczenia znikną. WPML przechowuje tłumaczenia w bazie danych, umożliwiając eksport, ale jest to bolesne. Nawet narzędzia desktopowe, takie jak Poedit, zdają test na papierze, ale ograniczają Cię tylko do .po i .mo.

Z SimplePoTranslate odpowiedź na wszystkie trzy pytania brzmi „tak”. Pobierasz standardowe pliki w pięciu formatach. Są Twoje. Usuń swoje konto jutro, a każde tłumaczenie, którego kiedykolwiek dokonałeś, nadal będzie działać.

Budowanie biblioteki tłumaczeń niezależnej od formatu

Dla agencji i programistów zarządzających wieloma projektami, najmądrzejszym podejściem jest zbudowanie biblioteki tłumaczeń — repozytorium Git lub folderu udostępnionego, w którym przechowujesz przetłumaczone pliki dla każdego projektu klienta.

translations/
├── client-acme/
│   ├── es_ES/
│   │   ├── flavor-starter-es_ES.po
│   │   ├── flavor-starter-es_ES.mo
│   │   ├── flavor-starter-es_ES.json
│   │   ├── flavor-starter-es_ES.php
│   │   └── flavor-starter-es_ES.xliff
│   └── de_DE/
│       └── ...
├── client-globex/
│   └── ...

Gdy klient potrzebuje nowego formatu, już go masz. Gdy klient zmienia platformy, Twoje tłumaczenia migrują bez żadnego wysiłku. Gdy nowy programista dołącza do zespołu, może zobaczyć dokładnie, co zostało przetłumaczone i w jakich formatach.

To właśnie oznacza „zabezpieczenie na przyszłość” — nie przewidywanie, jakiej technologii będą używać Twoi klienci w przyszłym roku, ale upewnienie się, że Twoje tłumaczenia działają z tym, co wybiorą.

Gotowy, aby przestać martwić się o formaty plików? Wypróbuj SimplePoTranslate za darmo — prześlij jeden plik, uzyskaj pięć formatów z powrotem. Bez skryptów konwersji, bez ponownego tłumaczenia, bez uzależnienia.