Comment 210 for bug 296867

(In reply to comment #59)
> Ideally, that distinctive message header should be a machine-readable
> version of the message, so OTR-literate UIs (Empathy) can discard the
> untranslated version from Gabble and display something translated. We've
> always had a policy of putting UI strings and their translations in the UIs,
> not the CMs.

The more I think about this, the more I think Gabble should not contain translated strings. It's OK for it to contain strings in the C locale (international English), but all translation should be taking place somewhere that already needs to be translated - the UIs.

As a purely practical thing, Gabble does not have any of the translation machinery, so those strings aren't going to be translated anyway.

Is the OtrlMessageEvent enum sufficiently stable that we can use it in the D-Bus API directly? That would probably be the easiest way. The only other information we need to put in the message header is:

- for OTRL_MSGEVENT_SETUP_ERROR: gcry_strerror (err)
  (perhaps { "otr-error": that string })

- for various codes: the username or account name, which the UI already
  knows anyway

- for OTRL_MSGEVENT_RCVDMSG_UNENCRYPTED: the unencrypted message
  (perhaps { "otr-unencrypted-message": that string })

- for OTRL_MSGEVENT_RCVDMSG_GENERAL_ERR: the message
  (perhaps { "otr-error": that string })