Another thing I forgot to mention.

Nice to have would also be an option to easily check other language translations of the source string. For example, for Romanian it's often useful to inspect the way French, Italian, Spanish, Portuguese translated it, but it's also less useful to check the Chinese or Japanese translations.

Pootle has a feature where translators can set 'alternate' languages (individual setting). Mozilla's Pontoon ( https://pontoon.mozilla.org/ ) also lets people check translations made by other locales from the translation interface.

This could be a cascading series of settings: a global setting (language families grouped together), a per-locale default setting (decided by locale leaders), but also adjustable by individual translators. For example: Romanian, French, Italian, Spanish, Portuguese could be grouped, but French locale leaders may decide Romanian is not relevant for them, and a French translator may decide German may be relevant to them. That one French translator would then get to see translations done by: Italian, Spanish, Portuguese and German.

Waiting for your feedback.

Jobava

On Wed, Mar 9, 2016 at 12:05 PM, Baadur Jobava <jobaval10n@gmail.com> wrote:
I would like to detail some suggestions I had for Zanata improvements, engagement for translators and testing.

1. Zanata is missing terminology control. This is a feature already in Transifex, Pootle and present in most proprietary translation tools out there.

Terminology control means "glossary", but also aspects of something people call "controlled language".

In Transifex, each project has an attached terminology, with translation reviewers being able to update the terminology. My workflow there is a little clunky, but workable:

I keep at the same time two tabs open, one with Terminology definitions, where I can add or adjust terms, and a second tab with the translation interface itself. As I translate, especially a new project, I add new terms to the list. (An improvement may be to be able to adjust terminology and translation from the same window)

Setting terminology as translation progresses helps maintain consistency even if there is just one translator working on it. Unlike the automated translation memory, terminology provides 'intent' and highlights the important terms.

As people translate, the terminology words get highlighted, with suggestions for each one. In Transifex there is inline highlighting (underlining) and a contextual bubble appears when you hover across the highlighted term. In Pootle the terminology terms appear to the side in a separate rectangle, along with their recommended translation and comments.

Other than simply a glossary, terminology control should also highlight 'terminology violations' and have a filter to select only for these strings.

As people add new terms to the terminology, the English variants get all added to a global list, so if a Japanese reviewer adds a new term, that one is also available to the French locale (and every other one) -- a good feature of Transifex. Now, a tool like Pootle only has locale-specific terms list, so each locale has to figure out their own terminology list. I prefer the Transifex way.

Something that doesn't exist, but may help: 'hard' and 'soft' terminology. Hard terms may be those specific to the application or technical terms with strict interpretation, while 'soft' ones may be regular language which needs to be kept consistent, but not critical or with a special meaning for that project. Hard terms may be global, while soft ones may be locale-specific.

more nice things to have:
2. Language-specific dashboards for Zanata
for each language, from the Language page (eg. https://fedora.zanata.org/language/view/fr ):
- latest changed projects, number of strings for each project and who did them
- a link to a diff-style list with 'before', 'after', 'translator' for the last changed strings

3. Diff tools for Zanata: a way to inspect the state of the strings in 'before' and 'after' style picking two arbitrary dates, with github-like diff coloring for the changes and authors for each string (or substring) changed.

4. Feature improvement: an option to automatically import strings to a branch from another branch (for example, from 'development' to F24) for identical strings. Maybe an option to import identical translated strings from all other projects.

5. L10n engagement:
- mass-email people who contributed to Fedora from Transifex who have not yet registered for Zanata (not yet joined a language group)
- mass-email translation contributors, even those not yet on the mailing lists about the Fedora schedule and deadlines and maybe another mail about vFAD or translation test day

6. Automatic UI testing
I was wondering if it were possible to set up some kind of automation that can:
Walk the UI of a given project and take screenshots progressively of the interface, menus, submenus, windows and contextuals. I understand Gnome already has a web tool where you can manually inspect the menus, but something that generates a flat list of screenshots can help people go through the UI in a faster way. This would be toolkit-specific, but may be worth investigating if possible.

That is all, thanks!

Jobava