A rough schemata for the technical process looks like this

Translate5 Development – translation data generation

• The data for the translation installation is generated on the developer machine as xliff file
• A translate5-specific xliff-editor for development purposes is build
  • XLIFF-files are used as resource files in translate5 in the future.
    • In the source-code, only the KEY remains. The convention for creating the KEY is: JIRA-Issue number+count+SHORT_TEXT_DESCRIPTION_OF_TEXT_IN_UPPER_CASE_LETTERS
    • Legacy strings stay as they are as the actual text as KEY (get not refactored – this would be to much work).
  • A translate5-specific xliff-editor for development purposes is build:
    • very simple, based on pure HTML-forms
    • It loads all trans-units in a HTML-table structure
    • a click on a table row opens the row for editing with the following form fields:
      • KEY
      • source content (with plain-text tags as HTML-tags)
      • target content (with plain-text tags as HTML-tags)
      • JIRA-Issue-number
      • plugin-name
      • location in application
  • On saving the form, the trans-unit in the xliff gets replaced (or a new gets generated). JIRA-number, plugin-name and location in app get connected together as 3 different comments to the trans-unit, that will get imported into translate5 for translation later on.
• Legacy strings will get no information about JIRA-number, plugin or location.
• to be valid XLIFF HTML tags must be converted to internal Tags, use okapi therefore
  • communicate to okapi to convert HTML to xliff (use matecat REST API)
• the application name "translate5" (and maybe other strings) must not be part of the translateable strings anymore, but kept as configuration variables and parsed into the strings at runtime. This way the application name is customizable.
  • introduce global variables in a easy extendable way, the variables are automatically replaced in the texts
• Clean up existing strings: A script removes all unused translations form the existing xliff-files

Translate5 application string translation

• translate5 must be capable of import standard xliff (without displaying the tag content in the first step!)
• the translation of the application strings is handled in a dedicated translate5 instance at http://translate.translate5.net/
• this instance holds one task for each language combination
  • this tasks may not be deleted
  • the tasks must be marked as „translation task“ somehow
• each translate5 task is updated with the new translations:
  • removed strings (aka segments) get deleted from the tasks (the developer has to ensure, that removed strings get removed from xliff-files)
  • new strings are added to the task
  • existing strings are not touched in the task
  • a comment on each segment list
    • with the context of the string in translate5 (module and region where the string is located in the GUI of the application)
    • with the timestamp when the string has been added to the translation task (use the comment date here?)
    • to which translate5-Issue (JIRA-number) it belongs (as http-Link, but not with a href-tag)
  • new segments are added at the end of the task (since auto generated ids are used for default sorting)
  • The task can only be updated by API by a PUT request, nothing needed in the GUI so far
  • Only a admin user should be able to make a task PUT in the moment
  • the translators assigned to each task get automatically notified via e-Mail about the number of new strings to be translated.
    • This notification is always done for task PUTs
• translators do their job (assisted by translation memory based on OpenTM2)
  • setup OpenTM2
• translator finishes a task
  • implement generic event trigger
• the translation is automatically committed and pushed into translate5 master repository
  • by a generic event trigger
• a new build and release is made
  • by a generic event trigger

Assignment of tasks to translators

• translators can volunteer for the translation of a language combination. They get assigned by the translate5 team to the task.
• tasks of language combinations, that stay unassigned, can be handled by every volunteer, that likes to translate them.

Updating and customizing translations in a translate5 instance

• updates are made by the translate5 updater as usual, also the translations in form of xliff files are getting updated
• in some cases translations (and even the source) need to be overridden for an installation
• for this purpose an undeleteable task is set up for each language combination in translate5.
  • Undeleteable is just the same attribute as the „translation task“ attribute on translate.translate5.net so that the same technique is used
  • creation date is 1.1.2010 - to achieve, that these tasks are always the last in default sorting
    • must be set manually on creating the translation task
  • one of the language combinations always is a German to German translation (since German is the source, but should be customizable, too)
• the updater also updates these tasks with the new translations, and deletes those, that are not existent any more. Translations that did not change since the last update (and therefore their customizations) are not changed.
  • Same mechanism as on translate.translate5.net
• when the translators are finishing the task, an automated xliff export is triggered, the xliff files are exported to a specific directory, which is used as overwrites directory for the delivered xliff files
  • xliff overwrites mechanism is needed, overwrites directory is configurable
• an intermediate generation of the xliff files (to show the translations / changes in the GUI directly) can be made by trigger an export, the downloaded file is not needed, but internally the xliff files are copied to the xliff overwrite folder
• the admin gets an e-mail, that lists the new strings for each language
  • reuse / refactor / make a generic version of the changes.xml mail