Jak nejlépe vyřešit dvojjazyčný e-shop?

Mám e-shop v PHP+MySQL. Jak nejoptimálněji vyřešit jeho jazykovou mutaci a běh na doméně příslušného státu? Úprava DB a switchování echoes (většina hlášek e-shopu je hard-coded) nebo předělání e-shopu do druhého jazyka a stejně tak i databáze? Jsou tam značné výhody i nevýhody... 1. varianta - v hlavě mám zatím dost zběsilou úpravu databáze a skripty plné switchů a podmínek... 2. varianta - každou položku upravovat, přidávat, mazat a přeceňovat dvakrát... Ještě mě napadá třetí varianta, předělat jen skripty a DB udělat společnou... Ale stejně, popisky budou jiné, ceny budou v jiné měně (přepočet podle kurzu ne-e)... Co vám přijde jako optimální řešení?

S týmito vecami by mal eshop počítať a byť na to pripravený, nedá sa prepísať niekoľko skriptov a všetko bude dobré. Predpokladám, že toto bude nejaká vlastná zlátanina, takže skôr by som si zhodnotil súčasný stav eshopu a preprogramoval ho nanovo, samozrejme s dostatočným návrhom vopred na papieri. Dve databázy sú nezmysel, spravovať to bude katastrofa, malo by to byť v jednej DB. Ja programujem pomerne rozsiahly eshop systém a tam to riešim tak, že pre položky počítam s jazykovými mutáciami priamo v databáze a taktiež aj eshopové html šablóny sú rozdelené pre každý jazyk zvlášť. Znamená to síce väčšie možnosti customizácie jazykových verzií, ale aj vyššie réžie na úpravy (tú samú vec treba previesť vo všetkých jazykových verziách danej šablóny) než napríklad za použitia gettext + preklady. Treba eshopové skupiny a ich lokalizáciu riešim v databáze takto: CREATE TABLE `shopgroup` ( `id_shopgroup` int(10) unsigned NOT NULL auto_increment, `id_parent_shopgroup` int(10) unsigned NULL default NULL, `orderby` smallint(5) unsigned NOT NULL default '0', `name` varchar(128) NOT NULL, `flags` int(10) unsigned NOT NULL default '0', PRIMARY KEY (`id_shopgroup`), UNIQUE INDEX `unique_name` (`name`), INDEX `fk_shopgroup1` (`id_parent_shopgroup`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE `shopgroup_lc` ( `id_shopgroup_lc` int(10) unsigned NOT NULL auto_increment, `id_shopgroup` int(10) unsigned NOT NULL, `lang` varchar(2) NOT NULL default 'en', `lc_name` varchar(128) NOT NULL, `url_name` varchar(128) NOT NULL, PRIMARY KEY (`id_shopgroup_lc`), UNIQUE INDEX `unique_url_name` (`url_name`), INDEX `fk_shopgroup2` (`id_shopgroup`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; lc_name je lokalizovaný názov skupiny a keď treba pracovať s názvami, JOINe sa tabuľka so shopgroup tabuľkou. Podobný princíp aj u položiek eshopu, ale to sem vkladať nebudem.

"Vlastná zlátanina" to je, ale e-shop je přeprogramovaný na novo teď čerstvě, dokončil jsem ho minulý týden.Upřímně, Tvůj vzorek databáze mi spíše napovídá "udělej samostatnou DB". Protože každou kategorii a každý produkt bych i ve Tvém řešení vkládal zvlášť, resp. určitě ta "nesystémová pole". A systémová pole se většinou vytvoří sama.Ve finále mi to pak přijde jako dlouhá práce s přepracováním e-shopu avšak stejná správa, jako při dvou DB... Případně se při dvou DB dá třeba vkládání produktů udělat najednou - vloží se do obou DB a v cizojazyčném adminu se pak jen přeloží potřebné texty...Čekám na protiargumenty =)

Napsal meloun;460499

"Vlastná zlátanina" to je, ale e-shop je přeprogramovaný na novo teď čerstvě, dokončil jsem ho minulý týden.

Neviem, či ten tvoj shop je jednoúčelová vec alebo jadro budeš ďalej používať, ale to, že si ho minulý týždeň dokončil, ešte nič neznamená :) Ja väčšinu už v polke nejakého väčšsieho projektu narážam na koncepčné nedostatky a viem, že keď dokončím, môžem kľudne začat s preprogramovaním, je to nikdy nekončiaci proces.

Napsal meloun;460499

Upřímně, Tvůj vzorek databáze mi spíše napovídá "udělej samostatnou DB". Protože každou kategorii a každý produkt bych i ve Tvém řešení vkládal zvlášť, resp. určitě ta "nesystémová pole". A systémová pole se většinou vytvoří sama.

Nie, v administrácii sa nič nevkladá zvlášť. Dáta, ktoré patria k sebe, sa vkladajú na jeden krát a basta. Pokiaľ sa eshop nastaví na niekoľko jazykových verzií, treba vložiť parametry všetky naraz, inak sa užívateľ ďalej nedostane, validácia ho nepustí. Všetko je transaction-based, takže rozpad dát nehrozí, že by sa do jednej tabuľky vložilo to, ale do druhej už nie. Nejak som nepochopil, čo si myslel tými systémovými a nesytémovými poľami. Pridanie ďalšieho jazyka do fungujúceho eshopu, hoci eshop jazyky podporuje, nieje tiež jednoduchá vec. Na to treba vytvoriť nástroj typu "pridám jazyk, ale nieje povolené ho vo frontend časti používať, vytvorí sa mi zoznam všetkých položiek, ktoré treba zmigrovať a až po vyčistení toho zoznamu sa bude môcť zapnúť táto jazyková verzia"

Napsal meloun;460499

Ve finále mi to pak přijde jako dlouhá práce s přepracováním e-shopu avšak stejná správa, jako při dvou DB... Případně se při dvou DB dá třeba vkládání produktů udělat najednou - vloží se do obou DB a v cizojazyčném adminu se pak jen přeloží potřebné texty...

A čo konzistencia dát? MySQL vraj síce podporuje transakcie naprieč databázami, ale vôbec netuším, aká je tam spoľahlivosť a ako sa to rieši, či nieje potrebný aj nejaký zásah na databázovom serveri. Ak dve databázy, tak jedine ako dva samostatné eshopy.

Napsal bruce;460684

Neviem, či ten tvoj shop je jednoúčelová vec alebo jadro budeš ďalej používať, ale to, že si ho minulý týždeň dokončil, ešte nič neznamená :) Ja väčšinu už v polke nejakého väčšsieho projektu narážam na koncepčné nedostatky a viem, že keď dokončím, môžem kľudne začat s preprogramovaním, je to nikdy nekončiaci proces.

Dělám si e-shopy vždy na míru pro konkrétní sortiment, pokud dělám nový obchod, vezmu ten systém, smažu, co není potřeba a přidám, co je potřeba. Samozřejmě, také stále něco předělávám, dodělávám, ale tentokrát jsem shrnul poznatky z dvou let s tou první verzí a udělal úplně nový.

Napsal bruce;460684

Nie, v administrácii sa nič nevkladá zvlášť. Dáta, ktoré patria k sebe, sa vkladajú na jeden krát a basta. Pokiaľ sa eshop nastaví na niekoľko jazykových verzií, treba vložiť parametry všetky naraz, inak sa užívateľ ďalej nedostane, validácia ho nepustí. Všetko je transaction-based, takže rozpad dát nehrozí, že by sa do jednej tabuľky vložilo to, ale do druhej už nie. Nejak som nepochopil, čo si myslel tými systémovými a nesytémovými poľami.

No, jasně, ale vkládáš dvakrát popisek, jednou česky, jednou třeba anglicky, to samé název apod. To souvisí s tím posledním příspěvkem, že není problém udělat takovou administraci nad 2 databázemi - shodná pole (např. číselné parametry zboží) se vyplní jen jednou, uloží shodně do obou DB. Popisky se vyplní zvlášť a uloží zvlášť.

Napsal bruce;460684

Pridanie ďalšieho jazyka do fungujúceho eshopu, hoci eshop jazyky podporuje, nieje tiež jednoduchá vec. Na to treba vytvoriť nástroj typu "pridám jazyk, ale nieje povolené ho vo frontend časti používať, vytvorí sa mi zoznam všetkých položiek, ktoré treba zmigrovať a až po vyčistení toho zoznamu sa bude môcť zapnúť táto jazyková verzia"

Bereš to nějak moc složitě :o) Prostě ke všem "echo" přidám cizojazyčné varianty a jakmile to přidám ke všem, můžu povolit ve front-endu změnu jazyka. Stačí si otevřít soubor po souboru a ctrl+f hledat echo :o)

