|
PHP multilanguage web - best practices
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! |
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 :) |
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. |
@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. |
Višejezični sajt
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. |
@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. |
Citat:
Citat:
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... |
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 :) |
Citat:
- ide sve u jednu tabelu - prevod stavljas u kolonu tipa TEXT, a recimo prevodis naslov CHAR(60) |
Citat:
@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: Kôd:
table languages |
Da, kontam poentu, svi prevodi idu u jednu tabelu, samo mi ona jedna tabela nije opravdavala postojanje. Inace, i dalje verujem da je broj 3 bolji, da li sto stare navike tesko umiru sta li je :)
|
Varijanta sa kolonama za svaki jezik mi je malo neprakticna.
Posto sam imao situaciju da treba da se podrzi veci broj jezika, i da to naravno treba da bude sto fleksibilnije, ishao sam na opciju da za svaki jezik imam odvojeno tabelu (content_page_sr, content_page_en, content_page_de), za jedan content item po red u svakoj tabeli, sa zajednickim content id-em (koji je sekvenca i cuva se negde druge i incrementuje po potrebi). Onda prosto uzmem $currentLanguage i mogu da zatrazim SELECT * FROM content_page_$currentLanguage i vozi... Povecan je broj kverija prilikom add/edit-a, ali su to ipak operacije koje imaju mali udeo u celoj prici. YMMV Prednost je u velikoj fleksibilnosti po pitanju broja polja i slicno. Mana je sto prilikom dodavanja novih jezika pored kreiranja tabele treba kreirati i po red za svaki postojeci content item. Sve u svemu, ovo mi se pokazalo kao najbolje resenje do sada. |
Ja stvarno ne vidim ni jednu prednost ovakve strukture (jedino ako bas ima PUNO redova, pa ako je cilj da se izbjegne da stavlja sve u jednu tabelu). Zar ti tabela sa kolonom languange_id ti nije prihvatljivije rješenje?
|
Za potrebe jednog projekta gde je trebalo omogućiti velik broj jezika (10-15) ali gde je procena da većina tekstova neće uopšte biti prevedena izveo sam sledeću varijantu:
Sve varijante (prevode) teksta sam spojio u jedan string, upotrebivši neki "delimiter" koji se ne pojavljuje u normalnom tekstu, dodavši prethodno svakom prevodu dvoslovnu oznaku jezika kao prefiks, i takav string snimio u tabelu, polje tipa longtext, čak u istu tabelu sa ostalim sadržajima stranice, dakle nema posebne tabele za prevode. Pri prikazivanju stranice naravno, dovućiće se iz baze i nepotrebni prevodi, ali kao što rekoh većina sadržaja ima u 1 ili 2 jezika. PHP je taj koji će explode-ovati taj zapis, potražiti ima li ga u traženom jeziku, ako ga nema potražiti ga u "default" jeziku sajta, a ako nema ni takvog prikazati u bilo kojem prevodu. Važno je napomenuti da ne prevedene tekstove uopšte ne snimam u taj zbirni string. Jednostavno ih nema. Takvim pristupom sam dobio jednostavan mysql query, bez join-ovanja i bez kontrolne logike tipa "a ako nema u tom jeziku", ili dupliranja zapisa neprevedenih tekstova. Mislim da sam žrtvujući malo veći transfer dobio na brzini izvršavanja querija. Dodavanje novog jezika ne zahteva nikakvu intervenciju u bazi, jednostavno će stranica prikazati default prevod jer u novom jeziku nema ništa. U situaciji da se očekivalo da će većina tekstova biti prevedena na tih 10+ jezika išao bih na varijatu koja mi se pokazala uspešnom: Kôd:
CREATE TABLE IF NOT EXISTS `multilang_texts` (Kad se edituje tekst u default jeziku, tekst se piše i u sve zapise bez tog flega. Kad se edituje tekst u alternativnom jeziku (prevod), postavlja se taj fleg da se više ne dira. |
Citat:
Redova inace zna da bude puno (mada se i to moze resiti na druge nacine..). Na sta treba paziti kod implementacije language_id kolone: Ako imam language_id kolonu, i dva reda za dva jezika, onda jedan content item nece imati jedan vec 2 id-a (sto iskljucuje mogucnost istog url-a sa prefixom ili poddomenom koji oznacava jezik). Znaci da moram da imam jos jednu kolonu koja sadrzi generisanu sekvencu za svaki content item i koja grupise sve jezike. |
| Vreme je GMT +2. Trenutno vreme je 23:15. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.