Webspire

Administrační systém

Jak v NetWings 7 řešíme překlady

Překlady jsou jednou z velkých výzev při tvorbě rozsáhlejších webů s mnoha jazykovými mutacemi. Stav, kdy je ke každé drobné změně překladu na webu potřeba zásah programátora je nevyhovující. Zejména proto jsme hledali vhodnou cestu, jak se k překladům postavit.

Samotné Nette poskytuje obecné rozhraní ITranslator, které je možné implementovat dle libosti a které je využíváno a vyžadováno napříč celým frameworkem. K dispozici je Latte makro podtržítko nebo podpora ve formulářích, nicméně samotnou implementaci rozhraní Nette nechává již na programátorovi.

Dle portálu componette.com nejpoužívanější open-source implementaci tohoto obecného rozhraní poskytuje výborný balíček Kdyby/Translation. Ten je portem Symfony/Translation do Nette a zachovává všechny příjemné funkce, které v Symfony/Translation jsou.

Tento translator podporuje klíče překladů (tzn. že například v Latte šabloně vidíme {_messages.googleMap.fullscreenCloseButton} místo {_Zavřít}), plnou pluralizaci (řešení klasického problému „1 den“, „2 dny“, „5 dnů“), parametry v překladech („Vyplněné pole XY je povinné.“ – překlad je stále stejný, ale XY se dynamický mění) a další. Podrobnosti lze najít v dokumentaci. Navíc přidává podporu načítání překladů ze souborů NEON (který používáme i na další věci v rámci NetWings) a umožňuje upravit systém načítání zdrojů pro překlady. A toho všeho jsme využili i my v NetWings 7.

Hlavní požadavek byl, že překlady musí být schopný upravovat sám administrátor v administračním systému, aniž by musel kontaktovat nás (vývojáře/support). To znamená, že je vhodné, aby překlady byly uloženy v databázi. Také je vhodné, aby v NEON souboru přímo v repozitáři projektu byl uložen výchozí překlad (fallback), texty z něhož uvidíme my při vývoji a který bude později sloužit pro administrátora jako zdroj překládaných frází. Pokud by tam tento výchozí překlad nebyl, viděl by admin před vyplněním překladu jen klíč překladu, který by pro něj neměl dostatečnou vypovídající hodnotu, tzn. nevěděl by, co za text se skrývá pod „messages.footer.bottomText“ a jak ho má přeložit.

Jak tedy funguje výsledná implementace a výsledná práce s překlady? Při běžném vývoji v PHP a Latte používáme identifikátory překladů. Ty a jejich výchozí překlad do češtiny pak uvádíme do NEON souborů jak přímo na projektu, tak v jednotlivých balíčcích. V produkčním prostředí jsou pak tyto soubory spojeny do jednoho velkého NEONu, který je nastaven jako zdrojový.

Příklad jednoho z mnoha NEON souborů s výchozími překlady z repozitáře:

formMailer:
    sent: Odesláno
    dateFormat: "j. n. Y H:i:s"
    checked: ano
    unchecked: ne
    to: test@inspire.cz # email
    url: test-url # router

Dále je v administraci modul překladů. Zde má administrátor možnost pro všechny povolené jazyky webu přeložit všechny texty dle svého uvážení. Až je překlad hotový a uložený do databáze, může administrátor nechat „generovat překlady pro ostrý web“. Tím dojde k mergi výchozích překladů z kódu a překladů z databáze a přegenerování výsledného zdrojového NEONu. Mimo to má administrátor možnost „generovat překlady pro toto sezení“, čímž dojde také k přegenerování výsledného zdrojového NEONu, avšak nové překlady na webu vidí pouze tento uživatel (pokud je přihlášen do administrace a má nastaven určitý GET parametr). Před uveřejněním překladů si tak admin může překlady zkontrolovat přímo na webu a nově přeložený web si proklikat ještě před tím, než ho uvidí někdo jiný.

Ukázka modulu pro překlady v administračním systému
Ukázka modulu pro překlady v administračním systému

Dalším z problémů, kterým jsme museli čelit, bylo to, že administrátoři občas nevyplňovali hodnoty překladů korektně. Například vyplňovali nevalidní e-mailové adresy, do překladů URL dávali diakritiku a podobně. To jsme vyřešili tak, že výchozí NEON soubory s překlady podporují tzv. flagy. To znamená, že za hodnotu překladu máme možnost napsat komentář „# email“ a administrace pak při editaci tohoto překladu uživatelem umožní zadat pouze e-mailovou adresu, v případě „# router“ pak pouze validní text do URL a podobně. Tímto způsobem je zajištěna validita překladů, které vyplní admin a my se o to vůbec nemusíme starat. Výchozí implementace NEONu v Nette parsování komentářů nepodporuje, to jsme si museli napsat sami.

Dalším ze šikovných flagů je flag copywriting. Pomocí něj označujeme překlady, které velmi doporučujeme klientovi před spuštěním výchozí jazykové mutace webu zkontrolovat copywriterem (většina překladů a českých textů zpravidla kontrolu nepotřebuje a lze použít jejich výchozí překlad z NEONu v repozitáři). Podle tohoto flagu je pak možné překlady v administraci filtrovat, takže pokud klient (nebo copywriter) nechce kontrolovat všechny překlady, může projít jen ty důležité.

Zmíním také flag # system, který je určený pro překlady, které se vůbec nemají zobrazit v administračním systému. Jsou to překlady například s pevnými URL adresami, které musí nastavit pevně programátor a admin do nich nesmí zasahovat.

Pro pohodlnost vývojářů jsme také implementovali podporu pro „on-the-fly“ vypnutí cache překladů, pokud web běží ve vývojářském režimu. Tím pádem změny ve zdrojových NEON souborech projeví ihned. Pokud tento vývojářský režim zapnutý není, naopak se vše cachuje, aby to bylo co nejrychlejší.

Shrnutí

  • V našem dev stacku používáme balíček Kdyby/Translation - port Symfony/Translation do Nette
  • Překlady načítáme z databáze a z kódu NEON souborů v repozitáři
  • Admin má možnost přeložit si texty, aniž by nás musel kontaktovat
  • Admin má možnost zkontrolovat navrhované překlady přímo na webu ještě před jejich publikací
  • Překlady po adminovi kontextově validujeme
  • Zvýrazňujeme pro admina překlady, které je nutné po vývojářích revidovat
     
Sdílet:
###message