Expose the current bundle to custom functions

[stasm]

Custom function may want to query the current bundle for information. For instance, the current language would be useful if a custom function was responsible for some formatting.

[stasm]

I think an easy way to do this would be to call functions in the context of the current bundle, essentially making the this keyword in the function's body meaningful and equal to the current bundle.

[Pike]

The ability to "spoof" this is very js-specific. Should we use a pattern that's easier to generalize? It's akin a bit to the extra args to toString, which made the python resolver look rather different.

Also, I'd rather not expose the full monty of the bundle, but define an explicit context. locale as in the current locale is a good start. Thinking about date formatters, we might also want to include something like os_locale and requested_locales?

There's also a side of me that wants to make it really hard to do something wrong on the implementers side, so I'd prefer to add things to that context only if we have strong guidance on how to choose.

[stasm]

The ability to "spoof" this is very js-specific. Should we use a pattern that's easier to generalize? It's akin a bit to the extra args to toString, which made the python resolver look rather different.

Right. In other implementations the context would need to be passed explicitly to the function when it's called, or bound to it during the bundle's constructions. Fortunately, none of these approaches would have impact on the translations. FOO(a, b) can be called as FOO.call(context, [a, b]) in JS, or as FOO([a, b], context=..) or FOO(context, [a, b]) in Python, etc.

Also, I'd rather not expose the full monty of the bundle, but define an explicit context. locale as in the current locale is a good start. Thinking about date formatters, we might also want to include something like os_locale and requested_locales?

Starting with the current locale (or, actually, locales, because that's what the bundle stores) sounds good to me. If we see the need to add more data, we can expose it later. The only provision I would make right now is to make the context an object, so that it's easy to add more properties to it later on.

There's also a side of me that wants to make it really hard to do something wrong on the implementers side, so I'd prefer to add things to that context only if we have strong guidance on how to choose.

I braindumped this issue quickly when I was writing my reply in projectfluent/fluent#227. I agree that we should start small; I don't know yet if I want people to call bundle.format() inside of custom functions :)