Additional variable types / Temproal support

[rkh]

Currently, fluent-bundle cannot handle Temporal.

What would need to change

It is hardcoded only to support FluentVariable entries (FluentType, string, number, or Date).

Here's how they are resolved:

fluent.js/fluent-bundle/src/resolver.ts

Lines 178 to 200 in 48e2a62

	// Return early if the argument already is an instance of FluentType.
	if (arg instanceof FluentType) {
	return arg;
	}
	// Convert the argument to a Fluent type.
	switch (typeof arg) {
	case "string":
	return arg;
	case "number":
	return new FluentNumber(arg);
	case "object":
	if (arg instanceof Date) {
	return new FluentDateTime(arg.getTime());
	}
	// eslint-disable-next-line no-fallthrough
	default:
	scope.reportError(
	new TypeError(`Variable type not supported: $${name}, ${typeof arg}`)
	);
	return new FluentNone(`$${name}`);
	}
	}

It is, therefore, not possible to pass in other values.

Possible fixes

• Built-in support for Temporal objects
• A way to pass in a function to convert custom objects into FluentType instances
• All of the above

The first one would be very convenient but would also require checking whether Temporal exists.

Project status

As a side note, I'm seeing a lot of old issues with no progress. I'm happy to work on a PR for this, but I'm wondering what the maintenance status of the project is.

[rkh]

Example of what the API could look like:

new FluentBundle(locales, {
  wrapVariable(value: Temporal.ZonedDateTime | FluentVariable): FluentVariable {
    if(value instanceof Temporal.ZonedDateTime) {
      return new FluentDateTime(value.epochMilliseconds, { timeZone: value.timeZoneId })
    } else {
      return value
    }
  }
})

[eemeli]

The library's still maintained, but new feature development is indeed not very active. I'd be very interested in reviewing new PRs, including ones bringing in Temporal support.

[rkh]

Pull Request: #635

[rkh]

Alternative implementation (more complete Temporal support, but no API for custom values): #636 – happy to integrate this into #635 if that's the preferred approach.