Többnyelvűség támogatása sablonokban
Alkalmazásfejlesztés során felmerülhet az igény arra, hogy a késztermék több nyelven legyen képes megjelenni. Erre a problémára szeretnék most egy egyszerű megoldást bemutatni.
Alap megoldásként felmerül, hogy használjunk valami szótár táblát, ahol valami szöveges kulcs alapján megtalálhatjuk az adott nyelvű kifejezést, ahol pedig meg szeretnénk jeleníteni valami szöveget, ott egy függvényt hívunk a kulcs paraméterrel, ami a lefordított értékkel tér vissza.
<!-- pelda.tpl -->
<h1><?= translate('udv_az_oldalon') ?></h1>
<ul>
<li><a href="#"><?= translate('belepes') ?></a></li>
<li><a href="#"><?= translate('blog') ?></a></li>
<li><a href="#"><?= translate('kapcsolat') ?></a></li>
</ul>
Az én problémám ezzel az, hogy
- sokáig tart begépelni (
translate
helyett lehetnet
is a függvény neve, de nekem úgy sem tetszene), - ha nem enged meg az alkalmazás bármit kulcsként (
[a-zA-Z_]{0,60}
), akkor ki kell töltenem a fordítás értékeit is, ha normális kimenetet szeretnék látni már tesztelés alatt is, - a függvény nagy valószínűséggel végrehajt egy lekérdezést (ha százszor használjuk egy oldal megjelenítésekor, akkor százat) – talán ez az amiért a leginkább unszimpatikus.
Ilyen gyötrelmek között próbáltam létrehozni valami olyan megoldást, ami
- kis terhelést rak a fejlesztő vállára,
- rugalmas,
- adatbázisbarát.
Végül arra jutottam, hogy valamilyen markuppal kell jelölni, hogy mely szövegeket kell lefordítani. Ezeket a kimenetre küldés előtt össze lehet gyűjteni és kicserélni. Jelölő karaktereknek a következő párost választottam: {%
és %}
.
<!-- pelda2.tpl -->
<h1>{% Üdv az oldalon %}</h1>
<ul>
<li><a href="#">{% Belépés %}</li>
<li><a href="#">{% Blog %}</li>
<li><a href="#">{% Kapcsolat %}</li>
</ul>
A példán látszik, hogy nem jelent túl sok plusz munkát egy sablont felkészíteni a többnyelvűségre. Kimenetre küldés előtt pedig szépen összegyűjthetők a lefordítandó kifejezések, használhatjuk az adatbázisban például az md5 hash értéküket keresési kulcsként (persze ha a fordító munkáját is meg akarjuk könnyíteni, nem árt eltárolni az eredeti értékeket is). Ha nem találnák fordítást a szöveghez, akkor egyszerűen elhagyhatjuk a jelölő karaktersorozatokat és értelmes kimenetet látunk.
A markup bővíthető plusz karakterek hozzáadásával, és nyilván felmerülhet még csomó probléma, csak az alapötletet szerettem volna bemutatni, igény esetén szívesen mutatok be részletesebb megoldást.
■
gettext
A te megoldásodban is megvan ugyanez az „overhead”, csak más formában. Ha lefordítod a sablont build során, ezt megkerülheted, de ez az első módszerre is igaz.
Másfelől erre van szabványos, beépített támogatás: a gettext.
Ehhez annyit tennék még
Fordítók
Cpanel vs threadSafe
A doksi is felhívja a figyelmet arra, hogy ez nem thread-safe alkalmazás. Tehát viccess elemek fognak képződni.
Példa:
1, elindul az alkalmazásod. Kap egy default locale-t.
2, beállitasz valamilyen nyelvet a setlocale() parancsal. Ez az egész threadre érvényes
3, elkezded a kiírást.
4, ugyan abban a threadben elindul még egy php alkalmazás. Kap egy default locale-t. Ez az egész threadre érvényes.
5, a scripted a lap alját már hibásan fordítja le.
Nem véletlenül nem használja ezt a módot alapértelmezettként sem a wordpress, sem a drupal.
Gettext overhead
igazabol amennyire latom a
http://framework.zend.com/manual/en/zend.translate.adapter.html
Tyrael
Erre is csak egy egysoros
Hátránya (vagy mégsem?), hogy a magyart is meg kell írni.
Ezt úgy érted, hogy a
Igazából nevezz engem szűk
Azért se nevezlek. ;) Én csak
nem mind1 viszont, hogy
Tyrael
kb ennyi lényegét látom én is a dolognak
igen, en ertettem a
Tyrael
Most épp egy 160 kifejezéses
Értem. Akkor tökéletesen
És a magyar sosem változik?
+1
Valamint ha ugyanarra a
És hát persze a paraméterek,
ha már sablon, akkor a smarty
én ugy csináltam, hogy pl fórum szekcióba teszem ami a fórum.tpl-hez kell majd, és akkor csak azt teszi a memóriába, ami kell a fórumhoz.
minden nyelvhez van egy-egy .conf....
Cache
Nyelvesítés
Ami a szövegeket illeti, szerintem is szimbolikus kulcsokat érdemes használni, különben nagyon könnyen előjön a WTF érzés, amikor egy év múlva elolvasod a sablont és köze nincs a felületen megjelenő szövegekhez.
Nem gátol meg semmi sem
Soha nem fogom megérteni,
"Alkalmazásfejlesztés során felmerülhet az igény arra, hogy a késztermék több nyelven legyen képes megjelenni. Erre a problémára szeretnék most egy egyszerű megoldást bemutatni."
Nem írom le, hogy miért, de szerintem már jónéhány éve (úgy 5-6 minimum) minden, 100 kódsornál hosszabb webalkalmazást illik többnyelvűre csinálni, az egyszerű megoldás amit leírsz az pedig egy csomó nyelvesítési módszerből már ismert, így semmi új nincs benne. De nem kívánok vitatkozni, mindenki csinálja ahogyan jól esik, mindez biztosan csak engem zavart, remélem nem baj, ha van itt egy ilyen vélemény is. :)
Nekem az időmből, energiámból
Elhiszem, hogy létezik olyan nyelvesítési módszer, ami ugyanezt a megoldást használja, én nem ismertem egyet sem, és a weblabor keresőjéből sem jutottam el olyan oldalra, ahol be lenne mutatva.
Írj olyan bejegyzést, amilyet szeretnél olvasni és jobb lesz a világ :)
Hátha megérted
Vannak itt kezdők is.