1611754 - Extend Fluent DOM args to handle date

Status: NEW

(Core :: Internationalization, enhancement, P3)

Description

[Zibi Braniecki [:zbraniecki][:gandalf]]

The way we carry Fluent Arguments via DOM uses JSON serialization/deserialization, with a flat key/value map.
That means that we're effectively limited to carrying strings and numbers, and there's no good way to encode a date.
While the value of the date can be stored as an epoch number, it's impossible to distinguish between a number-number and a date-number:

document.l10n.setAttributes(elem, "my-key", {
  unreadCount: 5,
  lastSeen: new Date(2019, 04, 10, 01, 23)
});

will both be serialized to:

<x id="elem" data-l10n-id="my-key" data-l10n-args='{
  "unreadCount": 5,
  "lastSeen": 1557444180000
}'/>

and it's impossible to deserialize that back.

I'd like suggest an extension to our logic which would allow the type to be string/number or an object where the object has one mandatory field type. It would then serialize like this:

<x id="elem" data-l10n-id="my-key" data-l10n-args='{
"unreadCount": 5,
"lastSeen": {"type": "datetime", "value": 1557444180000}
}'/>

and that can be serialized/deserialized properly, and can be extended to handle more types in the future.

Comment 1

[Zibi Braniecki [:zbraniecki][:gandalf]]

Stas, Axel - thoughts?

Comment 2

[Zibi Braniecki [:zbraniecki][:gandalf]]

The patches from https://bugzilla.mozilla.org/show_bug.cgi?id=1611509 may help us with implementation of date recognition out of JS via WebIDL.

Comment 3

[Staś Małolepszy :stas]

I think this should part of a larger discussion about how to serialize all kinds of arguments passed to Fluent, including arguments of custom subclasses and arguments with some options pre-set (and possibly protected from being overwritten by localizers).

Re. the issue at hand, could we for the time being pass dates as timestamps, and use the DATETIME builtin inside FTL?

Comment 4

[Zibi Braniecki [:zbraniecki][:gandalf]]

I think this should part of a larger discussion about how to serialize all kinds of arguments passed to Fluent, including arguments of custom subclasses and arguments with some options pre-set (and possibly protected from being overwritten by localizers).

So, this stuff seems to be designed already, at least in JS and now in Rust. We have custom types that extend FluentType and can encode options and extend options passed by localizers, with ability to limit what localizers can pass.

Re. the issue at hand, could we for the time being pass dates as timestamps, and use the DATETIME builtin inside FTL?

That's what it does at the moment. So passing a number as epoch will work, but passing a Date will not.

Comment 5

[Staś Małolepszy :stas]

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #4)

So, this stuff seems to be designed already, at least in JS and now in Rust. We have custom types that extend FluentType and can encode options and extend options passed by localizers, with ability to limit what localizers can pass.

I mean serializing the arguments such that they can be set via the data-l10n-args attribute. I don't think that's properly designed for all the use-cases I mentioned?

Also, I didn't realize the ability to limit what localizers can pass was already implemented. Can you point me to a bug or commit?

That's what it does at the moment. So passing a number as epoch will work, but passing a Date will not.

The document.l10n.setAttributes helper could be made to serialize Date objects to numbers. I realize this isn't a perfect solution as it requires the use of DATETIME on the Fluent side. But it may be an acceptable workaround for the time being.

Comment 6

[Zibi Braniecki [:zbraniecki][:gandalf]]

Also, I didn't realize the ability to limit what localizers can pass was already implemented. Can you point me to a bug or commit?

In fluent-rs?
There's an example in https://github.com/projectfluent/fluent-rs/blob/master/fluent-bundle/examples/custom_formatter.rs#L46
and in the implementation of that in Gecko we can filter out merging of currency.

The document.l10n.setAttributes helper could be made to serialize Date objects to numbers.

I see, yeah, that would work. I'll take a look at this.

But it may be an acceptable workaround for the time being.

Yeah, seems like it would help. It's not a blocker for anything, but would be nice to remove that paper cut even with such a workaround.