Multilanguage komponenta

Joomla řešení pomocí asociací opravdu není vhodné vždy, nasazení je ale nejjednodušší, Joomla na to má prostředky . Na druhou stranu pokud není třeba např. hlídat stav skladu na položce (to by u asociací bylo zase náročnější), je to asi nejsystémovější cesta jak to v Joomle nasadit. I kategorie se nasadí velmi jednoduše .

VM řešení je trochu specifické, pro každý jazyk nová tabulka, upřímně jsem to nikde jinde neviděl. Nevýhodu bych viděl v nutnosti změn struktury databáze při přidání jazyku, ale u MySQL to asi zase takový problém není. Kód jazyka se pak v dotazech místo ve where použije při join tabulky.

U jedné komponenty, kterou jsem dělal a byl jsem dostatečně líný jsem překlady pořešil jednoduše přidáním TEXT pole do tabulky (v podstat stejně, jako Joomla pracuje s params), a do toho pole ukládám JSON zakódované překlady. Formulář lze pak jednoduše nasmolit pomocí Subform field , nebo přidělat vlastní field který vytvoří počet polí pro počet aktivních jazyků. Samozřejmě pokud je potřeba dle pole hledat nebo řadit, tak toto použít nejde.

Další varianta, taková dle mého nejobvyklejší, je vyhodit názvy / popisy do samostatné tabulky, se sloupcem jazyk (v podstatě analogie toho VM řešení, jen v jedné tabulce). Editace asi opět pomocí Subform nebo vlastního fieldu.

No a poslední možnost co mě napadá je neřešit to, a překlady dělat pomocí Falang . Nasazení by mělo být poměrně jednoduché (kdysi jsem to někde dělal ještě s JoomFish), uživatelsky také poměrně přívětivé. Jako nevýhodu bych viděl způsob jak Falang pracuje - nacpe se přímo do SQL dotazů, které nahrazuje svými, tj. není nad tím kontrola, a výkon může jít poměrně výrazně dolů...

Myslim, ze Phoca Cart to dela standardne joomlovsky.

Ale vzpominam si, ze pri prekladech jsem narazil na komponentu z Multi-lingual Content na JED a ta se podobnymi nebo stejnymi vlastnostmi primo chlubila.

Já musím konečně napsat článek o vícejazyčnosti v Phoca Cart.

Osobně si myslím, že asi nejlepší cesta je použít kombinace různých systémů.

Základ je odvozenej od Joomly! a to je, že každá položka má vlastní ID (mluvíme o produktu nebo kategorii). To má sice hodně negativ, ale pokud se ale podíváme na rychlost přidávání jazykových variant a Joomla! core funkce - asociace - tak to může být zajímavý:





1) Tedy zaprvé standardní Joomla! funkce

2) Ta je ale nevhodná pro překlad např. order statusů (čekající, vyřízen, ...). Tam bych spíš použil plugin MultilanguagesCK - já ho trochu poupravil ( www.phoca.cz/download/category/100-phoca-cart-component ) tak, aby pracoval i v emailech, PDF, apod.

Například email zákazníkovi může obsahovat tento řetězec:

{langck=de-DE}Němčina - uživatelův email je: {email}{/langck}{langck=en-GB}Angličtina - uživatelův email je: {email}{/langck}

- pro každý jazyk se použije jeho jazyková část.

Teoreticky se to dá použít všude, jen by v některých případech muselo být změněný pole v databázi, např. z VARCHAR(250) na TEXT, aby se tam vešlo více jazykových variant (a tady nejsem se zkoumáním ještě u konce, těch možných míst na možnej překlad bude víc, než je momentálně řešeno)

( 1) a 2) se dá libovolně kombinovat)

3) Falang - mám sice nějaký soubory pro Falang (tuším, že je to snad převzatý projekt z Joom!fish), ale nemám s tím žádný zkušenosti.

Mohla by to být zajímavá cesta, jak se vyhnout problémům v 1) (každá jazyková verze - jiné ID produktu/kategorie), ale to by si s tím někdo musel pohrát a doplnit všechny pole pro překlad.

Pokud by to někdo někdy řešil pomocí Phoca Cart a Falangu a zjistil by, že ta cesta je Ok, rád se zúčastním - například při vytvářením pluginů (což by v podstatě měly být jen definiční XML soubory



)

