[GRASS-dev] rules for testing GUI components for encoding errors before commit ?

Hi,

I just posted a bug report about encoding issues in the new Vector network analysis tool [1].

More generally: I regularly get these kinds of encoding errors in the wxGUI. And I guess some of them only show up once translators have translated the strings of a new module. Maybe we should try to define some general rules / a how-to about testing new GUI components for such potential encoding issues. We could also propose a toolkit in form of example strings to put into the code, or through the obligation to test with at least two .po files in languages with special characters.

What do the GUI developers think about this ?

Moritz

[1] https://trac.osgeo.org/grass/ticket/2145

On 18/12/13 09:57, Moritz Lennert wrote:

Hi,

I just posted a bug report about encoding issues in the new Vector
network analysis tool [1].

More generally: I regularly get these kinds of encoding errors in the
wxGUI. And I guess some of them only show up once translators have
translated the strings of a new module. Maybe we should try to define
some general rules / a how-to about testing new GUI components for
such potential encoding issues. We could also propose a toolkit in
form of example strings to put into the code, or through the
obligation to test with at least two .po files in languages with
special characters.

What do the GUI developers think about this ?

Here's some more from the related bug ticket:

>Replying to [comment:1 annakrat]:

This particular error should be fixed in r58490. There was an empty
translatable string which resulted in some garbage.
However, once certain strings get translated, you will get such
errors again from multiple places. The code is pretty complex,
converting to string is there multiple times and I am not sure how to
fix this. In general, I don't really understand how to deal with this
issue and how to test it correctly.

I don't think there is one good way to fix this, but if we could
propose a test protocol that allows developers to quickly test their
work for different locale settings then maybe it would make it
easier to avoid such issues in the first place.

But as I'm not a GUI developer, I'd like some feedback on what those who are would find most useful. As a start, new developments should be tested in different locales, but as translation generally come later, it might be good practice to fill a .po file with artificial non-ascii strings and to test the module against those.

Moritz