[Kmymoney-devel] Bug in translated version of KMyMoney

Alvaro Soliverez asoliverez at kde.org
Fri Aug 6 05:23:41 CEST 2010


Hello,
I agree with your point, and I promise to remove that call, at least
in its present form, as soon as the release is done.

In the meantime, I went for the immediate fix and changed the context
so that the i18n and the I18N_NOOP calls match.

Thanks a lot for your prompt answer!

Regards,
Alvaro


On Thu, Aug 5, 2010 at 5:02 PM, Chusslove Illich <caslav.ilic at gmx.net> wrote:
>> [: Alvaro Soliverez :]
>> https://bugs.kde.org/show_bug.cgi?id=246702
>
> Immediate fix is (probably) simple enough, but there are some conceptual
> issues here.
>
> Human-readable text, especialy translated, should never be used as key in
> internal data structures. Instead, internal symbolic names (strings or
> enums, whatever) or numbers should be used as keys. Sticking to this would
> have avoided a functionality bug in translations in this case, one would
> just end up with untranslated text in interface.
>
> I18N_NOOP* series of macros should really be used only when at the point of
> invocation translation infrastructure has not been initialized. For example,
> if there is a bunch of file static strings. In this case, the
> MyMoneySchedule::occurrencePeriodToString method is called after everything
> has been initialized, so there is no justification for using I18N_NOOP* in
> it. (If this is done to use original text as key, it should not be according
> to previous paragraph.)
>
> (Immediate fix.) When const char *rawMsg = I18N_NOOP2("foo", "bar"); is
> used, the counterpart live call has to be QString msg = i18nc("foo", rawMsg)
> . That is, exactly the same context string must be repeated in the live call
> as the one used in macro. (This also illustrates why I18N_NOOP2 is ugly and
> should not be used unless there is no other option.)
>
> --
> Chusslove Illich (Часлав Илић)
> Serbian KDE translation team
>


More information about the KMyMoney-devel mailing list