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

[Yung-Jang Lee]

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.
>

Agreed.

But how to test different encoding with only one environment in Scilab
? It might be easy for language all base on one  encoding
(fr_FR.utf-8, zh_TW.utf-8,...*.utf-8) under LINUX,  but not easy  for
NON-UNICODE encoding environment,especially  under Windows. And patch
for 'setenv' and 'getenv'  is basically a fix for NON-UNICODE
encoding.


> 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.

No, case 2 and case 1 is independent.  Gettext's behavior is totally
different in this two cases. Must users use Scilab in case 1situation
under Vista and XP.

Case 2 is important for "advanced users" who may switch languages for
Scilab. But testing based on Case 2 can not ensure Scilab will
function well for most users, because their environment  is in 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.
>

Before this discussion, I have little experience with 'Case 2',
therefore the design of  encoding converting of either 5.0.3 or 5.1
only kept  'Case 1' in my mind.  So, in principle,  Scilab 5.0.3 (or
branch 5.1 or master)  shouldn't work for 'Case 2', because it failed
to convert string in function 'localeToTUF' for most "other"
languages.

However , since localeToUTF return the unconverted input text (an UTF8
sting)  if it fails to convert and that were just  fine for CASE 2.
This is the reason why CASE 2  also works for Scilab 5.0.3 in your
Chinese ('zh_CN') test.   But this feature is unreliable, and should
not be considered as normal situation.

--------------------------------function :
localeToUTF-----------------------------------
 .......
	if (iconv (localeToUTFConvert, (const char**)&inPtr,&inbytesleft,
&outPtr, &outbytesleft) == (size_t)(-1))
	{
		fprintf(stderr, "Error during call to localeToUTF: %s\n", strerror(errno));
		fprintf(stderr, "String Input: %s\n", inPtr);
		return buffer; // return unconverted text <------------------ Retrun
here for CASE 2
	}
 .....
------------------------------------------------------------------

In short, localization looks  correct for CASE 2 is just an "accident"
for Scilab  5.03 or 5.1 master. I need additional works to cover CASE
2.


TO COVER CASE 2, I MUST

   1. Detect current prototypes of 'gettext'.    If we can get
information  about setting of "Language for non-Unicode programs" by
Win API will  make things happy.  Otherwise, a simple test message for
function 'iconv'  may act as  a check for prototypes.


   2. Change the wrap of gettext , such as  _(String)  in
localization.h, to cover CASE 2 in

        #define _(String)  localeToUTF(gettext(String)) <---- for CASE 1
                           and
        #define _(String)  gettext(String) <---- for CASE 2

       We must ensure that in both case,  macro "_(String)" , return
an valid UTF8 string.


I will try to give a patch to cover CASE2 after period of Chinese New
Year. What is deadline of  Scilab 5.1 release ?


Regards,

Yung-Jang Lee