I18N support (Part 1)

[GoogleCodeExporter]

This is an initial patch to prepare the application to support an
internationalized interface. 

It removes most of the global variables for interface strings and wrap them
in wx.GetTranslation.

The remaining ones will be addressed in a future patch. Program logic
should not depend on interface strings, as well as a few other design
issues will need to be addressed in order to enable full i18n support in
the interface.

I will provide a patch to finish this feature once these initial changes
have been integrated.

Regards,
Cody Precord

Original issue reported on code.google.com by CodyPrec...@gmail.com on 8 Nov 2008 at 9:07

Attachments:

• i18n_support_part1.patch

[GoogleCodeExporter]

Hi Cody Precord,

I appreciate the hard work you put into this complex patch but I can not 
currently
integrate it since it went way off the (non-standard?) coding style of Winpdb.

In particular why did you change the constants into functions or literals across
winpdb.py? Can't the _() operator be assigned to the constants themselves? 

Nir

Original comment by nir1...@gmail.com on 11 Nov 2008 at 8:52

• Changed state: Accepted

[GoogleCodeExporter]

Hello,

Because if you assign it at the global level to the constants then it is 
evaluated at
import time which will result in the strings being exactly the same as they are
currently. Assigning them to functions (just a few of the long ones to improve
readability where they are used) and at their call locations will cause them to 
be
evaluated at call time so that the translations can take place.

I also found it a very odd design choice that the interface strings were 
assigned to
global constant especially since the majority of them are only used in one 
location.
It also makes reading the locations where they are used more complicated as you 
have
to go find and reference the variable as opposed to just reading it. This is 
the only
python program that I have seen do it this way. Having a large number of global
variables is typically considered poor practice and is very inefficient in 
python.

There is a number of other design issues that will need to be tackled to 
complete
this as well, interface strings should never be used to control program logic. 
They
should just be used for display. Using Id's that will not change are guaranteed,
strings on the other hand can be evaluated differently depending on the 
translation.

I have read (http://winpdb.org/cgi-bin/moin.cgi/GuideLines), there is however no
reference to what the coding style is? A reference to that would probably be 
helpful.
I also noticed documentation as a requirement so it was surprising to see not a
single comment nor docstring in that file ;).

Regards,

Cody

Original comment by CodyPrec...@gmail.com on 11 Nov 2008 at 1:09

[GoogleCodeExporter]

Here is my defense speech:...

Correct me if I am wrong but can't you still have the constant and apply the _()
operator at the place of use. For example:

GLOBAL_WARNING = "Watch out..."
... 8784 lines of cryptic code later ...
output_to_screen(_(GLOBAL_WARNING))

Assigning literals to globals is a habit I carry from Windows and C++ where 
strings
are usually located in resource files and used in the program with their
CONSTANT_IDS. It has its pros and cons. You are correct that sometimes it is 
more
readable to have a short string in place of use but I chose uniformity and 
habit.

I would rather have all strings as constants in the head of the file than have 
some
of them as constants, some of them as functions and some of them as literals in 
place. 

Also, if the focus of this work is to introduce i18n to Winpdb then it would be
better to shake as little as possible since otherwise you increase the 
likelihood of
new bugs in a refactoring effort which is complex enough anyway.

For example, in modifying the split-versions of some strings into functions the
newlines disappeared which is a bug.

Now, I also prefer to have literals as constant identifiers since it makes 
debugging
more readable. When I examine a structure in a debug session I would rather see
'running', 'broken' or '&File' instead of 0, 1, or 2.

There is no problem in having that as long as you only apply the _() operator 
in the
point of output.

You are absolutely correct about the lack of documentation (and testing). It is
horrible and should be corrected. There are a lot of subtle bug fixes which are 
not
documented and make Winpdb (and especially rpdb2) into a small mine-field.

Also, there are all sort of issues related to having Winpdb support i18n like 
for
example where the translation files should be at. Winpdb has no package folder. 
It is
placed directly in the site-packages folder, together with rpdb2.py

