Determination of language codes from a locale

[Markus Elfring]

Hello,

I have found two class libraries that have got the method "getLanguage".
http://www.icu-project.org/apiref/ic...0edae91f75c94f
http://java.sun.com/javase/6/docs/ap...l#getLanguage()

This method provides the capability to get the ISO 639 language code from a
locale. I am looking for a C function that offers the same service.

I know that a current setting can be queried by the function "setlocale". But I
do not see a function in the POSIX API to extract ISO 639 codes from the usual
naming conventions. Which is the recommended way to retrieve such information?
http://opengroup.org/onlinepubs/0096...setlocale.html

Regards,
Markus

[CBFalconer]

Markus Elfring wrote:

>
I have found two class libraries that have got the method
"getLanguage".

http://www.icu-project.org/apiref/ic...0edae91f75c94f
http://java.sun.com/javase/6/docs/ap...l#getLanguage()

This method provides the capability to get the ISO 639 language
code from a locale. I am looking for a C function that offers the
same service.

I know that a current setting can be queried by the function
"setlocale". But I do not see a function in the POSIX API to
extract ISO 639 codes from the usual naming conventions. Which is
the recommended way to retrieve such information?

http://opengroup.org/onlinepubs/0096...setlocale.html

This is off-topic on c.l.c. Try comp.unix.programmer. POSIX is
not C.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Markus Elfring]

>I have found two class libraries that have got the method "getLanguage".

>http://www.icu-project.org/apiref/ic...0edae91f75c94f
http://java.sun.com/javase/6/docs/ap...l#getLanguage()

This method provides the capability to get the ISO 639 language
code from a locale. I am looking for a C function that offers
the same service.

I know that a current setting can be queried by the function
"setlocale". But I do not see a function in the POSIX API to
extract ISO 639 codes from the usual naming conventions.
Which is the recommended way to retrieve such information?
http://opengroup.org/onlinepubs/0096...setlocale.html

This is off-topic on c.l.c. Try comp.unix.programmer.
POSIX is not C.

Can the requested functionality belong to a standard C library?

I see the use of specific language information constants (for "nl_langinfo()")
as another candidate to get the desired data. I find it not clear if a detail
like codeset name adheres to an ISO standard.
http://opengroup.org/onlinepubs/0096...anginfo.h.html
http://www.gnu.org/software/libc/man...-Fast-Way.html

Regards,
Markus

[CBFalconer]

Markus Elfring wrote:

>

>>I have found two class libraries that have got the method
"getLanguage".
http://www.icu-project.org/apiref/ic...0edae91f75c94f
http://java.sun.com/javase/6/docs/ap...l#getLanguage()

This method provides the capability to get the ISO 639 language
code from a locale. I am looking for a C function that offers
the same service.

I know that a current setting can be queried by the function
"setlocale". But I do not see a function in the POSIX API to
extract ISO 639 codes from the usual naming conventions.
Which is the recommended way to retrieve such information?

http://opengroup.org/onlinepubs/0096...setlocale.html

This is off-topic on c.l.c. Try comp.unix.programmer.
POSIX is not C.

Can the requested functionality belong to a standard C library?

This is still off topic for c.l.c. Also, please do not send e-mail
replies to things that can be handled in the newsgroup. F'ups set.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Ian Collins]

CBFalconer wrote:

Markus Elfring wrote:

>>>I have found two class libraries that have got the method
"getLanguage".
http://www.icu-project.org/apiref/ic...0edae91f75c94f
http://java.sun.com/javase/6/docs/ap...l#getLanguage()

This method provides the capability to get the ISO 639 language
code from a locale. I am looking for a C function that offers
the same service.

I know that a current setting can be queried by the function
"setlocale". But I do not see a function in the POSIX API to
extract ISO 639 codes from the usual naming conventions.
Which is the recommended way to retrieve such information?

http://opengroup.org/onlinepubs/0096...setlocale.html
This is off-topic on c.l.c. Try comp.unix.programmer.
POSIX is not C.

Can the requested functionality belong to a standard C library?

This is still off topic for c.l.c. Also, please do not send e-mail
replies to things that can be handled in the newsgroup. F'ups set.

I think F'up has a different meaning here, you declared a post OT on
c.l.c then set follow-ups to c.l.c...

An F'up indeed.

--
Ian Collins

[Antoninus Twink]

On 23 Oct 2008 at 20:15, Markus Elfring wrote:

