Üdv!
Érdekelne, hogy milyen módszerek lehetségesek egy többnyelvű oldal létrehozására, és melyik miért hatékony.
Jelenleg egy python (django) alapú oldalról lenne szó, de érdekességképpen php nyelvnél is érdekelne, ha van különbség.
2 dolog, amire gondoltam:
1) minden nyelvi dolgot mysql- ben tartani, de ez nyílván nagyon nagyon sok lekérdezéssel jár. Egy lekérdezésben nem is lehet minden adatot elkérni, mivel a generálás "elején" nem mindig tudom, hogy mire lesz szükség.
Sok olyan "mondat" van, ami úgy épül fel, hogy:
nyelviszoveg1 $valtozo1 nyelviszoveg17 $valtozo5 nyelviszoveg13 $valtozo22 nyelviszoveg32 ... .
Ha például van egy oldal, ahol sok szöveg van, és van benne mondatonként 2 változó, ez akár lehetne 50 lekérdezés egy oldalra, ami nem túl hatékony.
2) Gondolom egy jobb megoldás, ha a nyelvi dolgokat egy olyan fájlban tartom, amiben a változók már ott vannak, mondjuk egy jó nagy dic:
dic = {
'nyelviszoveg1': ('alma', 'apple', 'Apfel'),
'nyelviszoveg17': ('beka', 'frog', 'Frosch'),
'nyelviszoveg33': ('korte', 'pear', 'Birne')
}
.
Igazából ez a 2 ötletem van így hírtelen, de nyílván van jobb és hatékonyabb megoldás is "erősen dinamikus" oldalakra. Érdekelne, hogy mások ezt hogyan oldják meg.
Köszi a válaszokat.
Hozzászólások
Az SQL-es megoldással nincs gond, egyszerűen bele kell kalkulálni a dologba. A kevessé dinamikus tartalmak pedig cache-elhetőek, azaz előre legenrálhatóak. Ilyen lehet például egy Impresszum, egy ÁSZF, egy elérhetőség vagy ehhez hasonló menü. Általában a
SELECT text FROM akarmi WHERE lang = 'hu'módszert szokták alkalmazni a dinamikus tartalomhoz és a menükhöz pedig szótárfile-okat. Ezekben lehet konstansként vagy tömbelemként definálni ami kell. Pl.:$LANG['HU']['mainpage'] = 'Főoldal';.Emailekben lehet template-et használni, ahol %AKARMI%-re helyettesítesz be a szótárfile-okból vagy SQL-ből.
--
Apache Solr Druplahoz és Wordpresshez: http://solr.vpspro.hu
+1
Jelenleg én is ezt az elgondolást alkalmazom, még annyi, hogy ha később külső fordítók bedolgozása várható, nem biztos, hogy a php formátum olvasható nekik, érdemes lehet egy .csv formába export, és azt importálni, de azt meg db-be egyszerűbb. Üzleti szoftvereknél mindig könnyű találni fordítókat a leendő felhasználók között, én is fordítottam már license-ért, és fordíttattam is.
csv-vel csak szopatnam a forditot. Egy Gettext PO fajl peldaul sokkal hasznosabb lehet.
--
Az SQL fölé érdemes egy nosql (pl. Redis) réteget húzni, és oda pakolni a db-ből lekért fordításokat, jól kitalált kulcsokat használva.
akkor már miért nem memcache?
de a gettext a legjobb.
Ha relative sok adatot tart az ember a cache-ben, akkor annak kiürülése (mondjuk egy restart miatt) nem egy örömteli dolog. Oké, a redis teljesítménye kisebb, de valamit valamiért.
gettext :)
annyival nem rosszabb a redis, hogy memcache-t használjon az ember, az extra feature-ok pedig kifejezetten előnyösek tudnak lenni.
hátde forditásoknak tartani redist majdnem luxus.
de kérdéshez:
legeszerűbb a:
$text = sprintf(_('Matyi %s napot matyizott'),'három');
ellenben a
$text = sprintf($lng[$aktuálislng]['valamiazonostio'],'három');
ha pl uj szoveg kell, átirod a _() -ben a szöveget arra amire kell, és frissited a poeditben, és kész. a tömbös és defineos megoldásnál meg ugyis belekavarodsz előbb vagy utóbb.
raadasul ha melleutsz valahol, akkor legy egy ures stringed, gettextnel meg max nem forditodik le. mindkettoben van elony meg hatrany is...
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
jo, de szerintem ezt nem nekem akartad mondani. En csak a memcache<->redis dologba rofogtem bele, nem abba hogy helyes dolog-e redis-ben tarolni a forditasokat.
igen, azért irtam, hogy "de kérdéshez:" lusta voltam másikat nyitni.
Szerintem hasznald a Django beepitett i18n tamogatasat, akkor nem kell feltalalni ujra a spanyolviaszt.
--
|8]
+1 bar nem ertek a dijangohoz, de mar gondolkoztam rajta, hogy nem igaz, hogy nincs erre valami megoldas benne. Mondjuk azzal lehet vitatkozni, hogy az a legjobb-e, es a kerdezo inkabb arra volt kivancsi, mi valt be legonkabb a kozossegnek. A masik oldalon meg a dijangos kozossegnek az valt be ;)
--
zsebHUP-ot használok!
Ha a tényleges fordításokat nem gettext po formátumban tárolod, rövid úton pokolra jutsz!
___
Arany János: Grammatika versben
+1 gettext
+1 a gettextre. Igaz file alapú, de jól kezelhető és mindenhez van.
+1
Lehet, hogy én vagyok a hülye, minimalista, etc., de ha van rá egy egyszerű, könnyen kivitelezhető, saját megoldás, ami semmivel sem bonyolítja meg a felhasználást, akkor miért éri meg egy sok extra, sok esetben a feladathoz teljesen felesleges modulokkal és opciókkal rendelkező frameworkot használni?
Tobbek kozt azert, mert eleve, a hasznalt framework (Django) tamogatja a tobbnyelvuseget, teszi ezt gettexten keresztul, igy feltalalni a spanyolviaszt nagyobb befektetes, mint hasznalni a meglevot, ami eleve a framework resze.
--
|8]
+1, valamit ha gettextet használsz, fordítgathatod a szövegeidet kényelmesen, célszoftverrel: http://www.poedit.net/
az arrayos megoldás nem egyszerű. a define sem.
Mert a sajat, egyszeru, konnyen kivitelezett sajat megoldasod nincs betesztelve tobb ev es tobmillio felhasznalo altal. A Gettext meg igen. Es ez kb. minden feladathoz igaz.
--
nemcsak magat a forditas kell nezni, hanem mellett a koritest. te csak irod a kodot, es vannak toolok amik kigyujtik a forditani valot. kommentet lehet irni a szoveg melle, igy egy nemegyertelmu szoveget nem forditanak tokre hulyere. es tonnanyi editor van hozza. stb.
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Szia!
Én személy szerint xx.php file-ben define("LOGIN_LOGINBUTTON_TEXT","Login");
formában tárolom a statikus szövegeket, és amilyen nyelven van a felhasználó, azt includeolom. A dinamikus tartalmaknak (hírek, kommentek) meg simán adtam sql-ben egy language mezőt. Egyszerű szerkeszthetőség kedvéért ki szoktam rántani excelbe az egész statikus lang filét a fordítóknak.
Sok gondom eddig nem volt vele, bár tutira nem industry best practice :)
Annyira nem tunik rossznak, mar csak azert sem mert en is igy szoktam :D
Teljesen mellekesen megkerdeznem, hogy benchmarkolta-e mar valaki, hogy az arrayos meg defineos moka vajon gyorsabb-e, mint a gettext?
Illetve, hogy tudja-e ugyanazokat a dolgokat, amiket azert szokott hasznalni az ember (tobbes szam, format stringben parameterek mas helyutt, stb)? Kommentek forditoknak, adott nyelv forditasi szazalekanak, fuzzinessenek merese? Meglevo eszkozok a forditas egyszeru szerkesztesehez, frissitesehez?
Illetve arra gondolt-e valaki, hogy a Djangos mar meglevo megoldas milyen egyeb extrakat nyujt (pl Accept-Language header tamogatas), amiket igy nem kene ujra feltalalni?
--
|8]
valahol olvastam hogy a gettext gyors. régen. aztán valaki kimérte, hogy igen
http://mel.melaxis.com/devblog/2006/04/10/benchmarking-php-localization…
kéne valami hasonlot mérni
Szerintem az eredmeny tovabbra is ugyanaz (erre volt burkolt utalas a kerdes ;), de valoban megerne egy uj merest, ha masert nem, azert, hogy legyen friss eredmeny is, amire lehet mutogatni.
--
|8]
for ($i=0;$i<1000;$i++) $text .= sprintf(_('Üzenetek %s'),$i);
ez alig több mint 3 század másodpercig fut.
ha két századmásodpercig futna a tömbös vagy a define, akkor most melyik a jobb?
Nem a sebesseg az egyetlen szempont, FYI, es nem is feltetlenul olyan egyszeru formaban, mint a ciklusod.
Pl. ha templateben kell forditani, vagy picit komplexebb, mert mondjuk tobbesszam is van benne, rogton mas lesz a helyzet.
--
|8]
mutass példát
Fentebb keresd meg a django i18n doksit, van benne jopar pelda.
--
|8]
Tekintve hogy a gettext valahol melyen C szinten fordit, nem hiszem, hogy nagysagrendekkel lassabb tudna lenni, mint barmilyen PHP-s megoldas. Lehet, hogy van sebessegkulonbseg, de oszinten: ha egy oldalnal lassu, jo esellyel nem a gettext miatt az.
--
Szerintem olvasd el mit irtam, pont forditva ertelmezed ugy latom :)
--
|8]
PHP-ban ajánlom a yii framework-öt, annak az I18 implementacioja nekem eddig bevált.