Language kodovi za srpski
Bas sam se spremao da dodam u django sr latinicne i cirilicne prevode, ali...
Koji behose kodovi (ako ih ima) za sr_latin i sr_cyrilic?? Ubih se trazeci ali nigde da se nadje.
Ako samo definisem sr (IMO) to bi trebalo da bude latinica ili, mozda, cirilica?
p.s. ako je ovo pogresno mesto, "bacite" poruku gde god vise odgovara ;)
|
| Petar Marić |
04. 10. 2005. 22:21 |
"sr_LAT" i "sr_CYR" su. Mada, ne očekuj neku preteranu korist od toga, većina browsera čak i da je serbian-aware poslaće ti samo "sr".
Na XStandard, dogovor je bio da je "Српски (sr)" Ћирилица, a "Srpsko-Hrvatski (sh)" Latinica. Uzrok toj odluci je bio projektno ograničenje platofrme na ISO 2-karakternu predstavu jezika, gde ne postoji opcija za lokalitete.
PS: Sram te bilo, sam radiš prevod ccc...
|
| dinke |
04. 10. 2005. 23:24 |
Ja sam svojevremeno na Linuxu koristio sr_YU.utf8 za prevod SiteBuildera ( www.cafeid.com). |
I ja sam za sr_LAT i sr_CYR.
Genericki sr koji salji browseri mapira u sr_CYR? Vecina primera koje sam video sr tretiraju kao cirilicu, npr. Apple u meniju za izbor tastature ima Serbian kao cirilicu a Serbian-Latin za latinicu.
Zar ne bi trebalo da postoji neki standard za ovo? A da ga napravimo ;)
Za sada ostavljam sr kao latinicu u djangu, a za kasnije cemo da vidimo.
A evo i loga sa ICQ-a izmedju mene i BlueIce-a sa pricom o tome:
Kôd:
<snip>
9:53:34 <BlueIce>: Sta si odlucio za lang code?
9:53:57 <BlueIce>: Postoji li radna verzija koja se da videti?
9:54:07 <nesh>: pojma nemam, ima li neki standard? sr_lat sr_cyr?
9:54:48 <nesh>: za dan dva izbacujem betu, hosting ne mogu da biram ovaj put, a cekam da mi aktiviraj karticu za firmu pa da uplatim textdrive
9:54:58 <BlueIce>: sr_LAT i sr_CYR. Tako sam video preporuke ISO standarda
9:55:11 <nesh>: odlicno, onda cu tako
9:55:29 <BlueIce>: Ali ipak vecina koristi srpski (sr) i sprskohrvatski (sc)
9:55:40 <BlueIce>: :)
9:55:51 <nesh>: pa bice sr->sr_LAT
9:55:51 <BlueIce>: A sta radis kada ti browser posalej sr :))
9:56:13 <BlueIce>: ?
9:56:13 <BlueIce>: Kako?
9:56:29 <BlueIce>: Menjac kod djanga, ili?
9:57:04 <nesh>: pa sam kod koji bude prepoznavao (nesto slicno ima i uz gettext - normalize iirc) ce da to mapira
<snip>
10:07:04 <BlueIce>: Vidi vidi
10:07:31 <BlueIce>: Sad razgledam gettext manual i tamo pise da je SC rezervisan
10:07:44 <BlueIce>: sc
Sardinian.
10:07:48 <nesh>: xex
10:08:12 <nesh>: ma sr_LAT i sr_CYR
10:08:25 <BlueIce>: Mhm
10:08:30 <nesh>: upravo odgovaram na DPT :)
10:08:57 <BlueIce>: Sad cu morati da cimam one likove iz Belus technologies da menjamo prevod za XStandard :(
10:09:16 <nesh>: cek, gledam gettext src, tamo ima nesto ...
10:11:19 <nesh>: 'serbocroatian': 'sh_YU.ISO8859-2',
'sh': 'sh_YU.ISO8859-2',
'sh_hr': 'sh_HR.ISO8859-2',
'sh_sp': 'sh_YU.ISO8859-2',
'sh_yu': 'sh_YU.ISO8859-2',
10:11:29 <nesh>: 'sp': 'sp_YU.ISO8859-5',
'sp_yu': 'sp_YU.ISO8859-5',
10:11:30 <BlueIce>: Vidi vidi
10:11:33 <nesh>: tako oni mapiraju
10:11:45 <nesh>: ovo sa sp bi trebalo da je cirilica
10:11:46 <BlueIce>: A gde je UTF skotovi jedni?!?
10:12:58 <nesh>: xm, mozda bi trebalo da se zapne da se ubaci sr_LAT->sr_LAT_CS.UTF-8 npr ...
10:12:58 <BlueIce>: Nista moracemo nesto da preduzmemo povodom ovoga... Oces da bude good cop ili bad cop :)
10:13:55 <nesh>: ima li ko kod nas ko bi trebalo da se bavi time? ili da kukamo (gde) da se to resi?
10:14:48 <nesh>: ajd ja cu da prebacim deo ove price na DPT pa da organizujemo "zaveru" ;)
10:15:09 <BlueIce>: Mmm, KISS pravilo?
10:15:40 <BlueIce>: Mislim da je najbolje da ostavimo sr_LAT i sr_CYR
10:15:55 <nesh>: slazem se, samo pod utf-8
10:16:05 <BlueIce>: Ne bismo smeli da isuvise komplikujemo stvari
10:16:17 <nesh>: btw sad mi google nadje par paketa sa sr_lat za mandraka
10:16:26 <nesh>: za sr_cyr nista
10:16:46 <nesh>: i.e. http://fr.rpmfind.net/linux/RPM/mandrake/9.2/contrib/i586/psi-lang-pack-sr_lat-0.9-5mdk.i586.html
10:17:43 <BlueIce>: offtopic, sad sam na wikipedii video interesantnu definiciju KISS pravila za AI: "Keep It Simple and Stupid"
10:17:50 <BlueIce>: Amen to that
10:17:53 <nesh>: :D
10:18:16 <nesh>: ubuntu u share/locale ima sr i sr@Latn
10:18:59 <nesh>: ovo prvo je cirilica
10:19:19 <nesh>: Last-Translator: Danilo Ĺ*egan <danilo@prevod.org>
Language-Team: Serbian (sr) <serbiangnome-lista@nongnu.org>
10:19:31 <BlueIce>: Hmm
10:19:37 <BlueIce>: Ne dopada mi se
10:19:59 <nesh>: ma lat i cyr je savim OK, ja cu da napravim tako
10:20:21 <BlueIce>: Danilo? Majcice... Ako nam naidju on i povorka sa nase-pismo i prevod.org bice veslo :)
10:20:31 <BlueIce>: typo: veselo
10:24:21 <nesh>: ma mi moramo nekako da krstimo lat i cyr lokalizacije, a da se to slaze sa ostalim (bese neki ISO) i tamo je sve u fazonu <lang>_<grupa>
10:25:27 <BlueIce>: jedino da kontakiramo ISO i njih da pitamo :)
10:25:52 <nesh>: sr-lat, sr-cyr src: http://en.wikipedia.org/wiki/Petar_Petrovi?_Njegoš ;)
<snip>
10:26:36 <BlueIce>: Mislim da moras koristiti underscore, a ne dash
10:27:00 <nesh>: a i ovo http://cvs.sourceforge.net/viewcvs.py/moodle/mysql/libraries/select_lang.lib.php?rev=1.3
10:27:04 <BlueIce>: :)
<snip>
10:27:23 <nesh>: 'sr-utf-8' => array('sr|serbian', 'serbian_cyrillic-utf-8', 'sr'),
'sr-win1251' => array('sr|serbian', 'serbian_cyrillic-windows-1251', 'sr'),
'sr-lat-utf-8' => array('sr[-_]lat|serbian latin', 'serbian_latin-utf-8', 'sr-lat'),
'sr-lat-win1250'=> array('sr[-_]lat|serbian latin', 'serbian_latin-windows-1250', 'sr-lat'),
10:28:11 <BlueIce>: Da, nesto slicno koriste i za phpmyadmin
10:28:22 <BlueIce>: But that's wrong
10:28:25 <nesh>: pa i imas en-us
10:29:07 <BlueIce>: Da znam
10:29:17 <BlueIce>: Cek da vidimo sta mudra vatrena lija kaze
10:29:29 <BlueIce>: A ti bi mogao da proveris Safari...
10:30:05 <nesh>: ajd ja cu da bacim nesto od ovoga na dpt pa ce mo dalje tamo, sto nas se vise slozi oko toga, to ce biti "veci" standard :)
10:30:16 <BlueIce>: U liji samo sr
10:30:39 <BlueIce>: A doista kao separator se koristi dash
10:30:39 <BlueIce>: weird
10:30:50 <BlueIce>: Ajd, baci kompletan log slobodno
10:30:57 <nesh>: ok
<snip>
10:31:25 <nesh>: apple/darwin:
10:31:38 <nesh>: cat /usr/share/locale/sr_YU/LC_MESSAGES/sr_YU.UTF-8.out
^[Đ´ĐyY].*
^[Đ˝Đ
Đ´Đ°
не
(cirilica)
10:32:07 <nesh>: cat /usr/share/locale/sr_YU.ISO8859-2/LC_MESSAGES/sr_YU.ISO8859-2.out
^[dDyY].*
^[nN].*
latinica
10:32:12 <BlueIce>: WTF?
10:32:16 <BlueIce>: Ja dobio ovo: ^[Đ´ĐyY].*
^[Đ˝Đ
Đ´Đ°
не :))
10:32:41 <nesh>: ma pastovano iz konzole koja je pod 8859-1 :)
10:33:10 <BlueIce>: ccc
10:33:38 <BlueIce>: Prva stvar koju sam uradio na linux je bila promea sitemske konzole u utf-8
10:33:51 <BlueIce>: Dok sam ga koristio tj
10:34:07 <nesh>: ma apple se nije bas potrudio oko konzole, tako da moram da koristim onu koja dolazi uz C
10:34:13 <nesh>: s/C/X/ :)
10:34:30 <BlueIce>: s/C/X?
10:35:11 <nesh>: Substitute/<from>/<to>/ - nekada se koristio perl :)
10:35:24 <nesh>: mislio sam na X
10:35:56 <BlueIce>: gotta go
10:36:09 <BlueIce>: Korstio si perl GASP
10:36:13 <BlueIce>: Poor soul
10:36:44 <nesh>: davno bese, jos dok sam koristio UUCP za mail/news
10:36:47 <nesh>: cu
BlueIce disconnected (10:37:15)
|
| dinke |
05. 10. 2005. 13:14 |
Kôd:
dinke@devel:~$ locale -a |grep sr
sr_YU
sr_YU.iso88592
sr_YU.iso88595@cyrillic
sr_YU.utf8
sr_YU.utf8@cyrillic
sr_YU@cyrillic
dinke@devel:~$
Ovo ja dobijam na debianu (sarge). Ja znam da sam imao orgomne probleme sa gettext-om sve dok nisam setovao locale na sr_YU.utf8 |
Citat:
Originalno napisao dinke
Kôd:
dinke@devel:~$ locale -a |grep sr
sr_YU
sr_YU.iso88592
sr_YU.iso88595@cyrillic
sr_YU.utf8
sr_YU.utf8@cyrillic
sr_YU@cyrillic
dinke@devel:~$
Ovo ja dobijam na debianu (sarge). Ja znam da sam imao orgomne probleme sa gettext-om sve dok nisam setovao locale na sr_YU.utf8
|
Apple/Darwin (BSD)
Kôd:
nesh@zeus ~/devel/sportkomerc
$ locale -a | grep sr
sr_YU
sr_YU.ISO8859-2
sr_YU.ISO8859-5
sr_YU.UTF-8
Izgleda da nema standarda ;(
Ipak, mislim da @latin/cir nisam vidjao u upotrebi na web-u. Tamo obicno koriste lang-sublang (en-us, en-gb, ...). Ovo nase bi trebalo da se slicno tretira.
Posto python implementacija gettext-a sama po sebi uopste nije za web (tacnije za bilo koju multithreading primenu) za django koristimo preradjene klase, tako da sam izbor .mo fajla imamo pod kontrolom, nikakav problem da se koristi bilo koja varijanta (sr_lat, sr_cyr, sr_whatewer) a encoding je i onako uvek utf-8.
Voleo bih da mogu da isposxtujem (grrr, safari ne voli 8859-1 strane) neki standard, ali kada ga nema .... |
Xex, upravo mi je na django-devel listi BlueIce dao odlicnu ideju - osnovni fajl ce biti cirilicni a ako korisnik zeli latinicu konvertovace se (uz malo kesiranja) "u letu" u latinicu.
|
| Petar Marić |
11. 10. 2005. 15:10 |
Dobro može i tako - mislio sam da imamo alat koji sr_CYR po fajl pretvara u sr_LAT po fajl uz sve potrebne izmene (uglavnom header-i i lokacija datoteke) - taj princip sam ja koristio na drugim mestima dosad...
Ali opet čini mi se da je tvoja ideja (možda sam te inspirisao, ali nisam imao on-fly konverziju u planu) bolja.
|
| andrej |
11. 10. 2005. 15:14 |
Možda je najbolje da pitaš Danila, on se zeza oko toga. On koristi cs locale. |
Citat:
Originalno napisao BlueIce
Dobro može i tako - mislio sam da imamo alat koji sr_CYR po fajl pretvara u sr_LAT po fajl uz sve potrebne izmene (uglavnom header-i i lokacija datoteke) - taj princip sam ja koristio na drugim mestima dosad...
Ali opet ?ini mi se da je tvoja ideja (možda sam te inspirisao, ali nisam imao on-fly konverziju u planu) bolja.
|
Ovako ce morati da se odrzava samo jedan fajl, konverzija iz cirilice u latinicu je trivijalna stvar, a uz malo kesiranja nece predstavljati ni problem u performansama. A i totalno izbegavamo problem kako da "krstimo" prevode tako da gettext moze da ih pronadje ;).
Ja cak razmisljam o tome da kao "feature", na trenutnim sajtovima, uradim isto tako - osnovni tekstovi u cirilici, a latinica on-fly.
Sam gettext sistem je prilicno dobro podrzan na gomili jezika (C, PHP, Python, Ruby, ...) tako da je ovo prilicno univerzalno resenje. Za python cu ja da uradim konverziju. |
Citat:
Originalno napisao andrej
Možda je najbolje da pitaš Danila, on se zeza oko toga. On koristi cs locale.
|
Mislim da, ipak, ostajem pri 'sr'. Lat-Cir problem cu resiti kao sto smo BlueIce i ja napisali u prethodnim porukama.
'sr' je ono sto vecina (ako ne i svi) salju kao Accept-Language header kada su podeseni za nas jezik. |
| Petar Marić |
11. 10. 2005. 15:43 |
1 Prilog(a)
|
Citat:
Originalno napisao BlueIce
|
I ja treba da budem vidovit pa da pogodim redosled :D.
A sta salje u Accept-Language, kada je tako namesten? |
| Petar Marić |
11. 10. 2005. 21:04 |
Funny you should ask:
Kôd:
HTTP_ACCEPT_LANGUAGE: sr,sr;q=0.5
LOL :D |
Citat:
Originalno napisao BlueIce
Funny you should ask:
Kôd:
HTTP_ACCEPT_LANGUAGE: sr,sr;q=0.5
LOL :D
|
:D 10x, 10min sam se smejao :D
ix, konacno neka korist od IE
p.s. mogao sam i da pretpostavim. Odvikao sam se od win*sa (srecom) |
Xex, ko ne gleda ...
Našao sam (gledajuci python locale source) jasnu referencu za celu ovu pricu na RFC 1766.
Za one koje mrzi da citaju (ukljucujuci i mene) izdvajam:
Kôd:
In the first subtag:
- All 2-letter codes are interpreted as ISO 3166 alpha-2
country codes denoting the area in which the language is
used.
- Codes of 3 to 8 letters may be registered with the IANA by
anyone who feels a need for it, according to the rules in
chapter 5 of this document.
The information in the subtag may for instance be:
- Country identification, such as en-US (this usage is
described in ISO 639)
- Dialect or variant information, such as no-nynorsk or en-
cockney
- Languages not listed in ISO 639 that are not variants of
any listed language, which can be registered with the i-
prefix, such as i-cherokee
- Script variations, such as az-arabic and az-cyrillic
In the second and subsequent subtag, any value can be registered.
Izgleda da je prica rešena, (IMO) kodovi za cirilicu i latinicu bi trebalo da budu:
Kôd:
sr-latin
sr-cyrillic
ili za one koji bas vole
Kôd:
sr-yu-latin
sr-yu-cyrillic
iako je ova prva varijanta mnogo bolja. |
Citat:
Originalno napisao andrej
On koristi cs locale.
|
Kao sto napisah, po RFC 1766, na pocetku se nalazi:
Kôd:
In the primary language tag:
- All 2-letter tags are interpreted according to ISO standard
639, "Code for the representation of names of languages" [ISO
639].
- The value "i" is reserved for IANA-defined registrations
- The value "x" is reserved for private use. Subtags of "x"
will not be registered by the IANA.
- Other values cannot be assigned except by updating this
standard.
tako da nikako ne moze da bude cs.
Pocetni kod je kod jezika a ne zemlje.
IMO, cela prica o lokalizaciji je vezana za jezik a ne za lokaciju (iako subtag dozvoljava odvajanje po tome npr. en-gb i sl), tako da locale za srpski jezik nikako ne moze da spada pod cs (ma kako nas "skratili"). |
| Petar Marić |
12. 10. 2005. 00:02 |
Dobro nesh, koju ćemo varijantu koristiti
Kôd:
(sr_CYR, sr_LAT) ili (sr-latin, sr-cyrillic)
? |
Citat:
Originalno napisao BlueIce
Dobro nesh, koju ?emo varijantu koristiti
Kôd:
(sr_CYR, sr_LAT) ili (sr-latin, sr-cyrillic)
?
|
Xm, sto se djanga tice, ja sam vise za varijantu sa on-the-fly konverzijom cirilice u latinicu. Trenutni use-case za unos texta mi se OK slaze sa tim.
Za ostalo, ...., ako je vec definisano u RFC-u valjda bi trebalo da poslusamo ;). Samo da malo pregledam algoritam gettexta za nalazenje .mo fajlova i kako on mapira imena ...
Kôd:
>>> from gettext import _expand_lang
>>> _expand_lang('sr')
['sr']
>>> _expand_lang('sr-latin')
['sr-latin']
>>> _expand_lang('en')
['en_US.ISO8859-1', 'en_US', 'en.ISO8859-1', 'en']
>>> _expand_lang('sr@Latin')
['sr@Latin', 'sr']
>>> _expand_lang('sr-cyrillic')
['sr-cyrillic']
>>> _expand_lang('sr@Cyrillic')
['sr@Cyrillic', 'sr']
>>> _expand_lang('sr_latin')
['sr_latin', 'sr']
>>> _expand_lang('sr_cyrillic')
['sr_cyrillic', 'sr']
Xux??? Po ovome izgleda da je najlakse resenje @Latin ili _latin ??? Sad mi tek nista nije jasno :confused:
Posto gettext koristi ovo kao ulaz za pravljenje imena fajla koji trazi izgleda da je najjednostavnije da se uradi nesto tipa locale.replace('-', '_') prilikom parsovanje Accept-Language headera da bi se ispostovao RFC.
Javi cu se kada prespavam :) |
| Petar Marić |
12. 10. 2005. 00:39 |
1. Na koji si tačno način mislio da izvedemo on-the-fly konverziju u latinicu?
2. Gde bi čuvao/keširao lokalizacije? Mislim da bismo opet onda imali problema sa cache frameworkom - osim ako, naravno, ne koristiš kolače, koje korisnici "dijabetičari" ne vole.
offtopic: Doneću računar za vikend u NS, tako daćemo manje da smaramo sve vas ovde na forumu :D
|
Citat:
Originalno napisao BlueIce
1. Na koji si ta?no na?in mislio da izvedemo on-the-fly konverziju u latinicu?
2. Gde bi ?uvao/keširao lokalizacije? Mislim da bismo opet onda imali problema sa cache frameworkom - osim ako, naravno, ne koristiš kola?e, koje korisnici "dijabeti?ari" ne vole.
|
1. Xm, kada malo bolje razmislim, bez intervencije na i18n delu to nece ici. Videcu da li mogu da "izmislim" neki patch koji to moze da odradi. Ostalo je laksi deo posla.
Oops, sada mi se "ukaza" da bi za to najverovatnije trebalo da se menjaju *Translation klase. Xex, to nece ici tako lako.
2. Koliko videh, sredili su cache fw tako da bi to trebalo da bude ok.
Ipak, po svemu (a i jos sam budan), mozda ce morati za pocetak da se odrade oba prevoda. Izgleda da se vracamo na staro :)
Sutra cu da napravim konvertor, a sto se imena tice, mislim da koristimo sr_latin i sr_cyrillic kad vec nesto slicno pominju, cisto da ne izmisljamo toplu vodu.
Odosmo deebelo OT sto se tice djanga ;) |
Citat:
Originalno napisao nesh
Sutra cu da napravim konvertor, a sto se imena tice, mislim da koristimo sr_latin i sr_cyrillic kad vec nesto slicno pominju, cisto da ne izmisljamo toplu vodu.
|
Gledah nesto po Rozeti. Tamo svi nasi prevodi koji imaju obe verzije idu u varijati 'sr' = cirilica, 'sr@Latn' = latinica. Da se ne izmisljamo mnogo, nego da i mi ovako uradimo?
Nije problem da se doda da ako postoji 'sr' a ne 'sr@Latn' koristi ovaj prvi. |
| Petar Marić |
13. 10. 2005. 21:51 |
Hm, ne znam, ne dopada mi se. Ostali na djangu su radili LANG_EXTENSION a ne LANG@EXTENSION (pt_BR za brazilsku verziju Portugalskog).
Nego ako možeš sačekati koji dan, bivši student mog profesora na faxu radi u IBM-ovoj laboratoriji za i18n i i10n, pa možemo i njega pitati za savet... Mada ne bi bilo loše da me podsetiš na to sredinom sledeće nedelje :D
|
Citat:
Originalno napisao Petar Mari?
Hm, ne znam, ne dopada mi se. Ostali na djangu su radili LANG_EXTENSION a ne LANG@EXTENSION (pt_BR za brazilsku verziju Portugalskog).
Nego ako možeš sa?ekati koji dan, bivši student mog profesora na faxu radi u IBM-ovoj laboratoriji za i18n i i10n, pa možemo i njega pitati za savet... Mada ne bi bilo loše da me podsetiš na to sredinom slede?e nedelje :D
|
OK, trenutno mi to nije problem za ono sto radim (treba mi samo latinica). |
| Vreme je GMT +2. Trenutno vreme je 19:58. |
|
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.
