[Serbiangnome-lista] Re: Serbian (sr) language translation team: maintainer unresponsive

[Christian Rose]

mån 2003-04-07 klockan 22.44 skrev Danilo Segan:
> >I learned in school that Kroatian and Serbian was the same language,
> >but written in different scripts. Would that be a safe way out?
> >hr as used in Serbia could be the language code for the Latin variant.
> >(but maybe that would be a political problem)
> >Is YU still used for Serbia or is there a iso 3166 code for Serbia?
>
> Not exactly. They were quite similar, and convereged to the somewhat 
> same language (Serbo-Croatian"sh") during the time both were used in the 
> same country. But, since the dissolve of former Yugoslavia, they're 
> diverging again, and it's not rare for one word to be common in one, but 
> non-existant in the other.
> 
> So, no, "hr" would not be an option. Also, you probably have a Croatian 
> language team, and they ought to use that code.

We actually do have a Croatian team
(http://developer.gnome.org/projects/gtp/teams.html,
http://developer.gnome.org/projects/gtp/status/gnome-2.2/hr/).
I guess what Keld suggested was using hr_YU for Serbian in latin script
(if they were similar enough). I guess that's not a good idea if they
are diverging or even mildly different languages.


> On the other hand, it might be wiser to choose sr_lat, and sr (if one 
> wants to keep "sr" as latin, though anyone's preference shouldn't impact 
> the choice of the script), especially so because Serbian language comes 
> in two "dialects" (ekavian, and yekavian). Each of these dialects could 
> be written using any of cyrillic or latin, so we might have something like:
> address@hidden - Serbian yekavian
> address@hidden - Serbian latin yekavian
> sr - Serbian ekavian
> sr_lat - Serbian latin ekavian

If you don't have the manpower to do both the different dialects right
now, I'd advise against doing such separation now. You can always do it
later if you have the resources later. As a first step, having at least
one set of good Serbian translations in cvs is probably enough.

Also, I don't think using underscore as a separator is a good idea. Some
parsing software will perhaps misinterpret the following as a language
code. On the other hand, the @ symbol is explicitly recommended as a
separator for arbitrary variants. So having:

address@hidden
address@hidden

or

sr
address@hidden

is allowed.


Christian