raster_what() not compliant with localised version of GRASS

[andbal]

Writing a python script, I found that the grass.script.raster_what() output dictionary has different keys depending on language used in GRASS. The following python code:

point = grass.raster_what('clump', [[x,y]])[0]
print(type(point), point)

returns (with Italian GRASS):

<type 'dict'> {'clump': {'color': '143:247:067', 'etichetta': '', 'valore': '1'}}

Changing language to English, returns:

<type 'dict'> {'clump': {'color': '151:149:192', 'value': '1', 'label': ''}}

Changing language to German, returns:

<type 'dict'> {'clump': {'Farbe': '099:113:108', 'value': '1', 'label': ''}}

The translation seems to depend on the GRASS localisations and make impossible access to the dictionary keys in a general way.

Anyway a workaround could be achieved using grass.script.read_command('r.what') and accessing to the list values.

[mlennert]

Replying to andbal:

Writing a python script, I found that the grass.script.raster_what() output dictionary has different keys depending on language used in GRASS.

This comes from line 191 in lib/python/script/raster.py where these labels are noted as translatable strings. I agree that this is a very bad idea and that such dictionary keys should not be translatable.

Unless anyone gives a good reason for the contrary, I will change the vector of labels to non-translatable. This might break existing scripts, but I think this is necessary.

[marisn]

Replying to mlennert:

Replying to andbal:

Writing a python script, I found that the grass.script.raster_what() output dictionary has different keys depending on language used in GRASS.

This comes from line 191 in lib/python/script/raster.py where these labels are noted as translatable strings. I agree that this is a very bad idea and that such dictionary keys should not be translatable.

Unless anyone gives a good reason for the contrary, I will change the vector of labels to non-translatable. This might break existing scripts, but I think this is necessary.

Then also add line 184 ("No data").

This also needs to be explicitly stated in docstring that it is callers responsibility to use localized version of key values before they are displayed to the end user.

[lucadelu]

Replying to mlennert:

Replying to andbal:

Writing a python script, I found that the grass.script.raster_what() output dictionary has different keys depending on language used in GRASS.

This comes from line 191 in lib/python/script/raster.py where these labels are noted as translatable strings. I agree that this is a very bad idea and that such dictionary keys should not be translatable.

Unless anyone gives a good reason for the contrary, I will change the vector of labels to non-translatable. This might break existing scripts, but I think this is necessary.

In the attached diff I propose a change, because the actual behavior is useful for GUI modules but not for other uses

[annakrat]

Replying to lucadelu:

In the attached diff I propose a change, because the actual behavior is useful for GUI modules but not for other uses

I would prefer to avoid the gui parameter. Instead we could have a wrapper function raster_what in wxpython/core/utils.py which would replace the labels with the translatable ones? Sorry, no time for this right now, maybe later.

[lucadelu]

Replying to annakrat:

I would prefer to avoid the gui parameter. Instead we could have a wrapper function raster_what in wxpython/core/utils.py which would replace the labels with the translatable ones? Sorry, no time for this right now, maybe later.

Can you explain a little bit more why you don't like gui parameter? Your proposal seems to me a duplication of code...

[annakrat]

Replying to lucadelu:

Replying to annakrat:

I would prefer to avoid the gui parameter. Instead we could have a wrapper function raster_what in wxpython/core/utils.py which would replace the labels with the translatable ones? Sorry, no time for this right now, maybe later.

Can you explain a little bit more why you don't like gui parameter? Your proposal seems to me a duplication of code...

I didn't like the gui parameter, perhaps localized=False would make more sense when you want to use localized names in a script, not just in the gui.

[lucadelu]

Replying to annakrat:

I didn't like the gui parameter, perhaps localized=False would make more sense when you want to use localized names in a script, not just in the gui.

Ok, if it is only parameter's name, it is not problem to change. I like localized. Could I submit the code with localized parameter instead gui one?

[annakrat]

Replying to lucadelu:

Replying to annakrat:

I didn't like the gui parameter, perhaps localized=False would make more sense when you want to use localized names in a script, not just in the gui.

Ok, if it is only parameter's name, it is not problem to change. I like localized. Could I submit the code with localized parameter instead gui one?

Sure, if you tested it with different locale and it behaves as expected.

[lucadelu]

Replying to annakrat:

Sure, if you tested it with different locale and it behaves as expected.

committed with test in r67874. Tests are needed before backport.

[andbal]

Replying to lucadelu:

Tests are needed before backport.

I tried the testsuite code with two languages other than english and gave back 'OK' in both cases.

EDIT: No more tester but seems to works anyway, I close the ticket. Thank you.

[annakrat]

As far as I know, it hasn't been backported yet.

[martinl]

Can be backport done?

[annakrat]

Replying to martinl:

Can be backport done?

Yes, please do it.

[lucadelu]

In 69242:

python script: backported raster_what function to work with or without localized labels fixed #2912