(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 })
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/296867
Title:
empathy needs to support OTR encryption
To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
