Multilanguage web site


#21

Primjera radi, evo kako se fino može prevesti neki array koji je sačinjen od više kratkih riječi:

imeMjeseci=[{{'Siječanj','Veljača','Ožujak','Travanj','Svibanj','Lipanj','Srpanj','Kolovoz','Rujan','Listopad','Studeni','Prosinac'}}];
imeDanaSkraceno=[{{'Pon','Uto','Sri','Čet','Pet','Sub','Ned'}}];  

Zanimljivo je primjetiti da ove vitičaste u ovom slučaju izlaze izvan pravila sintakse programskog jezika. Ovdje je slučaj o JS-u, isto bi bilo da je i neki drugi jezik… no kako ova skriptu neće direktno parirati JS parser, na grešku se nitko neće buniti…i ovo postaje valid sintaksa.

Ono što će administrator dobiti iz ovoga je:
‘Siječanj’,‘Veljača’,‘Ožujak’,‘Travanj’,‘Svibanj’, ‘Lipanj’,‘Srpanj’,‘Kolovoz’,‘Rujan’,‘Listopad’,‘St udeni’,‘Prosinac’
‘Pon’,‘Uto’,‘Sri’,‘Čet’,‘Pet’,‘Sub’,‘Ned’

…što ispadne puno elegantnije nego da je sve rascjepkano. Kod kodiranja također ispadne jednostavnija sintaksa da se array ubaci u duple vitičaste, nego da se svaki item arraya mora provlačiti kroz funkciju…

Uglavnom, za sad prednosti ovog pristupa pršte na sve strane :slight_smile: …dok ozbiljniju manu još nisam sreo.


#22

Daj kod na uvid :wink:


#23

Kad velim manu, mislim na manu u pristupu rješenju problema. S čime kod nema veze… Sve da i nađeš neki propust u kodu, to nebi značilo da je pristup loš. A pristup možeš kritizirati čisto na logičkoj razini, nema potrebe da se gleda u implementaciju rješenja.

Jedino ako te kod zanima jer:
a. želiš vidjeti kako je stvar napravljena.
b. želiš iz koda razumjeti nešto što nisam dobro objasnio

Za a. ću te morati razočarati, ne da mi se iz više razloga.
za b. pitaj što te zanima…pojasnit ću.
Ako postoji c. reci.


Najbolji način za višejezičnu web stranicu
#24

Mane tvog rješenja ovako na prvu:

  1. prevodi jedan te isti string uvijek iznova
  2. sporost
  3. administracija
  1. recimo da imaš 10 fajlova i svaki file sadrži {{string1}} {{string2}} {{string3}},
    što na kraju dobiješ? Dobiješ 10 fajlova prijevoda koji sadrže jednu te istu stvar, a ti ih 10 puta moraš prevesti i to samo za jedan jezik, sad zamisli da imaš site sa 10 jezika :wink:

  2. mora da je ultra fast parsirati sve te filove i tražiti određeni string u njima, kad se isto moglo riješiti bez toga. Da, da, ti to keširaš na kraju znam.

  3. kako prevodiš sve to? Vidim spominješ admin dio gdje se prevodi, al na koji način?
    Da li se ponavlja ista stvar kao i s fajlovima pod 1. da prevodiš uvijek iznova jedan te isti string?

Prijevod preko fajlova mogu i moraju biti zgodno riješenje, iz svega navedenog ovo tvoje to definitivno nije.


#25
  1. Nebitno.
    Istina…dobiješ 10 fileova (svaki će biti preveden). Ali kao što sam objasnio, to po ničemu nije mana. Nek su fileovi redom prosječno 20kb, to znači da će na serveru otići 200kb zbog prevedenih fileova, i to je to. Ako prevodiš na deset jezika, to je 2MB prostora na serveru, drugim riječima jedna slika. Ovo je minus samo u teoriji, ali u praksi ne vidim kako ovo može stvarati ikakav problem. Može se samo eto samo tako navesti kao mana, no onda treba biti svakako svjestan koje benefite dobivamo uz ovako nebitnu manu. Pa nebitna mana postaje još nebitnija… Da ode 1GB na to, i dalje bi bilo nebitno, ako projekt ima bazu podataka od neznam koliko GB-a. A normalan red veličine je da će otići nekoliko MB-a.

  2. Nikakva sporost, objasnio već više puta. Dobiješ na brzini!
    Proces prevođenja file-ova se desi kao lokalni proces, može se promatrati kao svojevrsna instalacija…koja naravno, ne utječe nikako na brzinu online rada. Osim što je brži online rad ovom metodom, nego da se prijevodi čupaju iz baze kod isporuke web-a.