Napsal bruce;460684

A čo konzistencia dát? MySQL vraj síce podporuje transakcie naprieč databázami, ale vôbec netuším, aká je tam spoľahlivosť a ako sa to rieši, či nieje potrebný aj nejaký zásah na databázovom serveri. Ak dve databázy, tak jedine ako dva samostatné eshopy.

Ano, to určitě, ale měl jsem na mysli společný admin např. na vkládání a úpravu produktů (viz výše).

Napsal meloun;460741

No, jasně, ale vkládáš dvakrát popisek, jednou česky, jednou třeba anglicky, to samé název apod. To souvisí s tím posledním příspěvkem, že není problém udělat takovou administraci nad 2 databázemi - shodná pole (např. číselné parametry zboží) se vyplní jen jednou, uloží shodně do obou DB. Popisky se vyplní zvlášť a uloží zvlášť.

Tak jasné, že popis musí byť toľkokrát, koľko máš jazykov, predsa by som bol nerád, ak by vznikla skomolenina, kde polka je v takom a polka v onakom jazyku. Eshop by mal pôsobiť profesionálne. V shopgroup a shopgroup_lc niesú žiadne duplicitné stĺpce. Stĺpec `name` je interné pomenovanie skupiny, ktoré sa využíva v adminovi (jednoznačný názov, na ktorý sa dá spoľahnúť), zatiaľčo `name_lc` je lokalizovaný názov pre konkrétny jazyk, ktorý sa pri nastavovaní eshopu zadefinuje. U shopitemov je tiež podobný princíp, mám tabuľku `shopitem`, kde sú určité parametry plus jazykovo nezávislé informácie o tovare (číselné údaje) a tabuľku shopitem_detail, ktorá odkazuje na shopitem a obsahuje jazykovo závislé údaje, pre každý jazyk jeden záznam.

Napsal meloun;460741

Bereš to nějak moc složitě :o) Prostě ke všem "echo" přidám cizojazyčné varianty a jakmile to přidám ke všem, můžu povolit ve front-endu změnu jazyka. Stačí si otevřít soubor po souboru a ctrl+f hledat echo :o)

Nejako sa v tom teraz strácam a neviem čo presne myslíš, tak skús trocha podrobnejšie vysvetliť.

No, tak nějak mi z toho všeho, co píšeš, vychází, že jednodušší bude opravdu 2krát e-shop, 2krát databáze a nad DB společný admin...Nebo?

Neviem o bližších detailoch, ako tam máš čo riešené, takže ťažko vyvodzovať nejaké závery z mojej strany. Spoločný admin pre dva eshopy sa dá realizovať rôznymi spôsobmi, niečo sa dá spojiť, niečo nie. Treba definícia položiek nemusí byť taká katastrofa, ale také skladové zásoby, faktúry, objednávky v žiadnom prípade neriešiť kopírovaním z jednej db do druhej alebo teda v jednom adminovi meniť skladové zásoby na dvoch eshopoch naraz, to patrí do jednej databázy/tabuľky, v opačnom prípade si koleduješ o malér

Necital som posty ale na multilingual web je dobry sposob, ze si vsetky hlasky napsies v anglictine a prezenies ich cez nejaku funkciu. Tato funkcia spravi hash a porovna ho v db. Ak najde zaznam, tak vrati prelozenu frazu prisluchajucu nastavenemu jazyku(nejaka globalna premenna). No a v amine si spravis prekladove rozhranie, kde budes mat pevnu frazu anglictine a pridas jej len do db preklad v pozadovanom jazyku. Pocet querys obmedzis cachovanim stranok.

Tohle je velice dobré řešení, nicméně vhodné až pro 3+ jazyků, u dvojjazyčného webu je to celkem zbytečné...