PHP multilanguage web - best practices

[mb_sa]

Zdravo!

Čini mi se da nema ovakve teme na DPT-u, a sa obzirom da višejezični sajtovi dosta usložnjavaju razvoj od jednojezicnog sajta počevši od strukture baze, načina prevođenja stringova, SEO i prenos jezika kroz stranice, rad sa template sistemima u slučaju višejezičnog sajta ... mislim da bi ovakve tema bila korisna.

Iako ćemo pričati (nadam se) o svemu (db, seo, php ...) temu sam smjetio u ovu forum kategoriju.

Možda da počnemo sa dizajnom baze.

Kako vi rješavate strukturu baze podataka kod višejezičnih sajtova? Šta vam je najvažnije. Da li ispravan dizajn, jednostavno dodavanje novog jezika, performanse, ... da li pristupate drugacije ako se radi o high load sajtovima, pa ste spremni za neka neškolska rješenja ...

U ovom kratkom tekstu imaju fino opisana 4 pristupa dizajna baze.

U ovom trenutku ja bih se odlučio za pristup pod stavkom 4 (Coupled Translation table approach).

Bio bi zahvalan na vašim komentarima!

[bluesman]

Mislim da je jako bitno da se zna kakav multijezički sajt želiš da praviš. Ono što je sigurno je da sadržaj koji generišu korisnici (postovi, komentari, profili) ne možeš da menjaš čak i kada bi to bilo praktično, znači sve se svodi na to da li je to news / blog site ili je u pitanju neki corporate site, ili šta god.

Kod jedne vrste višejezičkih sajtova ti "prevodiš" samo interface i sistemske poruke, a kod drugih svaki post / vest mora da ide u onoliko verzija koliko jezika postoji. Svi automatski prevodioci su se do sada pokazali neupotrebljivi osim ako ne želiš da se ljudi smeju prevodu

[Milos Vukotic]

Ja sam se praktično vrlo malo srijetao sa situacijama kad je potrebno praviti prevod za svaki tekst, uglavnom se svodi na to da sajt ima sličan ali ipak različit sadržaj na različitim jezicima, zato sam skroz izbacio iz upotrebe koncept "original-prevod" i ostao samo na izboru jezika prilikom unosa.
Dakle, jedna tabela sa jezicima i svaki sadržaj ima svoj language_id, opcija 2 u ovom tekstu što si dao.

[mb_sa]

@bluesman
nije mi bio cilj da govorimo na koji način prevesti tekst i slicno. podrazumijeva se da će se radi dodatni upis u bazu i ručni prevod .

ja govorim recimo o news siteu i kako je najpametnije pristupiti dizajnu baze.

@Milos Vukotic

ova varijnta 2 iz teksta je jako zgodno rješenje jer se stvarno veoma lagano implementira i novi jezik se dodaje sasvim jendostavno.

Ako nema puno kolona koje se ne prevode (pa onda nema ni pretjerano puno duplog sadrzaja), ovo je OK rješenje.

Po meni ovo rješenje ima i nedostatak, a to je kako dobiti sve varijante jednog teksta sa jednim upitom?

Sto znaci da ako u footeru imam linkove 'O nama', 'Kontakt' ... i linkove tipa:

http://domena.com/en/page/about_us
http://domena.com/de/page/uber_uns

http://domena.com/en/page/contact
http://domena.com/de/page/kontakt

moram da unaprijed znam sve slug-ove (ili ids), odnsono da promjenom jezika i znam koji su slug-ovi za taj jezik.

[Croll]

Rešavanju ovog problema treba pristupiti prvenstveno od potrebe klijenta. Kada sam rešavao ovaj problem, meni je najlogičnije bilo da dodam posebnu tabelu jezika i tabelu poruka sistema. Praktično varijanta 2 - Multirow approach.

Da bi to sve malkice zakomplikovao, id jezika sam dodao i u tabelu kategorija. Na ovaj način sam dobio da struktura sajta na svakom jeziku može biti skroz različita od drugog jezika a i broj jezika nije ograničen. Naravno, insistiram da postoji glavni, tj. podrazumevani jezik.

