[GRASS5] another approach to i18n for tcltkgrass; former one revoked

Alex_Shevlakov · May 20, 2002, 11:36am

Hi all,

it seems that the method proposed before for i18n tcltkgrass has a major flaw,
that is to load a huge file with messages and parse them makes tcltkgrass slow.

This is why using msgcat for the purpose of i18n seems to me not a good choice
now.

Another method would be to place the translated script 'menu.tcl' and
modules scripts to src/locale/$LCL/tcltkgrass directory and copy them if they are needed to $GISBASE/tcltkgrass.

This method does not deal with the tcl/tk version issues, so it is safe.

I just commited files related to the second method.

--alex

Glynn_Clements · May 20, 2002, 1:15pm

Alex Shevlakov wrote:

it seems that the method proposed before for i18n tcltkgrass has a
major flaw, that is to load a huge file with messages and parse them
makes tcltkgrass slow.

Are you referring to the startup, or to normal operation?

BTW, is the "msgcat" package written in Tcl, or does it use the
functions from libintl/libc?

This is why using msgcat for the purpose of i18n seems to me not a
good choice now.

Another method would be to place the translated script 'menu.tcl' and
modules scripts to src/locale/$LCL/tcltkgrass directory and copy them
if they are needed to $GISBASE/tcltkgrass.

That would mean that the locale was fixed at install time; it should
be determined at run time, according to $LANG or $LC_MESSAGES.

Also, the generation of the translated scripts needs to be automatic.
If a developer makes any changes to tcltkgrass, they shouldn't have to
change multiple versions.

--
Glynn Clements <glynn.clements@virgin.net>

Russell_Nelson · May 20, 2002, 2:08pm

Glynn Clements writes:
> Also, the generation of the translated scripts needs to be automatic.
> If a developer makes any changes to tcltkgrass, they shouldn't have to
> change multiple versions.

Yeah, the whole idea behind i18n is to separate out the code from
the messages. That way, the programmers can change the code in
magical and mysterious ways without needing to interact with
translators in any way. For example, the code can be recompiled, menu
entries moved around, or even translated from Tcl/Tk into C or Python
or Perl, and the programmers never need to touch the translations.

I don't know if Tcl/Tk supports libintl in the current version.
Switching to a version that does is much, much better than siccing
translators on the tcltkgui source code.

Alex_Shevlakov1 · May 21, 2002, 11:04am

--- Russell Nelson <nelson@crynwr.com> wrote:

Glynn Clements writes:
> Also, the generation of the translated scripts
needs to be automatic.

It can be made automatic, if a complicated software
like "Socratus Pro Win" was used. Although I'm really
not sure the quality of translation would be normal,
and I doubt people would like it. Perhaps you know a
better translation program (and free software).

> If a developer makes any changes to tcltkgrass,
they shouldn't have to
> change multiple versions.

Yeah, the whole idea behind i18n is to separate out
the code from
the messages. That way, the programmers can change
the code in
magical and mysterious ways without needing to
interact with
translators in any way.

If a developer changes code, she does not need to
contact translators.
It's generally translators mess to follow the code
changes. This is what I think NLS maintenance is.

For example, the code can

be recompiled, menu
entries moved around, or even translated from Tcl/Tk
into C or Python
or Perl, and the programmers never need to touch the
translations.

Have you ever dealt with issues or just theoretizing?

I don't know if Tcl/Tk supports libintl in the
current version.
Switching to a version that does is much, much
better than siccing
translators on the tcltkgui source code.

It's free software.

BTW, it becomes clear if you look at menu.tcl (or any
module script), that there is no code in them. These
files are 95% messages, English or whatever. One of
the reasons why, in this particular case, I chose to
have these 212 tiny files instead of the one named
"ru.msg", is that sum of the disk space occupied would
be almost twice lower. This is because you need to
write each string twice (in both languages) in msgcat
loaded file, and only once in the chosen option. So
I've been also thinking about saving NLS translators
time, because I'm an NLS translator.

--alex

__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

Alex_Shevlakov1 · May 21, 2002, 11:42am

--- Glynn Clements <glynn.clements@virgin.net> wrote:

Alex Shevlakov wrote:

> makes tcltkgrass slow.

Are you referring to the startup, or to normal
operation?

I was referring mainly to load time (startup).
This made things slow in overall, though. I used a
make-up file combined of about 100
:msgcat:mc 'eng_message' 'ru_message' lines. The test
showed slow. This is why I think of not using msgcat.

BTW, is the "msgcat" package written in Tcl, or does
it use the
functions from libintl/libc?

