Benny Malengier skrev 2012-09-25 10:19:


2012/9/25 Peter Landgren <peter.talken@telia.com>
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 unicode.
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\"") % \
                        {'full_DB_path' : dirname.decode(sys.getfilesystemencoding()),
                         'f_t_name' : name}).encode(sys.getfilesystemencoding())
 
Similar change in "gramps -L" command:

                for item in sorted(summary):
                    if item == "Path":
                        summary[item] = (summary[item]).decode(sys.getfilesystemencoding())
                    if item != "Family tree":
                        print ("   %s: %s" % (item, summary[item])).\
                               encode(sys.getfilesystemencoding())


In this command all strings are translated except those in the "summary" variable
Any reason for that?


Originally, nothing in CLI was translated. I would guess many people still would add things to CLI in English only.

Yes, I know, but it does not hurt to do this to get the output in readable form.

/Peter

B
/Peter

Peter Landgren skrev 2012-09-20 16:18:
Benny Malengier skrev 2012-09-20 12:03:


2012/9/20 Peter Landgren <peter.talken@telia.com>
Hi,

1. Yesterday I worked with
http://www.gramps-project.org/bugs/vshould iew.php?id=6056
and fixed it. Committed.
I noticed that translated strings must be coded in
".encode(sys.getfilesystemencoding())"
in order to avoid "strange" characters in the output when non ASCII characters are
use in the translated strings or in filenames/directory names.

2. Today I have been working with
http://www.gramps-project.org/bugs/view.php?id=6058
And found a fix for that. (Not committed yet.)
However, I found many more translated strings that where printed
without ".encode(sys.getfilesystemencoding())".
I have fixed those that were connected with this issue.

How shall I proceed? Shall I add ".encode(sys.getfilesystemencoding())"
to all places, so that the translations are readable/understandable?

Best would be a function that can be easily changed.
I agree.
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 this encoding?
It seems so.
Remember the funtions added to handle Windows encoding problem.
get_unicode_path_from_file_chooser(path)
get_unicode_path_from_env_var(path)

I get correct strings on the console for both translated strings and for filenames with non ASCII characters,
using sys.getfilesystemencoding().
(I will away for the weekend.)

Regards,
/Peter



Benny
 

Note this a Windows only problem.

/Peter



------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Gramps-devel mailing list
Gramps-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gramps-devel





------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html


_______________________________________________
Gramps-devel mailing list
Gramps-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gramps-devel