* Add GitHub webhooks integration to sync a project
The webhook generates events that reads the repo’s config file (the same
config file used by accent-cli) and build "sync" and "add translations"
events in Accent.
It supports a default ref: you can specify to only
trigger the "sync" on the "release/production" branch. It also supports
automatic version sync. If you have a version in Accent that matches
your git tag, "sync" events will be generated for those versions,
without touching your current translations. This can be useful if you
use versions to freeze translations on your releases.
This commit only adds the API side of the feature. So while it’s not
user facing, if you want to test the feature, you can add a matching
"integrations" row in the database and setup your webhook in GitHub :)
* Add tests for integration scope
* Rename hook sync to hook update since the hook sync and add translations
* Order mix.exs deps
* Run formatter
* Fix credo
* Fix tests
* Move GitHub producer with the same shared code as the other producer, simple queue without back pressure
* Remove unused function
* Update event producer from gen stage queue broadcaster
* Add tests
![image](https://user-images.githubusercontent.com/464900/55203015-35c17980-51a0-11e9-8647-d91209c7b6de.png)
## Issue
📚https://github.com/mirego/accent/issues/21
## Feature
This is a basic implementation of the XLIFF 1.2 format. This format is used heavily in a lot of translations related tool (and in XCode) so I may have missed some of the implementation details. But it’s a good start for someone who want to contribute to Accent 😉
## Refactor
This format is a bit trickier than other since it required the master language to export the targets. We needed to refactor some module to use the master language in the serialization process. Also, not needed but cleaner, we wrap the document’s key `top_of_the_file_comment` and `header` inside a new struct `Language.Document`. This will become handy if we ever need to add an attribute to the document OR if we add a different attribute to the serialization input.
## Next steps
This format includes 2 new dependencies to handle XML encode and decode. _Why not use the same XML library used for the XML Android format?_ Because… \*drum roll\* The `<source>` XML tag when encoded by the `mochiweb_html` module is a self closing tag (per the HTML spec) 🥇
Since those 2 new deps are required for the XLIFF format and can pretty print XML, we should use them _instead of `mochiweb`_ 🎉
Interpolations are strings automatically marked (based on the format) to
be replaced by the application at runtime. Those strings are meant to be
left unmodified and not translatable. The UI reflects that. The
interpolations shown to the user is always the master translation’s
ones. This is to clearly show on not translated content that maybe
interpolations uploaded after the correction were removed or added.
The "sync_type" option can now be passed to the sync request to have a
different way to handle operations.
The new "passive" option will ignore all actions but the `new`, `renew`
and `remove`. It will ensure that when uploading a file, no translations
or master strings can be overwritten. It behaves the same way as the
existing merge_type "passive".