Conversation
… bundles.
This change changes a lot of tests, as there's a shift from
format() to format_pattern(get_message().value).
With the get_message API, the complex lookups format('msg.attr') also expose
an API surface that's not inline with other impls, so I removed
quite a bit of utility code that served that purpose.
And as I changed all lines referencing bundles, I named the local
variable `bundle` instead of `ctx`.
There's a bit of clean-up sneaking in to this patch, triggered by
reshuffling the referencing code. Notably, all resolvers now
consistently return fluent types. In some cases, they returned
resolvers, which required resolving to get to types.
This corresponds to what @fluent/bundle does on the js side, but doesn't try to be async at all.
| if not msg.value: | ||
| continue | ||
| val, errors = bundle.format_pattern(msg.value, args) | ||
| return val |
There was a problem hiding this comment.
Maybe return the errors, too?
| return parser.parse(source) | ||
|
|
||
|
|
||
| class FluentBundle(object): |
There was a problem hiding this comment.
Should we move this to its own file?
| self, locales, resource_ids, resource_loader, | ||
| use_isolating=False, | ||
| bundle_class=None, functions=None, | ||
| ): |
There was a problem hiding this comment.
Is this PR the right place to comment on the design of the FluentLocalization API? Would you prefer to move this discussion to Discourse perhaps?
I'd like to suggest using the pattern we use in @fluent/react and @fluent/dom, i.e. rather than pass a lot of config parameters to the constructor, we pass an iterator over bundles created by the user. This allow the user of the API to be in charge of the exact bundle class used, the options and functions used to initialize it, and the loading logic.
|
The state of this branch is released and published on PYPI. It's on a branch in case it's a dead end, but it doesn't seem to be. I think we should merge this branch as is, and create follow-ups if we want to revise APIs or refactor parts. For the expected behavior of the Localization class, discourse is probably a better platform than an implementation ticket, yeah. |
|
Per conversation on discourse and a chat with stasm on matrix, I went ahead and merged this. |
2 participants
This was an experimental branch to demonstrate how to implement the bundle API of other implementations, and to create a base Localization class for developers to use, and for binding-implementers to customize.
Per https://discourse.mozilla.org/t/experimental-release-of-python-fluent-runtime/47569/2, we should go ahead and merge this now.
CC @stasm @spookylukey