Multilanguage web site

Definitivno pogledaj https://www.gnu.org/software/gettext/manual/gettext.html, a tu imas i nesto o JS i18n https://24ways.org/2007/javascript-internationalisation, a imas i ovaj projekt http://i18next.com/docs/

Blago tebi kad imas vremena toliko filozofirati o svom kodu i izmisljati za svaku stvar “toplu vodu” nanovo i to svakog puta i za svaki problem ;).

Ima i razlog za to :smiley:
Znaš vjerovatno kako sljepci razviju posebne vještine da se snađu u okolnostima koje su ih snašle…

…tako sam i ja u ovim vodama slijep za jednu stvar. Ja sam naime krenuo programirati s gotovo nikakvim znanjem engleskog. Putem se nešto i naučilo…ali dugo vremena sam brže mogao napravio neku stvar, nego izučiti neku stvar. To je degradiralo moje skilse proučavanja, ali definitivno ojačalo moje skilse stvaranja. Dan danas…ako u 10 minuta guglanja ne pronalazim ono što mi treba u savršeno pakovanom obliku, uopće ne gubim vrijeme na daljnje guglanje…kada znam da ću kroz koji dan imati dobro vlastito rješenje. Takav pristup me nikada nije degradirao spram kolega koji su kretali iz iste točke kao ja…koji su bili potkovani engleskim i koji su se uglavnom oslanjali na gotova rješenja. No kad takvi kolege naiđu na problem koji nigdje nije rješen…lupe često u zid. Ja kad se nađem pred problemom kojeg nikada nitko nije rješavao…imam običan dan kao i svaki drugi dan :slight_smile:

A vlastita rješenja su mi draža i iz aspekta što ne možemo bolje poznavati srž nečega, osim ako to sami ne napravimo. Kasnije…kada uvidimo druga dobra rješenja…uvijek možemo križati metodiku vlastitog rješenja s onim dobrim stvarima tuđeg rješenja…te tako dobivamo još bolje rješenje i od vlastitog i od tuđeg.

P.S. kad sam došao prvi dan u firmu gdje sam radio kao vanjski suradnik…mislili su na glas da sam Bog kad sam u jednom danu rješio problem za koji nisu imali nikakvu ideju što i kako xd. …a onda s druge strane ispadnem totalni noob, kad neku tako općenitu stvar napravim komplicirano po svome…a postoje tako lijepa utabanata rješenja. No sve ja to prihvatim s vremenom…

Što suma sumaru ne govori da je ovaj moj pristup bolji, ali tebi daje konačno objašnjenje zašto sam ja primoran bio ići ovim putem i izmišljati uvijek toplu vodu, a u konačnici…nije da se bunim rezultatima, pa da sam prisiljen nešto mijenjati.

P.S.2
Dok bi ja prostudirao ovaj tvoj prvi link…ode baba s kolačima. Pa dok bi negdje zapeo…pa studirao razno razne forume za postojeće solucije rješenja…uzme to vremena. Zato ja razmišljam kraćim putem: “Ako postoji odličan univerzalan alat, facebook bi ga koristio…i ja se nebi nikad sreo u facebooku sa ne prevedenim gumbićem.” (A sretnem se često). To razmišljanje ne mora bit točno, ali je zato daleko brže i time efikasnije.
To razmišljanje poduprem s kratkim pogledom na stackoverflow forum…čim vidim u kojem smjeru idu rasprave, shvatim dali postoji univerzalan alat ili ne…koji je vrijedan gubljenja vremena.
Treća stvar koju napravim: pitam na forumima koja logika stoji iza određenog ostvarenja cilja (ovdje multijezičnost). Ono što želim čuti su načini, tehnika, mogućnosti …ne imena frameworka koji koriste te tehnike. Ako nađem jednostavnost objašnjenja nekog pristupa/tehnike…samo onda mogu prihvatiti i alat koji je razvio taj pristup. Ali bez objašnjenja pristupa, alat vjerovatno neću niti razmatrat.

…i na kraju otvaram temu, iznosim na vidjelo učinjeno ili zamišljeno… jer dobre kritike su Bogom dane. No u kritikama me ne zanima čuti da netko kaže:
“To je možda dobro rješenje jer tako radi Lavarel” …ili isto tako ako kaže:
“To nije dobro rješenje jer tako ne radi Lavarel”

…ono što od kritika želim čuti, je konkretno što u predloženoj metodiki je ograničavajuća stvar. Što je konkretno loše i zašto je loše. Što je dobro i zašto je dobro. Tek vaganjem dobrog i lošeg se može zaključiti o ispravnosti odabrane metode.
Ti da si u svojim linkovima ponudio bolju metodu (a možda jesi), nebi te ništa koštalo da u kratkim crtama izneseš zašto je taj pristup superiorniji spram ovoga. Ti to naravno nisi dužan iznesti, ali ja to smatram forumskom kolegijalnošću…na kraju tu vidim i smisao foruma. To što si ti meni dao link od tone pod linkova…i reko “ajd tim putem” …meni ništa ne znači, osim ako imam veliko povjerenje u tebe. A povjerenje stječem tek ako netko zna i želi obrazložiti svoj pristup.

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.

Daj kod na uvid :wink:

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.

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.

  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.

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?

…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”

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:

…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.

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:

Š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.

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

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.

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

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?

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.

1 Like

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.