Mazagran – translation toolkit pre nette aplikacie

HosipLan napsal(a):

Chtěl bych vidět nějaké screeny. Regl jsem se a při přidávání překladu cs mi to hodilo 500 :)

to bude sposobene tymi pravidlami, plural=(n==1) ? 0 : (n>=2 && n<=4) ? 1 : 2; takuto rovnicu php nevie spravne vyhodnotit. priznam ze cs som nefixoval :D tych jazykov je strasne vela, asi odtial vyberiem nejake najpouzivanejsie a tie poriadne otestujem. alebo teda prijimam pull requesty na opravu :)

Vytvořil jsem novou zprávu. Ta se přidala 2x – jako translated a untranslated a pak když jsem u té prvni odeslal něco do formuláře, tak se to uložilo do té druhé.

toto je velmi zaujimave. tuto bude nejaky skaredy bug.

Každopádně je to zajímavý počin a to webové rozhraní je příjemné. Chtělo by to na tom webu nějaký „článek“ se screeny kde bys popsal (očekávané) workflow.

diky. ked to este trosku odladim pridam screeny.

---

Má to ovšem celé jeden zásadní háček. Konkrétně Extractor. Vytahovat texty z kódu je hodně špatný nápad. Jeden příklad za všechny:

"text" . $text . "text";

Daleko lepší přístup je „extrahovat“ tyhle slovníky „za běhu“. Zkrátka pustíš aplikaci a všechny požadavky na překlad, které nemají odpovídající záznam, se někam uloží bez překladu.

Stejně musíš všechny stavy aplikace otestovat. Ať už ručně nebo automatizovaně. Takže všechny texty ti musí projít přes translator.

Pak už je to hračka.

vytahovanie texty za behu je rozhodne dobry napad. takto by slo prekladat aj texty vynimiek.
neviem aky je problem v tvojom pripade, ani jeden z tych textov by nebol vyextrahovany. texty musia byt oznacene na preklad teda

	{_"text" . $text . "text"}

neviem ako toto skonci, ale je to chyba programatora ked to tak zapise. extractor je presne ten isty gettext extractor ktory tu uz dost dlho koluje v doplnkoch. toto este uvediem v readme a v prislusnych triedach.

inak diky, slo mi hlavne o zhodnotenie napadu.

Eh, vytvořil jsem projekt, šel jsem do Translations a po přidání nové ‚cs‘ to spadlo na 500 :)

Má to ovšem celé jeden zásadní háček. Konkrétně Extractor. Vytahovat texty z kódu je hodně špatný nápad. Jeden příklad za všechny:

"text" . $text . "text";

Daleko lepší přístup je „extrahovat“ tyhle slovníky „za běhu“. Zkrátka pustíš aplikaci a všechny požadavky na překlad, které nemají odpovídající záznam, se někam uloží bez překladu.

Pokud chci tohle překládat, použiju sprintf(). Když překládáš „za běhu“, těžko získáš definitivní šablonu překladu, což je pro lokalizaci docela užitečná věc. Teda, zíksat tu šablonu můžeš, ale vznikne jako vedlejší produkt testů – není to trochu nechutný?

Sorry ale tohle mi neda ;)

Tahat preklady za behu je kravina!

Nutnost „zpusobit“ vsechny stavy aplikace kvuli prekladu je skutecna zhovadilost, protoze:

1. nektere stavy nasimulujes skutecne tezko („Na vanoce…“, „Pocitac je vypnuty…“)
2. prekladat "text" . $text . "text" je nesmysl, protoze to v podstate nikdy neprelozis, protoze nevis co :D tohle se resi parametrizovanym prekladem: "text %s text", $text

@pekelnik: to mi jako chceš říct, že napíšeš kód, který poběží jen o vánocích a dopředu to neotestuješ? Ale prosimtě :)

Ovšem uznávám, že můj extrémní příklad, se kterým si extractor neporadí, je maličko vykonstruovaný :) Na druhou stranu, stále si stojím za tím, že ukládat řetězce pro překlad za běhu je systémovější a výhodnější.

Editoval HosipLan (20. 8. 2012 9:56)

„Tady máte administraci překladů a překládejte“ – kde je problém? Proč by překladatel měl pouštět testy?

Pořád ale nechápu, jak můžeš mluvit o systémovým řešení, když de facto spojuješ dva úplně nesouvisející celky – testování a překlad.

Ty netestuješ aplikaci, když ji vyvíjíš? Třeba tím, že si otevřeš stránku a zkusíš odeslat formulář?

Když aplikaci spustíš a zavolá se ti někde vevnitř

$translator->translate($something, array($param1, $param2, $param3)); // třeba

tak můžeš udělat dvě věci

• podíváš se do slovníku a vrátíš překlad, pokud není, vrátíš předaný řetězec (prevence selhání)
• pokud překlad neexistuje, tak vložíš překládaný text do slovníku

V administraci si otevřeš slovník, koukneš co přibylo (administrace pozná podle data v databázi) a překládáš. Tohle se absolutně vůbec nevylučuje s gettextem. Můžeš si nechat vygenerovat slovník v libovolném formátu a poslat ho překladateli a pak ho zase nahrát do aplikace. Kde je problém?

nic nebrani tomu, aby fungoval extractor a aj vycucavaci translator zaroven a aby sa doplnali. mne osobne pride jednoduchsie si nechat texty vyextrahovat ako vsetko preklikavat. hlavne ked su texty aj v emailoch a inych veciach, co sa nedaju vzdy rucne nasimulovat alebo to zaberie dlhy cas a vela namahy.

@bazo: pokud máš v plánu podporovat oba přístupy, nemá cenu se tu dohadovat, který je lepší… Konec konců, to je asi nejlepší řešení

extractor uz vie posielat vyextrahovane retazce na server