Multijazyčnost, nejen u formulářů, ale všech statických textů aplikace
- mcmatak
- Člen | 504
Jak řešíte multijazyčnost statické části aplikace?
Asi se shodneme, že jediný správný nástroj bude gettext (pro jeho rychlost).
Já mám ovšem takový problém, že jedna aplikace se implementuje v XY verzích a tak 80% překladů mají stejných a 20% překladů mají individuálních.
Jak to efektivně spravovat? Procházet xgettextem zdroj je nereálné (prostě to nejde…). Některé verze mají jiné moduly apod. nicméně předpokládám, že máte jen jeden překladový soubor a v tom jsou překlady úplně pro všechny moduly. Asi nenačítáte XY překladů protože se na stránce objevuje více modulů? Používáte tedy pouze jeden soubor s překlady? Ať už současná implementace využije 10% nebo 50%? A jak řešíte jednotlivé odchylky, případně vznik nového modulu znamená do 50překladových souborů (které jsou určitou částí individuální) dodat cca 20 dalších výrazů.
Kudy do toho? Jak to řešíte nebo by jste řešili?
Jak to chci řešit nechám až na potom, abych neovlivnil.
- Ondřej Mirtes
- Člen | 1536
mcmatak napsal(a):
Jak řešíte multijazyčnost statické části aplikace?
Asi se shodneme, že jediný správný nástroj bude gettext (pro jeho rychlost).
Já mám ovšem takový problém, že jedna aplikace se implementuje v XY verzích a tak 80% překladů mají stejných a 20% překladů mají individuálních.
Jak to efektivně spravovat? Procházet xgettextem zdroj je nereálné (prostě to nejde…). Některé verze mají jiné moduly apod. nicméně předpokládám, že máte jen jeden překladový soubor a v tom jsou překlady úplně pro všechny moduly. Asi nenačítáte XY překladů protože se na stránce objevuje více modulů? Používáte tedy pouze jeden soubor s překlady? Ať už současná implementace využije 10% nebo 50%? A jak řešíte jednotlivé odchylky, případně vznik nového modulu znamená do 50překladových souborů (které jsou určitou částí individuální) dodat cca 20 dalších výrazů.
Kudy do toho? Jak to řešíte nebo by jste řešili?
Jak to chci řešit nechám až na potom, abych neovlivnil.
Já myslím, že bys mohl překlad rozdělit do víc souborů. Akorát si nejsem jistý, jestli to aktuálně dostupné Translatory pro Nette umí načíst.
- mcmatak
- Člen | 504
Jak tak o tom pořád přemýšlím, tak si myslím, že pouze jeden .mo soubor je ideální. Nicméně jak zajistit, aby existovalo XY verzí překladu a dal se nějak efektivně udržovat.
Věřím, že nejlepší by bylo udržovat překlady v dtb, z toho generovat .po soubor a z toho generovat .mo soubor, ale jak to udělat pokud to chci live (tak aby překladatel tohle mohl udělat z administrace webu) a pokud nemám přístup k příkazovému řádku ??
- David Grudl
- Nette Core | 8227
Osobně vůbec gettext nepoužívám, místo toho databázi + kešování. Je to dynamické, může to editovat i klient.
- mcmatak
- Člen | 504
no tak je to otázka no, já právě dělám na sérii článků na www.webfaq.cz, kde by i gettext měl být dynamický a udržovaný z adminu zákazníka (když se to nepovede tak holt budu využívat kešování a pole), ale nevím od kdy už tohle se nevyplatí? 1000–2000 slov, že by už gettext stál za to? zátěž je prý neměřitelná při použití gettextu
- norbe
- Backer | 405
Taky už jsem se nad něčím podobným zamýšlel, ale zatím na to nebyl moc čas. Jediný co jsem našel je stránka se scriptem, který generuje MO soubory (ještě jsem nezkoušel tak nevím jestli bude fungovat, každopádně pro inspiraci by se to dalo použít…).
- ViliamKopecky
- Nette hipster | 230
David Grudl napsal(a):
Osobně vůbec gettext nepoužívám, místo toho databázi + kešování. Je to dynamické, může to editovat i klient.
Nechceš o tom napsat trochu víc? Mně taky gettext nějak nezavoněl.
- mcmatak
- Člen | 504
asi to není co jste čekali, ale můžete posoudit
http://www.webfaq.cz/…zycnost-webu
nakonec jsem z větší části od gettextu ustoupil, pokud článek má podle Vás hlavu a patu, připravím řešení i pro gettext, podle mne i to lze řešit zcela dynamicky a bez nástrojů jako poedit apod., vše z administračního prostředí
každopádně řekněte sami jak moc je pro Vás důležité vyhledávání překladů přímo v kódu, nakonec jsem zjistil, že i u opravdu rozsáhlých aplikací jich zas tolik není a že ruční správa v externím souboru v podobě array není až zas takový problém
Editoval mcmatak (28. 11. 2009 21:38)
- mcmatak
- Člen | 504
to David Grudl: nechceš se pochlubit se svým řešením?
momentálně jsem na cca 1000 překladech včetně pluralu, zpomalení aplikace nepozoruji při použití array a klíčového identifikátoru
nový překlad napíši do kódu, zadám do centrální databáze a během dvou kliknutí je připraven k použití, zatím je to celkem pohodlné
- hurvajs
- Člen | 86
mcmatak napsal(a):
…nakonec jsem z větší části od gettextu ustoupil…
Gettext je podle me jedine spravne reseni. Ostatni zalezitosti, jako jsou asociativni pole, konstanty apod. jsou k nicemu a neefektivni (dovolil bych si rici i nesystemove ikdyz je to diskutabilni). Pro gettext mluvi predevsim to nasledujici:
- jedna je o nativni podporu ze strany PHP,
- ze slovnik je nacten na urovni Apache a nakesovan ⇒ nejrychlejsi reseni, ktere je vubec mozne
- zubem casu overeny a funkcni,
- dovolim si konstatovat ze na vsech kvalitnich hostingach je zapnuty (ISS na hostingu nepovazuji za kvalitni)
- dobre vyreseno sklonovani, kdy pro kazdy jazyk lze udelat potrebne mnozstvi pluralu,
- absolutne trivialni struktura PO souboru ⇒ trapne jednoducha uprava
- sice ne moc dulezite, ale gettext se ve svete opensource pouziva jako defaultni vec pro preklady aplikaci.
- apod.
Pro gettext proste mluvi jen same pro. Nezmam ani jednu jediny sebemensi nesvar. Pokuzivam gettext hodne dlouho (v radu nekolika let a NIKDY jsem s nim nemel problem – nikdy). Psal jsem web s 25 jazyky, kde byla zastoupena treba i cinstina i hebrejstina a nebyl to problem (max. tak se v tech znaci vyznat… :-D ). Proti gettextu opravdu neexistuje nic.
- mcmatak
- Člen | 504
asi jedine co beru je tohle
ze slovnik je nacten na urovni Apache a nakesovan ⇒ nejrychlejsi reseni, ktere je vubec mozne
ale jestli si cetl ten clanek tak spolu v podstate souhlasime, jen stim rozdilem, ze resim dynamicke generovani gettextu, a ještě před tím než sem řešení našel, tak se ukázalo, že asociativní pole v mém případě jaksi neduhy netrpí, a zatím nebyl objeven jediný problém s takovým řešením