All these issues and other should be best discussed/planned in the Wiki before 
being
applied.

As to coding style, I did not lay it out in the Wiki yet since I lack time (and
contributors) but the best would be to make sure code blends in well in terms of
spacing, line spliting, the non-standard comment formatting, etc...

Original comment by nir1...@gmail.com on 12 Nov 2008 at 3:48

[GoogleCodeExporter]

Hello,

No need for defense, sorry if that sounded offensive. (think I replied before 
having
my morning coffee).

Yes, wrapping the constants in their use locations with _() can work. But it
introduces another problem. All the gettext/gnu tools for automating the 
creation and
synchronization of the locale files search the source code for _("") expecting 
to
find the strings in the _(). As they don't evaluate the code to find what the
_(SOME_CONSTANT) would be. Doing it this way would require one to manually 
maintain a
master translation template file, instead of being able to simply regenerate it 
from
the source code when changes are made.

I am also familiar with how windows cpp application handle them with resource 
files
and find them much harder to maintain than this approach. However for something 
of
this scale it probably wouldn't be much different, and I wont be the one 
maintaining
it so its up to you how you would like to do it. I can do the initial setup, wx
stuff, and provide automation scripts for doing most of the work but I am not 
sure
how much time I will have beyond that.

The translation files could be deposited as a folder of data_files in the
site-packages directory with the other modules if winpdb was structured like a
package. However I can see where changing the install layout would cause 
backwards
compatibility issues (if there is anything out there importing winpdb/rpdb 
other than
the launcher scripts), with out doing something undesirable like adding some 
dummy
modules at the old location that import the real modules.

I guess it boils down to how much interest there is in supporting this. I have 
an
interest in making a plugin for Editra that makes use of the debugger but will 
need
to fix this and a few Ui issues before hand. I prefer to push as many 
fixes/changes
up stream as possible. So if you have some other ideas how you would like to 
support
this I am willing to work with it, but in my experience this is the 
easiest/cleanest
way to do it.

Regards,

Cody

Original comment by CodyPrec...@gmail.com on 12 Nov 2008 at 4:59

[GoogleCodeExporter]

So the _() operator can't be used on a constant after all. But what is wrong 
with
invoking it on import? Is it essential that the interface would change on the 
fly?
Isn't it enough that the language be determined as the debugger is first 
launched?

Winpdb is not structured as a package and changing that would not only cause 
backward
compatibility issues but also break a common scenario of using Winpdb/rpdb2 
without
installing it. So I would have to think about this.

I admit that personally I do not have much interest in pushing i18n support for 
two
reasons, first, the end users are developers (so learning English is good for 
them...
;) ) and second, I have limited time/resources to invest in such a change.

Still, as Free Software the user community can do whatever they believe is in 
their
interest, but I can only integrate such a wide change into the version posted 
on this
site if I feel it was done perfectly.

Also, a note about having Winpdb as plugin. Several popular packages have done 
that
in the past and there is a problem that frequently repeats. At some point they 
become
slow in upgrading their plug-in or package to the latest version of Winpdb. The
result is that users get to use outdated versions of the debugger. What is your 
take
on this?

Original comment by nir1...@gmail.com on 16 Nov 2008 at 2:09

[GoogleCodeExporter]

Hello,

The issue with doing it at import time is that the GetTranslation function is 
called
at that time and translates the strings in the context of the current locale 
and then
those translated strings are assigned to the variable. But the Locale object 
cannot
be created until after the wxApp object is instantiated so the GetTranslation 
call
would basically be a no-op.

Anyhow if you don't have much of an interest in this, I honestly have even less 
of an
interest in helping implement it. So feel free to close this.

Regards,

Cody

Original comment by CodyPrec...@gmail.com on 17 Nov 2008 at 12:49

[GoogleCodeExporter]

Original comment by nir1...@gmail.com on 7 Feb 2009 at 9:32

• Changed state: WontFix

[GoogleCodeExporter]

_("debu")

Original comment by Abey_...@hotmail.com on 17 Apr 2010 at 5:26