DevProTalk
Strana 1 od 2 1 2 >
Prikažite 40 poruka iz ove teme na jednoj stani

DevProTalk (http://www.devprotalk.com/index.php)
-   PHP (http://www.devprotalk.com/forumdisplay.php?f=9)
-   -   PHP multilanguage web - best practices (http://www.devprotalk.com/showthread.php?t=8014)

mb_sa 26. 10. 2009. 09:06
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!

bluesman 26. 10. 2009. 12:52
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 26. 10. 2009. 13:21
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 26. 10. 2009. 13:39
@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 26. 10. 2009. 14:03
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.

mb_sa 26. 10. 2009. 15:22
@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 26. 10. 2009. 16:02
Citat:
Originalno napisao mb_sa (Napišite 74914)
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...

Citat:
Originalno napisao mb_sa (Napišite 74914)
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 27. 10. 2009. 09:24
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 27. 10. 2009. 09:53
Citat:
Originalno napisao ivanhoe (Napišite 74921)
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 27. 10. 2009. 23:27
Citat:
Originalno napisao mb_sa (Napišite 74938)
- 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:
Kôd:
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...


Vreme je GMT +2. Trenutno vreme je 08:17.
Strana 1 od 2 1 2 >
Prikažite 40 poruka iz ove teme na jednoj stani

Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.