I know that a current setting can be queried by the function
"setlocale". But I do not see a function in the POSIX API to extract
ISO 639 codes from the usual naming conventions. Which is the
recommended way to retrieve such information?

I'm slightly confused. The locale could be "C" or "POSIX"; otherwise,
can't you just look at its first two characters, which will be the
standard language code?

(I notice that "CBFalconer" has told you that your question is "off
topic". Of course, it is perfectly topical. CBF is one of the resident
trolls here who seeks to disrupt the newsgroup - please ignore him.)

[Kenny McCormack]

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:
....

>(I notice that "CBFalconer" has told you that your question is "off
topic". Of course, it is perfectly topical. CBF is one of the resident
trolls here who seeks to disrupt the newsgroup - please ignore him.)

To all newbies: Keep in mind that in this newsgroup, trolls are like
bacteria (and like witches in the land of Oz) - there are good trolls
and bad trolls. Twink & I are good trolls. CBF is a very bad troll.

[Markus Elfring]

POSIX is not C.

Does a programming interface exist in the C standard function library that
returns informations in ISO 639 data format from a locale?
http://en.wikipedia.org/wiki/ISO_639

Is the API situation any better in desktop environments like GNOME and KDE?

Regards,
Markus

[Markus Elfring]

I'm slightly confused. The locale could be "C" or "POSIX"; otherwise,

can't you just look at its first two characters, which will be the
standard language code?

Where is the data format officially documented for the locale naming convention?

Regards,
Markus

[Antoninus Twink]

On 25 Oct 2008 at 10:41, Markus Elfring wrote:

>I'm slightly confused. The locale could be "C" or "POSIX"; otherwise,
can't you just look at its first two characters, which will be the
standard language code?

Where is the data format officially documented for the locale naming
convention?

I think POSIX leaves it implementation-defined, except for insisting on
the existence of "POSIX" as the default locale, "C" as a synonymn for
"POSIX", and "" for an implementation-defined "native locale". Cf.
<http://www.opengroup.org/onlinepubs/000095399/utilities/locale.html>
and
<http://www.opengroup.org/onlinepubs/009695399/functions/setlocale.html>
Here's what the manpage for glibc's setlocale has to say about it:

A locale name is typically of the form language[_territory][.code�
set][@modifier], where language is an ISO 639 language code, territory
is an ISO 3166 country code, and codeset is a character set or encoding
identifier like ISO-8859-1 or UTF-8.

I don't know of an implementation with a different convention, but the
language lawyers in this group could probably dredge up some mainframe
from the 80s that does something different.

[CBFalconer]

Markus Elfring wrote:

>

>I'm slightly confused. The locale could be "C" or "POSIX"; otherwise,
can't you just look at its first two characters, which will be the
standard language code?

Where is the data format officially documented for the locale naming
convention?

Ignore Twink. He is a troll, who attempts to disrupt the
newsgroup, as does McCormack. If you reply to my email address
again I will consider you a troll and stop replying.

Look at the C-99 references in the following. They document
everything that is topical on c.l.c.

Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://c-faq.com/ (C-faq)
<http://benpfaff.org/writings/clc/off-topic.html>
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf(C99)
<http://cbfalconer.home.att.net/download/n869_txt.bz2 (pre-C99)
<http://www.dinkumware.com/c99.aspx (C-library}
<http://gcc.gnu.org/onlinedocs/ (GNU docs)
<http://clc-wiki.net/wiki/C_community:comp.lang.c:Introduction>

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Markus Elfring]

I don't know of an implementation with a different convention, but the

language lawyers in this group could probably dredge up some mainframe
from the 80s that does something different.

I do not like the consequences from this software design aspect that the data
format is implementation-defined. I do not see that the C standard function
library supports a direct mapping from a locale identifier to more language
informations like ISO codes.

I have got the impression that only external libraries from the approach
"International Components for Unicode" can provide the requested functionality
for the C/C++ programming language so far.
http://www.icu-project.org/apiref/icu4c/

Regards,
Markus

[Markus Elfring]

Look at the C-99 references in the following. They document

everything that is topical on c.l.c.

[...]

<http://benpfaff.org/writings/clc/off-topic.html>

I guess that it is on-topic to discuss open issues in the standard C library.
How are the chances that improved support for Unicode features will result in
adjustments for locale programming interfaces?

Regards,
Markus

[Richard Heathfield]

Markus Elfring said:

>Look at the C-99 references in the following. They document
everything that is topical on c.l.c.

[...]

