Gettext + Poedit + Nette – konečné řešení lokalizace

Zdravím, je to super, nechceš ještě přidat podporu pro překládání formulářů?

Nemáte náhodou někdo zkušenost s tím, jak řešit překlady v Nette tak, aby si uživatel mohl překlady dělat sám v administračním rozhraní? Tzn. bez použití Poedit.

Moje stávající řešení není právě dokonalé z hlediska výkonu a využití paměti.
Jde o systém, který při konstrukci objektu Translator vytvoří asociativní pole překladů v daném jazyce (toto pole se pak může cachovat; vytváří se z databáze). Pokud se překlad nenajde (nebo je prázdný), ověří se zda je překlad v DB, jinak se tam přidá.

Úklid starých překladů je zajištěn také celkem blbě – lze zapnout na pár dní „updater“, který při každém použití překladu nastaví timestamp danému záznamu. Poté se vyhodnocuje, které záznamy nebyly použity a nabídne se jejich smazání (archivace).

Takto to funguje celkem dobře, ale výkon není nic moc. Máte někdo lepší řešení?

Vďaka za GettextExtractor!

V NetteCurlyBracketsFilter.php – pre podporu UTF8 treba doplniť za regexp modifikátor „U“:

preg_match_all('#{(!_)([^}]*?)([a-z](?:[^\'"}\s|]+|\\|[a-z]|\'[^\']*\'|"[^"]*")*)?}#U', $contents, $matches);

…

preg_match('#\'[^\']*\'|"[^"]*"#U', $m, $x)

Tí ktorí používajú Eclipse (alebo Zend Studio 6+) môžu skúsiť namiesto Poedit editor Gted. Je omnoho stabilnejší a pohodlnejšie sa v ňom pracuje.

ha, objevil jsem neco dost zajimavyho: gettextextractor (s tim mnou navrhovanym regexpem) si hrave poradi se vsim co mam v templatach ale neporadi si s normalnima PHP souborama, naprotitomu xgettext nezvlada ty templaty… takze v php parseru parsuju jenom soubory .php a vytvoril jsem novej parser na .phtml kterej parsuju gteckem. Zasadni je ze to funguje a kdyz uz to clovek rozchodi, tak to praci urychli asi o tisic procent… Super vec! Dik.

Nestálo by za to tohle přidat do https://componette.org/search/?q=cs ?

rokerkony napsal(a):

ahoj
zkousim rozjet localizaci podle navodu, ale mam problem… vzdy pri vytvoreni noveho katalogu (nebo i nasledne aktualizece) mi vyskoci hlaska „Program CLI přestal pracovat“.
nevim jestli je to chyba apache, windows, nebo poeditu? nesetkal jste se s tim nekdo?

