From Fedora Project Wiki
(page creation)
 
(review (merci José))
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
Translations are coming from everywhere, project by project on a "vertical" way. It comes from a project and through the packaging process it reach the user, project by project.
{{admon/warning|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]]}}
When an Hungarian or French use Fedora in his language, use many software when using Fedora, and see translations (and localisation) on a horizontal way ( ie, per locale ). To improve the end-user experience, we need to think and act in a transversal way.


== Proposal - try to change the way we provides translation to end-user ==
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.


=== Objectives ===
== Improve Fedora (as a platform) translation release preparation ==


Provide translations to end user on a "horizontal" way.
=== Objective ===
We want to push translation directly to the end user, without requiring efforts from upstream and packagers.
This will bring more reactivity, reduce efforts all across the ecosystem.


Context : please note this is not Fedora software focused but Fedora product focused, it means it also includes upstream projects perimeter.
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.


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


Current process :
== To do so, many metrics and tools are needed ==


We see errors > we do the work upstream > we find their translation platform (all different) and correct it > we ask for the publication of a new minor version > we request new Fedora packages
''Note: This list is a many-years road-map and have to be prioritized.''
===> from 3 weeks to 3 years, with many unneeded actors solicitation, resource utilization.  As Ralph Bean would say, this is not really Factory 2.0 compliant.


Idea of new process :
=== Globally ===


We see errors > we correct it > we submit the content to end user
* Monitor the current state of Fedora on a horizontal way ;
                              > and we submit modification upstream (at the same time)
** Status : what is the LANGUAGE status in Fedora packages ?
===> translation process only involve the language team that has the responsibility for quality, distribution and upstream. There is also a faster feedback loop from locale community to translators
*** 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/


Use case example : I want to make easy to translate software in Gnome Software for a community, by using the current translation process, it will be a never-ending painful work. By having an middle platform to translate and push strings directly to end-user, it would make translation team way easier.
* 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)

Latest revision as of 05:59, 12 October 2016

Warning.png
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

  • 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 ?
  • 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 ?
  • 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
  • Ease communication between Zanata contributors by adding feature =>
  • 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)
Retrieved from "https://fedoraproject.org/w/index.php?title=User:Jibecfed/Localization_proposal-Help_languages&oldid=476899"