• Type: Task
    • Status: Closed
    • Priority: Neutral
    • Resolution: Fixed
    • Affects Version/s: 2.1.8
    • Fix Version/s: 2.2
    • Labels:
    • Release notes required:
    • Documentation update required:
    • Sprint:
      Basel 111, Basel 112, Basel 113, Basel 114, Basel 115, Basel 116
    • Story Points:
    • Magnolia Release:


      This issue relates to the epic "Remove Content API". See for further detail.

      During the various sprints this ticket was in, we figured the best approach to getting rid of the content API was to create a new translation module. We would take the change and cleanup the API and problematic code (a lot) along the way.

      New artifacts

      The new modules are:

      • info.magnolia.translation:magnolia-content-translation:2.2-SNAPSHOT and
      • info.magnolia.translation:magnolia-content-translation-pages-integration-app:2.2-SNAPSHOT split out integration into pages app – used to be in the module itself).

      The old artifact

      • info.magnolia:magnolia-module-content-translation-support:2.2-SNAPSHOT is now being redirected to
      • info.magnolia.translation:magnolia-content-translation-support-compatibility:2.2-SNAPSHOT.

      Overview of changes

      PropertiesToTranslateFinder (info.magnolia.translation.finder)

      Same as before but the main difference is the underlying object. Previously called info.magnolia.module.contenttranslationsupport.export.NodeDataBundle (and also bound to Content API) the new object is info.magnolia.translation.finder.PropertyToTranslate. STK-related classes were not migrated.

      Export (

      Previously one had to specify info.magnolia.module.contenttranslationsupport.export.AbstractTranslationBundleWriter (s) in the CTS module config. This was highly problematic because this setup was mixing config (the actual exporter config) with logic (the writer instance).

      Now one specifies a info.magnolia.translation.TranslationExportOperationDefinition allowing to set a propery called writerImplementationClass which needs to be a subclass of Per executed export operation, a new instance of such a writer will be instantiated. Note that the previous info.magnolia.module.contenttranslationsupport.export.AbstractTranslationBundleWriter#init(, java.util.Locale[], java.util.Locale) methods were removed in favor of constructor parameters eleminating the need to call the init method before anything else.

      Import (

      So above section about export. Similarly there is a new definition called info.magnolia.translation.TranslationImportOperationDefinition that allows to specify an op incl. a readerImplementationClass property. This class needs to extend Same cleanup effort was done as with the writers.

      Export / import execution (

      The legacy module contained to separate beans for imports (info.magnolia.module.contenttranslationsupport.reimport.TranslationBundleUpdate) and exports (info.magnolia.module.contenttranslationsupport.export.TranslationBundle). One was produced to write to files, the other to read from files. There is now one single bean (incl. a builder) for both scenarios.

      One indirection for the export via info.magnolia.module.contenttranslationsupport.export.TranslationBundleExporter was completely removed and the was cleaned up. It now takes a TranslationExportOperationDefinition for exporting data and a TranslationImportOperationDefinition when importing data.

      Export still mainly happens in and the import in

      All code involved was clean up and logic was moved to where is was appropriate.

      Commands info.magnolia.translation.commands

      All deprecated commands were removed and both info.magnolia.translation.commands.TranslationFileUploadCommand and info.magnolia.translation.commands.TranslationFileDownloadCommand now extend info.magnolia.commands.MgnlCommand. Default configured commands come in catalog translation.

      Actions (info.magnolia.translation.ui.action)

      Previously, OpenCreateTranslationFileUploadDialogAction was bound to store any uploaded file in the website repository. This was changed: the action now uploads any binary into the workspace of the underlying item. Additionally the action used allow multi-items even though it was not extending the appropriate super class (hint AbstractMultiItemAction). This was cleaned up.

      TranslationFileDownloadDialogAction duplicated a ton of code from the AbstractCommandAction. Now it properly inherits from this action and only "overrides" logic by utilizing either #onPreExecute() or #onPostExecute(). Same goes for TranslationFileUploadDialogAction.

      Field info.magnolia.translation.ui.form.field.definition

      TranslationFileFormatOptionGroupFieldDefinition used to contain logic to read from the module config to show a list of available formats (next to a pretty broken definition itself). This was wrong. Now we use a custom factory (TranslationFileFormatOptionGroupFieldFactory) that reads a simple config and produces the desired field. An updated fieldType definition was added.




            • Assignee:
              pmundt Philip Mundt
              mmuehlebach Michael Mühlebach
            • Votes:
              0 Vote for this issue
              2 Start watching this issue


              • Created: