Dobrý den,
mám záludný dotaz, ha. Zajímalo by mě, zda a jak lze v "nižších" serverových jazycích jako php, ruby, perl vytvářet vícejazyčné weby, aniž by byly použity doplňující knihovny nebo nestandardní serverové objekty. Zároveň by to mělo být dobře škálovatelné s rostoucím objemem dat.
Jde mi o to, jak se nejlépe zbavit statického textu ze stránky, viz třeba zde: Seznam rubrik, Vnitřní pošta, Hledat, Přihlášení, Vložit... tudíž se všechno musí tahat odněkud zvenčí. Jak to efektivně provést?
1. Include/import textového souboru se staticky definovaným polem nebo proměnnými: víceméně nepoužitelné
2. Vytvoření slovníku (nebo kolekce/pole, indexovaného stringy) z includnutého textového nebo xml souboru. To by asi šlo, ale něco v tom přepisovat nebo upravovat by bylo peklo. Navíc by to bylo dost velké na procházení, načítání atd.
3. Vytvoření slovníku (jako ve 2, ale) z databáze - načtení komplet všeho pro zvolený jazyk. To už je o dost lepší, editace bez problému, přenos dat taky (web server = db server). Už by to brzdilo jen samotné provádění, protože se to musí načíst při každém jednotlivém přístupu na stránku.
4. Nějaký perzistentní objekt, který by obsahoval všechny jazyky, vytvořil by se při první žádosti o data, po ukončení skriptu by zůstal a existoval dál. Něco, co by běželo po celou dobu běhu web serveru. Nebude to však taky solidní zátěž, možná ještě horší než opakované vytváření?
5. Jiné řešení?
Narazil jsem na to, že php (stejně jako perl, s trochou snahy) má podmíněné includy, tedy si vložím jen tu jazykovou verzi, kterou potřebuju, ostatní se nebudou zbytečně načítat. Podmíněný include na to ale použít nemůžu.
Když bude používáno jen 200 výrazů nebo vět ve třech jazycích, fungovat to bude s čímkoli. Pokud půjde počet výrazů do tisíců a jazyků bude třeba deset, který způsob na tom bude nejlíp?
0x
asi bych na to šel poměrně jednoduše:
$pozdrav["cz"]="ahoj";
popř. $jazyk["cz"]["pozdrav"]="ahoj";
aha, měl jsem si přečíst celé zadání 
Počítáš, že těch textů bude víc než pár set kB? Jinak nemá cenu řešit zátěž, server se tím prochroupe velice snadno, na stranu uživatele se to samozřejmě nedostane.
Server to přečte snadno. Jak dlouho mu ale bude trvat, než najde, kde končí která závorka nebo který if? Když tam vrazím natvrdo "include texty.php" spolu s několika dalšími důležitějšími includy, jako funkce pro databázi, layout, generování obsahu a css, hashe, uploady, zpracování dat.. Řekl bych, že to těch 200-250kB možná mít bude - bez textů :D
Mě tam prostě děsí to, že by se to provádělo při každém jednotlivém přístupu a že je to vlastně úplně zbytečná brzdící operace, která má jen podpůrný účel, užitečná hodnota nulová 
zaprvé web má na výstupu mít kolem 50kb (bez obrázků)
za druhé je mu jedno jak je dlouhý IF jde o to co je v něm ( cyklus se dělá Nkrát ale IF jedenkrát )
a proč mu includovat všechny jazyky zaráz když stačí jeden jediný a to třeba bude v $_SESSION uložen jazyk a po nějaké podmínce jestli je zvolen se bude vkládat třeba include dirname(__FILE__)."/langs/".$_SESSION['lang'].".php"; a stačí v /langs/cz.php bude třeba:
$lang[1] = "Zdar";
$lang[2] = "další text";
to samé bude třeba v eng.php
$lang[1] = "Hi XY";
$lang[2] = "next text";
dále pro CSS a JS lze nastavit cachování a komprese ... lze jednoduše komprimovat obsah který leze ven a pak jej nechat cachovat browser třeba na týden čímž se zrychlí chod webu, ale hodně záleží na provedení cyklů a práce s DB (musí se hodně využívat cache a nebrat zbytečná data)
200-250kB bude mít ten zdroják, který se poskládá dohromady ze všech includů. Do toho nepočítám žádné texty.
Podmíněné includy bohužel provádět nemůžu.
Js a (částečně) css budou samozřejmě cachované, minifikované a gzipované (dohromady snad do 60kB), o velikost výstupu mi teď nejde.
To s tím IFem a závorkama jsem myslel tak, že to při provádění skriptu musí zdroják nějak rozparsovat, číst znak po znaku, brát tokeny, atd.. kontrolovat syntax.. když tam bude dvacet stránek textu, párů klíč: hodnota nebo něčeho takového a bude to hledat, kde končí závorka nebo kde končí if, jestli někde není zapomenutý konec funkce atd, tak to asi chviličku potrvá? Jeden uživatel může klikat na odkazy po pár vteřinách a nic nepoznat, ale co když bude uživatelů naráz deset, dvacet.. na serveru poběží i jiné věci, nebude mít 100% výkonu pro louskání tohoto. Proto hledám nějaké vhodné, nepříliš zatěžující řešení, nerad bych to pozdějš přepisoval od základu
rozsekni to jednoduše... trápí tě vliv vložení souboru (250kB) do každého prováděného skriptu. Podle mě je to na straně serveru prkotina. Měl jsem stejnou úchylku a kvůli 0,01sec jsem byl ochotný přepsat celý soubor skriptů.
Na netu si stáhni knihovny, které počítají jak se dlouho provádí skript. Teď mě nenapadá jak to najít, ale ty si poradíš. Za to si dej cyklus FOR s 1.000x provedením natažení souboru 250kB do skriptu a mrkni na výsledný čas. Nedivil bych se, kdyby to bylo 0,2sec a pokud to uděláš ještě jednou opět s natažením malinkého souboru tak to bude 0,15sec... to je podle mého zanedbatelné při provedení 1.000x.
Řešil bych to jen pokud bych měl mít služby vytížené na úrovni Seznam.cz, při přístupu do 50k UIP den pohoda
Není lepší cesty než to nechat proběhnout tisíckrát a vyladit na ostro. Tahkle to dělají všichni než se trápit s teorii co a jak. Podobně ladím SQL dotazy. 
Ok, ok
Došlo mi, že tak jako tak to v databázi bud určitě. Buď se to bude brát přímo (to spíš), nebo se (jednou, při změně systému) vygenerujou XML a bude se to brát z nich.
Měření nějakým high-resolution timerem a praktické pokusy mám určitě v plánu, jen zatím nejsem ještě dost daleko, aby vůbec nějak fungovaly.
Ještě jsem zvědavý, jak to bude fungovat, až tam bude nějaký ajax, třeba pro našeptávání výsledků při psaní, kdy je okamžitá odezva více než žádoucí :D
doplněno 12.02.13 15:38:Aha, tak jsem zjistil, jak rozsáhlé překlady mají rozsáhlejší systémy, které je načítají z .xml při každém načtení stránky. Snad s tím tedy nebude problém.
0x
Tak jo, zdá se, že varianta 3 bude v pořádku.
Musím sice vytvářet novou kolekci/slovník (pouze pro používaný jazyk) při úplně každém přístupu k jakémukoli skriptu, ale zatím to zvládá. V databázi je už pár stovek záznamů a zpoždění při načítání dat pozorovatelné není (následný přístup k nim je víceméně bez jakékoli změny). Co jsem zkoušel a měřil, z localhostu to se vzdálenou databází stíhá za vteřinu tak 2500 záznamů, na serveru podle nálady, mezi 10 a 23 tisíci záznamů za vteřinu.
Jen ještě nevím, co s tím budu dělat, jestli se to náhodou někdy na takové počty rozroste
Neneseme odpovědnost za správnost informací a za škodu vzniklou jejich využitím. Jednotlivé odpovědi vyjadřují názory jejich autorů a nemusí se shodovat s názorem provozovatele poradny Poradte.cz.
Používáním poradny vyjadřujete souhlas s personifikovanou reklamou, která pomáhá financovat tento server, děkujeme.