Poedit potom zahlasi jenom „Entries in the catalog are probably incorrect.“ ? ale i tak nevim co bych tam delal spatne :-(

Chyba by měla být v php, respektive v mysqli_php.dll. Zkusil bych nainstalovat novější PHP (popřípadě XAMPP).
Stejné řešení je popsané např. tady

Ahoj, chtěl bych upozornit na malou chybičku v třídě Translator. Pokud se překladá prázdný řetězec, vrátí se META data daného překladu. Chybu jsem objevil, když jsem Translator připojil k formuláři (pokud políčka nemají předvyplněnou žádnou hodnotu, zobrazí se META data o překladu, což není to co by člověk čekal).

Řešení je velmi jednoduché (jedna podmínka na začátku metody translate):

if($message == "")
	return "";

P.S. Při použití tohoto translatoru jsem na lokále také narazil na problém, že jazyková mutace nemůže být pojmenována pouze „cs“, ale musí být uvedena jako „cs_CZ“(seznam možných hodnot se vypíše zadáním příkazu locale -a), je to údajně způsobeno op. systémem Ubuntu.

Editoval norbe (7. 7. 2009 19:06)

Nepochopil jsem.

To me neprekvapuje. Zkusim to polopaticteji.

Mejme danu funkci t($message, $count = null), ktera nam nejakym mechanismem preklada retezec $message do jazyka ktery „nekde nastavime“. Je uplne jedno, jak funguje tahle cast mechanismu, jestli to je zalozene na gettextu, hard-codovanem asociativnim poli nebo na databazi. Podstatne je, ze _kdesi_ mame nejakym zpusobem ulozene pary klic ⇒ hodnota, ktere funkci t() slouzi jako prekladova tabulka. Dokud fungujeme pouze v singularu, mame kazdy klic dejmetomu* na dvou mistech: jednak v ulozisti definic paru a jednak v miste, kde se retezec vyskytuje a my ho chceme prelozit. Dejmetomu proto, ze samozrejme ten samy klic muze byt pouzit (odkazovan, prekladan) na vice mistech.

Rekneme, ze chceme, aby nas projekt podporoval dva jazyky: anglictinu a cestinu. V projektu potrebujeme vyuzivat pluralove formy (Mate 1 novou zpravu / 3 nove zpravy / 10 novych zprav).

Takze na prislusnem miste ve zdrojovem kodu zavolame t(„You have %d new messages“, $pocetZprav). Funkce t() se podiva do prekladove tabulky pro cesky jazyk a zjisti: Pokud je $pluralCnt rovno 1, vratim „Mate %d novou zpravu“. Pokud je $pluralCnt v uzavrenem intervalu <2, 4>, vratim „Mate %d nove zpravy“ a konecne pokud je $pluralCnt rovno 0 nebo vetsi rovno 5 vratim „Mate %d novych zprav“. Je to velmi jednoduchy model, pro vetsinu ceskych aplikaci s nim vystacime.

A ted prepneme do anglictiny.

A nabizi se dve moznosti, co se muze stat: budto mame i pro anglictinu prekladovou tabulku – pak preklad probehne podobne jako u cestiny – nebo pro anglictinu tabulku nemame. Co se stane? Budeme mit vystup budto „You have 0 new messages“ nebo „You have 1 new messages“ nebo „You have 5 new messages“. Obavam se, ze pokud je obecna uroven anglictiny mezi programatory takova, jako ve firme kde pracuji, nikdo v tom neodhali chybu. Chyba tam ovsem je a vsem, kdo maji anglictinu alespon trochu v ucte, bude „You have 1 new messages“ vadit.

Dejme tomu, ze mam anglictinu v ucte a tak mi tohle vadi. Co muzu jako programator delat? Napsat prekladovou tabulku, ktera bude z 80% zaplnena pary typu „Login“ ⇒ „Login“, „User name“ ⇒ „User name“, „Welcome back, %s“ ⇒ „Welcome back, %s“ a zbylych rekneme 20% budou moznosti typu „You have %d new messages“ ⇒ [„You have %d new message“, „You have %d new messages“] nebo „There were %d unsuccessful login attempts“ ⇒ [„There was %d unsuccessful login attempt“, „There were %d unsuccessful login attempts“]. Z toho zacinam mit dojem urcite redundance, to se mi zda zrejme.

Druha alternativa je upravit rozhrani Nette\ITranslator (.. respektive vytvorit si vlastni, pokud Nette tuhle koncepci neprijme za svou) a jednu tabulku prekladu (samozrejme tu anglickou) mit hardcodovanou primo ve zdrojovem kodu – tzn. pripravime si tabulku ceskych prekladu a kdyz si klient stranku vyzada v anglictine, funkce t() ma vsechno potrebne k zobrazeni spravneho prekladu v parametrech – jak retezec pro singular tak pro plural: t(„You have %d new message“, „You have %d new messages“, $pocetZprav).

Zkusme se statisticky zamyslet. Pristoupime-li na separovanou druhou tabulku prekladu, vznikaji nam redundantni data hned na nekolika mistech: jednak samotna zprava, kterou ve zdrojovych kodech predavame funkci t(), neni nikdy primo pouzita, takze kdybychom misto ni uvadeli ciselny identifikator, usetrime parseru nejakou praci s porovnavanim retezcu etc. (cemuz se kvuli prehlednosti kodu obloukem vyhneme, jak uz rekl kravco), a jednak budeme mit spoustu nesmyslnych paru typu Ahoj ⇒ Ahoj v tabulce s preklady.

Nekdo by mohl namitnout, ze kdyz bude muset pro kazdy plural volat funkci t() se tremi misto se dvema argumenty, zahlti se tim zbytecne kod. Namitku bych zamitnul s tim, ze pluralu na beznem webu zas tak moc neprekladame, takze nam to v porovnani s metodou druhe tabulky hodne prace usetri.

Snad jsem to vysvetlil dostatecne.

Editoval danik (23. 8. 2009 20:59)

danik napsal(a):

Najprv sa mi to nechcelo čítať (dlhé a zliate dokopy)…

Dejme tomu, ze mam anglictinu v ucte a tak mi tohle vadi. Co muzu jako programator delat? Napsat prekladovou tabulku, ktera bude z 80% zaplnena pary typu „Login“ ⇒ „Login“, „User name“ ⇒ „User name“, „Welcome back, %s“ ⇒ „Welcome back, %s“ a zbylych rekneme 20% budou moznosti typu „You have %d new messages“ ⇒ [„You have %d new message“, „You have %d new messages“] nebo „There were %d unsuccessful login attempts“ ⇒ [„There was %d unsuccessful login attempt“, „There were %d unsuccessful login attempts“]. Z toho zacinam mit dojem urcite redundance, to se mi zda zrejme.

Urob z toho múdru tabuľku:

"You have %d new messages" => [
	"You have %d new message",
	TRUE,
],

A redundancia je fuč ;)

