Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
msgcat broken?
227 views
Skip to first unread message
Torsten Berg
Feb 25, 2021, 2:42:14 AM2/25/21
to
Hi,
consider this:
% info pa
8.6.10
% package require msgcat
1.6.1
% namespace import msgcat::*
% mclocale
de_de
% msgcat::mcpreferences
de_de de {}
% mc Cancel
Cancel
So far, so fine. I know the locale is German but as no translations have been loaded (so I assume), I do not get any translated string. Or should the translation work already here? At least there is no command in msgcat to transparently just load what Tcl knows about a language (i.e. the msg catalogues in $::tk_library/msgs).
% namespace eval ::tk {msgcat::mc Cancel}
Cancel
OK, nothing here either. So now I follow the procedure you can find on wiki page https://wiki.tcl-lang.org/page/msgcat (but not in the msgcat manual, that should be added there at least!)
% mcload [file join $::tk_library msgs]
1
% mcpreferences
de_de de {}
% mc Cancel
Cancel
% namespace eval ::tk {mc Cancel}
Abbruch
Now, this is surprising. After loading the German translation, my string still has no translation although I know it is in the message catalogue. The trick is (looking at $::tk_library/msgs/de.msg) that the translations are put into the ::tk namespace and are thus only visible there! Why? This means that they will not be found in the global namespace I am using here and where I issued the [mcload] command. What is the reasoning behind this behaviour? (Further, I could not find that de.msg file in the Tcl source code at https://core.tcl-lang.org/tcl/dir?ci=5752520ea35ef823&name=library/msgs ... where is this file or do I have some wrong installation here??)
OK, so I thought it will work with tk_messageBox as this is a tk command:
% tk_messageBox -type okcancel -message test
But no, the button still says "Cancel"
% namespace eval ::tk {tk_messageBox -type okcancel -message test}
No change either. The button still says "Cancel and not "Abbruch".
To me, this seems broken. I should be able to expect that my translations just work when I have loaded them. But it seems that Tk never evaluates the setting of the button text in the ::tk namespace.
Any insights? Am I doing something wrongly?
consider this:
% info pa
8.6.10
% package require msgcat
1.6.1
% namespace import msgcat::*
% mclocale
de_de
% msgcat::mcpreferences
de_de de {}
% mc Cancel
Cancel
So far, so fine. I know the locale is German but as no translations have been loaded (so I assume), I do not get any translated string. Or should the translation work already here? At least there is no command in msgcat to transparently just load what Tcl knows about a language (i.e. the msg catalogues in $::tk_library/msgs).
% namespace eval ::tk {msgcat::mc Cancel}
Cancel
OK, nothing here either. So now I follow the procedure you can find on wiki page https://wiki.tcl-lang.org/page/msgcat (but not in the msgcat manual, that should be added there at least!)
% mcload [file join $::tk_library msgs]
1
% mcpreferences
de_de de {}
% mc Cancel
Cancel
% namespace eval ::tk {mc Cancel}
Abbruch
Now, this is surprising. After loading the German translation, my string still has no translation although I know it is in the message catalogue. The trick is (looking at $::tk_library/msgs/de.msg) that the translations are put into the ::tk namespace and are thus only visible there! Why? This means that they will not be found in the global namespace I am using here and where I issued the [mcload] command. What is the reasoning behind this behaviour? (Further, I could not find that de.msg file in the Tcl source code at https://core.tcl-lang.org/tcl/dir?ci=5752520ea35ef823&name=library/msgs ... where is this file or do I have some wrong installation here??)
OK, so I thought it will work with tk_messageBox as this is a tk command:
% tk_messageBox -type okcancel -message test
But no, the button still says "Cancel"
% namespace eval ::tk {tk_messageBox -type okcancel -message test}
No change either. The button still says "Cancel and not "Abbruch".
To me, this seems broken. I should be able to expect that my translations just work when I have loaded them. But it seems that Tk never evaluates the setting of the button text in the ::tk namespace.
Any insights? Am I doing something wrongly?
Harald Oehlmann
Feb 25, 2021, 3:52:30 AM2/25/21
to
thank you for the tests.
May I comment some points:
a) namespaces:
Message catalogue items are saved with the parameters namespace and locale.
If you do a lookup, with msgcat::mc, you have the current namespace and
locale set. msgcat::mc searches all locales in mcpreferences (de_de, de,
default) and all anmespaces and parent namespaces.
So, if you want to set cancel for all namespaces for all german
languages, you execute:
msgcat::mcset de Cancel "Abbruch"
in the global namespace.
Pagages don't do that, as translations are package local and not global.
About tk:
for me:
-start wish8.6.11 on windows
% tk_messageBox -type okcancel -message test
Gives German buttons.
As this is not the case for you, there might be an issue with your
installation or a bug. May you give more information (platform,
installation etc) ?
Thank you,
Harald
Torsten Berg
Feb 25, 2021, 8:07:36 AM2/25/21
to
Hi Harald,
thanks for the explanation. I know about the search path of messages and that is why I can't see the translation. msgcat doesn't look into the ::Tk namespace, only in my current namespace and parent namespaces, but not in other "sibling namespaces". This is also understandable and feels the right way to do. But why then does the de.msg file eval the translations in the ::tk namespace? This makes them unavailable in the global namespace.
Hm, maybe this really indicates that something is wrong with my installation. Therefore I asked about the de.msg file in the source code distribution of Tcl. I now found it. It is not in the Tcl code but in the Tk code:
https://core.tcl-lang.org/tk/artifact/d2055bbb5906f1ca
So, I can at least say that my de.msg file is the one I want to have, but then, why does it evaluate the translations in the ::tk namespace, making the unavailable in the global namespace?
I am working on macOS here and I built Tcl/Tk 8.6.10 from the source code on my Mac (macOS 10.15.7, German version). I use the bundled Wish app. When I start it and type in what you typed on Windows, I get what I reported earlier. I cannot image what should be broken in my installation ...
Why do you get German texts without even loading msgcat? I had the impression that you can't get translated string without ... so I checked, and oh, msgcat is already loaded in the background when I start wish. I didn't know that. I thought I needs to be explicitly loaded. OK, maybe my knowledge is outdated. Does Tcl also load the message catalogue from ::tcl_library/msgs/ and ::tk_library/msgs in the background when starting Tcl or Tk?
Cheers, Torsten
thanks for the explanation. I know about the search path of messages and that is why I can't see the translation. msgcat doesn't look into the ::Tk namespace, only in my current namespace and parent namespaces, but not in other "sibling namespaces". This is also understandable and feels the right way to do. But why then does the de.msg file eval the translations in the ::tk namespace? This makes them unavailable in the global namespace.
Hm, maybe this really indicates that something is wrong with my installation. Therefore I asked about the de.msg file in the source code distribution of Tcl. I now found it. It is not in the Tcl code but in the Tk code:
https://core.tcl-lang.org/tk/artifact/d2055bbb5906f1ca
So, I can at least say that my de.msg file is the one I want to have, but then, why does it evaluate the translations in the ::tk namespace, making the unavailable in the global namespace?
I am working on macOS here and I built Tcl/Tk 8.6.10 from the source code on my Mac (macOS 10.15.7, German version). I use the bundled Wish app. When I start it and type in what you typed on Windows, I get what I reported earlier. I cannot image what should be broken in my installation ...
Why do you get German texts without even loading msgcat? I had the impression that you can't get translated string without ... so I checked, and oh, msgcat is already loaded in the background when I start wish. I didn't know that. I thought I needs to be explicitly loaded. OK, maybe my knowledge is outdated. Does Tcl also load the message catalogue from ::tcl_library/msgs/ and ::tk_library/msgs in the background when starting Tcl or Tk?
Cheers, Torsten
Torsten Berg
Mar 1, 2021, 3:35:29 PM3/1/21
to
Hi again,
I now did a completely new installation from scratch on my Mac ... and the phenomenon is still the same. It make no difference whether I use an embedded build or a "normal" one. The buttons are still in English despite the German locale.
However, what made me wonder: When I call a script with this single simple line only:
tk_messageBox -typeokcancel
i.e. even leaving out the '-message' option, I actually get the German text "Hinweis" (German word for "Notice") in the message box. So, some auto-generated text gets inserted and it used a different language than the buttons.
In addition, the manual page says, the default value for '-messgae' is the empty string but that doesn't seem to hold.
I will investigate further (need to lock closely at the code for tk_messageBox e.g.) but if anyone on a Mac could confirm this behaviour about the language, we would a better ground for finding the cause.
Torsten
I now did a completely new installation from scratch on my Mac ... and the phenomenon is still the same. It make no difference whether I use an embedded build or a "normal" one. The buttons are still in English despite the German locale.
However, what made me wonder: When I call a script with this single simple line only:
tk_messageBox -typeokcancel
i.e. even leaving out the '-message' option, I actually get the German text "Hinweis" (German word for "Notice") in the message box. So, some auto-generated text gets inserted and it used a different language than the buttons.
In addition, the manual page says, the default value for '-messgae' is the empty string but that doesn't seem to hold.
I will investigate further (need to lock closely at the code for tk_messageBox e.g.) but if anyone on a Mac could confirm this behaviour about the language, we would a better ground for finding the cause.
Torsten
Alex Plotnikov
Mar 3, 2021, 10:10:35 AM3/3/21
to
понедельник, 1 марта 2021 г. в 23:35:29 UTC+3, Torsten Berg:
Could this help:
http://tcl-lang.org/man/tcl/TclCmd/msgcat.htm#M20
i.e. about NAMESPACES AND MESSAGE CATALOGS
> > > > % mcload [file join $::tk_library msgs]
> > > > 1
> > > > % mcpreferences
> > > > de_de de {}
> > > > % mc Cancel
> > > > Cancel
> > > > % namespace eval ::tk {mc Cancel}
> > > > Abbruch
> > > >
> > > > Now, this is surprising. After loading the German translation, my string still has no translation although I know it is in the message catalogue. The trick is (looking at $::tk_library/msgs/de.msg) that the translations are put into the ::tk namespace and are thus only visible there! Why? This means that they will not be found in the global namespace I am using here and where I issued the [mcload] command. What is the reasoning behind this behaviour? (Further, I could not find that de.msg file in the Tcl source code at https://core.tcl-lang.org/tcl/dir?ci=5752520ea35ef823&name=library/msgs ... where is this file or do I have some wrong installation here??)
---
> > > > 1
> > > > % mcpreferences
> > > > de_de de {}
> > > > % mc Cancel
> > > > Cancel
> > > > % namespace eval ::tk {mc Cancel}
> > > > Abbruch
> > > >
> > > > Now, this is surprising. After loading the German translation, my string still has no translation although I know it is in the message catalogue. The trick is (looking at $::tk_library/msgs/de.msg) that the translations are put into the ::tk namespace and are thus only visible there! Why? This means that they will not be found in the global namespace I am using here and where I issued the [mcload] command. What is the reasoning behind this behaviour? (Further, I could not find that de.msg file in the Tcl source code at https://core.tcl-lang.org/tcl/dir?ci=5752520ea35ef823&name=library/msgs ... where is this file or do I have some wrong installation here??)
Could this help:
http://tcl-lang.org/man/tcl/TclCmd/msgcat.htm#M20
i.e. about NAMESPACES AND MESSAGE CATALOGS
Torsten Berg
Mar 5, 2021, 6:15:04 PM3/5/21
to
Hi,
unfortunately, it does not help.
I have digged a bit deeper and it has nothing to do with the namespaces and probably not even with msgcat. What I conclude is this:
Launching tclsh will not automatically load msgcat. When you [package require msgcat] from within tclsh, it will only provide you with the msgcat commands, but not look into the system locale and load some message catalogues. So, from that perspective everything is fine.
Launching wish (or [package require Tk]) is different. The file tk.tcl (in the library directory of Tk) will automatically be sourced when doing so and this file loads the msgcat package and also loads the tk message catalogue depending on the locale of the computer you are using. The catalogue with the translations is loaded into the ::tk namespace because it is there, it will be used (for TK's own widgets). And ... it will not interfere with the global namespace that is for the user in the first place. I think, this is the reason why the translations are not "exposed" to the user but "hidden" in the ::tk namespace.
So, the question is still there. Why does Tk not show German button texts in tk_messageBox on macOS when the locale is de_DE? My conclusion is - it is not msgcat that is broken, it is the implementation of tk_messageBox on macOS:
On macOS, tk_messageBox is implemented via a native 'alert' dialog window, not via $tk_library/msgbox.tcl. If I call that library function directly (::tk::MessageBox) I get a localized dialog, but the macOS implementation of tk_messageBox in tkMacOSXDialog.c is not able to use the msgcat catalogue as it seems.
The fact that tk_getOpenFile and tk_getSaveFile result in German text buttons, however, seems strange. Maybe, this is something on the OS level. I assume that macOS is making sure that the button texts are localized. The file dialogues just use some standard buttons while the alert buttons in macOS are custom. So, in tkMacOSXDialog.c we have these texts:
static const char *const alertButtonStrings[] = {
"abort", "retry", "ignore", "ok", "cancel", "no", "yes", NULL
};
static const NSString *const alertButtonNames[][3] = {
[TYPE_ABORTRETRYIGNORE] = {@"Abort", @"Retry", @"Ignore"},
[TYPE_OK] = {@"OK"},
[TYPE_OKCANCEL] = {@"OK", @"Cancel"},
[TYPE_RETRYCANCEL] = {@"Retry", @"Cancel"},
[TYPE_YESNO] = {@"Yes", @"No"},
[TYPE_YESNOCANCEL] = {@"Yes", @"No", @"Cancel"},
};
And in the alert, they are directly used for the buttons, without localization.
i = 0;
while (i < 3 && alertButtonNames[typeIndex][i]) {
alert addButtonWithTitle:(NSString*) alertButtonNames[typeIndex][i++]];
}
In summary, localization of tk_messageBox is missing in the mcOS implementation. Perhaps it can be done with a wrapper procedure in Tcl that gets the localized strings from the Tk message catalogue and hands them over to the implementation in Tk_MessageBoxObjCmd. This could be done in $tk_library/msgbox.tcl.
Torsten
unfortunately, it does not help.
I have digged a bit deeper and it has nothing to do with the namespaces and probably not even with msgcat. What I conclude is this:
Launching tclsh will not automatically load msgcat. When you [package require msgcat] from within tclsh, it will only provide you with the msgcat commands, but not look into the system locale and load some message catalogues. So, from that perspective everything is fine.
Launching wish (or [package require Tk]) is different. The file tk.tcl (in the library directory of Tk) will automatically be sourced when doing so and this file loads the msgcat package and also loads the tk message catalogue depending on the locale of the computer you are using. The catalogue with the translations is loaded into the ::tk namespace because it is there, it will be used (for TK's own widgets). And ... it will not interfere with the global namespace that is for the user in the first place. I think, this is the reason why the translations are not "exposed" to the user but "hidden" in the ::tk namespace.
So, the question is still there. Why does Tk not show German button texts in tk_messageBox on macOS when the locale is de_DE? My conclusion is - it is not msgcat that is broken, it is the implementation of tk_messageBox on macOS:
On macOS, tk_messageBox is implemented via a native 'alert' dialog window, not via $tk_library/msgbox.tcl. If I call that library function directly (::tk::MessageBox) I get a localized dialog, but the macOS implementation of tk_messageBox in tkMacOSXDialog.c is not able to use the msgcat catalogue as it seems.
The fact that tk_getOpenFile and tk_getSaveFile result in German text buttons, however, seems strange. Maybe, this is something on the OS level. I assume that macOS is making sure that the button texts are localized. The file dialogues just use some standard buttons while the alert buttons in macOS are custom. So, in tkMacOSXDialog.c we have these texts:
static const char *const alertButtonStrings[] = {
"abort", "retry", "ignore", "ok", "cancel", "no", "yes", NULL
};
static const NSString *const alertButtonNames[][3] = {
[TYPE_ABORTRETRYIGNORE] = {@"Abort", @"Retry", @"Ignore"},
[TYPE_OK] = {@"OK"},
[TYPE_OKCANCEL] = {@"OK", @"Cancel"},
[TYPE_RETRYCANCEL] = {@"Retry", @"Cancel"},
[TYPE_YESNO] = {@"Yes", @"No"},
[TYPE_YESNOCANCEL] = {@"Yes", @"No", @"Cancel"},
};
And in the alert, they are directly used for the buttons, without localization.
i = 0;
while (i < 3 && alertButtonNames[typeIndex][i]) {
alert addButtonWithTitle:(NSString*) alertButtonNames[typeIndex][i++]];
}
In summary, localization of tk_messageBox is missing in the mcOS implementation. Perhaps it can be done with a wrapper procedure in Tcl that gets the localized strings from the Tk message catalogue and hands them over to the implementation in Tk_MessageBoxObjCmd. This could be done in $tk_library/msgbox.tcl.
Torsten
Harald Oehlmann
Mar 6, 2021, 8:02:22 AM3/6/21
to
Thorsten,
first of all, thank you checking this in detail.
I propose that you file a ticket at core.tcl-lang.org/tk, so no
information is lost.
And thank you not blaming msgcat any more, it had hit me a bit...
Thank you,
Harald
first of all, thank you checking this in detail.
I propose that you file a ticket at core.tcl-lang.org/tk, so no
information is lost.
And thank you not blaming msgcat any more, it had hit me a bit...
Thank you,
Harald
Torsten Berg
Mar 6, 2021, 10:51:41 AM3/6/21
to
Dear Harald,
I will do so and have already prepared some text for it. Will submit later today. I am glad that I put a question mark on my subject line in the first place. As often, it turns out that the first suspicion is wrong. msgcat is a nice and very useful package!
Maybe one thing:
And, this is wrong for German:
() 6 % namespace eval ::tk {mc Abort}
Abort
() 7 % namespace eval ::tk {mc Cancel}
Abbruch
This seems wrong to me. In both cases I would expect "Abbrechen". That's the word macOS used in these cases. Is it different on Windows?
Cheers, Torsten
I will do so and have already prepared some text for it. Will submit later today. I am glad that I put a question mark on my subject line in the first place. As often, it turns out that the first suspicion is wrong. msgcat is a nice and very useful package!
Maybe one thing:
And, this is wrong for German:
() 6 % namespace eval ::tk {mc Abort}
Abort
() 7 % namespace eval ::tk {mc Cancel}
Abbruch
This seems wrong to me. In both cases I would expect "Abbrechen". That's the word macOS used in these cases. Is it different on Windows?
Cheers, Torsten
Torsten Berg
Mar 6, 2021, 6:07:58 PM3/6/21
to
OK, this is now ticket: https://core.tcl-lang.org/tk/tktview/e68adb02ec811ca8c6fb461d11dd38c73b75262b
Harald Oehlmann
Mar 8, 2021, 4:56:58 AM3/8/21
to
Dear Thorsten,
this might be a reason for a 2nd bug report.
Thanks,
Harald
this might be a reason for a 2nd bug report.
Thanks,
Harald
0 new messages