kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Manveru wrote:
> 2009/5/21 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.
> 
> I think until the string is closed in _() it will be continuous while
> no comma separation or other string separators divide such strings.
> That is why translatable strings should be formatting stings in case
> of any value insertion from variables. I do not have facilitation now
> to check that for 100% sure.

I'll have to try the different methods of breaking a string and see how
poedit handles them. If I find anything conclusive, I'll update the GUI
translation document for future reference.

>> 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.
> 
> Translatable strings have to be consistent in terms of context where
> they are used in code. If you divide one error message into parts, you
> make the translator work a real horror. I can check different
> behaviours of GNU gettext tools for you, but not now. I would prepare
> samples of different translation used in .cpp and results of .pot
> templates.

I try to avoid concatenating strings whenever possible to avoid these
issues. Although I'm sure I'm guilty of letting some these slip by me.

>> 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.
> 
> Good practice is to translate everything. But this fairly quickly
> leads to problems with bug reporting or things like that. There is no
> golden mean here. For error and debug messages, project should have
> unambiguous list of return codes - they are translation independent,
> but hard to maintain in not centrally managed projects.

Ugh! That would be a lot of work to define error codes and make every
error message translatable. Although, the error codes makes sense to
avoid confusion when translating.

Wayne

<< snipped >>