[GRASS-dev] [GRASS GIS] #2727: wxGUI startup: 'ascii' codec can't decode byte 0xc3 in position 15: ordinal not in range(128)

[GRASS GIS]

#2727: wxGUI startup: 'ascii' codec can't decode byte 0xc3 in position 15: ordinal
not in range(128)
--------------------------+-------------------------
  Reporter:  mlennert     |      Owner:  grass-dev@…
      Type:  defect       |     Status:  new
  Priority:  normal       |  Milestone:  7.0.2
 Component:  wxGUI        |    Version:  svn-trunk
Resolution:               |   Keywords:  encoding
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+-------------------------

Comment (by mlennert):

 Replying to [comment:3 annakrat]:
 > Please try r66036.

 Works, thanks !

 > Currently (quite recent change r64834) translatable strings return byte
 strings and we have to respect it in the code.

 Yes. This change (and the ticket it relates to) clearly show one of the
 problems we currently have in grass development: with the growing
 importance of the wxGUI and of Python scripting, I have the feeling that
 choices at one point in the code have more and more impact on other parts
 of the code. Development at module level does not have this kind of impact
 and in my (perhaps erroneous) perception C-library changes were done by
 fewer people, possibly with better understanding of the consequences.

 With Python opening development up to more people, and with the growing
 importance of the GUI, we might need a more centralised ruleset of how to
 do certain important things in order to ensure that we keep the code
 coherent.

 >
 > It's difficult to define any rules when things change all the time...

 That's why I've been pleading for a more fundamental reflection about how
 to approach encoding issues in the wxGUI in order to define one way to
 things once and for all without trying to solve this case-by-case. The
 trouble seems to be that most of us do not really fundamentally understand
 how string handling works and what different choices involve.
 But then again, maybe this is already solved... More importantly,I don't
 have the time at this stage to delve into the matter enough to be the
 motor of this, so I will shut up. ;-)

 Moritz

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2727#comment:4>
GRASS GIS <https://grass.osgeo.org>