Re: libgcj/5031: LANG=fr_FR incorrectly translated into user.language/user.region

Re: libgcj/5031: LANG=fr_FR incorrectly translated into user.language/user.region

[tromey]

Synopsis: LANG=fr_FR incorrectly translated into user.language/user.region

Responsible-Changed-From-To: unassigned->tromey
Responsible-Changed-By: tromey
Responsible-Changed-When: Tue Jan  8 13:45:24 2002
Responsible-Changed-Why:
    I'm handling this.
State-Changed-From-To: open->closed
State-Changed-By: tromey
State-Changed-When: Tue Jan  8 13:45:24 2002
State-Changed-Why:
    I looked at this today.
    I think the best fix is to simply use one of the LC_*
    variables to choose the default Java locale.  This is the
    best we can do since Java locales and POSIX locales don't
    really work the same way.
    I've written a patch that does this; I chose to look
    at LC_MESSAGES since this seems like the most appropriate
    choice.
    I'm closing this PR since I'll be checking in my fix shortly.
    The fix will appear in gcj 3.1.
    Thanks for the report.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5031

libgcj/5031: LANG=fr_FR incorrectly translated into user.language/user.region

[michel.chevanne]

>Number:         5031
>Category:       libgcj
>Synopsis:       LANG=fr_FR incorrectly translated into user.language/user.region
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Dec 06 01:06:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Michel Chevanne
>Release:        gcc 3.0.2
>Organization:
>Environment:
Linux 2.2.18-SMP
Suse 7.1 distribution
>Description:

If I do : export LANG=fr_FR
then from a java program :
"user.language" is "LC"
and "user.region", "CT"

Sun Java correctly indicate user.langage=fr user.region=FR
>How-To-Repeat:
see description

import java.util.*;
public class Test {

    public static void main(String [] args) {
	System.err.println(System.getProperty("user.language"));	
	System.err.println(System.getProperty("user.region"));
}
}

Do also :

#include <unistd.h>
#include "stdlib.h"
#include "stdio.h"
#include <locale.h>


int main(char * argv [],int args)
{

  char *locale = setlocale (LC_ALL, "");
printf(locale);
}


>Fix:
The parsing is done in natSystem.cc at line 428,
The code does : 
char *locale = setlocale (LC_ALL, ""); 
and copy the first two chars to user.language

but a small test with a c program indicates that
the result of setLocale is :
LC_CTYPE=fr_FR;LC_NUMERIC=fr_FR;LC_TIME=fr_FR;LC_COLLATE=C;LC_MONETARY=fr_FR;LC_MESSAGES=fr_FR;LC_PAPER=fr_FR;LC_NAME=fr_FR;LC_ADDRESS=fr_FR;LC_TELEPHONE=fr_FR;LC_MEASUREMENT=fr_FR;LC_IDENTIFICATION=fr_FR

so the code parse "LC_CT" instead of "LC_NM".

A quick verification on a HP UX 10.20/GCC 2.7.2.2 indicates
that the result of setLocale is fr_FR.roman8 fr_FR.roman8 fr_FR.roman8 fr_FR.roman8 fr_FR.roman8 fr_FR.roman8
(with LANG=fr_FR.roman8)

So the best way to proceed it probably :
to look for the string "=", if present start the parsing after
the "="
otherwise, do a before

>Release-Note:
>Audit-Trail:
>Unformatted: