User:Jibecfed/Localization proposal-Help languages

This page is a work in progress. It has not been validated and and has to be considered has a basis for discussion between translation teams. Please also have a look to User:Jibecfed/Localization_proposal-Horizontal_distribution

Translations are coming from upstream and reach end-users through the packaging process, project by project. The end user using Fedora in his language will use many software and see the benefit of localization globally on the platform (ie, per locale). To improve the end-user experience, we need to think Localization globally, regardless of the upstream project.

Improve Fedora (as a platform) translation release preparation

Objective

We want to support language teams activities and help the emergence of new languages by giving them more support tools to help platform monitoring : production process, current status and quality insurance.

Context: please note this is not Fedora software focused but Fedora product focused, it means it also includes upstream project perimeter.

To do so, many metrics and tools are needed

Note: This list is a many-years road-map and have to be prioritized.

Globally

• Monitor the current state of Fedora on a horizontal way ;
  • Status : what is the LANGUAGE status in Fedora packages ?
    • Overall statistics about current packages translation (with time-line)
    • How active is the localization team ? mailing list, active contributors, bugs, words changed
    • Request level : per country visitor stats : ISO download, websites visitors, user settings
    • Automated quality checks : typographic rules, grammar rules, translation pull from source.
  • Status examples already exists, have a look to :
    • Mozilla Transvision platform : https://transvision.mozfr.org (Warning: use the top menu, many interesting entries!)
    • Pology : http://pology.nedohodnik.net/ (one reuse in Fedora context: https://github.com/rbuj/review-translations/)
    • Debian's translation tracker for package description : http://ddtp2.debian.net/ and http://ddtp2.debian.net/ddtss/index.cgi/xx
    • Gnome's platform - Damned Lies : https://l10n.gnome.org/

• Improve communications with other teams, packages maintainers and, in the long term, a standardized operation procedure (SOP) for translators
  • Write about translation platform, good and bad habits, encourage internalization, explain how we work, etc.
• Support a per language community (independent of project source or processes)
  • Language teams should be helped to go beyond Fedora limits and reach other translation teams
• We need a translation team wrangler / supervisor (with a task of managing dates, schedules, and the role of leader among the coordinators)
• Have recurring online meetings on IRC or elsewhere, maybe once together with Zanata devs
• Clarify the way we handle new Fedora versions (websites, docs, packages, languages)

On the current translation platform (Zanata)

• Know where we are => Metrics  : what is translated/fuzzy/untranslated for my language ?
  • Examples : https://l10n.gnome.org/releases/gnome-3-22/ and https://l10n.gnome.org/teams/fr/
• Product centric categories => what is translated/fuzzy/untranslated for my language for Fedora 25, or Fedora Atomic, etc.
• Product centric information => when is the next release and until when can I correct things ?
  • We should have this kind of time-line for the Fedora release focused packages : https://wiki.gnome.org/Schedule
• To know what is happening => who contributed ? What has changed in the translation (diff) ? What are the new project po files ? What are the last added projects ?
  • Examples : add improved version of this page https://fedora.zanata.org/profile/view/jibecfed
  • Sorting improvements : sort project by last edit, by last maintainer po push, by importance, etc.
  • Produce automatic digest of changes to mailing list (new projects, new files, translation updates, etc.)
• Create per language review processes => a language team should be able to prevent a translated content to be made available to the project maintainer if it hadn’t been reviewed
  • each time, teams are different in term of size and process, so autonomy is needed to adapt to resources (by activating or not this feature)
  • Example: use status https://l10n.gnome.org/languages/fr/gnome-3-22/ui/
• Ease communication between Zanata contributors by adding feature =>
  • enable project maintainers to write a message to translators,
  • enable translators to have discussion together about a string, a po file,
  • enable translators to write messages to maintainers, (example: asking the meaning or context of a string, ask which branch will be in the next Fedora release, etc.)
  • Example: https://docs.weblate.org/en/latest/devel/review.html?highlight=comment#string-comments
• Automatic tools to help =>
  • Ex1 : detect very close sentences that have different translations
  • Ex2 : When a string is not yet translated and there exists a translation memory that could almost match, allowmerge. (use case : two branches on the same project, one was translated, not the other one)
  • Ex3: Automate quality checking, looking for potential typo, size of the string, typographic rules
• Zanata feature request to aid problems above
  • Percentage usage from translation memory - what is fuzzy, or need to be fully retranslated (minor fix, or remake)
  • Branch categorization - better overall view of the project files, and their importance before freezing date
  • Missing overall statistics per language (untranslated, fuzzy, translated)