[WIP] Startup: restore locale after importing core

[HuidaeCho]

from grass.script import core as gcore installs a new _() function? Better solve this problem in the core module, IMO.

The address of the _() function changes after importing the core module. The setup module is OK...

See below. The exiting messages are all translated into Korean, but they are printed in English because a new _() is installed with no language information.

This PR fixes it.

[HuidaeCho]

The same problem in clean_default_db() in lib/python/script/setup.py. Cleaning up default sqlite database ... is not translated.

[HuidaeCho]

Again, IMO, it needs to be fixed in the core module because importing it causes the problem. Importing the setup module is OK. But internally in the setup module, _() is not translated.

[HuidaeCho]

something related? https://stackoverflow.com/questions/44882445/python-gettext-how-to-get-right-locale-for-module-and-class-level-variables

[HuidaeCho]

and maybe this ticket from 6 years ago: https://trac.osgeo.org/grass/ticket/1739

[neteler]

@pmav99 do you have any comment for us on this PR?

[wenzeslaus]

The half-translated strings definitively sounds a lot like what was observed at times of Trac 1739 you are mentioning, although from what you are saying it seems like only startup procedure is an issue. I can't recall all the details of what I went through at that time (all the dead ends for example), but it seem you got good understanding of what is happening in the code right now.

As for this PR, it seems your current solution is hacky, but you probably know that already. I did not dive into this for now, so I can't comment on what it does.

I have the same opinion when I did ee95f55 and 1423e79 (now reverted by bb779c2) and opened Trac 2425: The grass package should use an import, not a buildin, for the translation function. (See details in the tickets.) I'm not sure if that alone would solve the possible initialization problem here, probably not, but the fix should be at least more straightforward without workarounds.

[wenzeslaus]

Another note about a broader context of the suggested changes: In an ideal case, we will move things from grass.py to the grass package. This may increase the number of places where this fix is needed if the change is gradual and may change the nature of the problem if grass.py will really just call some main function for the library. See grass-dev: move everything from /lib/init/grass.py to /lib/python/init (nabble) which should be now easier also thanks to, e.g., 2246f5b.

[HuidaeCho]

it seem you got good understanding of what is happening in the code right now.

I have some understanding of what is happening here. I see two different problems: 1. importing the core module changes the _() function (I have no idea why). 2. imported modules (such as setup) don't have access to the _() function previously installed by its parent automatically, so it needs to be installed again. What is not clear to me is how gettext is supposed/designed to be used in these cases.

As for this PR, it seems your current solution is hacky, but you probably know that already. I did not dive into this for now, so I can't comment on what it does.

I'm aware that this PR is hacky and believe there should be a better and cleaner solution.

[wenzeslaus]

What is not clear to me is how gettext is supposed/designed to be used in these cases.

You can read through Trac 1739, Trac 2425, and Trac 3790. My comments there capture my understanding at the time of writing which is possibly better than the one I have now. One "dead end" I vaguely remember which may not be mentioned anywhere is that installing the translation function multiple times is against what the gettext manual says. (I'm sorry for not being more specific. Except for the discussion last year, I worked on this at a sprint in 2013.)

[HuidaeCho]

For our records, this problem became worse. Even the welcome message is partially translated. Actually, it's only the first line because _() is reset in line 1191.

def can_start_in_gisrc_mapset(gisrc, ignore_lock=False):
    """Check if a mapset from a gisrc file is usable for a new session"""
    from grass.grassdb.checks import can_start_in_mapset

Again, it can be fixed using the same hack:

def can_start_in_gisrc_mapset(gisrc, ignore_lock=False):
    """Check if a mapset from a gisrc file is usable for a new session"""
    global _
    __ = _
    from grass.grassdb.checks import can_start_in_mapset
    _ = __

But, it would be better to fix this issue more fundamentally.

[ninsbl]

Is this stil in the scope for the 8.0.1 milestone? Or should it be bumped up to 8.0.2?

[neteler]

This PR needs to be rebased (and bump to 8.4.0 milestone?).

[echoix]

Solved conflicts. Make sure the changes still make sense (I ported the changes from the deleted setup.py file to the current setup.py)