t(„You have %d new message“, „You have %d new messages“, $pocetZprav).

Môj názor: toto má dosť veľký wtf faktor. A navyše v prípade opakovania v kóde máš redundanciu približne takú, akej sa chceš zbaviť…

Zkusme se statisticky zamyslet. Pristoupime-li na separovanou druhou tabulku prekladu, vznikaji nam redundantni data hned na nekolika mistech: jednak samotna zprava, kterou ve zdrojovych kodech predavame funkci t(), neni nikdy primo pouzita, takze kdybychom misto ni uvadeli ciselny identifikator, usetrime parseru nejakou praci s porovnavanim retezcu etc., a jednak budeme mit spoustu nesmyslnych paru typu Ahoj ⇒ Ahoj v tabulce s preklady.

Zásadne šetrím čas sebe, nie parseru…

Nekdo by mohl namitnout, ze kdyz bude muset pro kazdy plural volat funkci t() se tremi misto se dvema argumenty, zahlti se tim zbytecne kod. Namitku bych zamitnul s tim, ze pluralu na beznem webu zas tak moc neprekladame, takze nam to v porovnani s metodou druhe tabulky hodne prace usetri.

Namietam, no nie zahltením kódu, ale wtf faktorom vyššie…

Snad jsem to vysvetlil dostatecne.

Myslím, že áno.

danik napsal mnoho textu…

wtf?? ;-)

Zapište do záznamu že vůbec nevím o čem to tady mluvíte

toho textu je hodně a diakritika by výrazně vypelšila jeho čtivost

Zrovna když se to chystám řešit tak to někdo vytáhne… Předem říkám že neumím česky na tož anglicky… Ale tohle mě vadí (zase tak špatně na tom snad nejsem)… :-)

danik díky za nakopnutí. Dělat něco jako translate(string $message, string $messagePlural, int $count = NULL); se mě ale nelíbí spíš bych uvítal variantu translate(string $message, int $count = NULL, string $messagePlural = NULL); nebo proste odstanit string z metody translate pak by se to dalo řešit translate(array("You have %d new message", "You have %d new messages"), 1); s tím že translator si to už pořeší.

Když se na to podívám z druhého pohledu tak stejně budu (asi) potřebovat anglickou tabulku překladů. Protože pak příjde potencionální překladatel který bude chtít přeložit appsku třeba do „cikánštiny“ (nejsem rasista → podporuju menšiny :-D) a jednoduše pouze veme anglickou tabulku a přepíše jí. Blbost můžu vzít jakýkoliv jiný překlad a dělat to z něho… 2× Blbost co když je aplikace jenom anglicky a potencionální překladatel si z ní původní texty neumí vytáhnout?

Editoval vrtak-cz (23. 8. 2009 22:15)

danik napsal(a):

wtf faktor… velmi vystizna velicina.

jak uz jsem rekl, parametrizovane pluraly v prekladu jsou na webu alespon podle moji zkusenosti spis vyjimka, tzn. bezne budu volat napriklad t(„User name“), t(„Welcome back, %s!“) a podobne, tady se nic nemeni. Ale kdyz budu potrebovat prelozit pocet novych zprav, rekl bych, ze to budu mit v sablone jen jednou… a tim padem budu mit t(„%d new message“, „%d new messages“, $pocetZprav), coz ma dejme tomu wtf faktor rovny dvema – dvakrat tolik retezcu nez by bylo nezbytne nutne. Zajima me, jaky wtf faktor potom bude mit kazdy radek .PO souboru s pary typu „User name“ ⇒ „User name“? Vzhledem k tomu, ze tady by nebyl potreba ani jeden vyskyt retezce „User name“ a mame tu vyskyty hned dva, delime nulou. A kdybychom si nahodou chteli misto nuly predstavit extremne male kladne cislo, abychom se deleni nulou vyhnuli, dostavame se limitne k wtf faktoru rovnemu nekonecnu. Trocha matematiky.. Navic, kravco, tenhle pristup ma byt skutecne programatorsky privetivy, taky nejsem fanousek translate(5488, $msgCnt) a podobnych priser.

