[Scilab-Dev] PATCH for set/get environment variables

[Allan CORNET]

Hi,

First , i checked your test about setgetenv for each language.
If language configuration of your Windows is correct, it works :)
Problem is that this test is "system dependant", we need to split this test to check if it is correct on a current system.
I would prefer to have a only test which works everywhere.

Yes , there are 2 cases for windows like you describe.
Case 2 is VERY important because Vista is Multilanguage and XP too. 
And if it works with case 2 , it will work for case 1.

If I try Scilab 5.0.3 with setdefaultlanguage('zh_CN') on my vista (French,english,chinese), localization seems to be correct (menus enabled and strings).
Now, if I try current version of scilab (branch 5.1 or master) result is not correct (menus grayed, incorrect string).
With a chinese O.S , it works.

Can we consider this, like a regression or not ?

Best regards 

Allan :)

 
-----Message d'origine-----
De : Yung-Jang Lee [mailto:yjlee123 at gmail.com] 
Envoyé : lundi 26 janvier 2009 18:39
À : Scilab dev list; Allan CORNET; Sylvestre Ledru
Objet : Re: [Scilab-Dev] PATCH for set/get environment variables

Allan, Sylvestre :

Behavior of native 'gettext' may not in usual way in Allan's testing
of Chinese-Windows. And this cause the failure of testing, I think.

Usually, string return from native 'gettext' is in system encoding
rather than UTF8.  But from tracing the problems Allan reported in
this thread, I find that if "Language for non-Unicode programs" of
"Advanced option" is not compatible  with the region selected with
"Regional option" of ""Regional and Language options" in control panel
Windows, return string of 'gettext' is in UTF8 instead of system
encoding.

To resolve this problem, we need cover two prototypes of 'gettext'

   case 1.   system_locale_string gettext(char *key)

                 and

   case 2.   UTF8_string gettext(char *key)

Case 1 is for most Windows environment and being handled by current
Scialb5.X implementation. Case 2 only occur for multilanguage
environment when user change the region with "Regional option"  but
not change the "Language for non-Unicode programs" of "Advanced
option".


If it is what I expected, current implementation still works for most
single language environment. Therefore , to test Scilab localization ,
it need single language environment for each language.

Case 2 is quite unusual. I suggest wait for next few releases to fix
it when additional information are gathered.

As to Sylvestre recent change of  about localization,

 http://gitweb.scilab.org/?p=scilab;a=commitdiff;h=7c4255abc485b557f610370ff0530b75b5cc5e6

It look fine and seems not  related with Allan's reports in this
thread. But from the comments you put on  file 'localizatioJava.h'

----------------------------------------localizatioJava.h-----------------------------------
/* This piece of code has been written because of the bug #4005
 * in version 5.0, we were using two localization system (native and
 * Java).
 * Now, only the native one is used.
 * However, for an unknown reason, gettext() is not working. Only
 * dgettext is */
#define scigettext(String1) dgettext(NAMELOCALIZATIONDOMAIN,String1)
-----------------------------------------------------------------------------

I would suggest you replace macros 'scigettext' with

#define scigettext(String1) localeToUTF(gettext(String1))

just like macros  _(String)  in localozation.h

---------------------------------------------------------------------------
#define _(String)  localeToUTF(gettext(String))/** for console message*/
--------------------------------------------------------------------------


Regards,

Yung-Jang Lee
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff-zh_CN.JPG
Type: image/jpeg
Size: 106738 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/dev/attachments/20090127/0d79db46/attachment.jpe>