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

DevProTalk (http://www.devprotalk.com/index.php)
-   Planiranje i usability (http://www.devprotalk.com/forumdisplay.php?f=35)
-   -   O cemu treba voditi racuna, visejezicni sajt sa bazom itd. (http://www.devprotalk.com/showthread.php?t=439)

[nq] 18. 12. 2005. 00:44
O cemu treba voditi racuna, visejezicni sajt sa bazom itd.
 
O cemu treba voditi racuna prilikom izrade sajta sa bazom podataka, da bi se lakse mogao dobiti visejezicni sajt ? U pitanju su makar 3 jezika i vise.

Znaci ako ima neko neka iskustva nek podeli sa nama.

Hvala. :)

nixa 18. 12. 2005. 01:55
Lang file za svaki jezik zasebno kod cms-a ,tako da je za taj deo,a u administraciji moze da se isto resi :)

DejanVesic 18. 12. 2005. 09:13
Citat:
Originalno napisao [nq]
O cemu treba voditi racuna prilikom izrade sajta sa bazom podataka, da bi se lakse mogao dobiti visejezicni sajt ? U pitanju su makar 3 jezika i vise.

Znaci ako ima neko neka iskustva nek podeli sa nama.

Hvala. :)
Za statički deo sajta (stranice), nekoliko varijanti:

- UTF8 je obavezan za kodiranje stranica
- fraze se čitaju iz resurs fajla za izabrani jezik
- fraze se čitaju iz baze, uz OBAVEZNO keširanje prilikom prvog čitanja (preporučujem onda prilikom podizanja sajta puštanje spajdera preko celog sajta koji će ga obići i ukeširati sve što treba, da to ne bi radio prvi posetilac)

Za dinamički deo sajta:

- baza; UTF8 kodiranje u bazi
- najbolje je napraviti Dictionary šemu koja radi prevođenje i nju puniti, bez povezivanja sa ostatkom biznis logike; posle se lako (sa sve frazama da iskoristiti na drugim projektima)

Generalno:

- obratiti pažnju na formate datuma
- obratiti pažnju na formate brojeva
- obratiti pažnju na formate zapisa novca
- ako treba da podržiš right 2 left jezike, obrati pažnju kako to hendluje svaki browser (IE opet ima nasty bagove tu).

Preporuka:

- neka ti glavni development sajt bude u DRUGOM jeziku (mi smo radili na ćirilici) - tako ćeš odmah videti nedostatke trenutne faze razvoja (šta nije prevedeno, gde ima problema itd)

Primeri:
(više detalja za RTL kod IE imate ovde: http://www.aplus.co.yu/css/direction...layouts-in-ie/ )

dinke 18. 12. 2005. 12:00
Jedna reč - gettext :)

Koristili smo ga na sitebuilderu koji je do sada preveden na tri jezika. U najkraćem, Gettext ti omogućava da za sve 'output' pozive tipa echo "foo" koristis echo _("foo") čime će reč 'foo' outomatski biti prikazana na odabranom jeziku. Vidi gornji link kao i gettext manual za više informacija.

Gettext je dobar za kraće fraze. Za database driven sajtove (poput ovog gore koji sam naveo) duže rečenice treba čuvati u bazi za svaki jezik pojedinačno.

[nq] 18. 12. 2005. 23:32
@ Svi
Zaista odlicne smernice, mnogo stvari o kojima treba razmisliti, Hvala Vam.

@Dejan,
U pitanju je 3 jezicni sajt, nema R2L, o ovome nisam cak ni razmisljao.
Hvala na odlicnom postu. :)

oliver78 19. 12. 2005. 01:05
Citat:
Originalno napisao DejanVesic
- fraze se čitaju iz baze, uz OBAVEZNO keširanje prilikom prvog čitanja (preporučujem onda prilikom podizanja sajta puštanje spajdera preko celog sajta koji će ga obići i ukeširati sve što treba, da to ne bi radio prvi posetilac)
Moze li malo vise o ovome. Spider?
Kako raditi kesiranje?

ivanhoe 19. 12. 2005. 03:45
mislim da je gettext i malo jednostavne logike primenjene na include fajlove bolje nego guranje texta u bazu, imaces manje dodatnog posla i bolje perfomanse...naravno ovo se odnosi na obicne sajtove, ako pravis CMS koji textove cuva u bazi onda je logicno da ce i prevodi biti tamo...

K'o sto Dinke rece gettext je odlican za textove menija, razne kratke poruke i slicno, jer automatizuje pravljenje language fajlova. Kao sto je vec receno koristis __() funkciju da prikazes text neke poruke, ali glavna prednost ovog pristupa je sto ti kad zavrsis pravljenje strane na default jeziku, pomocu jedne skripte automatski mozes da iscupas sav text svih poruka jer se nalazi u __('..'). Taj skript ti kreira language fajl koji ti lepo spakujes i posaljes prevodiocu na prevodjenje. On to prevede zadrzavsi isti format fajl, ti njegov prevod snimis gde treba i automatski imas poruke na novom jeziku na raspolaganju prostom promenom local setovanja. Nema zezanja da ti rucno svaku poruku unosis u bazu ili tako nesto... ako izmenis neku stranu, samo ponovo pustis batch da pokupi izmene, prevedes ih i to je to...

za vece komade texta je naravno prakticnije odraditi ceo templejt na drugom jeziku, snimiti sve templejte za taj jezik u zaseban dir, i onda kad include-ujes templejt samo kazes:
include(JEZIK_DIR . 'ime_templejta');

gde je JEZIK_DIR putanja direktorijuma za trenutni jezik... ovo je ultra brzo resenje, i vrlo prosto za odrzavanje i rad na prevodjenju...

Istom logikom mozes da odradis i include funkcija koje zavise od jezika, tipa formatiranje datuma, novca i slicno... Naprosto napravis za svaki jezik po jednu biblioteku takvih funkcija i inkludujes ih na isti nacin kao i templejte... Ukoliko se funkcije nece menjati u buducnosti (a posto su takve funkcije obicno vrlo proste, najverovatnije da nece), ovo je mnogo cisce resenje (i malko brze) nego gomila switch-case-ova koji proveravaju trenutni jezik unutar svake bozije funkcije...

zextra 19. 12. 2005. 22:06
kad smo vec kod templejtova i prevodjenja, sigurno je svakom ko je malo detaljnije citao smarty manual zapao za oko primer upotrebe register_block funkcije u sluzbi pravljenja multi-language sajta.

http://smarty.php.net/manual/en/api.register.block.php

naravno, nije tesko eliminisati onaj deo lang="br" iz template-a, i raditi to u samom kodu, a zavisno od jezika, menjati cache_id parametre u odgovarajucim funkcijama, da bi se za svaki jezik keshirala odgovarajuca verzija templejta... malo sam sad nabacao postupak, ali koga interesuje, lako ce saznati kako to moze da se uradi - smarty manual je dosta dobro napisan.

slicno tome, na primer, moze da se registruje funkcija za prikazivanje lokalizovanih podataka. primer:
Kôd:
Cena: {localize type="currency" value=$cena},
datum: {localize type="date" value=$unix_timestamp}
naravno, opet postoji ona pro&contra polemika, ali ako moze bez toga ovaj put :) zadrzimo se na funkcionalnosti...

DejanVesic 22. 12. 2005. 11:34
Citat:
Originalno napisao oliver78
Moze li malo vise o ovome. Spider?
Kako raditi kesiranje?
Vrlo zavisno od tehnologije:

- globalna struktura unutar web aplikacije koja obavlja:

1. Da li je ova fraza tražena ranije?
1.1 Ne - dohvati iz baze, stavi u lokalni keš, vrati rezultat
1.2 Da -dohvati iz keša vrati rezultat.

Ovo može da bude i poseban proces u okviru iste mašine.

Spajder - ako se ovo radi strana po strana, pustiš bilo koji spider proces koji obiđe ceo sajt i obavi inicijalno keširanje za statičke stranice i prevode na njima.

ivanhoe 23. 12. 2005. 03:34
samo jos jedna mala primedba oko kesha, keshiranje apsolutno svake strane sajta je retko isplativo, ima nekih strana koje ce retko ili nikad biti posecene, i bezveze ce da zauzimaju prostor u keshu... a nije zauzece najveci problem, nego sto veliki kesh nuzno znaci i sporiji kes...

zato se obicno keshevi rade tako da imaju neku logiku kojom brisu podatke posle nekog vremena, obicno se koriste LRU (least recently used - brise stranicu koja je posecena najdavnije), FIFO (first in first out - brise stranice redom kojim su stavljane, obicno putem vremenskog limita) ili random izbor podatka za brisanje.. svaka logika ima neku svoju prednost, a zanimljivo je da random brisanje nije uopste lose resenje po efektima...


Vreme je GMT +2. Trenutno vreme je 18:11.
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.