Project

General

Profile

Feature #10331

Feature #10034: Translation web platform

Feature #10257: Merge strategy from Weblate

Investigate the review processes available inside weblate

Added by u about 3 years ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Infrastructure
Target version:
Start date:
10/03/2015
Due date:
% Done:

100%

QA Check:
Pass
Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:

Description

It's supposedly a must that there should be such a review process inside weblate.
People should be able to translate, but a reviewer should review before things get pushed.

History

#1 Updated by u about 3 years ago

  • Parent task set to #10257

#2 Updated by intrigeri about 3 years ago

  • Related to Feature #10299: Consider disabling the htmlscrubber ikiwiki plugin added

#3 Updated by intrigeri about 3 years ago

  • Related to deleted (Feature #10299: Consider disabling the htmlscrubber ikiwiki plugin)

#4 Updated by muri almost 3 years ago

oke, moving this here from #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 u almost 3 years ago

Indeed, thanks muri.

So we would need to review the current roles.

#6 Updated by u almost 3 years ago

  • % Done changed from 0 to 10

#7 Updated by emmapeel almost 3 years ago

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 almost 3 years ago

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 almost 3 years ago

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 u almost 3 years ago

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

#11 Updated by sajolida almost 3 years ago

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 u almost 3 years ago

yes!

Shall we create a ticket to set this up?

#13 Updated by intrigeri over 2 years ago

  • Category set to Infrastructure

#14 Updated by sajolida over 2 years ago

  • Target version set to Tails_2.3
  • QA Check set to Ready for QA

So. We concluded in #10802 that Weblate has two states:

  • "Suggestion" where translations are only saved in the database.
  • "Translation" where translations are written to PO files on the disk.

Weblate also has a system for ACL where groups can be granted rights to perform different actions.

We could have:

  • Translators being granted the right to suggest translations.
  • Reviewers allowed to vote for suggested translations. With two votes the suggestion turns into a translation that is written to the disc.

This could met our requirements for the review process and be nice to Git. Yeah!

#15 Updated by u over 2 years ago

  • Status changed from Confirmed to Resolved
  • Assignee deleted (u)

thanks for researching this!

#16 Updated by intrigeri over 1 year ago

  • % Done changed from 10 to 100
  • QA Check changed from Ready for QA to Pass

Also available in: Atom PDF