This introduce a new way of doing "migration" of data based on the
operation table. Before, we simply executed the SQL query as the
migration were run. Like for a "new" operation, we did an insert of a
"transactions" row and an update to the "operations" table _for each
entry in the synced file._ For a file containing 1000 keys, we did a
total of 2000 SQL queries.
After this commit, we only do 2 SQL queries (well 4 since we batch the
SQL params by 500). By aggregating operation like {:update_all,
operation.id, %{synced: true}}, we are able to batch the operations
efficiently.
This results in a much faster sync/add translations/correct/uncorrect
operations.
## 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".
