Uploaded image for project: 'translate5'
  1. translate5
  2. TRANSLATE-2063

Enable parallele use of multiple okapi versions to fix Okapi bugs

    XMLWordPrintable

Details

    • Critical
    • Hide
      NEXT: Fixed docker autodiscovery not to overwrite existing config.
      5.9.0: Added dedicated CLI commands to maintain Okapi config.
      5.7.6: Multiple okapi instances can be configured and used for task imports.
      6.1.0: Enhancement: Fixed naming scheme for the keys of the Okapi Server Configuration entries
      Show
      NEXT: Fixed docker autodiscovery not to overwrite existing config. 5.9.0: Added dedicated CLI commands to maintain Okapi config. 5.7.6: Multiple okapi instances can be configured and used for task imports. 6.1.0: Enhancement: Fixed naming scheme for the keys of the Okapi Server Configuration entries
    • -

    Description

      problem

      There are a lot of critical bug fixes in the new okapi file filter release.

      Yet we can only use it together with translate5, if we support the usage of multiple okapi versions at the same time, because if a file is converted to xliff with an older version of okapi, it can happen that it can not be converted back with the current version.

      Therefore translate5 has to know, which version it used for the conversion to xliff and use the same version for converting it back.

      This will be implemented with this issue.

      Requirement

      • develop frontend config editor component (key/value name - server url, similar as the ranges analysis editor) where the user can add/edit/remove servers
      • Whenever someone removes server from the config, validation should be triggered to check if this server is used for some of the tasks. If yes, the config should not be removed and the user should get an info message why this is the case

      Implementation

      • to differ between the different okapi versions, we first need the possibility to configure multiple Okapi instances. Therefore we need a new configuration:
        • runtimeOptions.plugins.Okapi.server, type map, editable on instance level, in description the hint "do not change the name afterwards!" is needed.
        • precondition is the implementation of TRANSLATE-2469
      • the information which okapi instance should be used by a task has to be stored also in a new config:
        • runtimeOptions.plugins.Okapi.serverUsed, type string, defaults are generated dynamically out of the above config names (same idea as in the bconf defaults list), editable on task-import level
      • refactor all current usages of runtimeOptions.plugins.Okapi.api.url so that the server URL is retrieved via the name stored in runtimeOptions.plugins.Okapi.serverUsed from a task based config, and then from runtimeOptions.plugins.Okapi.server[name]
      • a migration script which sets:
        • runtimeOptions.plugins.Okapi.server = {"used-on-Y-M": VALUE} where Y and M are the current year and month and VALUE is the current config value from runtimeOptions.plugins.Okapi.api.url
        • runtimeOptions.plugins.Okapi.serverUsed = "used-on-Y-M" → also Y and M with values as above
        • runtimeOptions.plugins.Okapi.api.url can be removed  then
      • Fix the confluence documentation:
        • in runtimeOptions.plugins.Okapi.server are the URLs
        • the key is freely setable, useful is the okapi version like "m39", which is not possible automatically when introducing this feature, since the version could not be read from okapi, and it is nowwhere stored in translate5.

      Attachments

        Issue Links

          Activity

            People

              aleksandar Aleksandar Mitrev
              marcmittag Marc Mittag [Administrator]
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: