Multijazyčnost, nejen u formulářů, ale všech statických textů aplikace

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
mcmatak
Člen | 490
+
0
-

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
+
0
-

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 | 490
+
0
-

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 | 8082
+
0
-

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 | 490
+
0
-

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
+
0
-

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
+
0
-

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 | 490
+
0
-

teď o tom píšu článek :)

iguana007
Člen | 970
+
0
-

mcmatak napsal(a):

teď o tom píšu článek :)

Už se nemůžu dočkat :)

mcmatak
Člen | 490
+
0
-

možná blbý dotaz, ještě před tím co o tom píšu článek, ale proč proboha se k využití pluralu píše do ngettext ten druhý alternativní text? nějak mi to nejde do hlavy, což nestačí jeden identifikátor?

paranoiq
Člen | 392
+
0
-

@mcmatak: to druhé není identifikátor, ale přímo plurál pro výchozí jazyk. pokud se nepřekládá do jiného jazyka, tak se přímo použije. není pak nutné psát překlad i pro angličtinu jen kvůli plurálům

mcmatak
Člen | 490
+
0
-

no já tomu rozumím, jen mi to přijde zbytečně moc psaní, protože ten plural přece gettext zná! navíc nette s něčím podobným ani nepočítá ne? interface k translatoru dovoluje jen dva parametry

mcmatak
Člen | 490
+
0
-

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 | 490
+
0
-

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
+
0
-

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 | 490
+
0
-

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