Hi all,
I'd like to attempt making permanent changes to tcltk scripts (especially,
tcltkgrass) code in order to internationalize them. As much as I know, there is a Tcl built-in 'msgcat' command allowing to internationalize messages. I have previously translated the whole package of tcltkgrass to Russian language and distributed it alone (http://motivation.ru/src). In order to have all i18n options in one distribution with GRASS, I think about some simple changes done, namely:
proc create_entry in gui.tcl to look like:
label $path.label$n -anchor w -padx 2 -text [::msgcat::mc $description]
instead of:
label $path.label$n -anchor w -padx 2 -text $description (change 1)
with two lines added in the beginning:
package require msgcat
::msgcat::mcload [file join [file dirname [info script]] msgs]
This would allow to read all messages in interface_build boxes (i.e., modules boxes) in NL, granted in the same directory with gui.tcl (i.e., main) there is a catalogue 'msgs' with files fr.msg, de.msg, ru.msg, etc. (all except for the subtitle description line in blue which I still have no idea how to).
The second needed change is (oh, long work) menu.tcl: replace all "strings"
with '::msgcat::mc "strings"'. This would make main menu in NL.
I just tested all these items to work fine on my computer (Linux TCL/Tk 8.3).
Any ideas/comments are welcome.
--alex
Alex Shevlakov wrote:
I'd like to attempt making permanent changes to tcltk scripts
(especially, tcltkgrass) code in order to internationalize them. As
much as I know, there is a Tcl built-in 'msgcat' command allowing to
internationalize messages.
AFAICT, the msgcat package was added in Tcl 8.1; versions prior to
that won't have it.
Personally, I don't think that it's reasonable to require 8.1+ in
order to use tcltkgrass. Instead, any changes should be made in such a
way that tcltkgrass continues to work with older versions of Tcl
(albeit without I18N).
--
Glynn Clements <glynn.clements@virgin.net>
On Fri, May 17, 2002 at 02:09:16PM +0100, Glynn Clements wrote:
Alex Shevlakov wrote:
> I'd like to attempt making permanent changes to tcltk scripts
> (especially, tcltkgrass) code in order to internationalize them. As
> much as I know, there is a Tcl built-in 'msgcat' command allowing to
> internationalize messages.
AFAICT, the msgcat package was added in Tcl 8.1; versions prior to
that won't have it.
Alex: What other possible drawbacks of your solution can you think of?
Personally, I don't think that it's reasonable to require 8.1+ in
order to use tcltkgrass. Instead, any changes should be made in such a
way that tcltkgrass continues to work with older versions of Tcl
(albeit without I18N).
I agree.
Somehow we must make sure that GRASS still works with older tcltk version.
This does not mean we do not want internationalisation,
we just have to find a way to implement it.
Without knowing much about it:
Could a preprocessing step be used to prepare the
tcltk script for the different tcltk version?
Thus it might just remove the internatiolisation code
for people not wanting out or not having the modern tcltk version.
--->[Quoting Bernhard Reiter <bernhard@intevation.de>:]
On Fri, May 17, 2002 at 02:09:16PM +0100, Glynn
Clements wrote:
> Alex Shevlakov wrote:
>
> > I'd like to attempt making permanent changes to
> > tcltk scripts (especially, tcltkgrass) code in
> > order to internationalize them. As much as I know,
> > there is a Tcl built-in 'msgcat' command allowing
> > to internationalize messages.
>
> AFAICT, the msgcat package was added in Tcl 8.1;
> versions prior to that won't have it.
Alex: What other possible drawbacks of your solution
can you think of?
> Personally, I don't think that it's reasonable to
> require 8.1+ in order to use tcltkgrass. Instead, any
> changes should be made in such a way that tcltkgrass
> continues to work with older versions of Tcl (albeit
> without I18N).
I agree. Somehow we must make sure that GRASS still
works with older tcltk version. This does not mean we
do not want internationalisation, we just have to find
a way to implement it.
Without knowing much about it: Could a preprocessing
step be used to prepare the tcltk script for the
different tcltk version? Thus it might just remove the
internatiolisation code for people not wanting out or
not having the modern tcltk version.
I do not agree. Upgrading Tcl/Tk is one minute job.
Your proposition requires special procedures, branching
developement tree, special configure options, etc.
Progress in software sorrounded grass is certainty, we
cannot go against the stream, beacause we go to nowhere.
--
http://ibiblio.org/ser/ | http://it-zone.org/
_________________________________________________________
tldp.org|gnu.org|hyperreal.info|pld-linux.org|it-zone.org
"The moon is made of green cheese." -- John Heywood
ser@it-zone.org wrote:
I do not agree. Upgrading Tcl/Tk is one minute job.
Maybe for you; but not for everyone. In some cases, installing another
version simply may not be an option.
--
Glynn Clements <glynn.clements@virgin.net>
On Fri, May 17, 2002 at 05:24:09PM +0200, ser@it-zone.org wrote:
--->[Quoting Bernhard Reiter <bernhard@intevation.de>:]
> I agree. Somehow we must make sure that GRASS still
> works with older tcltk version. This does not mean we
> do not want internationalisation, we just have to find
> a way to implement it.
>
> Without knowing much about it: Could a preprocessing
> step be used to prepare the tcltk script for the
> different tcltk version? Thus it might just remove the
> internatiolisation code for people not wanting out or
> not having the modern tcltk version.
I do not agree. Upgrading Tcl/Tk is one minute job.
Well most users are not in a position to do this.
Your proposition requires special procedures, branching
developement tree, special configure options, etc.
I can see no other option, if we want i18n early.
Progress in software sorrounded grass is certainty, we
cannot go against the stream, beacause we go to nowhere.
This argumentation is against my experience with most Free Software
projects. Many developers and the vast majorities of the users are quite
reluctant to upgrade to newer versions if the component is already
established. There must be a real incentive for people to upgrade.
I cannot see this for most users for tcltk.
Keep the requirements as low as practical is a wise approach.
Hi all,
a simple stub that does not require new configure options is:
if [catch {package require msgcat}] {
puts stderr "Packgage msgcat is not present - message translation disabled"
proc G_msg {message} {
return $message
}
} else {
::msgcat::mcload [file join [file dirname [info script]] msgs]
proc G_msg {message} {
return [::msgcat::mc $message]
}
}
I do not expect any potential problems here. The proposed changes (again):
gui.tcl:
the above header (without stderr comment) would be present and create_entry modified as:
label $path.label$n -anchor w -padx 2 -text [G_msg $description]
menu.tcl as:
set monitors_menu {
[G_msg "Start"] "" { (...etc)
Thanks,
--alex
On Fri, May 17, 2002 at 02:09:16PM +0100, Glynn Clements wrote:
Alex Shevlakov wrote:
> I'd like to attempt making permanent changes to tcltk scripts
> (especially, tcltkgrass) code in order to internationalize them. As
> much as I know, there is a Tcl built-in 'msgcat' command allowing to
> internationalize messages.
AFAICT, the msgcat package was added in Tcl 8.1; versions prior to
that won't have it.
Personally, I don't think that it's reasonable to require 8.1+ in
order to use tcltkgrass. Instead, any changes should be made in such a
way that tcltkgrass continues to work with older versions of Tcl
(albeit without I18N).
--
Glynn Clements <glynn.clements@virgin.net>
--- Bernhard Reiter <bernhard@intevation.de> wrote:
I still think it should be mostly folded into 5.1.x.
But right now it looks like stuff will go into 5.0.1
or 5.0.2,
if it is stable.
I hope it is stable. The only question is if i18n breaks some systems with separate libintl.
To be sure if it is stable, it would be good to have a number of testers with NLS on their systems. So far, the status of i18n changes:
a set of src.postgresql modules (Alex) + s.surf.rst(Artem) - done (with .po files);
libgis - done, .po file exists; (Alex). Should the Gmakefile be modified to be linked to $INTLLIB? It compiles without it.
tcltkgrass (proposed, can be done rather quick);
configure.in, config.h.in, Makefile.in are modified to check for gettext in libc or in separate libintl, to check if the user had --with-nls enabled, to build .mo files if both checks are ok and to install them to $INST_DIR/locale; (Glynn, Alex, Markus)
locale.c and glocale.h in src tree added; (Glynn, Alex)
In release 5.0rel4 - the above changes should be present except for libgis.
--alex
Alex Shevlakov wrote:
> I still think it should be mostly folded into 5.1.x.
> But right now it looks like stuff will go into 5.0.1
> or 5.0.2,
> if it is stable.
I hope it is stable. The only question is if i18n breaks some systems
with separate libintl.
The changes to libgis will.
libgis - done, .po file exists; (Alex). Should the Gmakefile be
modified to be linked to $INTLLIB?
The simplest fix is to change the definition of GISLIB in make.mid,
i.e.
GISLIB = -lgis $(INTLLIB)
Otherwise, every program which linked against libgis would need to
have $(INTLIB) added to the link command.
It compiles without it.
It will on Linux, as dgettext() etc are part of GNU libc. On platforms
with a separate libintl, the only programs which will link
successfully are those which explicitly link against libintl, i.e.
grass.postgresql/* and s.surf.rst.
--
Glynn Clements <glynn.clements@virgin.net>