[GRASS-dev] rules for testing GUI components for encoding errors before commit ?
mlennert at club.worldonline.be
Fri Dec 20 06:14:01 PST 2013
On 18/12/13 09:57, Moritz Lennert wrote:
> I just posted a bug report about encoding issues in the new Vector
> network analysis tool .
> 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.
More information about the grass-dev