[Scilab-Dev] Localization Scilab / Scipad

[Sylvestre Ledru]

OK, seems to me that I haven't been clear enough.

First, there is a list of advantages of switching to gettext:
* we benefit from all the gettext tools to manage localization files
(extract, update, build, check validity...)
* we use a defacto standard, thanks to that we can benefit some
fantastic collaborative tools like Launchpad - translation:
https://translations.launchpad.net/scilab/
* Scipad strings could go on this website and will be translated with
the rest of Scilab.
* most of the encoding issue are already managed by gettext (and thanks
to Yung-Jang, we fixed the unmanaged cases).
* we would use the same format in Scilab everywhere: better consistency
(technical and literary), won't need to have to translation procedure,
easier scripting, some strings are used in both Scilab and Scipad
(Cancel, OK, File...).

And other point which is interesting to raise is that when gettext
cannot find a translation, it automatically switch to the default
language (english). It can sounds as a detail but it is pretty
important.


Le dimanche 29 juin 2008 à 11:44 +0200, François Vogel a écrit :
> Enrico Segre said on 29/06/2008 10:42:
> > For the first launch of scipad in a session, we could make provisions in
> > scipad.sci for starting scipad with the desired language instead of
> > reading it from the saved preference file.
> 
> Hmm, yes this is of course technically possible, but does this mean 
> that the Scipad language would no longer be saved in the pref file any 
> more? 
Niet, I was thinking about adding a Scilab function to manage this
information. Like setDefaultLanguage("bz_FR") for example. This one
could be use by Scipad, isn't it?

> Currently the scheme is that Scipad starts in english the first 
> time, then the user can change the language from Scipad, and this is  
> preference which is automatically saved across Scipad sessions.
Well, it is a "Windows user approach" here.
Under Linux/Unix, it is pretty rare to be able to change the locale of
an application being launched. The way to do it is to rely on the locale
provided by the system in the env (no matter what means the "system").

> > However, please note that the current localization set of scilab is a
> > small subset of that of scipad. Would really have sense to force the
> > scipad language to be the default choice for scilab, when more choices
> > are available (and the user might have already chosen one)? Imho the
> > problem stays even if the scilab set grows, as long as the two language
> > sets don't coincide.
Well you have a point!
For now, I think we will have both simplified and tradtionnal Chinese +
Russian + French + maybe Indonesian & Italian (despite the fact that we
are a few Bretons in the Scilab team, tragically, we won't have this
fanstatic and usefull language into Scilab 5).
We really don't overlap on this.

The case "Scilab is managing this case but not Scipad" won't occur too
much since we can ask to translator to also translate Scipad.
The other one will be much more common.
A solution can be:
* on the startup of Scilab, check the locale of the user, if we are
handling it, fine, tell it to Scipad and we are all cool.
* We don't handle it but Scipad does. We still send the information and
Scipad is managing it (I will have some work to do on this if we select
this solution).


I want to insist that, at least on the first start, it is important from
the user-friendly point of view to have Scipad starting in the same
language as Scilab (even I am sure you agree on this).

> > Perhaps what you want is that at first run of scilab (no scipad
> > preference file existing yet) the default scipad language matches that
> > of scilab?
> 
> I guess this is what Sylvestre was after. On this, OK, why not, 
> instead of using the default english fallback we could use the Scilab 
> language if the localization files exist in Scipad. We would have to 
> map Scilab languages to Scipad languages, and have a fallback in case 
> there is no match.
Moving to gettext, you probably wouldn't have to to this match ;)

> > ps: what about making the debugger work, first?
> 
> This is also my very point of view.
> 
> Scipad localization works fine. Honestly I do not see any point for 
> changing it. Uniformisation with Scilab or whatnot is a very weak 
> argument IMO.
I do think that uniformation is a strong argument. As you just said, we
don't overlapp. Having two way to manage localization is a brake and
won't fix this trend. Scilab & Scipad will be translated in the same
time.

> We can fix later what is already working in Scipad, when major bugs 
> like the broken debugger get fixed. What is the opteam progress on 
> this? We made proposals and didn't read your thoughts on them.
I am handling it.

Sylvestre