907820 - Figure out a way to return all translations w/ the objects returned in the API, when needed

Status: VERIFIED FIXED

(Marketplace Graveyard :: API, defect, P2)

Description

[Mathieu Pillard [:mat]]

For some features (mostly when editing stuff) we need a way for the API to return all translations with an object. (Or maybe with multiple objects even). For instance, rocketfuel needs this when editing collection, devhub will need this when editing an app's details, and reviewers tools probably need this too.

bug 907181 will add this for Collections, but we should figure out a way to do this for all kind of objects, in all our APIs. The problem is, we probably don't want this everytime, because for instance consumer pages don't care about 90% of the translations anyway, they only want the one in the current language.

Comment 1

[Mathieu Pillard [:mat]]

relevant discussion on IRC:

<basta> mat: what if we had an HTTP header which turned the objects on/off?
<basta> consumers obviously don't need all the translations
<basta> and the API just returned the string when the header tells it what to send rather than the object
<mat> mmm
<mat> I wonder how annoying this is to implement with django-rest-framework, but it's worth a shot
<mat> we'll need this for apps when implementing devhub w/ the API for instance
<mat> I'm not a super fan of the header, but I don't see a more elegant solution atm

Comment 2

[Allen Short [:ashort]]

Let's talk about other options besides a header here -- I know we don't like query args but that seems better than a magic extra header for controlling what data is returned.

Another option would be to add a separate resource for translations.

Comment 3

[Matt Basta [:basta]]

I don't know what having a separate resource means.

We can totally have a query string param, but for rocketfuel we're basically just going to hard-code it to "on". There's never a case where we wouldn't want the object.

The only case where we'd want a string back is on the consumer side where we care about bandwidth and latency. Maybe it should be a switch to turn the objects off rather than on.

Comment 4

[Mathieu Pillard [:mat]]

Separate resource == separate endpoint. Something like: /api/v1/translations/collection/<x>/ and it would return alls the Translation fields on the Collection, in the object form. It would mean a separate HTTP request, but it's simplify the rest, and wouldn't be used by consumer side stuff so maybe it's not so bad?

Comment 5

[Matt Basta [:basta]]

(In reply to Mathieu Pillard [:mat] from comment #4)
> Separate resource == separate endpoint. Something like:
> /api/v1/translations/collection/<x>/ and it would return alls the
> Translation fields on the Collection, in the object form.

Let's not do that.

Comment 6

[Mathieu Pillard [:mat]]

Another proposal:
- All GET requests with explicit 'lang' parameter only return strings (in that language if possible, or default_locale/language, just like it works now for apps API). If that parameter is omitted, or empty, all translations are returned in an object form.
- All POST, PUT, PATCH always return objects with all translations (and always accept a dict with as many locales-translations as you want as input for translated fields)

From my initial observation it seems coherent with what fireplace does (always sends lang parameter). Thoughts ?

Comment 7

[Matt Basta [:basta]]

Yes, that seems right. Ideally, if no `lang` parameter is sent, the API should return the dict of translations.

We should just be careful with things like ratings, where I believe the actual review field is a translated field (I think), but we have weird expectations of what the data is on the way back. Not a real concern but something to test.

Comment 8

[Mathieu Pillard [:mat]]

Here is a PR implementing that proposal : https://github.com/mozilla/zamboni/pull/1231

Comment 9

[Mathieu Pillard [:mat]]

(P2 because it's blocking more and more conversions to DRF which are P2)

Merged in https://github.com/mozilla/zamboni/commit/38473d8eefda7f10fd09a837a110807af78384df now that bug 935940 has been fixed.

STR:
- Go the the curation tool on -dev, make sure you can edit name & description for operator shelves / featured apps collections in multiple languages
- Verify that your changes are saved in the curation tool
- Verify that changing your lang in the consumer pages affect the name & description of the displayed operator shelves / featured apps collections (e.g., if you made a featured apps collection name to be "Foo" in english and "Bar" in french, make sure it's showing "Bar" in the consumer pages when you have french as your prefered browser language)

Comment 10

[Victor Carciu]

Verified as fixed for French language : http://screencast.com/t/tR8f40ViOiyR