Nakonec je ale pravda, ze spousta programatoru anglicky temer neumi.. takze to asi nema smysl. Zapomente na to, asi to je zbytecna snaha. Obcas kdyz ctu zdrojove kody a narazim na nejakou vyjimku nebo neco kde autor musel zapojit vyraznejsi anglictinarske schopnosti nez if a while mam pocit ze nechci byt programator..

Nevím jak ty, ale já podobný problém řeším .po souborem, kde mám jen ty plurály. Pokud se pokusím přeložit singulár, tak můj translator nenalezne žádný záznam a použije ten, co jsem mu předal ve funkci. Sice to není úplně ideální, ale pracuje se s tím docela fajnově.

Navíc s tím WTF faktorem můžeme jít ještě dál, pokud bychom chtěli něco takového:

t("No new messages", "%d new message", "%d new messages", count($messages));

A co kdybychom jako nativní jazyk nepoužili angličtinu, ale nějaký jiný jazyk, například proto, že máme překladatele, který anglickou lokalizaci napíše lépe a bude to rychlejší, než kdyby to po programátorech opravoval? To by počet těch volání mohl být ještě vyšší, protože ten jazyk může mít třeba singulár, duál, plurál, do toho se může zamíchat varianta pro 0 zpráv a ještě ten plurál může mít víc tvarů, třeba jako tvoří čeština pro intervaly 2 – 4 a 5+?

Osobně tedy zastávám názor, že konkrétní realizace překladů by měla být specifická pro konkrétní projekt. Pokud chceme předat více řetězců, můžeme jako parametr $message předat již zmiňované pole. Větší počet parametrů na úrovni rozhraní by dle mého soudu celý systém značně komplikoval.

Editoval Panda (23. 8. 2009 22:30)