Ako baš želiš lokalno imati updejtan prijevod na svaki load, neće ni to biti sporo. Jer ako uključim tu opciju, sistem ne prevodi svaki puta sve fileove…nego samo one na kojima se nešto mijenjalo/radilo od zadnjeg loada. Tako da u principu pred load, prevede samo jedan-dva filea, što opet dođe neosjetno.

Admin naravno neće morati prevoditi više puta jedan te isti string! Štoviše, i neki različiti stringovi će se pojaviti u administraciji kao jedan string, npr stringovi:
{{Registracija}}
{{REGISTRACIJA}}
{{Registracija:}}
{{…registracija…}}

Znači, sistem će samostalno brinuti o interpukcijskim znakovima prije poslije, o velikom malom slovu. Administrator sve prevodi na lowercase, a kasnije se prijevod vrati u izvorno stanje koje može biti: lowercase, uppercase, capitalize.
Jedino ako je string bio recimo:
{{reGisTracija}} …onda će se točno takav naći u administraciji, i kod povratka će se poštivati veliko/malo slovo onakvo kakvo je administrator zadao u prijevodu.
Što se tiče interpukcijskih znakova, sistem pazi i na to, makar u codeu se interpukcija ne mora omeđiti vitičastim zagradama, pa bi problem i tako bio rješen.
Samo bolje izgleda {{Registracija:}} , nego {{Registracija}}:
…čisto da se vizualno može bolje vidjeti što je dio nekog izraza.

Administracija osim toga ima opciju i komentiranja svakog prijevoda, gdje se kroz komentare može raspravljati o nekom izrazu, ostaviti dodatne upute za administratore koji će prevoditi.
Izrazi za prevođenje se mogu grupirati po kategorijama, tako da mogu nekome linkati samo određenu grupu koju treba prevesti.
Main admini se mogu subscribat na novi komentar u sistemu prevođenja, onda dobiju mail/notifikaciju ako je neki lower admin upitao nešto o nekom stringu za prijevod putem komentara. Naravno, ako je admin sudjelovao već u komentarima, onda se nije morao subscribeat…dobit će notifikaciju po principu facebooka: “Netko je komentirao objavu koju ste i vi komentirali”
Dodao sam i Googlov Translate API, tako da je moguće prevoditi i automatski pomoću Google Translatea, koji sugerira prijevod.
Ako već postoji prijevod na engleski, onda recimo Neki njemac može prevoditi sa engleskog na Njemački…ne mora nužno izvorno čitati ono što je u source-code-u.
Ako se recimo prevodi sa source-code -> Hrvatski, onda dobijemo lektoriranje (Pod pretpostavkom da je source code pisan na hrvatskom)

…i tako, administracija je već vrlo dobro posložena. A najdivnije je što taj razvoj nikad ne mora stati. Uvijek se može nadograditi ono što se ukaže potrebnim.

Nešto malo sam i sintaksu proširio:


…a to je isto bitno primjetiti, da razvoj sintakse je također unlimited. Po potrebi se mogu mnoge kerefeke dodati koje će se moći pisati u sklopu vitičastih zagrada, a koje će preprocesor razumjeti.


#26

Pod manu nisam mislio koliko prostora zauzima na disku (u tvom slučaju i to je mana) već da se jedan te isti string nalazi u svim tim fajlovima u kojem se nalaze prijevodi, plus taj string još moraš učitati i parsirati iako je to već napravljeno nebrojeno puta. Ali kako ti kažeš to je nebitno i nije mana. :joy:

[quote=“bozoou, post:25, topic:29123”]
Nikakva sporost, objasnio već više puta. Dobiješ na brzini![/quote]
Yeah right !

Hm… znači u administraciji se nalazi/prevodi jedan string, a u prijevodima ih ima na stotine/tisuće tih istih stringova ? Kako to?


#27

…zvuči kao da neki dio koncepta nisi shvatio, a ja ne kužim koji dio.Ne pronalazim smisao u ovome što si gore napisao…

…Ovo pak potvrđuje da ti neki dio koncepta nije jasan. Ako ne vjeruješ da se dobije na brzini, specifiziraj na kojem djelu misliš da se gubi na brzini?
A kada kažem da se dobije na brzini, mislim da se dobije u odnosu na metodu prevođenja koja će prevoditi tako da su izrazi za prevođenje provučeni kroz neku funkciju, koja će čupati prevode iz baze…

  1. Preprocesor, pronalazi tagirane izraze u vitičastim zagradama
  2. Generira ID izraza, (koji zovem dictID), koji je neovisan o tome jeli izraz lowercase, uppercase, capitalize. Također dictID je neovisan o interpukcijskim znakovima prije/poslije. Znači, ako imamo:
    {{Registracija}}
    {{REGISTRACIJA}}
    {{Registracija:}}
    {{…registracija…}}
    …samo izraz “registracija” će biti ključ za kreiranje dictID-a, no preprocesor uz dictID pamti i format izraza iz kojega je uzeo dictID, tako će recimo za izraz “REGISTRACIJA:”, format biti “u||:” …ako format razbijemo po |, dobijemo dijelove koji označavaju:
    [1] : u -> uppercase
    [2] : -> interpunkcija prije (null)
    [3] : : -> interpukcija kasnije (dvotočka)

Kod updejtanja ponuđenih izraza za prevođenje u bazi, preprocesor samo izraz “registracija” šalje u administraciju na prevođenje. Zato se tamo neće naći duplići.

Kod prevođenja, preprocesor uzima prijevod samo za dobiveni dictID, koji je vezan samo uz normaliziran izraz “registracija”. Kada iz baze dobije prijevod “registration”, onda će pomoću formata rekonstuirati taj prijevod u izraz koji se zapravo prevodi. Jednostavno će vratiti prevedeni izraz u lowercase/upercase/capitalize…i vratit će interpunkciju prije/poslije…tako da u konačnici za ovaj slučaj dobijemo “REGISTRATION:”

Zapravo, stvar je vrlo jednostavna: “Uzmi, normaliziraj, prevedi normalizirano, vrati prijevod u stanje iz kojeg je normaliziran source”


#28

Po svemu onome što si napisao u ovoj temi, mislim da nisam ništa krivo skužio, dapače. Jednostavno iz svega toga ne mogu zaključiti ništa drugo nego da je tvoje rješenje ovog “problema” jako loše realizirano.

Jasno mi je da ne želiš dati kod na uvid, uostalom zašto bi ga i dao, ali ako si već osjetio potrebu “podijeliti” svoje rješenje s nama, mogao si ga priložiti. Mislim da bi dobio puno “više”, bar u komentarima. :wink:


#29

…gore je pitanje. Nema li odgovora na isto, sve tvoje upise smatram trolanjem…
Jer kritike ti nisu na nekom nivou, a onda ako ih još ne želiš elaborirati, ne mogu te drugačije shvatiti…nego kao pokušaj trolanja.


#30

Stvarno misliš da se parsiranjem fajlova i traženjem određenih stringova u njemu dobiva na brzini ?
Ako da, ne znam tko je trol :wink:


#31

Što tebi znači dobivanje na brzini?
Meni znači: “Brzina kojom server može isporučiti web stranicu prema clientu”

Ako se slažemo oko gornje izjave…onda možemo dalje.
Ako smo to ustanovili (ili možda nismo? …drugačije poimaš brzinu?) …onda ovo nema nikakvog utjecaja na brzinu, pošto nikako ne utječe na server. Sve parsiranje se desi lokalno.
Može se naravno trigirati i online, no to je onda jednokratan proces…koji opet ne utječe na brzinu kojom će server isporučivati web. Jednokratno će se odraditi instalacija i to je to.

Zašto kažem da ovo čak ubrzava isporuku weba, ako gore kažem da nikako ne utječe na brzinu.
Ubrzava zbog toga jer nakon što se odradi ta jednokratna instalacija, stvorili smo okruženje serveru u kojem može brže isporučiti web nego za situaciju gdje bi prijevode direktno čupali iz baze.


#32

Možda sam ostao malo nedorečen. Nisam mislio da ti ne valja koncept, već realizacija istog.

Tvoje rješenje radi na način da:

include ML_getFile($filePath)

  • učitava fajl koji želimo prevesti,
  • zatim učitava prijevod za taj fajl koji želimo prevesti
  • parsira fajl koji želimo prevesti tražeći tag {{nešto}}
  • ako nađe tag {{nešto}}, zamjenjuje taj tag s učitanim prijevodom za taj tag

Jel tako? Kad ovo utvrdimo idemo dalje na ostalo


#33

