Split "What's new" content from the main description in the API call

[JohanLorenzo]

See bug 1444391 comment 14

[flodolo]

@JohanLorenzo After a bit of thinking, how am I supposed to know what to serve for api/v1/fx_android/translation/59/en-GB/? For us 59 starts at Beta, then becomes release.

I could serve the release content if available, fall back to beta if not, or return an error if the version is unknown.

But I don't think that would actually solve that bug, and I don't want to store information (i.e. dates) about the release cycle, or time merges around RC dates.

[flodolo]

But I don't think that would actually solve that bug, and I don't want to store information (i.e. dates) about the release cycle, or time merges around RC dates.

Practical example: using the Release -> Beta -> Error fallback chain, for us 59 would have been release on March 8, when we merge the content update for the new Beta.

[JohanLorenzo]

I think api/v1/fx_android/translation/59/en-GB/ should serve

{
    "whatsnew": "some new feature that is highlighted in Fennec 59" 
} 

Then, there is no date nor fallback to provide. It should just be data that is relevant for this particular train. What do you think?

[flodolo]

Then, there is no date nor fallback to provide. It should just be data that is relevant for this particular train. What do you think?

I still think we need some sort of priority: for us 59 has two files, one for beta and one for release, and sometimes string changes between the two when a feature is disabled (rarely).

Or maybe we need to simplify things on our side, and start using only one file instead of two.

I'll have to think a bit more about it, but I believe I have enough to start :)

[flodolo]

Actually, more questions: would api/v1/fx_android/translation/59/en-GB/ (or whatever URL we come up with) only return the whatsnew content, not the full API response we have right now (title, desc, etc.)? Otherwise, we're back to the problem of knowing to which channel a version belongs to.

[JohanLorenzo]

Actually, more questions: would api/v1/fx_android/translation/59/en-GB/ (or whatever URL we come up with) only return the whatsnew content,

That's right. That would be closer to the data structure Google Play expects.

[flodolo]

@JohanLorenzo Does this work?

The old URL is still valid, content is unchanged https://l10n.mozilla-community.org/stores_l10n/api/v1/fx_android/translation/release/fr/

New URL always return a string for whatsnew: if it's not translated, it returns the English content (same behavior as the current /translation):

• Translated
• Untranslated

If the app version is unknown, it returns 400.

[JohanLorenzo]

That's awesome! I'll update mozapkpublisher to fetch whatsnew from the app version URL. Thank you!

[flodolo]

Great. I'm marking this as fixed by #161. Let me know if I had to add something to that call.