Feature Request (Fedora Hub): Additional webhooks

Description

I work on the Fedora Infra team and was wondering if it's possible to
get the webhooks listed below implemented so we can have the Fedora
Zanata server interface with Fedora Hubs.

1. when a string is available for translation (project_id, project_version, language, msgid, msgstr)
2. when a string is available for review (project_id, project_version, language, msgid, msgstr)
3. when a string is successfully reviewed (project_id, project_version, language, msgid, msgstr)
4. when a new branch is created (project_id, project_version)
5. when a new project is created (project_id, project_name, project_versions?)
6. adding/removing maintainers for project_id?
7. When new pot/po file has been added (project_id, project_version)

Use Case

Here are some of the use cases for the web hooks:

  • Widget that displays % translated statistics for various critical pieces of Fedora. (How do we define critical?) Goal of the widget would to be to identify those parts of Fedora in most critical need of translation and try to encourage translators to pop over to those items in Zanata and submit some new translations.

  • Widget that displays translation submissions in need of review. From what I understand thus far, translated strings must be approved by a reviewer on the translation team. The goal of this widget would be to draw more attention to strings that have been submitted but need review to get them in.

  • Widget that displays a random untranslated string to tease the logged in user to submit a translation. This one could be tricky because we need to know the language the user can translate in order for the widget to be useful

We plan to get mockups drawn up asap.

src: https://lists.fedoraproject.org/archives/list/hubs-devel@lists.fedoraproject.org/message/ZMGUOK63U76RTGCOFOBDFI6RDOLQSS6D/

The additional hooks is for future projects that we would like to start piping zanata data into fedmsg http://www.fedmsg.com/en/latest/

Here's how the raw data looks like for our other projects that utilize fedmsg https://apps.fedoraproject.org/datagrepper/raw

Activity

Show:
Szymon
June 27, 2016, 2:25 PM

Image mock up

Alex Eng
June 29, 2016, 5:19 AM

1. when a string is available for translation (project_id, project_version, language, msgid, msgstr)

The only way to know if a string is available for translation is if its saved as untranslated/fuzzy.

2. when a string is available for review (project_id, project_version, language, msgid, msgstr)

This can be extracted when a translation has been saved as 'translated'

3. when a string is successfully reviewed (project_id, project_version, language, msgid, msgstr)

This can be extracted when a translation has been saved as approved/rejected

I think for 1-3, it can piggyback on https://zanata.atlassian.net/browse/ZNTA-938 where we probably need to include the msgId of the textflow, or the url to the editor
Also for 1, new event for when source doc is uploaded without translations.

4. when a new branch is created (project_id, project_version)

New event for new version creation of a project.

5. when a new project is created (project_id, project_name, project_versions?)

Webhook configuration is in project level and can only be added after project is created.

6. adding/removing maintainers for project_id?

New event for maintainers add/edit

7. When new pot/po file has been added (project_id, project_version)

This will be new event for when doc is uploaded

Alex Eng
August 31, 2016, 11:02 PM

After evaluating more with our current available webhook. 1-3 is basically implemented but in document level instead on message level.
Example payload:

The webhook consist of states changes of the document in a language. So from the statistics in the payload, you would be able to determine if

a string is available for translation

if 'New' in 'wordDeltasByState' is +

a string is available for review

if 'Translated' in 'wordDeltasByState' is +

string is successfully reviewed

if 'Approved' or 'Rejected' in 'wordDeltasByState' is +

For request No. 5 is impossible at the moment since the webhook config is in project level. 4,6,7 will be will webhook request.

Ready for Release

Assignee

Alex Eng

Reporter

Szymon

Labels

Tested Version/s

None

Story Points

0.5

Sprint

None

Fix versions

Priority

unspecified
Configure