[Scilab-Dev] Localization Scilab / Scipad

Enrico Segre enrico.segre at weizmann.ac.il
Sun Jun 29 15:47:49 CEST 2008


Hi Sylvestre,

> First, there is a list of advantages of switching to gettext:

no need to convince at least myself, on the long term I think it will
pay off, for all the reasons you write.

"However": 

-it is a somehow lower priority for us at this instant of time

-we still have to find the optimal solution for tcl to read .po files.
Once we're there, we can discuss, and probably transform automatically
our .msg files in .po format. 

So far we staid with msgcat because there was no point in trying to do
better (msgcat was working fine, we had our tool, scilab didn't have so
many other languages, nor the prespective to have many soon by
collaborative effort [launchpad])

At the time we started to set up the localization of scipad, we were
definitely aware of gettext, the available tools and its added value,
but as I remember we didn't find a suitable glue with tcl. That is why
we staid with msgcat. If something new came up in the last three years,
and someone knows about, suggestions are welcome.

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

lack of fallback is another limitation of msgcat we're aware of. This is
why we resorted to string labels coinciding with the english text
itself, but it is not a solution we're too happy with.

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

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

ok, we could think of such things, and of having a mapping table for
fallback languages (next of kins), etc. etc. Technically possible, I
would discuss details later on, if and when we get that far.

Enrico




More information about the dev mailing list