Sve krivo, a to sam objasnio već više puta…i pogledaj bolje, vidjet ćeš kako radi. Sad ne stignem dati objašnjenje…žurim.
Ukratko. ml_getFile()
-dohvaća prevedeni file (ako postoji)
-a ako ne postoji prevedeni file, znači da traženi file niti nema inačicu prijevoda, (nema očito ništa tagirano vitičastim unutar sebe) te vraća njegov osnovni oblik.


#34

Hm… da, sad tek vidim. :slight_smile:

OK; Znači ti parsiraš sve fajlove projekta u potrazi za tagovima ? I ako nađeš te tagove, te iste fajlove prevodiš i spremaš?

Nakon ovoga moram priznati da je moje mišljenje o ovome još i lošije :slight_smile: nhf


#35

Tako je. Nadam se da ne moram ponavljati da je to jednokratan proces koji možemo promatrati kao “instalaciju”.

Nadam se da svoje mišljenje možeš potkrijepiti i nekim činjenicama/argumentima?


#36

Prvo da se ispravim, ne valja ti koncept ni realizacija istog.

Parsiranje i kopiranje cijele programske logike u kojoj se nalaze tagovi za svaki jezik u svrhu prijevoda mi nema smisla. Tvoje rješenje podrazumijeva da ako imam web stranicu na 10 jezika i ako svaki file sadrži barem jedan tag moram imati 10 sajtova na disku, i to ne samo predloške, već i cijelu programsku logiku.

I šta na kraju dobiješ? Dobiješ to da si cijelu aplikaciju podredio čemu? Prijevodu?! Ma daj nemoj me… volio bi vidjeti malo veće projekte s integriranim tvojim “rješenjem”. Naravno, što god da ti kažem ti ćeš opet tupiti po svom, tako da nema smisla raspravljati dalje o ovome.

Kolege su ti dale odlične linkove na neka opće prihvaćena rješenja, umjesto da ih malo “pogledaš” ti izmišljaš toplu vodu, i to radiš krivo.


#37

Aham, argument je da tebi nema smisla? Može li točno detalj čime to tvoje “nema smisla” šteti u izradi i isporuci weba? Jer jedino o tome je riječ!

Ovo što si opet iznova zaključio, nakon što su ti sve ostale barke potonule…da će neke skripte biti multiplicirane…samo po sebi nije big deal. I to sam također objasnio više puta. Pa ako već ideš u tom smjeru, daj i konkretno koja je problematika oko toga. “Nema mi smisla” nije argument.

A nema ti smisla ni raspravljati? Zašto? Zato jer ja kao negiram neku očitu manu koja je potkrijepljena činjenicama?

Ja ne bježim od kritika, štoviše dobre kritike volim čuti. Ali reći “Nema mi smisla” nije kritika. Za svaku manu se mora točno znati čime degradira projekt, tek tada možemo vagnuti prednosti i mane i donesti konačan sud.
A ja kad ću vagati mane i prednosti ne mogu razmišljati na način: “Multipliciranje skripti nije dobro jer korisniku aee to nema smisla”

Plus na sve to, developer ovim pristupom nije primoran da neki file bude preveden zbog jednog taga…jer uvijek po želji može tagirano držati u separiranom fileu, od kuda će čupati izraze. Što pokazuje da ova metoda omogućava i takav pristup i puno više od toga pristupa.
No bez obzira i na tu mogućnost… i dalje stojim iza toga da je automatsko prevođenje/multipliciranje jedino memorijski dodatak na projekt, gdje je dodatni utrošak memorije zanemariv. Pogotovo zanemariv ako se poredi sa prednostima koje nudi ovakav pristup.


#38

Ne možeš iskoristiti neki od već postoječih JS templating engina, npr.

https://mozilla.github.io/nunjucks/templating.html
http://handlebarsjs.com/
http://mustache.github.io/


#39

Pa iskreno, kao što sam već napisao gore…bacio sam se u kratku potragu za gotovim rješenjem koje ću koristiti. Par opširnih tema na stackoverflowu mi nije ukazalo na niti jedno rješenje koje mi se svidilo. Dali je iza toga postojalo neko rješenje koje bi mi bilo ocke, to trenutno ne znam…jer nisam dalje tragao.
A sada, prošla baba s kolačima :slight_smile: S ovim što imam, ja sam prekomjerno zadovoljan. I nemam zaista ništa protiv čuti dobre kritike, da vidim što se još može unaprijediti i na što bi se eventualno trebalo paziti i staviti u fokus. A o tome je trenutno jedino riječ…

A neda mi se sada niti proučavati neka druga rješenja. Ako ima neki zanimljiv pristup koji se koristi u nekim od tih rješenja, ne vidim problem da se u kratkim crtama taj pristup prezentira ovdje. Barem usporedba prednosti/mana sa prednostima/manama moga rješenja.

