Repository navigation
Add endpoint to fetch fluent reference variants - #4517
Conversation
This will be incorporated to utilities s.t. we can directly pass strings instead of manually parsing at call-sites.
This optionally moves the parsing to the utility bodies, which allows us to simplify tests and eventually call-sites.
|
The diffstat is rather large for my taste, but it's mostly tests. I have attempted to follow the existing project conventions, if there's something that I missed that needs adjusting, just let me know. Also if I misinterpreted any terminology around Fluent strings I'd be happy to be corrected -- this was the first time for me fiddling with the format as well as with its AST. |
eemeli
left a comment
eemeli
left a comment
There was a problem hiding this comment.
Took a quick peek at this before I head off to PTO, so please dismiss my review if it gets stale:
As @mathjazz mentions in #2363 (comment), this API should be fetching all available terms in a project+locale, not just the ones referenced in a single entity. Terms are Fluent-only, and identifiable by their identifier starting with a hyphen-minus - character.
There also should be no need to do any parsing as a part of the work here.
|
Thanks for the quick check before the PTO @eemeli! I definitely misread the intent in #2363 (comment), but I now see the assumption and the trade-off makes sense. re.
I'm not super familiar with the data model, so correct me if I'm wrong, but as I see now |
Yes. For Fluent terms, you'll also need to account for |
This has been superseded by the get_fluent_terms view, which fetches term translations at the project level instead, and requires no Fluent format parsing in the view.
The `get_references` and `get_selector_variants` Fluent format helpers were only used by the removed view.
|
Sorry for the delay here, life happened in the middle… the code has now been updated to fetch all available terms for a project+locale combination. The PR description has been updated accordingly, too. |
mathjazz
left a comment
mathjazz
left a comment
There was a problem hiding this comment.
Apologies for the slow turnaround here — we were at the Mozilla engineering summit.
This looks good to me, nice work!
The payload is keyed on the bare term identifier, so two .ftl files in a project defining the same term would overwrite each other. Given the way we use terms at Mozilla, we should be good. If it turns out to be a problem in practice, let's address it separately.
"...please dismiss my review if it gets stale:"
3 participants
Refs. #2363
In this changeset we introduce the
/get-fluent-terms/endpoint that allowsconsumers to retrieve any term selectors and their variants for a locale within
a project.
This endpoint requires a
projectslug and alocalecode.The view:
properties.
Terms are determined by listing Fluent resource entities that are part of the
provided project and start with the
-character. When translations for thespecified locale are missing, these come back as
None.Note this is the building block for the Fluent term variants autocomplete
feature that will be implemented separately, so the endpoint is not being used
yet.