Language kodovi za srpski

[nesh]

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ć]

@andrej: "cs" locale ti ništa ne znači, jer IMHO većina browsera danas šalje sr, tj. ako je uopšte "svesna" Srpskog.

PS: Sad sam video kako IE rešava problem latinice i ćirilice... Originalno nema šta

[nesh]

Originalno napisao BlueIce

@andrej: "cs" locale ti ništa ne zna?i, jer IMHO ve?ina browsera danas šalje sr, tj. ako je uopšte "svesna" Srpskog.

PS: Sad sam video kako IE rešava problem latinice i ?irilice... Originalno nema šta

I ja treba da budem vidovit pa da pogodim redosled .

A sta salje u Accept-Language, kada je tako namesten?

[Petar Marić]

Funny you should ask:

HTTP_ACCEPT_LANGUAGE: sr,sr;q=0.5

LOL

[nesh]

Originalno napisao BlueIce

Funny you should ask:

HTTP_ACCEPT_LANGUAGE: sr,sr;q=0.5

LOL

10x, 10min sam se smejao

ix, konacno neka korist od IE

p.s. mogao sam i da pretpostavim. Odvikao sam se od win*sa (srecom)

[nesh]

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:

   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:

sr-latin
sr-cyrillic

ili za one koji bas vole

sr-yu-latin
sr-yu-cyrillic

iako je ova prva varijanta mnogo bolja.

[nesh]

Originalno napisao andrej

On koristi cs locale.

Kao sto napisah, po RFC 1766, na pocetku se nalazi:

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ć]

Dobro nesh, koju ćemo varijantu koristiti

(sr_CYR, sr_LAT) ili (sr-latin, sr-cyrillic)

?

[nesh]

Originalno napisao BlueIce

Dobro nesh, koju ?emo varijantu koristiti

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

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

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ć]

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