Sad opet žurim, ali čim se vratim složit ću jednu tablicu po kojoj će se moći usporediti dva sistema. Gdje će tablica znači sadržavati prednosti/mane sustava prevođenja. Za početak moga…
Ali smisao će biti da se polja tablice prošire sa prednostima/manama koje nudi neki sistem, koji ne postoje u ostalim sistemima. Tako će se dobiti polja po kojima se mogu uspoređivati dva sistema…i polja koja će ukazivati na jedinstvenost prednosti/mana nekog N sistema. Čisto da se u isti skup stave i prednosti koje nudi neki N sistem. Jer nije isto razmatrati neku sitnu manu koja postoji bez razloga…i koja postoji zato jer podupire iza sebe druge prednosti.


#40

Nije baš tablično prikazano, ali evo rezime prednosti/mana koje sam ja do sada opazio. Što može biti nekakav okvir ako netko želi usporediti drugi sistem po istim točkama. Ili ako netko želi nadodati koju prednost/manu ovog ili drugog sistema.

Prednosti:
-jednostavna sintaka i pregledan code
-univerzalna sintaska za PHP, JS, HTML, CSS …te bilo koji drugi željeni jezik, ili bilo kakve ekstenzije, koje su u suštini txt fileovi.
-mogućnost izlaženja sa sintaksom izvan okvira sintakse jezika u kojem prevodimo nešto. Tipa, array se može prevesti na način: var dani =[{{‘Pon’,‘Uto’,‘Sri’,‘Čet’,‘Pet’,‘Sub’,‘Ned’}}];
-dodavanje novog prijevoda iz “glave”, na točno mjesto gdje ćemo ga koristiti
-bez potrebe vođenje posebnih fileova za organiziranje prijevoda
-bez potrebe provjere ID-a prijevoda kojeg negdje uključujemo

-load stranice ne zahtjeva nikakav dodatni proces da bi isporučio web na traženom jeziku. (Točnije bi bilo reći gotovo nikakav, jer PHP se mora oslanjati na funkciju file_exists()) …no nije potrebno čupanje prijevoda iz baze podataka.

-load stranice neće povući niti jedan prijevod koji se ne koristi na onoj stranici koja se isporučuje. Znači, bandwith je također max optimiziran.

Mane:
-postojanje multipliciranih skripti, što dovodi do nešto većeg utroška memorije na hostu.
-kod loada, PHP se mora oslanjati na funkciju file_exists(), s time da ta funkcija stvara vlastiti cache kako bi bila maksimalno optimizirana i općenito se ubraja u ne zahtjevan proces.
-treba znati posložiti projekt da ispravno includa file-ove. Nije nauka, umjesto include($file) treba koristiti include (ml_getFile($file))
-uvođenje zabranjenih simbola za korišteni jezik. Zabranjeni simboli nastaju zbog rezervacije simbola za tagiranje prijevoda.
-duži upload projekta ili potreba instalacije prijevoda nakon uploada. S time da sistem trigira automatski instalaciju nakon što detektira da se desio upload + ne radi kompletno novu instalaciju, nego doinstalirava samo ono što opazi da je promjenjeno. Time i ova instalacija postaje “lagan” proces.
-mogućnost konfuzije s fileovima istog imena unutar editora.
-potrebno razumjevanje sistema da bi se mogao integrirati u sklop nekakvog drugog preparsera ili cijelog frameworka

Zaključak:
Eto, zvjerski sam se potrudio da iskopam sve mane koja sam opazio. Niti jedna nije diskreditirajuća…niti jedna nije čak niti ozbiljnija mana. Dok su neke prednosti baš odlične. Sistem koji bi mi pored ovakvog bio interesantan, nebi trebao rješiti ove mane…nego:
-> ponuditii barem iste prednosti uz smanjenje ovih mana
-> ponuditi bolje prednosti uz zadržavanje mana (ili čak unos novih mana)
Ukoliko bi zaista neki sistem unio nove prednosti i pri tome i nove mane, onda bi trebalo napraviti vaganje pluseva i minusa.

Sistem koji nema gore spomenute mane, ali nema ni gore ponuđene prednosti, nije mi baš po ničemu zanimljiv dok god se ne ispostavi da neke od nabrojanih mana ipak jesu diskreditirajuće. A to može objasniti jedino neki dobar argument, a ne stav “Za mene to nema smisla”.