kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

I just committed some internationalization string macro fixes that
caused Visual C++ to choke on code that had long strings split for code
formatting purposes. GCC has no problem compiling _( "A string split "
"for code indentation purposes" ) but Visual C++ 8 will complain. I am
the guilty party for breaking these strings in the first place so I
fixed them. While I was fixing them I started thinking that this could
also cause problems when you create a new catalog with poedit. If I
caused problems for any of our translators, I apologize.

Now comes the fun part. How do we deal with long internationalization
strings? Having source code 150 columns long is hideous. I have my
editor set to wrap at 80 columns so long lines of source code are really
distracting. Long strings can be formatted using '\' and continuing the
string on the next line but this isn't much better than line wrapping.
Does splitting the line this way cause any problems for the translators?
The GNU gettext documentation was not really helpful. If some one has
experience with this issue, any input would be greatly appreciated.

While I am on the subject of internationalization, I noticed that there
is a lack of consistency where translated strings are used in error
messages. Some of error messages (particularly file parsing error) are
translatable and some are not. It seems to me if the user is going to
see it, it should be translated. Although, a translated error message
may not mean any thing to a developer. Also, some of debugging output
is translated as well. I have not made any of the debugging output I
have added translatable because I didn't think it made sense to
translate text that the end user will never see. The GUI translation
document does not address what strings should be translatable. I wanted
to get the groups feelings on this before I start fixing things.

Best Regards,

Wayne