locale name for sub-country dialects?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

locale name for sub-country dialects?

Robert Millan

Hi!

How should sub-language dialects that, instead of matching a country
(ISO-3166-1), match a sub-country (ISO-3166-2) division, be specified in locale
values?

POSIX (XSI) reads:

<quote>
If the locale value has the form:

language[_territory][.codeset]

it refers to an implementation-provided locale, where settings of language, territory, and codeset are implementation-defined.
</quote>

Do we handle this with ISO-3166-2 codes, or are generic @something modifiers
preferred?

And in case @something modifiers are preferred, do we use the name of the
language variant in English, or in the local language itself?

Thanks,

--
Robert Millan
Reply | Threaded
Open this post in threaded view
|

Re: locale name for sub-country dialects?

Robert Millan

Nobody knows?

If there are no standards, rules, or requisites by the Glibc maintainers that
cover this situation, then please let me know so that we can come up with
something ourselves.

We'd like to avoid a situation in which we start using a locale name and later
we have to migrate to something else :)

I've been pointed out that RFC 3066 restricts dialect names to 3-8 character
length.  Other than this I couldn't find any more restrictions.

Thank you!

On Wed, Mar 29, 2006 at 11:58:58AM +0200, Robert Millan wrote:

>
> Hi!
>
> How should sub-language dialects that, instead of matching a country
> (ISO-3166-1), match a sub-country (ISO-3166-2) division, be specified in locale
> values?
>
> POSIX (XSI) reads:
>
> <quote>
> If the locale value has the form:
>
> language[_territory][.codeset]
>
> it refers to an implementation-provided locale, where settings of language, territory, and codeset are implementation-defined.
> </quote>
>
> Do we handle this with ISO-3166-2 codes, or are generic @something modifiers
> preferred?
>
> And in case @something modifiers are preferred, do we use the name of the
> language variant in English, or in the local language itself?
>
> Thanks,
>
> --
> Robert Millan

--
Robert Millan
Reply | Threaded
Open this post in threaded view
|

Re: locale name for sub-country dialects?

Denis Barbier
On Fri, Mar 31, 2006 at 09:27:57PM +0200, Robert Millan wrote:
>
> Nobody knows?

If this situation has not been handled before, it is indeed likely that
nobody knows.  Anyway, can you please give an example?  I did not
understand exactly what your problem is.

Denis
Reply | Threaded
Open this post in threaded view
|

Re: locale name for sub-country dialects?

Petter Reinholdtsen
In reply to this post by Robert Millan
[Robert Millan]
> Nobody knows?

I do not know, but have a few observations and suggestions.  I assume
you have found <URL:http://www.student.uit.no/~pere/linux/glibc/>.

If there are two or three letter ISO language codes, use them.  if
these do not exist, you need to present a convincing case for the need
o fa new locale, and it is probably easier to get a ISO language code
than convincing the glibc maintainers that there is a need.  Normally
the dialects without their own language codes are expected to use the
official language code and locale.

If there is no unique language code, and you still want to make your
own variation, then modifieres need to be used.  @modifier is appended
to the locale name, and the only info I have been able to gather on
modifiers is available from the URL mentioned above.

Sorry for not being to more help.  I'm still struggeling to understand
what will be accepted by the glibc maintainers. :)
Reply | Threaded
Open this post in threaded view
|

Re: locale name for sub-country dialects?

Robert Millan
On Sat, Apr 01, 2006 at 12:42:34AM +0200, Petter Reinholdtsen wrote:
> [Robert Millan]
> > Nobody knows?
>
> I do not know, but have a few observations and suggestions.  I assume
> you have found <URL:http://www.student.uit.no/~pere/linux/glibc/>.

I hadn't.  Thanks for the pointer.

> If there are two or three letter ISO language codes, use them.  if
> these do not exist, you need to present a convincing case for the need
> o fa new locale, and it is probably easier to get a ISO language code
> than convincing the glibc maintainers that there is a need.  Normally
> the dialects without their own language codes are expected to use the
> official language code and locale.

No, that's not the case.  It is like the other dialects except it isn't
delimited to a particular country to identify it.

> If there is no unique language code, and you still want to make your
> own variation, then modifieres need to be used.  @modifier is appended
> to the locale name, and the only info I have been able to gather on
> modifiers is available from the URL mentioned above.

Well, that at least confirms there aren't any known requisites.

> Sorry for not being to more help.  I'm still struggeling to understand
> what will be accepted by the glibc maintainers. :)

No problem.  Thank you,

--
Robert Millan
Reply | Threaded
Open this post in threaded view
|

Re: locale name for sub-country dialects?

Eduardo Trápani-2
>>If there are two or three letter ISO language codes, use them.  if
>>these do not exist, you need to present a convincing case for the need
>>o fa new locale, and it is probably easier to get a ISO language code

What does a language need in order to be able to present a "convincing case"?  Speakers, literature, mainstream opensource localizations, wikipedia, could you tell me as maintainer what do you expect from a language to consider including it in glibc?  Apart from the ISO code, of course.

Once the required information is collected, should it be submitted to this list or to some glibc approval body?

Thanks, Eduardo.
Reply | Threaded
Open this post in threaded view
|

Re: locale name for sub-country dialects?

Robert Millan
On Mon, Apr 03, 2006 at 10:25:56AM -0300, Eduardo Tr??pani wrote:
>
> What does a language need in order to be able to present a "convincing
> case"?  Speakers, literature, mainstream opensource localizations,
> wikipedia, could you tell me as maintainer what do you expect from a
> language to consider including it in glibc?  Apart from the ISO code, of
> course.

Petter's site is quite useful in this regard (he pointed to it earlier in this
thread):

  http://www.student.uit.no/~pere/linux/glibc/

> Once the required information is collected, should it be submitted to this
> list or to some glibc approval body?

I guess Glibc bugzilla is a good place.

--
Robert Millan
Reply | Threaded
Open this post in threaded view
|

Official policy for new locales

Eduardo Trápani-2
>>What does a language need in order to be able to present a "convincing
>>case"?  Speakers, literature, mainstream opensource localizations,
>>wikipedia, could you tell me as maintainer what do you expect from a
>>language to consider including it in glibc?  Apart from the ISO code, of
>>course.
>
>
> Petter's site is quite useful in this regard (he pointed to it earlier in this
> thread):
>
>   http://www.student.uit.no/~pere/linux/glibc/

Thanks. In relation to the language I want to add, there is a comment in that page 'maintainers seem to refuse "artificial languages" like Esperanto an Lojban, even if they got a ISO 639 code'.

Having that comment added to the glibc *official* page would save time to all the people periodically asking for esperanto to be added.  Please check bugs #2135 and #711 to see the latest presentations of our case.

I think it's best for everybody to have the official policy spelled out clearly.

Eduardo.
Reply | Threaded
Open this post in threaded view
|

Re: Official policy for new locales

Danilo Segan
On Monday at 19:38, Eduardo Trápani wrote:

> I think it's best for everybody to have the official policy spelled out clearly.

There is no "official policy" that I know of.  Try with Denis Barbier
and belocs package on alioth instead, and push for your distribution
to use that.

Also, Serbian Jekavian locale (dialect officially used in Montenegro
part of Serbia and Montenegro) was rejected:

  http://sources.redhat.com/bugzilla/show_bug.cgi?id=39


Cheers,
Danilo