Have the API return string constants instead of human-readable values for some fields

[diox]

The new API currently returns type, status and platform in an human readable string format, translated according to the lang parameter (falling back on Accept-Language header). So for instance we get:

{
...
"status": "Fully Reviewed",
"type": "Extension",
...
}

(Example: https://addons-dev.allizom.org/api/v3/addons/addon/adblock-plus/)

I'd like to change this to string constants. In this case, we'd get "status": "public" and "type": "extension". This would let the client be in charge of translating the constants to a human-readable string in the right language, and more importantly constants would allow the client to do proper conditions based on the add-on type, status and file platform. The problem is, the front-end would then need to have a copy of the constants and their meaning, and keep in sync with addons-server. Any thoughts on how we should proceed, @mstriemer @muffinresearch @EnTeQuAk ?

[muffinresearch]

I think heading in the directions of constants is a good idea since eventually we should be at a point where the majority of the l10n should be happening on the client (in both the front-end server (node) and the client-side code thinking ahead to when we have a universal front-end powered by the API).

Right now we have code in addons-frontend that forks based on the type. Clearly that's not going to work if that's a localized value. :/

If we wanted to DRY the constants up (and not duplicate them) then we could consider having a lib for this which outputs both a python and npm package. However this does mean you end up with some maintenance overhead around bumping package versions etc.

If we went the package route I'm not sure about whether localizing that package would necessarily make sense. Having translations carried out where they are consumed is probably OK since translations can be contextual so a literal translation of a constant may not always work.

[mstriemer]

I think returning constants seems like the right thing to do.

As far as keeping them in sync I'm not sure a package that exports to pypi and npm is the right solution. We did that with marketplace-constants and I wasn't crazy about it. It didn't feel like it caught any bugs and added a good amount of overhead.

My suggestion would be to store the constants in a JSON file in each repo with the same format, then in each consuming project add another task to the Travis build that just clones addons-server and diffs the files.

In marketplace-constants it had some tasks to convert JSON to .py and .js files, we could move those tasks into each repo if we wanted or have the projects read the files directly (not an issue for python, I'm assuming webpack handles reading a JSON file gracefully but I'm unsure).

Downside being if the constants update it breaks the build everywhere until they get updated.

[muffinresearch]

I like @mstriemer's idea about off-loading the syncing problem as automation. Could be nicer than all the package wrangling.

[diox]

I like the idea, but is it really better than the package thing ? Ultimately instead of updating the constants package across all repos you need to fire up the sync task or whatever for all repos, which probably means a PR or at least a commit for each repos like the package bump would.

We may not need to solve this now depending on what data we want to display in disco pane / internal search initial versions anyway. I'll proceed with making the API return string constants.

[EnTeQuAk]

First, I'm 👍 on returning string constants instead of the actual text-representation.

But I think I'm against syncing constants between repositories. Let's take a (imaginative) permission system for example, where you have can_create_addon, can_modify_addon permissions and constants on the backend (we have billions of those) as well as can_delete_addon.

All these are present in our backend logic and we already have (and probably always will) a textual-representation of those in the backend. At least for human readable error-responses.

So maybe respond with a constant and the human readable translation when possible? I see error-responses like "you don't have access to xxx" as an example which are fully translated on the backend and could used 1:1 on the frontend.