Preko .htaccess-a odradimo rewrite url'a i to je to. Sve adrese su unique, nema dupliciranja sadržaja, dodamo novi jezik kao i poruke sistema na dotičnom ako nam treba neki novi jezik.

Obzirom na to da su poruke sistema uglavnom standardne, ponuda raspoloživih jezika raste bez potrebe za velikim dodatnim radom.

To je neka moja odluka i nisam do sada imao potrebe da menjam ovu logiku iako bih to istog momenta uradio ukoliko bi se pokazalo da klijent ima potrebu koju nije moguće na ovaj način zadovoljiti.

[mb_sa]

@Croll
Stičem dojam da govoris o prevodu statičnih dijelova stranice, tj. stringova. Da li ce se ti prevodi cuvati u tabeli ili u php fajlu u vidu konstanti ili kao arrays, ili će se korstiti gettext nije ono o cemu sam ja poceo diskusiju (mozemo o tome svakako razgovarati), a to je dizajn i struktura baze visejezicnog news sajta.

[ivanhoe]

Originalno napisao mb_sa

ova varijnta 2 iz teksta je jako zgodno rješenje jer se stvarno veoma lagano implementira i novi jezik se dodaje sasvim jendostavno.

Ovo sam ja koristio na par sajtova i fino se pokazalo...

Originalno napisao mb_sa

Po meni ovo rješenje ima i nedostatak, a to je kako dobiti sve varijante jednog teksta sa jednim upitom?

kad se unose tekstovi moraju se oznaciti prevodi (u zasebnoj tabeli povezes), ali to moras ionako da uradis, ovako ili onako, sem da se odjednom unose verzije na svim jezicima sto je neprakticno..

Inace, 3-ka je mnogo bolje resenje od 4-ke, jer nikad ne znas kad ces pored Title i Content sadrzaja dobiti zahtev i za podnaslove, i abstract i jos custom polja...

[DakiPro]

Cao, moze li neko (da ne kazem Ivanhoe ) pojasniti na prakticnom primeru pristup 3, uopste ne mogu da skontam kako se koristi, cenim da se u translation_entry cuvaju svi prevodi za svako polje ponaosob (kao jedan red po polju koje se prevodi) ali ne kontam upotrebu table translation, koja ima samo jedno polje ID.
Ako sam dobro skontao, ovaj pristup mi ima prednosti za dinamicka polja stavki , gde bi se lako dodavali redovi za potreban prevod novo nastalog polja.
Inace licno rabim pristup 4, nemam nesto potrebu da dinamicki dodajem prevodiva polja. Ali kada budem bio, verovatno ce pristup biti slican kao pod 3

[mb_sa]

Originalno napisao ivanhoe

Inace, 3-ka je mnogo bolje resenje od 4-ke, jer nikad ne znas kad ces pored Title i Content sadrzaja dobiti zahtev i za podnaslove, i abstract i jos custom polja...

da, ali meni se ovaj princip ne svidja iz dva razloga:

- ide sve u jednu tabelu
- prevod stavljas u kolonu tipa TEXT, a recimo prevodis naslov CHAR(60)

[ivanhoe]

Originalno napisao mb_sa

- prevod stavljas u kolonu tipa TEXT, a recimo prevodis naslov CHAR(60)

pa i nije to neka bitna razlika... malkice vise prostora zauzme


@DakiPro: i mene je ta translation tabela zbunila, pretpostavljam da je to neka denormalizacija sa idejom da ako ima vise istih prevoda, ne dupliras sadrzaj, nego je translation vezna tabela, ali ja je licno ne bih nikad tako radio... Ali poenta je da imas tabelu sa sadrzajem, u kome cuvas sve prevode, nebitno o kom tipu sadrzaja se radi (naslov, text, itd..). Ja bih to organizovao ovako nekako:

table languages
-- id (int)
-- name (varchar)
--code (char(2))

table pages
-- id (int)
-- language_id (int fk)
-- title (int fk)
-- content (int fk)

table translations
-- id (int)
-- content (text)
-- content_type_id (int fk)

table content_types /* ovo cisto da se olaksa administracija, mozda i ne treba? */
-- id (int)
-- type (varchar)

ovo cisto na brzaka, verovatnomoze i pametnije...