> <http://benpfaff.org/writings/clc/off-topic.html>

I guess that it is on-topic to discuss open issues in the standard C
library.

Well, ish. But I saw nothing atopical about your original question. There
*is* a limit (although the group sports a small number of trolls who
appear to think otherwise), but I don't think you broke it...

How are the chances that improved support for Unicode features
will result in adjustments for locale programming interfaces?

....and I'd be delighted to answer your question if only I knew the answer!
You might get a more useful answer here in the next day or two, but on the
other hand you may well find that you get better joy in comp.std.c.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Flash Gordon]

Markus Elfring wrote, On 26/10/08 08:49:

>Look at the C-99 references in the following. They document
everything that is topical on c.l.c.

[...]

> <http://benpfaff.org/writings/clc/off-topic.html>

I guess that it is on-topic to discuss open issues in the standard C library.
How are the chances that improved support for Unicode features will result in
adjustments for locale programming interfaces?

There is a group comp.std.c specifically for discussing the standard
itself, as to how to programming in standard C. That group has more
people who are involved in the standardisation process than this group
so you are more likely to get an accurate answer as to whether the
standard might change over there. Be aware though that changes to the C
standard tend to take a long time to be implemented across the board, as
evidence the version released in 1999 is *still* not fully implemented
by most compilers.

Currently the best way to handle your problem is to use third-party
libraries and/or Posix if you are only concerned with Linux/Unix
--
Flash Gordon
If spamming me sent it to sm**@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/

[Antoninus Twink]

On 26 Oct 2008 at 8:49, Markus Elfring wrote:

>Look at the C-99 references in the following. They document
everything that is topical on c.l.c.

[...]

> <http://benpfaff.org/writings/clc/off-topic.html>

This is a lie. They document the opinion of *one individual* about
what's topical on clc.

I guess that it is on-topic to discuss open issues in the standard C
library.

Of course it is, as should be obvious to anyone with an ounce of common
sense.

Those who strut around pretending it's off-topic are never going to help
you anyway, so just ignore them and leave them to wallow in their
absurdities.

[Markus Elfring]

Currently the best way to handle your problem is to use third-party

libraries and/or Posix if you are only concerned with Linux/Unix

Would any software developer like to integrate the capability to query more
language informations like ISO 639 codes into locale programming interfaces by
the standard C library?

Can an extension like a symbol "_NL_IDENTIFICATION_LANGUAGE" for the function
"nl_langinfo" become part of the official API?
http://www.gnu.org/software/libc/man...formation.html

Regards,
Markus

[CBFalconer]

Markus Elfring wrote:

>

>Currently the best way to handle your problem is to use third-
party libraries and/or Posix if you are only concerned with
Linux/Unix

Would any software developer like to integrate the capability to
query more language informations like ISO 639 codes into locale
programming interfaces by the standard C library?

Can an extension like a symbol "_NL_IDENTIFICATION_LANGUAGE" for
the function "nl_langinfo" become part of the official API?

Of course it CAN. It won't, because anything of that nature would
make C highly system sensitive. Note that names begining with a
'_' character are generally reserved for the implementation.

Please don't delete attribution lines for material you quote.
Those are the initial lines of the general form "Joe wrote:".

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Ian Collins]

CBFalconer wrote:

Markus Elfring wrote:

>>Currently the best way to handle your problem is to use third-
party libraries and/or Posix if you are only concerned with
Linux/Unix

Would any software developer like to integrate the capability to
query more language informations like ISO 639 codes into locale
programming interfaces by the standard C library?

Can an extension like a symbol "_NL_IDENTIFICATION_LANGUAGE" for
the function "nl_langinfo" become part of the official API?

Of course it CAN. It won't, because anything of that nature would
make C highly system sensitive.

How?

Note that names begining with a
'_' character are generally reserved for the implementation.

Which is where Markus is proposing this goes.

--
Ian Collins

[user923005]

On Oct 26, 1:49*am, Markus Elfring <[e-mail]:

Look at the C-99 references in the following. *They document
everything that is topical on c.l.c.

[...]

*<http://benpfaff.org/writings/clc/off-topic.html>

I guess that it is on-topic to discuss open issues in the standard C library.

While such discussions are topical here, probably news:comp.std.c is
even better.

How are the chances that improved support for Unicode features will result in
adjustments for locale programming interfaces?

I use ICU.
http://icu-project.org/

[CBFalconer]

Ian Collins wrote:

CBFalconer wrote:

>Markus Elfring wrote:

.... snip ...

>>

>>Can an extension like a symbol "_NL_IDENTIFICATION_LANGUAGE" for
the function "nl_langinfo" become part of the official API?

Of course it CAN. It won't, because anything of that nature would
make C highly system sensitive.

How?

By forcing every implementation to understand and define whatever
is meant by "_NL_IDENTIFICATION_LANGUAGE" and "nl_langinfo".

>

>Note that names begining with a
'_' character are generally reserved for the implementation.

Which is where Markus is proposing this goes.

I don't know that. At any rate, all I said was "note".

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Nick Keighley]

On 25 Oct, 00:45, [e-mail] (Kenny McCormack) wrote:

In article <[e-mail]>,
Antoninus Twink *<[e-mail]:

(I notice that "CBFalconer" has told you that your question is "off
topic". Of course, it is perfectly topical. CBF is one of the resident
trolls here who seeks to disrupt the newsgroup - please ignore him.)

To all newbies: Keep in mind that in this newsgroup, trolls are like
bacteria (and like witches in the land of Oz) - there are good trolls
and bad trolls. *Twink & I are good trolls. *CBF is a very bad troll.

Twink and Kenny have this exactly backward. CBFalconer is sometimes
wrong (way too often wrong). But he is not deliberatly
disruptive of the Newsgroup. T&K rarely (*vanishingly* rarely)
post anything useful or constructive.

[Markus Elfring]

CBFalconer schrieb:

By forcing every implementation to understand and define whatever
is meant by "_NL_IDENTIFICATION_LANGUAGE" and "nl_langinfo".

Would you like to suggest different symbols and better function interfaces with
clear data structures to improve the involved API situation?

Regards,
Markus

[Kenny McCormack]

In article <0a**********************************@v72g2000hsv. googlegroups.com>,
Nick Keighley <ni******************@hotmail.comwrote:

>On 25 Oct, 00:45, [e-mail] (Kenny McCormack) wrote:

>In article <[e-mail]>,
Antoninus Twink *<[e-mail]:

>(I notice that "CBFalconer" has told you that your question is "off
topic". Of course, it is perfectly topical. CBF is one of the resident
trolls here who seeks to disrupt the newsgroup - please ignore him.)

To all newbies: Keep in mind that in this newsgroup, trolls are like
bacteria (and like witches in the land of Oz) - there are good trolls
and bad trolls. *Twink & I are good trolls. *CBF is a very bad troll.

Twink and Kenny have this exactly backward. CBFalconer is sometimes
wrong (way too often wrong). But he is not deliberatly
disruptive of the Newsgroup. T&K rarely (*vanishingly* rarely)
post anything useful or constructive.

I'm sure the Witch of the West would say that she (and Ms. East as well)
is/are a good witch. I respectfully, disagree.

You and CBF probably think you are the good ones, too.

[David R Tribble]

CBFalconer schrieb:

>By forcing every implementation to understand and define whatever
is meant by "_NL_IDENTIFICATION_LANGUAGE" and "nl_langinfo".

Markus Elfring wrote:

Would you like to suggest different symbols and better function interfaces with
clear data structures to improve the involved API situation?

IIRC, the current ISO C standard does not require the
implementation to be aware of any external environment variables
for its operation. (That's not to say that a given implementation
cannot use environment variable settings, it's just that ISO C does
not /require/ it.)

So it's not a question of symbol names, but about requiring
certain environment variables to exist in the first place. On some
systems, the very notion of "environment variable" is an unknown
concept.

Also, it's an uphill battle to add X/Open or POSIX functionality to
the ISO C standard library. How would MS/Win32 applications
deal with them, for example, in light of the fact that the Win32
platform already has its own locale functions?
FWIW, I've taken a different approach in my various proposals for
ISO C library enhancements. I borrow the most useful and most
general functionality from several sources (primarily POSIX and
Win32, but also others) and invent an entirely new set of function
and variable names to embody them. That way, no single existing
implementation is favored over the others, but the functionality
still covers all (or most) of them.

See
http://david.tribble.com/letters.html#c-proposals

-drt

[Markus Elfring]

David R Tribble schrieb:

Also, it's an uphill battle to add X/Open or POSIX functionality to
the ISO C standard library. How would MS/Win32 applications
deal with them, for example, in light of the fact that the Win32
platform already has its own locale functions?

Is there a growing demand to complete the standard programming interfaces?
Are more extensions needed for locale data to express personal preferences?

Regards,
Markus