Exposing Pontoon Data Through API

[Matjaz Horvat]

Hey,

The first iteration of Pontoon API landed!

Check out the blog post for more details and a few examples:
https://blog.mozilla.org/l10n/2017/10/10/exposing-pontoon-data-through-api/

Big shout-out to Staś Małolepszy for making this happen!

To quote Staś himself:

"We’d like to keep the development of the API use-case-driven. If
you’re interested in creating a report, mobile app or an extension
which pulls data from Pontoon, please let us know about your use-case.
We’d like to prioritize the upcoming features to best serve the needs
of the community."

For more information about the planning process, consult the wiki:
https://wiki.mozilla.org/L10n:Pontoon/API

Cheers,
Matjaž

[Michal Stanke]

Oh, that's cool. I will need to learn a bit more about the API, but it
looks very promising so far.

Michal Stanke

Dne 10.10.2017 v 20:38 Matjaz Horvat napsal(a):

> _______________________________________________
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n

[Staś Małolepszy]

Michal, you might be interested in
https://wiki.mozilla.org/L10n:Pontoon/API#Milestone_4 :) It's still
far out in the future (I'd estimate Q1 2018). I'd love to get your
early feedback on what data would be helpful to Pontoon Tools.

[Michal Stanke]

Hi Stas.

Thank you for the first version of the API. I am still looking at how I
can incorporate it into the add-on the best way now.

As for the notifications, to maximize the user benefit from using the
API, the query result should be a bit richer than what is not displayed
in the UI. I can imagine getting and object, that would look like:
{id, timestamp, type, actor, project, verb, newStrings, messageHTML,
deadline}

In this scheme, the fileds /id/, /timestamp/ and /type/ would be a
mandatory skeleton, other may vary depending on the actual notification
/type/. By /type/ I mean an easy way to distinguish between
notifications for new strings, messages from admins, deadlines or other
notifications. Every time can than only contain the fields that are
appropriate - project and number of strings for new strings
notification, sender and project and message for messages, project and
date for deadlines, etc. A bonus would be an API (or some new RESTlike
endpoint) to mark notifications as read one by one using their ID.

Michal

Dne 11.10.2017 v 18:08 Staś Małolepszy napsal(a):