The following components of the main task (TRANSLATE-766) will be implemented:

Replace automatic Xliff-Generation of translate5 with a simple XLIFF-editor

• 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
    • text content (with plain-text tags as HTML-tags)
    • target content (with plain-text tags as HTML-tags)
    • JIRA-Issue-number
    • plugin-name (as needed for the context)
    • location in application (as needed for the context)
• On saving the form, the trans-unit in the xliff gets replaced (or a new transunit 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.
• A trans-unit can also be deleted through the simple editor

Legacy strings will get no information about JIRA-number, plugin or location.

Changed trans-units where the KEY stays, get a changed-flag

Developers are responsible for deleting trans-units, for which they remove the usage in the code.

Revise and rework existing xliff files and existing text strings

• Clean up existing DE-strings: A script removes all unused DE-strings form the existing DE-xliff-files
  • This is done by parsing the DE-xliff-files and search each entry in the project source code, so just the other way round as gettext for example would do it
• remove and clean up all existing translations, only a DE Skeleton XLIFF per module remains
• remove branding from existing strings (information about translate5 as a brand)

Extend OpenTM2 XLIFF Import for import our own xliff

(this makes it closer to complete standard xliff 1.2 support for the import but not complete)

• import all types of internal tags of xliff 1.2 spec, but without ability to show the original tag name/content (so the translator will not know, what the internal tag stands for in HTML)
• import comments into translate5 comments
• import the changed-flag

Enable translate5 to translate itself from DE to any target

• make a task updateable
  • new strings are added
  • existing ones not touched
  • strings not existing any more are deleted from the task
  • for strings with a changed flag the existing translation gets deleted and the auto-status is set to untranslated.

Setup dedicated translate5 instance for translating translate5 itself

• will be done at translate.translate5.net
• will be used by translators of using companies to translate translate5 into EN, IT and ES
• this instance holds one task for each language combination
• will use new OpenTM2 integration
• will notify assigned translators automatically on new strings in the task

Enable overwriting translations in companies installations of translate5

• for each language there exists one proofreading task in the companies translate5 instance
• it can be used to overwrite default translations
• proofreaders and PMs see through translate5's autostatus flags, which segments have been changed locally
• proofreaders see in the comments, to which translate5 JIRA issue an string belongs and what its context is
• when a proofreader finishes one of these tasks, translate5 automatically creates overwrites-xliffs for translations (they only contain the changed translations)
• also a DE to DE task exists for customizing German
• when the DE-DE task is set to state finished:
  • translate5 exports the DE-DE-overwrite.xliff to the overwrite directory
  • for each changed segment (by autostate or where is source != target)
    • it loops over all DE-To_Target-Tasks and searches for the same segment there (by mid)
      • if the given DE-DE Source is different to the source in the other language task
        • the source is set to the DE-DE source
        • the target is set to an empty string (so that the translator has to retranslate the changed source)
        • the autostate is set to untranslated

Via translate5's updater

• also update xliff files
• update dedicated overwrite tasks in the companies translate5 instance with new translation pairs
  • as above for translate.translate5.net:
    • new strings are added with auto-status translated
    • existing ones not touched
    • strings not existing any more are deleted from the task
    • for strings with a changed flag the existing translation gets deleted and the auto-status is set to untranslated.
• the above mechanism for reapplying overwritten DE-strings to the translations-sources is reapplied.