Lepší podpora vícejazyčnosti

Myslím, že jsi nepochopil jak přesně to funguje (nebo jsem já nepochopil o co se snažíš).

Jde o to, že šablony se v jakémkoliv jazyce nakešujou úplně stejně, protože makro {_'message'} se nahradí voláním funkce $template->translate('message') a ne výsledným přeloženym řetezcem. O překlad se stará až translátor při každém načtení stránky. Kešování překladů je pak spíš jeho záležitost.

Sám to tak mám v projektech. V translátoru si sestavím slovník pro aktuální jazyk a uložím do keše. Dokud se v překladech něco nezmění tak se slovník bere z keše, jinak se znovu sestaví a zase uloží do keše.

Editoval Jur4 (2. 5. 2011 0:45)

jsem na tom stejně jako Jur4… moc nerozumím proč se snažíš o to o co se snažíš…

To přece můžeš udělat, úpravou storage a napsáním vlastního filtru :) Popř. rozšířením Latte

Ne nutně. Stačilo by to tomu přizpůsobit. No vidím, že to nezaujalo, byl to jen nápad, mně se tímhle způsobem podařilo zrychlit běh aplikace o stovky ms.

pLuRál.

Jenže to pořád nic nemění na tom, že musíš při každém zobrazení stránky celou stránku prozkoumat a pro každý {_""} najít jeho překlad a nahradit ho. Proč to dělat pořád dokola, když to stačí udělat jednou?

Třeba takhle:

CS:

<?php
<table>
        <tr>
                <th>Jméno</th>
                <th>Účast</th>
        </tr>
        {foreach $actions as $action}
        <tr>
                <td>{$action->name}</td>
                <td>{__['%d účastník', '%d účastníků'], $action->participants}</td>
        </tr>
        {/foreach}
</table>
?>

S tím, že {__[…], $value} makro by jen rozhodlo, který překlad použít.

Editoval knyttr (2. 5. 2011 11:58)

Nevím, jak moc je to neefektivní, ale každé zobrazení je asi o 300 ms rychlejší.

David Grudl napsal(a):

Teoreticky by to udělat šlo, úprava by šla nad rámec vlastního makra, protože je třeba ještě zajistit, aby se pro každý jazyk vytvářela samostatná cache šablony.

Právě proto jsem myslel, že by to mohlo být součástí Nette – v tuhle chvíli tu cache doslova znásilňuju a rozhodně to pěkné není.

To si se asi s moc lidmi nesetkal ;-) Tím samozřejmě neříkám, že to není overkill ;-)

No, tak můžeš díky tomu mít všechna data na jednom místě a nemusíš používat žádné nástroje navíc.

Btw, to makro {__['', ''], $var} by vlastně mohlo být prospěšné i pro jednojazyčné verze – dalo by se uplatnit kdekoliv je potřeba vypisovat plurály.

Ještě v těch filtrech takhle používám např. bloky {cs}…{/cs} a {en}…{/en}, přičemž {cs} bloky jsou z anglické verze odstraněny a vice versa.

Editoval knyttr (3. 5. 2011 18:53)

Viz můj příspěvek. Řešíš daný problém na úplně špatném místě a z toho vyplývají všechny ty problémy. Přesuň kešování do tvé implementace ITranslator, zrychlení pocítíš stejné a budeš mít kešované překlady v celé aplikaci, nejen v šablonách. A bez problémů.

Já taky ukládám překlady v databázi. Jak už jsem ale psal, kešuju je na úrovni Translatoru (pokud je možnost tak do MemcachedStorage, ale to není všude). Mám tak překlady pro celou aplikaci na jednom místě a jednoduše je můžu invalidovat.

S tvým přístupem stejně budu muset mít Translator, který bude překládat všechny ostatní věci a při změně překladů budu muset řešit nejen invalidaci keše Translatoru ale i invalidaci šablon. A to pro pár milisekund.

Taky si myslím, že to není úplně špatný nápad. Proč by se měli pořád vyhledávat texty v nějaké kolekci, která ve velkých aplikací nebude malá, když by mohly být statické texty rovnou v šabloně a není tak nutná naprosto žádná režie.

Jediné, co se musí řešit je invalidace šablon, pokud se změní překlad.

A to pro pár milisekund.

Jistě.. Tak, prosím, smaž veškeré cache z velkých aplikací a pak si řeknem něco o pár milisekundách.

Edit: dodatek – jsem ale pro obě cache současné jak translatoru, tak přeložených šablon.

Editoval redhead (3. 5. 2011 21:18)

Tharos napsal(a):

IMHO to není chyba návrhu. Mně to připomíná klasickou výstupní cache (uchovávající kompletní vygenerované HTML či generuje patřičné hlavičky) a ta se přece běžně používá. Každý přístup má své výhody i nevýhody a určitě bych něco neprezentoval jako „jediné správné řešení“. Zrovna tak je to IMHO s ukládáním překladů do databáze, to má přece taky svá pro i proti a určitě to není „zhmotnělé zlo“. :)

Ono jde o to, když z jedné šablony generuješ stovky stránek, tak u stránek, které se otevírají hodně a jsou už nakešované, není problém. Potom ale ty stránky, které se otevírají zřídka a nakešované nejsou, tak se pak poprvé generují zbytečně dlouho.

knyttr napsal(a):

Ono jde o to, když z jedné šablony generuješ stovky stránek, tak u stránek, které se otevírají hodně a jsou už nakešované, není problém. Potom ale ty stránky, které se otevírají zřídka a nakešované nejsou, tak se pak poprvé generují zbytečně dlouho.

To je ale normální princip invalidace, to přece jinak udělat nejde. Jeden z těch uživatelů prostě odnese generování stránky a o nepatrné cuknutí se mu zpomalí vykreslování.

Už bych nerozpitvával, jestli požadavek je oprávněný nebo ne, protože oprávněný je, howgh :-)

Na straně přidání Latte makra by žádný zádrhel být neměl, prostě bude to obdoba implementace makra {_}, které se předá translator. Aby k tomu bylo možné použít FileTemplate, je třeba změnit klíč ze současného $this->file na vlastní zahrnující jazyk. Taktéž by se asi hodila možnost specifikovat vlastní podmínky při ukládání cache.

Ale – totéž platí i pro třídu Template, byť tady by se změna klíče dala simulovat přidáním nějakého {* lang:cs *} na konec řetězce. Napadá někoho šikovný refaktoring, jak kešování upravit v Template i FileTemplate?

knyttl napsal(a):

Co jsem si ale teď díky tomu zvykl dělat je používat makra {cs}, {en}:

{cs}Tohle se vygeneruje v české šabloně{/cs} {en}This will appear in english template{/en}

Výhodou je, že člověk ty překlady nemá nikde zašité mimo a snadno se mění.

Nevýhodou je, že překladateli nestačí poslat jeden soubor s klíči, ale musí se vrtat v šablonách. A zvyšuje se tím riziko, že něco rozvrtá.

Nicméně ale souhlasím s tím, že překlad při compile-time je dobrý nápad. Co se tím ušetří?

• Soubor s překlady se nemusí vůbec ani parsovat, případně stahovat z databáze
• Neprobíhá X vyhledávání v kolekci (kde X je počet překladů na stránce)
• Neparametrické překlady ani nemusí vést k zavolání nějaké funkce, jsou do šablony prostě vepsané
• Parametrické mají za následek pouze vložení parametrů, v nejhorším rozhodnutí formy plurálu