ugrás a tartalomhoz

Több nyelvű honlap készítése

Gully Foyle · 2007. Ápr. 3. (K), 13.54
Sziasztok!

Kétnyelvű honlapot szeretnék készíteni, kétnyelvű adatbázissal. A jelenlegi tudásom – úgy érzem - elegendő az elkészítéséhez, de az optimális módon való elkészítéséhez már szükségem lenne némi útmutatásra. Ha tudtok, kérlek segítsetek az irányelvek terén. Nagyon fontos szempont a későbbi bővíthetőség, a kezdeti kétnyelvű honlapból hosszú távon akár ötnyelvű honlap is lehet.

1. Szerintetek mi a jobb? Nyelvenként külön könyvtárba tenni a honlapokat, vagy minden oldal / aloldal tartalmazzon feltételes elágazásokat és így jelenítse meg a választott nyelven a menüpontokat és a tartalmat. Talán az első módszer áttekinthetőbb lesz hosszútávon…

2. Az adatbázis terén csak a szükséges mezők legyenek többnyelvűek, vagy inkább legyen egy-egy adatbázis minden nyelven? Itt is az első megoldást tartanám jobbnak, és feltöltés szempontjából felhasználóbarátabbnak.

3. Megoldható valahogy, hogy aki a .com-ot hívja be az angolul, míg aki a .hu-t az magyarul lássa a honlapot alap esetben? (Természetesen a két domain név egy tárhelyre mutat.)

Várom a javaslataitokat.
‹ PHP beépített SOAP kliense vs. hibakezelés Program tervezés a gyakorlatban ›
 ■
1

először keress

gex · 2007. Ápr. 3. (K), 14.02
http://weblabor.hu/forumok/temak/1685
http://weblabor.hu/blogmarkok/13736

ha ez nem elég, akkor keress tovább, mert jópárszor felmerült már.
2

Többnyelvű oldal

Max Logan · 2007. Ápr. 3. (K), 14.27
Nekem a céges honlapot és a belső rendszert kell többnyelvűre megcsinálnom. Előszőr az adatbázisos megoldással keztem, aztán rájöttem, hogy nem túl rugalmas és lényegében felesleges bonyolítás. A megoldás nálam az ini file lett, amit parse_ini_file-lal töltök be. Igazából nemtom, hogy menyire sok infó lesz nálad egy adott modulhoz. Ha csökkenteni akarod a betöltést, akkor az egyes modulokhoz (oldal egyes részeihez) tartozó cimkéket külön ini-be teheted és mindig csak a megfelelőt töltöd be (+ az általános dolgokat). Nemtom, hogy mennyire dobja meg a terhelést, ha csak egy ini file van és minden oldaltöltésnél betöltődik a teljes nyelvi csomag. Az ini file-os megoldás előnye, hogy sokkal könnyebb egy új nyelvi csomagot hozzátenni az oldalhoz. Nálam indulásnál lesz 3-4 nyelv és az idők folyamán ez folyamatosan bővülni fog.

A tmával kapcsolatban a tutorial.hu-n publikáltam egy automatikus (és manuális) nyelvválasztást megvalósító scriptet, amit aztán BlackY kicsit kiegészített (időközben én is rájöttem azon dolgokra, amit BlackY kifogásolt a script-emben és ha lesz időm írok egy javított változatot - bár BalckY megoldása nem rossz, nekem nem fekszik és nem egészen úgy használom a modul-t ahogy ő leírja ...)
3

inkább darabolni

amonrpg · 2007. Ápr. 4. (Sze), 22.11
Én javaslom mindig darabolni a nyelvi fájlokat. Mégpedig azért, mert az include általában kisebb költségű időben, mint amennyi memóriát elvisz a felesleges stringek tárolása.

Ha szerkeszthetővé akarod tenni a nyelveket, én azt javaslom, hogy szerezz be egy xml2array és egy array2xml function-párost, és írj hozzá parsert. Mármint XML-ben töltheti fel a user a nyelvi fájl, és beparsolod include-olható php-vá. Aztán az XML kezeléséhez meg írhatsz egyszerű programot, ha akarsz, amit aztán N+1 projektben használhatsz. Én éppen efelé nézelődök. Ehhez meg akár desktop alkalmazást is lehet csinálni, mert XML-t szinte minden programnyelvben egyszerűen lehet kezelni.
4

Re

Max Logan · 2007. Ápr. 4. (Sze), 23.22
XML2Array és Array2XML függvények alatt pontosan mit értesz? A mostani céges belső rendszerben XML-ben kommunikálok az SAP-val szóval már van olyan függvény, ami tömböt csinál egy XML doksiból. Akkor azt mondod, hogy csináljak egy olyan parser-t ami az XML file-ból csinál egy PHP-t, amiben gyakorlatilag tömbben vannak már a cimkék és ezt include-oljam?

Egyébként most hogy XML-ben kell fogadni és küldeni az adatokat a jelenlegi munkámnál nagyon rákattantam a dologra, főként az általad is említett platformfüggetlen adattárolás miatt.
5

többnyelvű weblapon link

zaum · 2008. Május. 28. (Sze), 16.19
egy többnyelvű weblapon dolgozom, amiben külön mappában vannak a nyelvek, logikusan a css-t, képeket stb., ami ugyanaz ezeken a mappákon kívül (felül) helyezném el. Local-ban remekül működik a "../img/akarmi.gif" forma, de ha feltöltöm már nem jó! nincs jogosultságom? vagy mi lehet a baj?
6