Neumí… :-(
Více zde: https://forum.nette.org/…tte-aplikaci

danik napsal(a):

Argument „anglickou tabulku udělá překladatel“ se zamítá. Naučte se anglicky a pak se vraťte k programování. Psát do zdrojového kódu programovacího jazyka, jehož sémantika je založena na angličtině, výrazy v jiných jazycích (ať už jako klíčové názvy nebo do řetězců) je pro slušného člověka tabu. To nám zároveň velmi zjednodušuje teoretickou úvahu nad počtem argumentů, které by musela překládací funkce mít a tleská teorii Romana Sklenáře o ternárních operátorech.

wtf?

DocX, jděte se schovat někam do kouta, než někdo objeví, že vás někde ukradli. Pokud možno si s sebou vemte původní tutoriál Karla Klímy k jeho GettextExtractoru a o volných chvílích si čtěte.

WTF??

Pane Sklenáři, nikdo nikoho nenutí tlačit věci do distribuce bez předchozí diskuse a konsensu všech zúčastněných. Jezděte dál na velocipédu.

WTF, tak tohle jsem přečetl asi 3× a stále nevím jestli už nespím…

danik napsal(a):

Tady se nám toho ale sešlo.

Teď na to koukám že zajímavě.
>

Vrtáku, děkuji za podporu. Pole je ale v dané situaci podle mě spíš sedm zbytečných písmenek navíc.

Nemyslím si snažil jsem se aby můj návrh co nejméně ovlivnil stávající implementaci. Jinak pokud jsi četl celý příspěvěk tak jsem tě zase tak moc nepodporoval.

Naučte se anglicky a pak se vraťte k programování. Psát do zdrojového kódu programovacího jazyka, jehož sémantika je založena na angličtině, výrazy v jiných jazycích (ať už jako klíčové názvy nebo do řetězců) je pro slušného člověka tabu. To nám zároveň velmi zjednodušuje teoretickou úvahu nad počtem argumentů, které by musela překládací funkce mít a tleská teorii Romana Sklenáře o ternárních operátorech.

WTF? Spousta lidí začínajících s programováním aglicky neumí (někteří vůbec!!!). Ale nevím proč by jim to mělo bránit v programování (co když vymyslejí další Google, FB, YouTube?) na to přece angličtinu umět nemusejí!!! Proč když to PHP dovoluje bych nemohl pojmenovat proměnou česky a klidně i s diakritikou? (kdyby to PHP zakazovalo tak to chápu ale takhle ne!)

DocX, jděte se schovat někam do kouta, než někdo objeví, že vás někde ukradli. Pokud možno si s sebou vemte původní tutoriál Karla Klímy k jeho GettextExtractoru a o volných chvílích si čtěte.

Ale no tak snad se tu nebudeme urážet! Pokud si chcete měřit (teď mi promiňte) pinďoury tak někde jinde prosím. Nerad bych zbytečně četl další nic neříkající příspěvky.

Pane Sklenáři, nikdo nikoho nenutí tlačit věci do distribuce bez předchozí diskuse a konsensu všech zúčastněných. Jezděte dál na velocipédu.

Však roman neříkal že někdo někoho nutí jenom vyjádřil svůj názor že se mu to nelíbí. A jelikož je to jeden z commitujících lidí a tím pádem v něj má david důvěru.

PS: Prosím urážení si nechte někam jinam!!! (máte na to své blogy a podobně) Pokud doopravdy musíte někomu říc že je to… Pošlete mu e-mail ať ostatní nemusejí číst zbytečné texty (a ztrácet tak čas).

Děkuji a ještě tady veřejně se omlouvám všem za svoje stupidní příspěvky, byl to špatný pokus o špatný humor. Danik.

Pokusím se o malé shrnutí:

Použití ITranslatoru

Výhody:

• některé třídy Nette mají zabudovanou jeho podporu → nemusí se pak psát okolo každého textu věci jako _().
• co se týče (současné) definice rozhraní, nepřikazuje pužití jakékoli technologie (gettext, databáze, pole ID → text, apod.).
• může být použito tak, že finální texty nejsou nikde v kódu a řeší je až ten, kdo se stará o texty.

Nevýhody:

• Neumí plurál, což ústí k užití překladové tabulky i pro všeobecně plurálově asi nejjednodušší jazyk jako je AJ.
• Zda jde o množné nebo jednotné číslo se zjišťuje až v runtimu.

Upravit ITranslator o plurál

Výhody:

• Jelikož se všeobecně jako primární jazyk používá angličtina, může být ta celkem jednoduše součástí kódu.
• Tím by odpadlo použítí jedné překladové tabulky navíc.
• Dopředu by program věděl, zda se jedná o množný nebo jednotný tvar.

Nevýhody:

• Asi by se tím zamezilo možnosti zapouzřit překlad do tříd, jako jsou teď Forms.
• Rozhraní by se přiblížilo k překladové technologii na principech gettextu.

Obecné nevýhody ITranslatoru

• Při využití zmíněné abstrakce (což je podle mě celkem fajn věc) se prakticky zamezí automatické získávání textu.
• Pokud by jsme se tomu chtěli vyhnout a pužívali všude $mujITranslator->translate(...), je nám to vlastně k ničemu.

Ačkoliv je tedy ITranslator vlastně „geniálně jednoduchý“, představuje pro mě z pohledu implementace a údržby riziko. Proto pro mě osobně stále zůstává jako dobrá volba přímo gettext a všude píši _(...) nebo ngettext(..., ..., x). I když jsem si chvilku myslel, že je ITranslator výborný, nakonec by mi přinesl spíše více starostí než ulehčení.

PS: je to můj názor, samozřejmě se mohu mílit nebo se špatně formulovat. Každou seriozní výtku výtám :)

Editoval DocX (25. 8. 2009 1:40)

vrtak-cz napsal(a):

DocX napsal(a):

Upravit ITranslator o plurál

Nevýhody:

• Rozhraní by se přiblížilo k překladové technologii na principech gettextu.

Můžu vědět proč to považuješ za nevýhodu?

Z tohoto vlákna jsem nabyl pocitu, že je právě výhoda to, jak je rozhraní jednoduché. Někdo tu zmiňoval pole s konkstantami, jiný texty v SQL databázi. Ať už jsou tyto varianty jakkoli dobré nebo špatné, rozhraní by podle mě nemělo nic přikazovat.