This is TCL.(

proc msgcat::mc {src args} {
# Check for the src in each namespace starting
from the local and
# ending in the global.

    variable msgs
    variable loclist
    variable locale

    set ns [uplevel 1 [list ::namespace current]]

    while {$ns != ""} {
        foreach loc $loclist {
            if {[info exists msgs($loc,$ns,$src)]} {
                if {[llength $args] == 0} {
                    return $msgs($loc,$ns,$src)
                } else {
                    return [uplevel 1 \
                            [linsert $args 0 ::format
$msgs($loc,$ns,$src)]]
                }
            }
        }
        set ns [namespace parent $ns]
    }
    # we have not found the translation
    return [uplevel 1 \
            [linsert $args 0 [::namespace origin
mcunknown] $locale $src]]
}

> This is why using msgcat for the purpose of i18n
seems to me not a
> good choice now.
>
> Another method would be to place the translated
script 'menu.tcl' and
> modules scripts to src/locale/$LCL/tcltkgrass
directory and copy them
> if they are needed to $GISBASE/tcltkgrass.

That would mean that the locale was fixed at install
time; it should
be determined at run time, according to $LANG or
$LC_MESSAGES.

Please see the locale/Gmakefile. If $LCL is defined at
run-time, it is defined the same for mofiles and
tcltkgrass, i.e., once define both.

--alex

__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

Russell_Nelson · May 21, 2002, 1:43pm

Alex Shevlakov writes:
> Have you ever dealt with issues or just theoretizing?

I've compiled code that uses libintl, and modified code that uses
message catalogs, but have never written such code from scratch. Have
I ever dealt with issues or am I just theoretizing?

> It's free software.

But it's not free to install it, and if installing it breaks something
else, then it is rather expensive software.

> BTW, it becomes clear if you look at menu.tcl (or any
> module script), that there is no code in them.

I already looked at menu.tcl and a couple of module scripts. There's
code in them. If I wanted to write a more normal gui for grass
(e.g. where the menu was at the top of the window, and what grass
calls a "monitor" was automatically started up), I'd do it in Python,
not Tcl/Tk. If the translations get written into menu.tcl and the
module tcl code, I would have to extract the translations by parsing
the tcl code from Python. That's certainly possible, however it
presumes that I either cheat and parse the existing structure for its
messages and that nobody is ever going to change the code in menu.tcl
or the module tcl code. Or else I have to write a full Tcl
interpreter in Python.

To put it a different way: to my eyes, there's code in those files.
If, on the other hand, you are thinking of them as
data-with-a-particular-syntax-that-matches-tcl-code, then I'm happy
with that. Perhaps you could document the syntax of those files
apart from whatever documentation may exist for tcl code?

> These files are 95% messages, English or whatever. One of the
> reasons why, in this particular case, I chose to have these 212
> tiny files instead of the one named "ru.msg", is that sum of the
> disk space occupied would be almost twice lower.

If I was worried about disk space, I wouldn't install GRASS!!

Glynn_Clements · May 21, 2002, 3:51pm

Alex Shevlakov wrote:

> > Also, the generation of the translated scripts
> needs to be automatic.

It can be made automatic, if a complicated software
like "Socratus Pro Win" was used. Although I'm really
not sure the quality of translation would be normal,
and I doubt people would like it. Perhaps you know a
better translation program (and free software).

I wasn't talking about translating the natural language strings
automatically. I was referring to keeping the translation information
separate from the code (as Russell mentioned). E.g. rather than
modifying the Tcl files directly, creating a sed script (analogous to
a message catalogue) which would translate the Tcl files.

> > If a developer makes any changes to tcltkgrass,
> they shouldn't have to
> > change multiple versions.
>
> Yeah, the whole idea behind i18n is to separate out
> the code from
> the messages. That way, the programmers can change
> the code in
> magical and mysterious ways without needing to
> interact with
> translators in any way.

If a developer changes code, she does not need to
contact translators.
It's generally translators mess to follow the code
changes. This is what I think NLS maintenance is.

The way that the C code is internationalised, changes to code (as
opposed to message strings) don't require any effort from the L10N
maintainers.

Also, there's still the issue of selecting the locale at run-time,
rather than compile time. This shouldn't be much work, and shouldn't
result in any significant performance penalty.

--
Glynn Clements <glynn.clements@virgin.net>

Glynn_Clements · May 21, 2002, 4:04pm

Alex Shevlakov wrote:

> > makes tcltkgrass slow.
>
> Are you referring to the startup, or to normal
> operation?

I was referring mainly to load time (startup).
This made things slow in overall, though. I used a
make-up file combined of about 100
:msgcat:mc 'eng_message' 'ru_message' lines. The test
showed slow. This is why I think of not using msgcat.

> BTW, is the "msgcat" package written in Tcl, or does
> it use the
> functions from libintl/libc?

This is TCL.(

OK, that would explain the performance hit. I had initially assumed
that it was just Tcl bindings for the corresponding libintl/libc
functionality.

> > This is why using msgcat for the purpose of i18n
> seems to me not a
> > good choice now.
> >
> > Another method would be to place the translated
> script 'menu.tcl' and
> > modules scripts to src/locale/$LCL/tcltkgrass
> directory and copy them
> > if they are needed to $GISBASE/tcltkgrass.
>
> That would mean that the locale was fixed at install
> time; it should
> be determined at run time, according to $LANG or
> $LC_MESSAGES.

Please see the locale/Gmakefile. If $LCL is defined at
run-time, it is defined the same for mofiles and
tcltkgrass, i.e., once define both.

locale/Gmakefile is run at *install* time. "run time" is when the user
runs "tcltkgrass". Currently, if NLS support is enabled, the Russian
versions will be installed over the English versions. Which isn't
acceptable.

The correct solution is to install the localised versions to a
separate directory, and have tcltkgrass source the appropriate version
depending upon $env(LC_MESSAGES), or $env(LANG) if the former is
unset.

--
Glynn Clements <glynn.clements@virgin.net>