I know there was one more thing to
test: paths with non ASCII.
In the case of "gramps -l" command, path is returned in system
file encoding and
family tree names in another encoding. The translated string is in
So for this to work in this command I changed the print statement
around line 400
in arghandler.py to:
print (_("%(full_DB_path)s with name
\"%(f_t_name)s\"") % \
Similar change in "gramps -L" command:
for item in sorted(summary):
if item == "Path":
if item != "Family tree":
print (" %s: %s" % (item,
In this command all strings are translated except those in the
Any reason for that?
Peter Landgren skrev 2012-09-20 16:18:
Benny Malengier skrev 2012-09-20
2012/9/20 Peter Landgren <firstname.lastname@example.org>
1. Yesterday I worked with
and fixed it. Committed.
I noticed that translated strings must be coded in
in order to avoid "strange" characters in the output when
non ASCII characters are
use in the translated strings or in filenames/directory
2. Today I have been working with
And found a fix for that. (Not committed yet.)
However, I found many more translated strings that where
I have fixed those that were connected with this issue.
How shall I proceed? Shall I add
to all places, so that the translations are
Best would be a function that can be easily changed.
It seems so.
I have the impression that a windows expert that
understands the issue in depth is needed.
sys.getfilesystemencoding() should only be needed when
dealing with filenames. Is the console in windows also using
Remember the funtions added to handle Windows encoding problem.
I get correct strings on the console for both translated strings
and for filenames with non ASCII characters,
(I will away for the weekend.)
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
Gramps-devel mailing list