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

[Moritz Lennert]

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