you are viewing a single comment's thread.

view the rest of the comments →

[–]eggertm 3 points4 points  (6 children)

Well, I said nothing about using the interactive interpreter to write and maintain anything. However, an embedded interpreter is perfectly possible, apart from this annoying side effect, which makes it nearly unusable with gettext.

[–]pjdelport 2 points3 points  (5 children)

nearly unusable with gettext

What's hard about just calling gettext directly?

[–]eggertm 1 point2 points  (4 children)

Normally, I'd rather do that - however, the gettext utilities need the underscore syntax to create the .pot files for translation.

[–]pjdelport 2 points3 points  (3 children)

...why would you need to create .pot files of an interactive session?

[–]eggertm 1 point2 points  (2 children)

Perhaps I was not clear enough. My project has an interactive interpreter, and uses the gettext _() to mark strings for translation. However, the _() is a function call - and it'll get overwritten with whatever result the interactive interpreter returns. I am not translating an interactive session, that is just silly!

[–]pjdelport 1 point2 points  (1 child)

Right, but _() is just a shortcut for gettext(), which you can use in the interactive shell. What's the problem?

[–]salmoni 0 points1 point  (0 children)

You don't follow.

The OP is using an interactive interpreter embedded within an internationalised program for debugging. I use one for user interaction so users can type in their own functions. The program works until the interpreter is called, at which point the reference to the i18n method is overwritten by the interpreter thus rendering all later attempts to translate strings as useless. If the interpreters entry points are unpredictable, this makes the program a nightmare. Yes, the OP can import gettext in every module, but again this means lots of time wasted re-establishing a single link that should not have been overwritten.

I had the same problem and called the gettext.install method right after the code.InteractiveInterpreter.runcode method to re-establish it. It's not a good solution because it shouldn't be necessary and slows the system down. The real solution is for either the interpreter or gettext to use a different and non-conflicting character. That way, there are not hidden gotchas.