Generic Import Module prefs error?

[Christian Stimming]

Derek Atkins schrieb:
> Benoit Grégoire <bock at step.polymtl.ca> writes:
> 
>>>Err -- IIRC that strings should *not* be translated. Instead, IIRC they
>>>are only translated at display time, but *not* for storing. Anyway you
>>>should probably try out whether it works that way or the other, but from
>>>what I recall these strings should not be translated in the lookup calls.
>>
>>Oups, I was under the impression that all strings in gettext macros were 
>>initialised at program start.  I'll run a few tests to make sure either way.
> 
> Well, it depends.  Some strings require _(), some require N_().

The option lookup system, which means functions like 
gnc_lookup_boolean_option() and gnc_set_boolean_option() (e.g. in 
src/import-export/hbci/gnc-hbci-gettrans.c:197), require the 
non-translated string as pref page identifier and *without* any gettext 
macros around it. The only time when the pref page name shows up in a 
gettext macro is inside a N_() or in scheme (N_ ) at the point where 
that option is defined. That macro has no effect and only marks that 
strings to be included in gnucash's message catalog po/gnucash.pot. The 
storage of the pref page name will always store the non-translated 
version, but the display code will run the stored strings through 
gettext at display time, which is why these strings need to show up in 
gnucash.pot.

This behaviour is different from e.g. gtk1's menu code, where the menu 
items were inserted with their *translated* strings and where we have 
been running into all sorts of fscking problems because of precisely 
that fact (keywords: different translations and/or keyboard shortcuts in 
the translations...)

Christian