Tails

#4 Updated by muri 2015-11-09 03:32:30

oke, moving this here from Feature #10257, because thats the correct ticket, sorry for the mixup:
i wrote:
> so, i set up my own weblate instanz and tried to figure out some kind of workflow (both in weblate and mergin the results):
>
> so, first of all, in weblate every file to be translated is a component and every component consists of strings. as mentioned above, there is a feature called suggestion voting, which means that a one doesn’t simply translate a string, but one suggests a translation. as soon as N users voted for that suggestion, that translation is used. ‘translation is used’ means, that it is commited, together with all the other translations that can be used (enough users voted on). this commit can be done by hand (if one user has the permissions to do so) or by cron job. then the changes are in the local repository of this specific component.
> then the changes can be pushed to a remote repository (by hand, if one has the permission, or automatically when comitted).
> this remote repository can be set specific to the component (which in weblate means ‘file’).
>
> i haven’t found anything about branches in weblate. to me it seems that if we use one repository for translations, all the commits of translated content ends up in that repository. so the person merging these commits into the tails repo would have to look over all of them at once or look at the commits that affect one specific file (like a the branches we use at the moment).
> there is a pre-commit-script and a post-commit-script option available in weblate, but i don’t know yet if that could be used to group commits together into a branch (if that is even needed?). i think would have to look into git to do so…
>
> i think the notification )if needed) could be done once a day by a commit hook to tails-l10n?
>

and sajolida (my response inline):
> Thanks for looking into this! I can foresee how it would be problematic to choose N in such a system. If N=2, then any team of two malicious translators nobody knows could commit stuff on our website, if N>2 then it would add unnecessary work on the other translators to vote for their strings and thus delay everything.

i thought of the people able to upvote a translation as the same people who are translating/reviewing at the moment. in my case N would be 2. spriver and i (and any other ‘trusted’ translator) can vote. if we both are oke with a translation, it gets saved. so maybe that is the ‘reviewer’ role. there can be another role ‘translator’ which only can suggest translations.

> In the requirements we came up with (see blueprint) there’s was the notion of “role”:
>
> MUST: provide user roles (admin, reviewer, translator)
>
> and that was our initial idea for the review process: some people are “translators”, and some others are “reviewers” that we trust to validate these translations. Did you see any notion of “role” in weblate?

yes, weblate has groups and every permission can be added to a group and/or a user.

#5 Updated by Anonymous 2015-11-20 07:08:43

Indeed, thanks muri.

So we would need to review the current roles.

#7 Updated by emmapeel 2015-11-24 13:49:12

Users can have permission to suggest or translate, and also of commiting.

In my opinion few people should have rights to commit the changes in the repo. Also this repository can be reviewed when merging to master.

There are email alerts about finished .po files. So maybe this can trigger a review, as reviewing each string separately makes no sense sometimes. And maybe at least few people per language able to commit the changes.

#8 Updated by sajolida 2015-11-26 04:02:49

> In my opinion few people should have rights to commit the changes in the repo.

Ok, so could people with the rights to commit can be considered as
reviewers then?

> Also this repository can be reviewed when merging to master.

Not really as this requires Git knowledge, and let’s assume that not all
the people we would trust for reviewing are knowledgeable about Git.

> There are email alerts about finished .po files. So maybe this can trigger a review, as reviewing each string separately makes no sense sometimes. And maybe at least few people per language able to commit the changes.

Also, I don’t know how these “commits” are made but while reviewing the
Farsi translations, I saw that weblate was basically creating a commit
for each translated string or so. If we say that “commit rights” are
only for reviewers, could we then have a single Git commit per review.
That would be nice!

#9 Updated by emmapeel 2015-11-26 10:04:09

sajolida wrote:
>
> Also, I don’t know how these “commits” are made but while reviewing the
> Farsi translations, I saw that weblate was basically creating a commit
> for each translated string or so. If we say that “commit rights” are
> only for reviewers, could we then have a single Git commit per review.
> That would be nice!

If the same user is translating the file it will not commit until the file is finished, a commit is forced, a pull has changes, or after the user stops for a while. There is also a lock when somebody else is translating the same file.

Also I see many commits related to the headers of the .po files. When importing a component, or checking the files afterwards, weblate will correct the headers of the file (like poedit) and commit the changes. This is related to new files or languages being added, so maybe we will not have so much of it later.

#10 Updated by Anonymous 2015-11-26 10:41:04

So, yes weblate can be configured not to commit every single change.

#11 Updated by sajolida 2015-11-27 03:59:26

Ok, so could people with the rights to commit can be considered as reviewers then? and non-trusted translators would not have commit rights?

#12 Updated by Anonymous 2015-11-27 04:53:36

yes!

Shall we create a ticket to set this up?