//EDIT: Jo jinak jsem se vlastně snažil schrnout argumenty pro a proti oboum verzím :) Takže je to jakoby nevýhoda oproti původnímu ITranslatoru.

Editoval DocX (25. 8. 2009 1:45)

Já jsem nad tím taky trochu přemýšlel. Vím, že u template translatorů jde ze šablon předat do překládací funkce libovolný počet argumentů, takže ať budeme translate volat s jedním msgId a plurálem nebo dvěma a plurálem, není to problém. Ale (opravte mě, jestli se pletu) myslím, že formulářové volání translatoru předává jenom a pouze jeden argument – není tu prostor pro plurály ani parametrizaci zprávy. Řekl bych že změnit tohle by si vyžadovalo relativně rozsáhlé zásahy do API Nette a to by asi nebylo nijak jednoduché.

Tak či onak, to je problém na další diskuzi, protože ať už budeme chtít překládací funkci předat jakýkoliv počet msgId, pořád nám chybí to podstatné a to je pluralCount, podle kterého by náš překladač určil, kterou formu má použít.

No a co se týká msg id a wtf faktorů atp, napadlo mě jedno řešení, přivedl mě na něj Panda (a možná to myslel přímo takhle):

• Překladač dostane při inicializaci definováno, co je výchozím jazykem aplikace, v němž jsou v kódu psána msg id.
• ITranslator se neupraví, zůstane tak jak je. Tj. při překládání mu předáme buď msgId nebo msgId plus pluralCount.
• Budeme mít kompletní tabulky s překlady pro všechny jazyky s výjimkou jazyka výchozího. Ten bude mít tabulku speciální: budou v ní páry nikoliv JazykA ⇒ JazykB, ale Singulár ⇒ Plurál (-y jako pole, řekněme).
• Naše implementace ITranslatoru potom posoudí následující:
  1. Je-li aktuálním jazykem ten výchozí a pluralCount není uvedeno, vrátí msgId.
  2. Je-li aktuálním jazykem jazyk výchozí a zároveň je specifikováno pluralCount, „přeloží“ odpovídajícím způsobem singulár výchozího jazyka na plurálovou formu odpovídající pluralCount
  3. Není-li aktuálně zvolen výchozí jazyk, přeloží standardní cestou msgId do odpovídající formy aktuálního jazyka podle jeho překladové tabulky.

Takhle by vlastně všechna msgId byla zároveň singulárovou formou všech výrazů jednoho jazyka, plurály k němu bychom měli jinde a další jazyky bychom překládali tou běžnou cestou. Je to trochu směrem k gettextu, ale nemusí to tak nutně být. Koneckonců už relativně dlouho přemýšlím o tom, že bych zkusil napsat k Gettextu nějakou alternativu šitou PHP / Nette na míru, ale ještě nejsem dost guru :o)

Jinak já mám obecně na překládání pod Nette zaregistrovanou jako službu komponentu i18n, kterou taky pro každý překlad nevolám Environment::getService(„i18n“)->translate(..) :o) mám makro t(..), které mi to zprostředkuje s libovolným počtem argumentů, můžu poslat kód (ale tohle je zrovna trivka ;o) ).

vrtak-cz napsal(a):

Tak to asi budu řešit tak že si udělám ITranslatorPlural s metodou translate(string $msgid1, string $msgid2, int $n) v base presenteru rozšířím metodu setTranslator o jeho podporu. A napíšu si macro _n nebo ngettext nebo _plural. Editnu Gettext extractor… A hurá máme to tam. Možná jenom rozšířím ITranslator o metodu translatePlural(string $msgid1, string $msgid2, int $n). Ještě nevím musím si to nechat pořádně projít hlavou.

Jakou to má potom výhodu oproti přímému použití gettext funkcí?

Ahoj, pravda tohle moc nesouvisí s Nette, ale třeba na to někdo narazil. poedit používá utilitu msgcat na merge dvou .po souborů. Například když se přidá nějaký nový překlad.
Gettextextractor volá addslashes při zápisu výstupního souboru (ten slouží jako jako INPUTFILE pro msgcat), tj. escapují se např. apostrofy. Imho to je správně, msgcat ale zařve při merge „invalid control sequence“ na řádku a znaku kde je apostrof. Řešení ve stylu odstranění volání addslashes v extractoru se mi moc nelíbí. Setkal jste se s tím někdo?

Díky, Michal