Podobně jako ten MultilanguageCK pracuje také n3t Language Filter - jen je to content plugin a ne systémový. Ale to je už opravdu spíš na překlady obsahů. Někdy používám na jendoduché články nebo custom moduly, abych neměl v administraci maglajs...

Umí Phoca hlídat stav skladu napříč asociacema?

Cony napsal: Umí Phoca hlídat stav skladu napříč asociacema?

Achillova pata výchozí vícejazyčné vlasnosti v Joomle!, kdy má každá jazyková položka vlastní ID, tedy i v Phoca Cart je každá jazyková verze samostatný produkt (tedy ano, sklad je v tomto případě nepoužitelný a těch limitů bude víc)

Osobně by mě zajímalo, jestli má někdo zkušenosti s Falangem, jestli vůbec stojí za námahu se na to podívat?

Rudolf napsal: Jestli to má být navíc ve smysluplné rychlosti kdy při 50 představeních za měsíc mám již 250 000 sedadel v DB, tak při multilanguage je Core řešení Joomla cesta do pekel (ať se na mě nikdo nezlobí, tohle je amatérské - byť jsme na joomla dělali online deníky pro Burdu a NEJPes)

Co se týče výkonu, neřekl bych, že by v tom měl být nějakej zásadní rozdíl, protože i ta externí komponenta musí někde ukládat to stejný, co dělá core. Každá přeložená varianta bude mít vlastní ID navázané na ID položky (typ Falang) a tedy záznamů bude v podstatě stejně u jakýhokoliv způsobu. Co se týče těch plugin kódů pro každou řeč, tam to bude asi ještě horší, protože se pracuje s textem (hledání a nahrazování).

Jak jsem psal výše, osobně by mě asi nejvíc zajímala komponenta typu Joom!fish, Falang, apod. a ne kvůli výkonu (ten asi od core lišit nebude), ale kvůli všem těm limitům, co se vztahují k jednomu produktu s více ID.

S Falangem jsem zatím moc nepracoval, zkušenosti mám s JoomFish, ale letitý...

Princip byl takovej, že se navěsil někam na Database::execute a před spuštěním jakýhokoliv SQL dotazu jej rozparsoval, našel tabulky a elementy který by se měly přeložit a nahradil je. Už tady je nějaký ten výkon skrytý. Navíc do dotazu doplnil join na svojí tabulku (která jestli si pamatuju byla společná pro vše, takže docela masivní), i když vlastně původní dotaz byl jen na jednu tabulku (select id, title from articles nahradil necim jako select a.id, coalesce(b.title, a.title) from articles left join translations on ....).

Ale to vše furt nějak fungovalo. Problém byl u komplikovaných dotazů, tam se občas ztratil, ale předpokládám, že to už vychytali...

Pokud bych ale dělal svý řešení, spíš bych si to udělal do svých tabulek (osobně bych preferoval jednu tabulku, než VM styl), už jen proto abych měl nad vším plnou kontrolu, navíc pak editace všech jazyků může být v jednom formuláři (např. na záložkách), což mi přijde jako fajn...

Cony napsal: Pokud bych ale dělal svý řešení, spíš bych si to udělal do svých tabulek (osobně bych preferoval jednu tabulku, než VM styl), už jen proto abych měl nad vším plnou kontrolu, navíc pak editace všech jazyků může být v jednom formuláři (např. na záložkách), což mi přijde jako fajn...

Jasný, ale jde spíš o to, nevymýšlet znovu kolo. Asi je každýmu jasný, že prostě vícejazyčná verze rozhodně nebude přítel databáze. Ono je to tak, že člověk si řekne, že to udělá jednodušeji, ale jak postupně zjišťuje složitosti a přidává vychytávky, najednou se mu z toho stane stejný moloch, jako nějaké již existující řešení.

Já momentálně zkouším Falang a mohlo by to být řešení, co se týče těch ID (tedy že by jeden produkt měl pouze jedno ID a to i při různých jazykových verzích)

Ovšem asi to nebude tak jednoduchý, protože pokud něco načtu přímo z tabuky, je to přeložený, pokud to načtu jako left join (součást jiné tabulky), pak se to nepřeloží.

Příklad:
Dodací metoda - pokud se načte např. v checkoutu, je přeložena, pokud se načte např. v zobrazení objednávek, kde se z databáze načítá pomocí LEFT JOIN k tabulce objednávky, pak se nepřeloží.

Zkusím konktaktovat autora, jestli se tohle dá nějak řešit