kicad-developers team mailing list archive

[Manveru <manveru@...>]

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.

> 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.

> 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.

It could be nice to have web based tool storing all project
translations in some database, and allows match the translated string
to original, what would be helpful (not exactly simpler) in case of
bug reporting or other support case.

-- 
Manveru
jabber: manveru@...
gg: 1624001
http://www.manveru.pl