typo3 ezt az alábbi módon kezeli

Matyi Gábor · 2008. Május. 28. (Sze), 16.30
a nézd meg a www.typo3cafe.hu oldalt, ez most három nyelvet kezel. Alapjáva véve úgy működik, hogy ugye az index.php?id=10 mondjuk a 10-es oldal, aminek lehetnek fordításai. Ezek index.php?id=10&L=1 v. index.php?id=10&L=2 -ként tölthetőek be, ennek megfelelően is tárolódik le az adatbázisban. Ezzel a megoldással tetszőleges oldalról át lehet menni a más nyelvű oldalra. A menü megjelenítésekor az le van programozva, hogy az az oldal, aminek nincs fordítása, az a menüpont ne jelenjen meg. Persze úgy is megcsinálhatod, hogy külön oldalstruktúrát csinálsz az egyes nyelveknek, de szerintem az úgy bonyolultabb.
Azt, hogy mindezt a saját rendszeredben miként valósítod meg, az a te dolgod...
7

köszi

zaum · 2008. Május. 28. (Sze), 21.36
de nekem csak egy szimpla html megoldás kellene, egyszerűen nem megy a ".." felfele linkelés
8

gyorsítótár

blabla · 2009. Nov. 10. (K), 09.50
Sziasztok

A kérdésem annyi hogy megéri-e fordítói gyorstárat (pl APC) használni a nyelvi file-ok alkalmazásánál? Eddig a nyelvválasztáshoz a nyelvi file-ok alkalmazását ismertem, amelynek beemelése sima pl. include(hungarian.php) hívással történik és ahol a hungarian.php fileban define-nal vannak meghatározva az adott stringek. Schlossnagle könyvében (PHP fejlesztése felsôfokon) azt ajánlja hogy define helyett konstans osztályállandókban tároljuk a globális változókat.

A weboldal nem nagy forgalmú, hobbi oldal.

köszönöm a válaszokat elôre is
bla
9

Szerintem

gphilip · 2009. Nov. 10. (K), 12.39
Hali!

Nagy forgalmú oldalaknál érdemes bevezetni Gettextet vagy hasonló megoldást, ilyenkor viszont szinte kötelező saját blokk függvényt Írni Smarty-hoz, ha azt használsz. Így igazán kényelmes a dolog szerintem. Ráadásul a forgÍtó motort is könnyedén cserélgetheted Így...

Képzelj el egy ilyen sort Smarty-ban:
<body>{trans 1=$num_latogat}Köszöntjük oldalunkon! Ön a $1. látogató.{/trans}</body>


Igazán egyszerű, nemde? Még a nyelvet sem kell kiválasztanod, mert azt is a függvényed választja ki mondjuk a subdomain alapján vagy a Gettext konfigja alapján.

Különben szerintem ha a Redis elterjed, kiváló eszköz lesz fordÍtások tárolására és visszatérÍtésére.
10

+1

fchris82 · 2009. Nov. 10. (K), 14.32
Én is hasonlóan oldottam meg a dolgot még úgy 5 éve egy projektnél. Csak én kicsit beszédesebben. Ha már smarty:
<p>{t name=$name}Hello %name%!{/t}</p>
Ha kódban kell fordítani, akkor pedig (pl hibaüzeneteknél):
$msg = t('Hello %name%!', array('name'=>$name));
Van egy adatbázis a háttérben, ami automatikusan gyűjti a "mintákat". A fordítók az admin felületen keresztül látják, hogy mit kell lefordítani. Bevezettem még egy __version__ és egy __comment__ "változót", ami kétértelmű esetben jön jól:
<li>{t __version__="address" __comment__="A lakcímét kell megadnia"}Cím{/t}: <input type="text" name="address" /></li>
...
<li>{t __version__="title" __comment__="A cikk címét kell itt megadni."}Cím{/t}: <input type="text" name="title" /></li>
Így nem kell kismillió konstanst fejben tartani, csak azt, hogy milyen versionök vannak, amiből meg elég kevés van, mert mondjuk lakcím esetén inkább kiírom, hogy "Lakcím". Az adatbázis magától hízik. Ezzel a megoldással az alábbi problémák lehetnek:
- ha vmi apróbb szöveg változik, vagy helyesírási hiba került javításra, akkor a fordítóknak többször le kell fordítani ugyanazt vagy hasonlót
- a fordítás lassan megy, mert nem az van, hogy egy szöveges fájlt kell szerkeszteni, hanem folyamatosan kattintgatni kell az admin felületen, majd beírni a fordítást (ezen lehetne segíteni, ha írnék egy import/export funkciót, de annyira nem volt sok a fordítandó, hogy ezzel érdemes legyen bajlódni)

A hibaüzenetek fordítása szokott még gondot okozni, de amióta van __comment__ lehetőség, azzal se nagyon volt gond. A fordítók munkáját segíti:
- __comment__ -ben megadott szöveg
- készül "mentés" arról az oldalról, ahol először előfordult az adott szöveg, és ezt egy kattintással betölthetik.
- láthatják, hogy a többi nyelvre a másik fordító hogyan fordította le. Ez abban az esetben jön jól, amikor pl magyarul nagyjából tudó, de orosz ember fordít nekünk oroszra, aki tud angolul is. Amióta ez bevezetésre került, még egyszer sem írt, hogy nem egészen érti, mit is akarunk ott "mondani".