From Fedora Project Wiki
m (rework structure)
 
(3 intermediate revisions by one other user not shown)
Line 17: Line 17:


= Current processes =
= Current processes =
* Any project owner - a Fedora contributor - can come an create a new translation project.
* Inside Zanata, documents for a project are grouped into ''versions''. For simple projects, it is typical to create a single version named 'master'. Other projects use workflows in which there is a version under active development, and one or more versions that are being maintained in a stable state with only some minor changes. Grouping these related versions under the same project allows for easier reuse of translations between versions. See [http://docs.zanata.org/en/release/user-guide/versions/create-version/ doc] for details.
* Multiple files format are theoretically supported by Zanata, but only gettext format really matter.
** SELECT `contentType`, count(`id`) FROM `hdocument` GROUP BY `contentType`, shows 12702 application/x-gettext and 137 text/plain.
** Default file type by project: File 12, Gettext 80, NULL 23, Podir 5, Properties 2, Xliff 1, Xml 1
* The project owner can manually upload and download data with Zanata (rare use case)
* The project owner can use a Command Line Interface to upload/download data with Zanata
** Some projects uses the Zanata CLI Continuous Integration or Continuous Deployment.
'''Strengths''':
# Upstream project are autonomous and don't require anyone from l10n team to create/push or pull translation
# there is only one commit for all translation
'''Weaknesses''':
# nobody get noticed when a new ''project'', ''version'' or ''document'' is created
# there is no easy way to know if upstream downloaded the latest translation from Zanata
# there is no easy way to know if content in Zanata is still synced with upstream
# projects can decide not to store translation in a git repository
'''Risks''':
# Zanata packages may not be available anymore for project to push/pull content https://apps.fedoraproject.org/packages/zanata-platform/builds/
'''Opportunities''':
# ...


= User stories=
= User stories=
Line 50: Line 79:
= System requirements =
= System requirements =
=== supported file formats ===
=== supported file formats ===
{| class="wikitable sortable"
|-
! Translation format !! Weblate !! Fedora
|-
| GNU gettext || yes || required
|-
| Monolingual gettext || yes || ?
|-
| XLIFF || yes || ?
|-
| JSON || yes || ?
|-
| JSON i18next || yes || ?
|-
| Qt Linguist .ts || yes || ?
|-
| Java Properties || yes || ?
|-
| CSV || yes || ?
|-
| YAML || yes || ?
|-
| Ruby YAML || yes || ?
|-
| Excel Open XML || yes || ?
|-
| PHP Strings || yes || ?
|}
Additional formats are available [https://docs.weblate.org/en/latest/formats.html here]
=== synchronization with the source repository ===
=== synchronization with the source repository ===
=== automation support tools ===
=== automation support tools ===
=== translation quality checks ===
=== translation quality checks ===
=== the interface possibilities ===
=== the interface possibilities ===

Latest revision as of 07:37, 20 August 2019

Future migration plan
This page is a work-in-progress content about L10N Move to Weblate

Context

The Fedora Localization project has a few groups in https://fedora.zanata.org:

  • Upstream project, organized in two categories
    • main Following Fedora development cycle
    • upstream Not following Fedora development cycle
  • Fedora Project specific content:

In addition, we have two groups aiming to help prioritization:

  • Priority Packages List of priority packages, documentation and websites for the upcoming Fedora release
  • rhel Branches for Red Hat Enterprise Linux

Current processes

  • Any project owner - a Fedora contributor - can come an create a new translation project.
  • Inside Zanata, documents for a project are grouped into versions. For simple projects, it is typical to create a single version named 'master'. Other projects use workflows in which there is a version under active development, and one or more versions that are being maintained in a stable state with only some minor changes. Grouping these related versions under the same project allows for easier reuse of translations between versions. See doc for details.
  • Multiple files format are theoretically supported by Zanata, but only gettext format really matter.
    • SELECT contentType, count(id) FROM hdocument GROUP BY contentType, shows 12702 application/x-gettext and 137 text/plain.
    • Default file type by project: File 12, Gettext 80, NULL 23, Podir 5, Properties 2, Xliff 1, Xml 1
  • The project owner can manually upload and download data with Zanata (rare use case)
  • The project owner can use a Command Line Interface to upload/download data with Zanata
    • Some projects uses the Zanata CLI Continuous Integration or Continuous Deployment.

Strengths:

  1. Upstream project are autonomous and don't require anyone from l10n team to create/push or pull translation
  2. there is only one commit for all translation

Weaknesses:

  1. nobody get noticed when a new project, version or document is created
  2. there is no easy way to know if upstream downloaded the latest translation from Zanata
  3. there is no easy way to know if content in Zanata is still synced with upstream
  4. projects can decide not to store translation in a git repository

Risks:

  1. Zanata packages may not be available anymore for project to push/pull content https://apps.fedoraproject.org/packages/zanata-platform/builds/

Opportunities:

  1. ...

User stories

File formats:

Description Reasons, if required Priority
As a project maintainer, I want to be able to push/pull translation files with the following formats : po n/a MVP

Interaction:

Description Reasons, if required Priority
As a project maintainer, I want to have a direct connection between the translation platform and my project repository Make sure there is no delay. TBD
As a project maintainer, I want to have a manual connection between the translation platform and my project repository Pull/push mecanism as we currently have with Zanata. MVP
As a ‘’’???’’’, I want to be able to interact with the translation platform using an API. TBD

Quality checks:

Description Reasons, if required Priority
As a project maintainer, I can set/unset some technical checks. programming langage checks TBD

System requirements

supported file formats

Translation format Weblate Fedora
GNU gettext yes required
Monolingual gettext yes ?
XLIFF yes ?
JSON yes ?
JSON i18next yes ?
Qt Linguist .ts yes ?
Java Properties yes ?
CSV yes ?
YAML yes ?
Ruby YAML yes ?
Excel Open XML yes ?
PHP Strings yes ?

Additional formats are available here

synchronization with the source repository

automation support tools

translation quality checks

the interface possibilities

Retrieved from "https://fedoraproject.org/w/index.php?title=L10N_Move_to_Weblate/Objective:_hosting_projects&oldid=550591"