Open Bug 1551896 Opened 5 years ago Updated 2 months ago

Rewrite Thunderbird Chat's system messages for fluent

Categories

(Chat Core :: General, enhancement)

Product:
Chat Core
Component:
General
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: KaiE, Unassigned)

References

Details

The OTR code inserts system messages into the chat window, which are based on template strings, that need to be translated, combined with some dynamic information, such as the usernames.

The new fluent localization system suggests to either use static binding of document elements to string IDs, or to use async functions.

In our case, I need strings with args (variables, dynamic parts).

IIUC, the ideal implementation compatible with fluent would work like this, when adding new system messages to the chat window document:

  • a new DOM node is created
  • the data-l10n-id attribute is set on that node with the corresponding string id
  • the data-l10n-args attribute is set, which contains the dynamic parameters
  • the DOM node is added to the document

With this approach, the full combined string wouldn't be produced by the chat application code, but rather by the DOM and fluent code when it's time to display.

Looking at today's situation, the corresponding API (systemMessage in imConversations.js) takes a simple string, which means, the sending side needs to fully prepare the dynamic strings, by using l10n.formatValue().

It's preferable to call the async version of formatValue.

However, converting all related JS code in Thunderbird Chat to be async functions seems like a challenge. I tried, and ran into crashes. The crashes appared to be related to OTR calls through the ctypes library into the external libOTR code. It's not yet clear if I made mistakes, (e.g. if I wasn't sufficiently careful converstion the JS code to be async), or if the external libOTR has trouble with multithreaded operation.

As a short term workaround, it seems easier/safer to use the synchronous version of fluent's formatValue.

In the long term, it might make sense to rewrite the chat code to take string IDs and an array of parameters, instead of fully formatted strings.

Type: defect → enhancement

(In reply to Kai Engert (:kaie:) from comment #0)

In the long term, it might make sense to rewrite the chat code to take string IDs and an array of parameters, instead of fully formatted strings.

Letting fluent mess with the DOM in the chat browser would completely break the message theme system. The long term solution here is to make everything async. The message display is already asynchronous, but asynchronous code from before the async keyword existed.

(In reply to Kai Engert (:kaie:) from comment #0)

if the external libOTR has trouble with multithreaded operation.

We would probably need to ensure libotr, gcrypt, gpg-error, etc. are all thread safe. Looking online quickly offers no answer here though.

Severity: normal → S3

Martin -- any idea if this happened in bug 1889422?

Flags: needinfo?(martin)
You need to log in before you can comment on or make changes to this bug.