2010/9/29 Peter Landgren <peter.talken@telia.com>
Den Tuesday 28 September 2010 19.44.32 skrev Benny Malengier:
> 2010/9/28 Peter Landgren <peter.talken@telia.com>
>
> > Den Tuesday 28 September 2010 11.28.47 skrev Benny Malengier:
> > > 2010/9/28 Peter Landgren <peter.talken@telia.com>
> > >
> > > > Hi,
> > > >
> > > > I'm working on using Gramps on Win with non ascii usernames.
> > > >
> > > > This works well now, but there is a strange side effect:
> > > >
> > > > The first 138 translation strings, sent to gettext,  goes to a line
> > > > in ggettext.py:
> > > > return unicode(pgettext.gettext(msgdid))
> > >
> > > This is an entry of encodings into Gramps, so we convert to unicode to
> > > be sure we work internally in Gramps with unicode strings.
> > >
> > > > >From this I assume that the real translation should take place in
> > > >
> > > > pgettext.gettext,
> > > > but that code is never called.
> > >
> > > Yes, no matter what, gettext does the translation. The new gettext
> > > class retrieval of strings returns unicode by default I think, but
> > > these basic methods not.
> > >
> > > > The rest of the translations strings are translated OK.
> > > >
> > > > Most of the first 138 strings emanate from programs is src/gen/lib.
> > > >
> > > > I can't see how my patches could influence this?
> > > >
> > > > Any ideas?
> > >
> > > Remember that Josip did a lot of magic for gettext to work properly, by
> > > searching the correct dll's on windows.
> > > If you add a print statement, I assume not only the first 138 strings
> > > go there, but all of them, no?
> >
> > It's both Linux and Windows problem.
> > But now I know where it comes from.
> > I have in TransUtils.py together with other impor statements:
> > from Utils import get_unicode_path_from_env_var
> > If I comment out that import and its usage, everything is translated fine
> > now.
> >
> > If I move the import statement to where the function is used, it also
> > works fine.
> > So, what shall i do? What's the rule in a case like this?
>
> The order of imports  at startup is very important for the translation
> system.
> You must start with gramps.py, and look at function after function, so that
> TransUtils.py is imported and domain is set before other imports are
> dragged in.
>
> That is why we had to put the win() function in a new file too, because
> const.py could not be imported before TransUtils was done, remember?
Yes, I remembered that and that's why I managed to find this place.

I have done some more checking and found that all file names are in unicode except if they are from
plugins. In TransUtils
get_addon_translator(filename=None, domain="addon")
this code creates the filename, but as a str:
    if filename is None:
       filename = sys._getframe(1).f_code.co_filename
and the path is then given by
    path = os.path.dirname(os.path.abspath(filename))

If "sys._getframe(1).f_code.co_filename" could return unicode, we could get rid of the conversion
TransUtils. But I'm not sure if this is possible. I have looked at "sys._getframe" in the
documentation and understand what it means.  "f_code.co_filename" returns the filename and I suppose
it's hidden in the sys module, so it's nothing I can do then.

So, the only possibility, I see, is to have the import of "Utils"  within the definition of
"get_addon_translator" in order to avoid conflict with the translation system.

Is it not easier to, duplicate the function of Utils in Transutils? It is a small method, not a big deal if it appears twice, as long as the documentation is clear.

if get_addon_translator is called only once per plugin, then an import inside of the function is not a big deal (but still with 100 plugins, that is 100 times doing the import). Probably the function is only called when the plugin is instantiated, not on registering, so that makes it even less a problem to do import there.

You decide.

Benny


/Peter