Többnyelvű oldal - hatékonyság

Internet: PHP, CGI, stb.

Ü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.

  • 4603 megtekintés

( andrej_ v | 2012. 09. 03., h – 10:25 )

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.

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.

+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!

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?

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!

( xcenter | 2012. 09. 03., h – 12:22 )

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 :)

( uid_194 | 2012. 09. 03., h – 17:31 )

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]

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.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( mudlee | 2012. 09. 06., cs – 15:08 )

PHP-ban ajánlom a yii framework-öt, annak az I18 implementacioja nekem eddig bevált.