Description of problem: There's some contention between what is defined as "Done" for a project. We use the term "Requires" for the review enabled project, but in actuality it's not required at all. * Project status default front page should show the project's "Done Status", not an intermediate state. * There's no indication of a language being 100% complete, when it's fully approved. This is a terrible way to present information to the user. A translator specifically will see their language as 0.0% translated - i.e. not at all done. * Translators (I expect being the vast majority of users) do not care about review until the review has failed the targets. * The use case for displaying the intermediate state between "done" and "not done" is arguably small. * When exporting/downloading a translated file the "translated" state flows are delivered, despite the project having a "requires review" condition. Projects should be able to specify a minimum export quality if they have "Requires Review" set, or behave very specific to the review guidelines as indicated. Version-Release number of selected component (if applicable): 3.5
We should also make proper use of the "Fuzzy" state for a Requires Review process, thus doing away with the "Rejected" state completely. Users find that "Rejected" is too harsh a term for something that has not passed review, and Fuzzy indicates that there is a translation but there is issue with it. So a better course of action would be for the reviewer rejection to behave similarly in the UI (force a comment, etc) but push the translation state back to fuzzy. This is "less negative" an is more streamlined than having another offshoot state to deal with.
In addition to this i think "Fuzzy" should be changed to "Needs work". There would (at this time) be 3 types of needs work. Fuzzy (from TM) Draft (Not finished or sure of own work) Reviewed and needs work
Firstly we need to get our terminology right. For project that need review, so far our states represent: Approved: Translator say "done" and Reviewer say "Ok" Rejected: Translator say "done" and Reviewer say "NO" Translated: Translator say "done" but not yet Reviewed. Fuzzy: Translator still working. Untranslated: Empty string. "Translated" in translator's view and non-review projects, may mean that: "Translator say 'done', and reviewer did not say 'NO'. We can use either 1 ."Pending Review" for "Translator say 'DONE'" but not yet reviewed for review-enabled projects. or 2. Use some other term that says "Translator say 'done', and reviewer did no say 'NO'".
This is what I think our main statuses should be: Untranslated Needs Work Translated Then an extra flag for "approved" which can will always accompany a "translated" status. I think we should have the ability to have issues for strings. There can be multiple types of issues. If a translation is reviewed and not good enough, the reviewer can add an issue to the translation and it will automatically be moved back to the "Needs Work" status. Issues could also be used for source strings and similar to github issues reporters could add custom labels/tags to an issue. This would allow for more detailed reviews (which I know we are trying to do in house from my talks with other translators). There is a lot more we could do with issues too. As for the "TM Fuzzy" and "Draft" Needs Work statuses, we should be able to provide a small amount of meta data as to why this current translation is marked as "Needs Work" if it has not come back from a review. e.g. If it came from TM and what is its % match or who was the translator that saved it as Needs Work and did they leave a comment as to why.
Also as far as editor filters go we can filter the main statuses: Untraslated Needs Work Translated We can also filter Approved. We can filter translations with issues. We can also have a broader filter for: - Needs Translation (Untranslated and Needs Work) - Needs Review (Translated but not approved)
+1 on https://bugzilla.redhat.com/show_bug.cgi?id=1153474#c4. We should only have 3 states for translation: translated, needsWork(Fuzzy) and Untranslated. Review states (approved,reject(issue)) should always be treated separately. Current implementation of merging these 2 already creating confusion not only in UI, but also in the backend.
(In reply to Luke Brooker from comment #4) > This is what I think our main statuses should be: > > Untranslated > Needs Work > Translated > > Then an extra flag for "approved" which can will always accompany a > "translated" status. To do that, beside update documentation, as well as data migration. i.e. Approved -> Translated with Approved flag. > I think we should have the ability to have issues for strings. There can be > multiple types of issues. That should be addressed in other bug. > If a translation is reviewed and not good enough, the reviewer can add an > issue to the translation and it will automatically be moved back to the > "Needs Work" status. > As for the "TM Fuzzy" and "Draft" Needs Work statuses, we should be able to > provide a small amount of meta data as to why this current translation is > marked as "Needs Work" if it has not come back from a review. e.g. If it > came from TM and what is its % match or who was the translator that saved it > as Needs Work and did they leave a comment as to why. Come to think of it, we also need to think of the case that translators do "peer-review", that is, non-reviewer translators may downgrade other translators' work as "Need work".
(In reply to Ding-Yi Chen from comment #7) > Come to think of it, we also need to think of the case that translators do > "peer-review", that is, non-reviewer translators may downgrade other translators' > work as "Need work". Yep. Issues work there too. It's only approvals that need to be done by "Reviewers".
As we are getting more review work, I believe this is important feature we need to improve on. setting the priority high to decide on implementation details.
Migrated; check JIRA for bug status: http://zanata.atlassian.net/browse/ZNTA-297