Difference between revisions of "ARK2/Localization"

From ARK
Jump to: navigation, search
(→‎Localization)
(→‎Localization)
 
(3 intermediate revisions by the same user not shown)
Line 6: Line 6:
 
* The [http://symfony.com/doc/current/components/intl.html Symfony Intl] component as a wrapper for the [http://php.net/manual/en/book.intl.php PHP Intl] extension and ICU, for collation, formatting and parsing
 
* The [http://symfony.com/doc/current/components/intl.html Symfony Intl] component as a wrapper for the [http://php.net/manual/en/book.intl.php PHP Intl] extension and ICU, for collation, formatting and parsing
 
* The [http://symfony.com/doc/current/components/translation.html Symfony Translation] component for translation
 
* The [http://symfony.com/doc/current/components/translation.html Symfony Translation] component for translation
−
* [http://punic.github.io/ Punic], using CLDR, as a source of some translations
 
 
* The standard JS [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl Intl API], or the [https://github.com/andyearnshaw/Intl.js Intl Polyfill] where Intl is not available
 
* The standard JS [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl Intl API], or the [https://github.com/andyearnshaw/Intl.js Intl Polyfill] where Intl is not available
  
 
== Translation ==
 
== Translation ==
  
−
* Translations are stored and transmitted in the XLIFF file format
+
* Translations are stored in the core database
 +
* Translations are exported into XLIFF file format, allowing offline apps to download the full catalogue
 
* Translations uses keys rather than source strings
 
* Translations uses keys rather than source strings
 
* Translations will be split in a number of catalogues:
 
* Translations will be split in a number of catalogues:
 +
** Vocabulary
 
** Core interface
 
** Core interface
 
** User interface
 
** User interface
 
** Admin interface
 
** Admin interface
 
** Schema (one for each created)
 
** Schema (one for each created)
−
* Actor and User IDs are translated using a custom loader from the database
+
* Actor and User IDs are translated live using a custom loader from the database
  
−
The Admin Interface provides a basic interface for the maintaining of translation. Export and import interfaces are provided for the ???? online translation community.
+
The Admin Interface provides a basic interface for the maintaining of translation. Export and import interfaces are provided for the chosen online translation community.
 +
 
 +
== Translation Workflow ==
 +
 
 +
Translation workflow will have two modes, Debug and Live.
 +
* In Debug mode, the database is the canonical source for translations
 +
* In Live mode, the XLIFF files are the canonical source
 +
 
 +
In Debug mode:
 +
* Translations can be disabled in the site.json file for testing or development purposes
 +
* Translations are loaded live from the database
 +
* Translation Admin page shows stats, allows editing of translations, and import/export to XLIFF (also to translation website)
 +
* Translation extractors can be run to extract the used keys from code files
 +
* Translations can be edited in the Translation Profiler page
 +
** Profiler bar shows translation stats for the page
 +
** Profiler page allows live editing of translations used on the page with persistence back to the database and flagging as fuzzy
 +
 
 +
In Live mode:
 +
* Translations are always active, sites.json disable is ignored
 +
* Translations are loaded from the XLIFF files, database is only used for Actors/Users
 +
* Translation Admin page is available, but changes do not take effect until exported to XLIFF
 +
 
 +
== Development Required ==
 +
 
 +
No existing package supports our requirements so we will need to fork a number of existing projects (see below):
 +
* Translation extractors
 +
* Translation admin page
 +
* Translation Profiler page
  
 
== Design Decisions To Be Made ==
 
== Design Decisions To Be Made ==
Line 46: Line 74:
  
 
None of these quite match our requirements, but may be adapted to achieve our workflow.
 
None of these quite match our requirements, but may be adapted to achieve our workflow.
 +
 +
Translations in javascript:
 +
* https://github.com/willdurand/BazingaJsTranslationBundle
 +
* https://github.com/wikimedia/jquery.i18n

Latest revision as of 23:32, 5 March 2018

Localization

Localization is the process of translating the user interface and data into the language and formats of the user.

ARK2 uses the following components for localization and translation:

Translation

  • Translations are stored in the core database
  • Translations are exported into XLIFF file format, allowing offline apps to download the full catalogue
  • Translations uses keys rather than source strings
  • Translations will be split in a number of catalogues:
    • Vocabulary
    • Core interface
    • User interface
    • Admin interface
    • Schema (one for each created)
  • Actor and User IDs are translated live using a custom loader from the database

The Admin Interface provides a basic interface for the maintaining of translation. Export and import interfaces are provided for the chosen online translation community.

Translation Workflow

Translation workflow will have two modes, Debug and Live.

  • In Debug mode, the database is the canonical source for translations
  • In Live mode, the XLIFF files are the canonical source

In Debug mode:

  • Translations can be disabled in the site.json file for testing or development purposes
  • Translations are loaded live from the database
  • Translation Admin page shows stats, allows editing of translations, and import/export to XLIFF (also to translation website)
  • Translation extractors can be run to extract the used keys from code files
  • Translations can be edited in the Translation Profiler page
    • Profiler bar shows translation stats for the page
    • Profiler page allows live editing of translations used on the page with persistence back to the database and flagging as fuzzy

In Live mode:

  • Translations are always active, sites.json disable is ignored
  • Translations are loaded from the XLIFF files, database is only used for Actors/Users
  • Translation Admin page is available, but changes do not take effect until exported to XLIFF

Development Required

No existing package supports our requirements so we will need to fork a number of existing projects (see below):

  • Translation extractors
  • Translation admin page
  • Translation Profiler page

Design Decisions To Be Made

Potential online portals include:

  • Transifex - Market leader, but now closed source, offers free hosting to open source projects, large community, great features and automated workflow, API, Github integration, etc.
  • Zanata - A Red Hat open-source project (in response to Transifex going closed) with free hosting and large existing community, or can be self-hosted (JBoss based), great features and automated workflow, API, Github integration, etc. No RTL?
  • Weblate - An open-source project with free and paid-for hosting, but no central community, or can be self-hosted, good features, API, Github integration, etc. Django based.
  • https://localise.biz/ Free or GBP5 p/m plan may be enough, good api, Symfony bundle
  • Translation Project - A FSF open-source project with free hosting and large existing community, but very basic features and manual workflow.
  • Pootle - An open-source project, self-hosted, Django based

Zanata would seem the preferred option for a hosted service, but Weblate might be better if self-hosting.

A number of options exist for automating extraction of Symfony translations, or for allowing interactive editing inside the admin panel or profiler panel:

None of these quite match our requirements, but may be adapted to achieve our workflow.

Translations in javascript:

Retrieved from "https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Localization&oldid=124868"