Jak na překlady u dost velké aplikace

tany

Ahoj, řeším v nette velkou multijazyčnou aplikaci a jsem na rozcestí, jak vyřešit překlady textu (ne gui).
Dotaz na vypsání jednoho prvku se skládá z odkazu na 9 relací, kde z nich 7 ma ještě relaci na překlad do uživatelova jazyku. SQL dotazy začínají být docela pěkný humus (asi si přemapuju nějakou klávesu aby vypisovala řetězec „left join on =“).

Takže si pohrávám s myšlenkou, umístit tyto překlady textů do gettext, s klíčema zhruba ve tvaru table_column_primary-key. Databázový diagram by se až extrémně zjednodušil, nebyly by v něm žádné relace na překladové tabulky, žádné textové a varchar sloupce. ALE otázka je, jak by to na tom bylo z hlediska výkonu … ?

Pokoušel se někdo o podobné harakiri ? Už teď jsem na nějakých 38 tabulkách a ještě to není komplet ..

Editoval tany (26. 10. 2011 20:56)

Ondrej

tany napsal(a):

velkou multijazyčnou aplikaci a Už teď jsem na nějakých 38 tabulkách a ještě to není komplet ..

38 tabulek na velkou aplikaci? :) Já se na velkých projektech dostávám přes 100 tabulek. V tom problém není. Určitě je lepší mít překlady textů v databázi než v gettextu. JOINovat tabulky je korektni pristup ;)

Patrik Votoček

Ondrej napsal(a):

Určitě je lepší mít překlady textů v databázi než v gettextu.

celkem by mě zajímalo jak jsi na tohle přišel. nebo co tě vedlo k tomuhle zjištění. a abych předešel dalšímu dotazu tak pls uvěď zda mluvíš o i18n nebo o l10n nebo o obojím.

Ondrej

mluvím pouze o lokalizaci textů(článků, produktů) na webu. Na GUI je samozřejmě nejlepší gettext. Připadá mi trochu zvrácené po každém přidaní/upravě článku v administraci generovat několik kličů (titulek, úvodník, text) do .po souboru a kompilovat do .mo.
A hlavne vypisy z databaze potrebujes řadit (např. podle názvu produktu) a stránkovat. Bez JOINu v DB neudelas vypis prvnich x objektu serazenych podle abecedy.

EDIT: samozrejme to jde i bez JOINu, pokud mas lokalizaci ve sloupcich jedne tabulky, coz neni Tanyho pripad.

Editoval Ondrej (26. 10. 2011 23:17)

tany

myslím i18n i l10n je fakt že tam nepůjde to řazení :) to je pravda, nad tím sem nějak opoměl přemýšlet. Nad odstavením překladů do jedné lokalizační tabulky jsem také přemýšlel, zjednodušilo by to dotazování na určitý překlad z l10n. Modely se právě komplikují kvůli zjišťování existence překladu. i18n bude uritě v gettextu, tam je to jasný .. viva la vida latte

Ani

To co se ukládá do db překládat v db, to co se ukládá v šabloně překladá gettext. To mi přijde jako standartní.

paranoiq

je tu možnost nahradit některé LEFT JOINy uživatelskou funkcí – např:

SELECT product.id, getProductName(product.id, lang) FROM ...

ve funkci je samozřejmě SQL dotaz. u opravdu složitých dotazů to je dokonce rychlejší (ano, 1+n dotazů může být rychlejší než jeden LEFT JOIN, musí se to ale celé odehrávat na straně databáze). je třeba s tím ale opatrně a testovat výkon

tany

no já sem si nakonec udělal StorageClass, kter má jen overload metody a getAll. Celý výsledek pak hážu do web cache (některé dotazy nejdou napsat rozumně jako jeden, zvláště určité vazby 1:n) .. přišlo mi to vzhledem k častým relacem 1:(n:m) jako asi nejrychlejší řešení, protože u většiny z nich nebude prakticky docházet ke změnám.