|
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:11. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.