Milyen formában érdemes tárolni a nyelvi fájlokat?

**lpmorpheus** · 2009-06-11, 20:57

Sziasztok!

A tapasztaltabb felhasználókhoz szólnék, hogy milyen formában érdemes tárolni egy többnyelvű weblap esetén a tartalmat? Melyik az a tárolási forma, amivel a legkényelmesebb módosítható/bővíthető a nyelvi fájl, és szinkronban tartható a többivel? (Első sorban PHP-s környezetben felhasználható megoldások érdekelnének!) Előre is köszönöm!

Hasonló témák:

**huncyrus** · 2009-06-11, 21:29

Ez természetesen elég szubjektiv dolog. Nagyon erősen függ az oldal tematikájától és felépítésétől.

Legáltalánosabb a file letárolás, és változókban, define-kben vagy tömbökben való tárolás (gyakorlatilag a legtöbb moduláris opensource kód, főként a cms-ek lásd joomla és egyéb nyalánkság).
- Pro: gyors megvalósítás, könnyű kezelés, közepesen átlátható
- Kontra: programozottan macera a változtatás, nagy méretnél lassít és memoriát zabál, több file

E mellett lehet xml-ben (asp .net-nél és java-nál ), amely dom/node alapú
- Pro: viszonylag gyors, dom alapú, jó struktúrálható = jól átlátható, könyebb a változtatás, közepes memória fogyasztás
- Kontra: xml-t kell kezelni, közepes memória fogyasztás, lassabb megoldás

Aztán lehet még sql-ben is, de erősen optimalizálni kell.
- Pro: gyors, könnyen kezelhető, minden egy helyen, könnyen adminisztrálható
- Kontra: sqlnek is kell a kakaó, átláthatóság alacsony, redundancia

Én használtam / használom mindhármat, mindnek van előnye és hátránya. Leirtam h kb melyiknek mi (biztos kapok rá ellenkezést).

Ha a projected kicsi akkor én a file alapút javaslom. Ha überdurva a project akkor már az xml-n gondolkodnék, ha meg sok sql-t használsz és van normális vasad az sql alatt (akár standalone / cluster

) akkor meg sql-be vele.

Persze biztosan van rész, amit kifejeltettem, de én ezeket használom a gyakorlatban jelenleg.

**TLoF** · 2009-06-11, 22:35

Nyelvesitésre eddig én az alábbi megoldást használtam, az átmenet az sql és a file között.

SQL-ben tárolod a stringeket amiket nyelvesiteni kell, viszont a kész nyelvi változatot "cache" -ként kimented file-ba is / egyetlen sql mezőbe serializáltan. Igy könnyen lehet frissiteni, ugyanakkor gyors is lessz.

Amivel még lehet játszani az a php gettext fügvény, ami eleve a nyelvesitéshez van kitalálva.

**lpmorpheus** · 2009-06-12, 09:05

huncyrus: Jó az összefoglalás, köszönöm!
huncyrus & TLoF: Én sokáig a változókban/defineokban tárolt megoldást használtam, de nem olyan régen kipróbáltam az SQL-es megoldást, ahol úgy képzeltem el, hogy egy mező az azonosító, minden további mező pedig egy-egy adott nyelv. Alapvetően fejlesztésnél semmi probléma nincs azzal, hogy SQL-ben tárolom, mert így biztosan nem fog előfordulni olyan, hogy az egyik fájlban már bevezetett változót nem tartalmazza a másik. Kényelmetlennek akkor bizonyult, amikor az adott fejlesztés után a szerverre akartam updatelni. Mindig ki kell exportálni az adott SQL táblát, és PHPMyAdmin-ban meg importálni. :/ Ez nagyon macerás, főleg ha updatelés után még sok aprót módosítasz, és abban a fázisban vagy, hogy na most akkor már jó lesz, de nem, és kábé 5 perc alatt ~20x módosítod a táblát.

Valamint, nekem még fontos az is, hogy a weblap fejlesztése során, a nyelvi fájl bővítésekor tudjam az azonosítókat mondjuk ABC sorrend szerint rendezni. Ezt nehezen oldható meg, ha változókban tárolom, tehát ezért is próbáltam ki anno az SQL-t. Viszont, most azt próbálgatom, hogy CSV-ben kellene őket tárolni, így egy OpenOfficeban bárhol tudom szerkeszteni, de még egy Google Spreedsheetben is, ha nem vagyok itthon. Az apró probléma ezzel viszont az, hogy mindketten máshogy kezelik egy kicsit a CSV-t, és OpenOffice se teljesen helyesen (ha érdekel kifejtem miért), de semmi esetre sem úgy, ahogy nekem optimális lenne.

Nemsokára ki fogok próbálni egy grafikus XML szerkesztőt, hátha azzal hasonló módon könnyű a bővítés.

**huncyrus** · 2009-06-12, 10:45

TLoF > thx, tudtam hogy valami kimaradt... hát a cache-elősdi

Ipmorpherus > csv-ben ragaszkodj a "szabvány" verziohoz. pontosvessző a végén \r\n akkor kb minden ugyanúgy kezeli (mac-linux-pc hármasban nálam tökéletesen ment sun/open/ko/m$ verzsönökben, gugli szpidshit-et meg ilyenre nem használtam. halálsszanak mástól adatot

)

de visszatérve, számodra tényleg vagy a csv exportolt sql vagy a szimpla sql lesz a megoldás.
amit már tetszőlegesen utána cache-elhetsz ha akarsz

**lpmorpheus** · 2009-06-12, 11:19

huncyrus eredeti hozzászólása

Ipmorpherus > csv-ben ragaszkodj a "szabvány" verziohoz.

Igen, ragaszkodom, de az OpenOffice meg a Google Spreadsheet sem ragaszkodik túlságosan. :| Viszont, ahogy írtál az SQL-ből exportált CSV-ről, rögtön megoldásra is találtam. :] Hála az égnek a MySQL Query Browser teljesen szabványosan formázza meg a CSV-t, tehát mától Ő lesz az én CSV editorom (hála az égnek linuxra is elérhető).

Így két legyet is ütök egy csapásra, mert adatbázisban is benne lesz a teljes tartalom az összes nyelven, és két kattintással kiexprtálom CSV-be, amit már egyszerűbb F5-tel felküldeni az FTP-re Total Commander-rel.

(És gyakorlatilag 0 plusz munkával redundanciát állítok elő, aminek segítségével még arra is odafigyelhetek, ha valamelyik fájl nem található/nem olvasható, akkor használja az adatbázist. Ez már nagyon pazar.

)

Köszönöm nektek, hogy segítettetek eljutni a megvilágosodásomig.

**WSzP** · 2009-07-09, 01:50

lpmorpheus eredeti hozzászólása

milyen formában érdemes tárolni egy többnyelvű weblap esetén a tartalmat

Én mindenként az XML-t javasolnám. Egyrészt a PHP5 tartalmaz nagyon jó XML kezelő függvényeket alapból, másrészt nagyon logikus és struktúrált, harmadrészt könnyen lehet kezelni, módosítani, stb.
Ha a programozással teljesen párhuzamos fordítókkal dolgozol akkor is nagyon könnyű elmagyarázni nekik a lényeget. Ha mégse sikerülni, akkor megkérheted, hogy írják a fordítást ami akarják (akár Excel is megteszi), és szinte bármiből nagyon könnyű generálni XML-t.
A másik nagy előnye a dolognak, hogyha egy projekthez van egy fordítás, akkor a következő hasonlónál felhasználható, még akkor is, ha az első PHP, a második mondjuk Ruby on Rails, vagy Adobe Flex.