coremedia / coremedia-globallink-connect-integration

Translation integration via GlobalLink Connect Cloud

Translation via GlobalLink Connect Cloud

This open-source workspace enables CoreMedia CMS to communicate with GlobalLink Connect Cloud (GCC) REST API in order to send content to be translated, query the translation status and to update content with the received translation result eventually.

Feature Overview

This open-source extension adds the following functionality to the CoreMedia Studio:

• Send content to GlobalLink for translation into one or multiple languages with individual due dates in one or multiple workflows.
• Retrieve content from GlobalLink once the translation is finished.
• Automatically detect cancellations of submissions at GlobalLink and cancel the translation workflow in CoreMedia Studio.
• Configure the connection to GlobalLink per site hierarchy.
• Show additional information like the translation status from GlobalLink in CoreMedia Studio.
• Download XLIFF files and import log files in CoreMedia Studio if an error occurs during import.
• Editors in CoreMedia Studio are notified about completion, cancellation, and import and communication errors of a translation workflow with GlobalLink.

Detailed documentation available at GitHub Pages, or browse directly in docs/ folder.

⑃ Branches & Tags

• master:

  When development has finished on develop branch, changes will be merged to master branch.

• develop:

  Will contain preparations for next supported major.

• ci/develop:

  An artificial branch required for CoreMedia internal CI systems.

• Version Tags:

  For adaptions to CoreMedia CMS major versions you will find corresponding tags named according to the CMS major version. It is recommended to take these tags as starting point from within your project, choosing the major version matching your project version.

See Also

• Changelog

  for recent changes

• Documentation

  for guides for editors, administrators and developers

GCC Java REST Client Facades

• README: gcc-restclient-facade

  Facade encapsulating all calls to GCC REST, the Java API as well as the REST backend.

• README: gcc-restclient-facade-default

  This is the default and fallback facade used when nothing is defined in settings — or if there is no other facade applicable.

• README: gcc-restclient-facade-disabled

  This facade mainly serves as example how to implement custom connection types. The implementation just throws exceptions on every interaction with the facade.

• README: gcc-restclient-facade-mock

  The mock facade will simulate a translation service in that way, that it replaces the target nodes (pre-filled with values from source nodes) in XLIFF with some other characters.

CoreMedia Labs

Welcome to CoreMedia Labs! This repository is part of a platform for developers who want to have a look under the hood or get some hands-on understanding of the vast and compelling capabilities of CoreMedia. Whatever your experience level with CoreMedia is, we've got something for you.

Each project in our Labs platform is an extra feature to be used with CoreMedia, including extensions, tools and 3rd party integrations. We provide some test data and explanatory videos for non-customers and for insiders there is open-source code and instructions on integrating the feature into your CoreMedia workspace.

The code we provide is meant to be example code, illustrating a set of features that could be used to enhance your CoreMedia experience. We'd love to hear your feedback on use-cases and further developments! If you're having problems with our code, please refer to our issues section. If you already have a solution to an issue, we love to review and integrate your pull requests.

coremedia-globallink-connect-integration's Issues

computeActionState expecting Processes while it's being passed Tasks (with CMCC 2207.1)

Hi,

it looks like computeActionState is getting passed Tasks as workflowObjects opposed to the expected Processes (with CMCC 2207.1). This leads to the custom workflowListAction button never to be shown. I adjusted the code as below to work with 2207.1.

Might just be an old issue with that particular CMCC version, but still wanted to capture it.
If it's not an issue with the current release, please feel free to close this ticket.

Cheers
--Henning

  computeActionState: workflowObjects => {
      if (!workflowObjects || workflowObjects.length === 0) {
        return {
          hidden: true,
          disabled: true,
        };
      }

      for (let i: number = 0; i < workflowObjects.length; i++) {
        const wfobject = workflowObjects[i];
        // adjusted code, seems like we are getting Tasks, not Processes with 2207.1?
        if (!is(wfobject, Task)
                || !RemoteBeanUtil.isAccessible(wfobject)
                || wfobject.getContainingProcess().getDefinition().getName() !== TRANSLATION_ULG_PROCESS_NAME) {
          return {
            hidden: true,
            disabled: true,
          };
        }
        const process:Process = wfobject.getContainingProcess();
        if (!process.getProperties().get(CANCELLATION_ALLOWED_VARIABLE_NAME)
                || process.getProperties().get(CANCEL_REQUESTED_VARIABLE_NAME)) {
          return {
            hidden: false,
            disabled: true,
          };
        }
      }

NPE in DownloadFromGlobalLinkActionUnitTest

java version "11.0.3" 2019-04-16 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.3+12-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.3+12-LTS, mixed mode)

Linux Mint 19

[INFO] --- maven-surefire-plugin:3.0.0-M3:test (default-test) @ gcc-workflow-server ---
[INFO]
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO] Running com.coremedia.labs.translation.gcc.workflow.SendToGlobalLinkActionTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.195 s - in com.coremedia.labs.translation.gcc.workflow.SendToGlobalLinkActionTest
[INFO] Running com.coremedia.labs.translation.gcc.workflow.DownloadFromGlobalLinkActionTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.418 s - in com.coremedia.labs.translation.gcc.workflow.DownloadFromGlobalLinkActionTest
[INFO] Running com.coremedia.labs.translation.gcc.workflow.DownloadFromGlobalLinkActionUnitTest
[ERROR] Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.008 s <<< FAILURE! - in com.coremedia.labs.translation.gcc.workflow.DownloadFromGlobalLinkActionUnitTest
[ERROR] testNewEntries Time elapsed: 0.006 s <<< ERROR!
java.lang.NullPointerException
at com.coremedia.labs.translation.gcc.workflow.DownloadFromGlobalLinkActionUnitTest.setUp(DownloadFromGlobalLinkActionUnitTest.java:36)

[ERROR] testNoDir Time elapsed: 0.001 s <<< ERROR!
java.lang.NullPointerException
at com.coremedia.labs.translation.gcc.workflow.DownloadFromGlobalLinkActionUnitTest.setUp(DownloadFromGlobalLinkActionUnitTest.java:36)

[ERROR] testNoEntries Time elapsed: 0.001 s <<< ERROR!
java.lang.NullPointerException
at com.coremedia.labs.translation.gcc.workflow.DownloadFromGlobalLinkActionUnitTest.setUp(DownloadFromGlobalLinkActionUnitTest.java:36)

[INFO] Running com.coremedia.labs.translation.gcc.workflow.GlobalLinkActionTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.168 s - in com.coremedia.labs.translation.gcc.workflow.GlobalLinkActionTest
[INFO]
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR] DownloadFromGlobalLinkActionUnitTest.setUp:36 » NullPointer
[ERROR] DownloadFromGlobalLinkActionUnitTest.setUp:36 » NullPointer
[ERROR] DownloadFromGlobalLinkActionUnitTest.setUp:36 » NullPointer
[INFO]
[ERROR] Tests run: 7, Failures: 0, Errors: 3, Skipped: 0

Submission name might be too long

Right now the name of a submission is created in DefaultGCExchangeFacade#createSubmissionName. However GlobalLink only accepts submission names of max 150 characters => this might result into an error as the method may produce longer Strings.

Add documentation for how to adjust the integration to generate a separate workflow for each target locale

The current default setup/configuration for the GlobalLink integration will create a single workflow for all selected target locales.

Having individual workflows for each separate target locale might be more desirable depending on translation/editorial requirements, e.g. to be able to individually "handle" the translations as they are returned for each locale.

Please add documentation for how to adjust the integration to have the system create a separate workflow for each target locale.

Artifact ID "workflow-server" Re-Used

Description

In release 2004.1 (and maybe before), the root module for the workflow server's extension uses artifact ID workflow-server - just as the workflow server's docker module in Blueprint workspace. If a user integrates the GlobalLink extension and expects a

mvn clean install -pl :workflow-server -am ...

to operate as before, s/he will be disappointed and start moaning heart-breakingly.

Could you consider to find another name that will not clash so that people don't step into this trap?

Workaround

Prepend old workflow-server module with proper group ID, i.e.

mvn clean install -pl com.coremedia.blueprint.docker:workflow-server -am ...

Fix code scanning alert - Arbitrary file access during archive extraction ("Zip Slip")

Tracking issue for:

• https://github.com/CoreMedia/coremedia-globallink-connect-integration/security/code-scanning/4

Rating

While zipping is used from production code, the unzip-feature is (up to now) only used from test code. Thus, overall rating is low, while the issue should still be fixed.

Error handling in GlobalLink translation workflow breaks

Describe the bug
There is a bug in the error handling of the GlobalLink translation workflow. If an issue needs to be serialized to JSON, this fails.

The fix should be to change in GlobalLinkAction

  private static final Gson contentObjectReturnsIdGson = new GsonBuilder()
          .enableComplexMapKeySerialization()
          .registerTypeAdapter(Content.class, new ContentObjectSerializer())
          .create();

to

  private static final Gson contentObjectReturnsIdGson = new GsonBuilder()
          .enableComplexMapKeySerialization()
          .registerTypeHierarchyAdapter(Content.class, new ContentObjectSerializer())
          .create();

i.e. instead of type adapter it should use type hierarchy adapter (I suppose because Content is an interface, not a class, so no concrete object can have the exact class Content).

I have attached an excerpt of the workflow server log where the error happens. It is from our production system.

To Reproduce
Steps to reproduce the behavior:

1. In Studio, create a content item and send it to translation using the Global Link translation workflow
2. While the content item is being translated, log in using another user to Studio and check out the localized content item that is in translation
3. Wait until the content item comes back from translation
4. As the translation is ready and is downloaded, the workflow server can't update the localized item because it's now checked out by another user

Expected behavior
The workflow gracefully goes to the "download error" state and shows in Studio (when clicked) the error that the content item could not be updated because it was checked out by another user. The workflow can continue if the task is accepted and the next step of "retry" is chosen (after checking in or reverting the problematic localized content item).

Actual behavior
The workflow escalates because serializing the issue to JSON fails with the stack trace in the attached log.txt file. The only way to continue is to abort and destroy the escalated workflow.

Desktop:

• OS: Windows 11
• Browser: Firefox
• Version: 124.0b8

Additional context
Log file excerpt:
log.txt

GCC does not use spring to create dedicated facades

Describe the bug

If you want to implement a custom facade that is using spring beans, you need to do a lot of changes, since a facade is currently created using

ServiceLoader.load(GCExchangeFacadeProvider.class);

Additional context
This issue was moved to GitHub from jira.coremedia.com. CoreMedia experts will find some more comments to this issue here.

DefaultGCExchangeFacadeSessionProvider.openSession broken when called concurrently from multiple workflows

DefaultGCExchangeFacadeSessionProvider.openSession uses a java.lang.ServiceLoader to find GCExchangeFacadeProvider implementations. The ServiceLoader instance is used concurrently, if the method is called by multiple concurrently running workflow actions.

ServiceLoader however must not be used concurrently. From its Javadoc:

Instances of this class are not safe for use by multiple concurrent threads.

This can lead to NoSuchElementExceptions or not found implementations, which in turn lead to escalated workflows.

2021-05-19 08:03:12 - [WARN] com.coremedia.cap.workflow.plugin.LongActionBase [] - exception occurred in LongActionBase, will pass as result (LongActionManager-2 for coremedia:///cap/task/477873/477881)
java.util.NoSuchElementException: null
at java.base/java.lang.CompoundEnumeration.nextElement(Unknown Source)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass(Unknown Source)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(Unknown Source)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(Unknown Source)
at java.base/java.util.ServiceLoader$2.hasNext(Unknown Source)
at java.base/java.util.ServiceLoader$3.hasNext(Unknown Source)
at com.coremedia.labs.translation.gcc.facade.DefaultGCExchangeFacadeSessionProvider.openSession(DefaultGCExchangeFacadeSessionProvider.java:40)
at com.coremedia.labs.translation.gcc.workflow.GlobalLinkAction.openSession(GlobalLinkAction.java:430)
at com.coremedia.labs.translation.gcc.workflow.GlobalLinkAction.doExecute(GlobalLinkAction.java:202)
at com.coremedia.labs.translation.gcc.workflow.GlobalLinkAction.doExecute(GlobalLinkAction.java:84)
...
2021-05-19 08:03:12 - [WARN] com.coremedia.labs.translation.gcc.workflow.GlobalLinkAction [] - com.coremedia.labs.translation.gcc.workflow.DownloadFromGlobalLinkAction: Unknown error occurred (GCC-WF-10000) (LongActionManager-3 for coremedia:///cap/task/494864/494872)
com.coremedia.labs.translation.gcc.facade.GCFacadeException: No GCExchange facade available as default/fallback.
at com.coremedia.labs.translation.gcc.facade.DefaultGCExchangeFacadeSessionProvider.openSession(DefaultGCExchangeFacadeSessionProvider.java:50)
at com.coremedia.labs.translation.gcc.workflow.GlobalLinkAction.openSession(GlobalLinkAction.java:430)
at com.coremedia.labs.translation.gcc.workflow.GlobalLinkAction.doExecute(GlobalLinkAction.java:202)
at com.coremedia.labs.translation.gcc.workflow.GlobalLinkAction.doExecute(GlobalLinkAction.java:84)
at com.coremedia.cap.workflow.plugin.LongActionBase.execute(LongActionBase.java:91)

TranslateGccConfiguration#postProcessBeforeInitialization should return a mutable list

According to CoreMedia's documentation, "translate.xliff.translatableExpressions" is the list bean, where customers add their own translatable expressions. Hence, this list should be mutable.

    @SuppressWarnings("unchecked")
    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) {
      if (TRANSLATE_XLIFF_TRANSLATABLE_EXPRESSIONS.equals(beanName)) {
        if (bean instanceof Iterable) {
          Iterable<String> list = (Iterable<String>) bean;
          return ImmutableList.<String>builder()
            .addAll(list)
            .add("CMLinkable.localSettings.callToActionCustomText")
            .build();
        }
        throw new BeanNotOfRequiredTypeException(beanName, Iterable.class, bean.getClass());
      }
      return bean;
    }

Workflow Sidebar has toast messages where the title and the text are exactly the same

Describe the bug
Some messages in the workflow sidebar toast have the exactly the same message and title.
The same happens for a few other messages, pls. check the resourcebundle entries.

To Reproduce

Start the translation workflow.
Accept the workflow.
Click "Next" in the bottom right corner.
Select "Finish Workflow"
=> Then I got the toast.

Expected behavior
Title and message should not be duplicates. This is bad UX.

Screenshots

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

Update GCC workflow to new feature "Dependent Contents strategy chooser"

With CMCC 2007.1, we are able to display a new checkbox that lets a user decide, how the dependent content of a translation workflow should be calculated.

The checkbox will be displayed automatically, however the variable where this checkbox writes to, needs to be added to the process definition.

=> We need to adapt the process definition of the GCC workflow according to the changes in the file "translation.xml" from OneRepo.

Map CoreMedia locales to supported locales

The site structure in CoreMedia might be slightly different from the supported locales on gcc side.

For example, we have a two-level site structure where we have a "global master" site, the World English site. From that site we derive all country-specific English language sites such as the Germany English site (with locale en-DE). From the Germany English site we then derive the Germany German site (with locale de-DE).

Similarly e.g. for Austria we have an Austria English site (en-AT) and from that derived the Austria German site (de-AT).

For the German language, we only want to do the translation once, to de-DE. We don't separately want to translate de-AT, we want de-AT to be just a copy of de-DE.

Additionally we have in our system some other websites, that just have the locale NO_COUNTRY German, i.e. locale "de". This we also want to translate with the locale de-DE on gcc side.

Thus what we need is some way to map the source and target locales, before sending content to translation. For example if we translate the Austria German site, we want the source locale to be en-GB (instead of en-AT, which does not really even exist as a language). Similarly we want the target locale to be de-DE (instead of de-AT, which we don't even have configured on gcc side).

It should be rather straightforward to do this mapping in the SendToGlobalLinkAction class. It could be configurable with a boolean property if this mapping should be done or not. The supported locales can be easily retrieved from the gcc API with getConnectorsConfig().getSupportedLocales(). The best matching supported locale could be found by primarily matching the language and secondarily the country (if there are several matches for the language, or if there are no matches for the language like what could be the case in mapping no-NO to nb-NO).

Configure poll frequency default via Spring properties

The GlobalLink translation workflow is out-of-the-box configured to poll the GlobalLink API every three minutes (180 seconds) for each running workflow, to check if the translation is ready yet (file translation-global-link.xml)

One can easily change the poll frequency by modifying the timer value in the above XML. However this means that the customer's copy of the GCC translation workflow definition will diverge from the out-of-the-box workflow and potentially causes merge conflicts in future CoreMedia version updates.

Can we make the poll frequency configurable with Spring properties?

Add Documentation of .gcc.properties to GitHub Pages

The use of .gcc.properties is only described directly in workspace:

• coremedia-globallink-connect-integration/README.md at master · CoreMedia/coremedia-globallink-connect-integration

As others seem to have hard times, locating this information when needed, it seems to be a good idea duplicating (or moving?) the documentation to GitHub Pages (docs folder). Most likely someone will search for it within the Development section.

Expose Locale's language tag in error and logging messages

When failures arise as given here:

coremedia-globallink-connect-integration/apps/workflow-server/gcc-workflow-server-facade/gcc-restclient-facade-default/src/main/java/com/coremedia/labs/translation/gcc/facade/def/DefaultGCExchangeFacade.java

Line 182 in 81e9e4f

throw new GCFacadeCommunicationException(e, "Failed to create submission: subject=%s, source-locale=%s", subject, sourceLocale);

we only log toString() of locales, which may be hard to debug issues.

We should rather use toLanguageTag() as it is less irritating and is the only parseable format.

Improve logging for GCFacadeCommunicationException(s)

When testing the integration, we saw the following type of messages in the workflow-server logs:

2020-09-28 18:12:09 [INFO] com.coremedia.labs.translation.gcc.workflow.GlobalLinkAction [] - com.coremedia.labs.translation.gcc.workflow.SendToGlobalLinkAction: Failed to connect to GCC (GCC-WF-20000). Will retry 4 time(s): com.coremedia.labs.translation.gcc.facade.GCFacadeCommunicationException: Failed to create submission: subject=HenningSaul 2020/09/28 6:07 PM, source-locale=en_GB (LongActionManager-16 for coremedia:///cap/task/2444272/2444276)
No further information as to the underlying issue was logged.

After debugging, we found the root case to be an IllegalStateException with the following message:
'Error sending request. {"status":400,"message":"Provide valid target locales data","response_data":{"invalid_locales":["nl-NL"]}}'

Actually, after submitting this ticket, I found that the issue is only logged as a WARNing WITH the root cause after the 5 failed retry attempts.

Please improve the INFO messages for the failed attempts to include root cause information.

We added the message of the root cause to the message of the GCFacadeCommunicationException in DefaultGCExchangeFacade:

try { SubmissionSubmit.SubmissionSubmitResponseData response = delegate.submitSubmission(request); return response.getSubmissionId(); } catch (RuntimeException e) { throw new GCFacadeCommunicationException(e, "Failed to create submission: subject=%s, source-locale=%s, root cause='%s'", subject, sourceLocale, e.getMessage()); }

Git subtree approach

The documentation for the connector recommends either using git submodule or just copying the connector files to the CoreMedia Blueprint workspace. However I think that there is a third possible approach, which perhaps combines some of the good sides of the two other approaches: git subtree.

The approach is roughly as follows:

• Clone the coremedia-globallink-connect-integration repository
• In your CoreMedia Blueprint workspace repository checkout a new branch (let's say gcc for example)
• In your CoreMedia Blueprint workspace repository, add the connector as a git subtree, e.g.
  git subtree add --prefix=modules/extensions ../coremedia-globallink-connect-integration master --squash
• Merge the gcc branch to your main branch in your workspace repo
• In the future when there are changes to the connector, checkout the gcc branch and cherry-pick the new commit(s), e.g.
  git fetch ../coremedia-globallink-connect-integration
git cherry-pick -m 1 -Xsubtree=modules/extensions 77695e2b39f3eb36fdaca3ee992e8702c49f23fa
  and merge the gcc branch to your main branch again.

Benefits:

• No hassle with two Git repositories that git submodule gives
• You can modify the connector files (you don't need to fork the connector repo to do that)
• In the future, you can cherry-pick commits from the connector repo and merge them to your code easily

Please feel free to consider this and update the documentation if you think it would be useful.

Allow specifying translation type and other fields for workflow submission

We would need to specify the translation type on a per-workflow basis, e.g. MTPE full, MTPE light or raw MT. I'm not sure how this would be specified in the translations.com API (for /submissions/submit) but currently it's not possible to make the SubmissionSubmitRequest from the connector with such information.

It should be possible to add at least the following to the SubmissionSubmitRequest:

• instructions - this should probably be the notes (comment) of the workflow as entered when starting the workflow in Studio
• submitter - this could be set to the CoreMedia user ID of the owner of the workflow
• attributes or config or workflow - maybe one of these could be used to specify the translation type to be done e.g. MTPE full or MTPE light or raw MT

Setting mockDelaySeconds=0 does not reduce the mock pause after starting a translation workflow

The same goes for mockDelayOffsetPercentage

Direct cancellation of workflow might result into failure

When cancelling a directly started translation workflow, the GlobalLink-Api will return an error "Submission cannot be cancelled in Pre-process or Delivered state" or an error with an empty response.

The translation workflow still functions correctly as there is an automatic retry built in.
After 1 - 2 minutes, the workflow can be cancelled without errors correctly.

GlobalLink Settings name hard coded in client extension

Given I want to define multiple GlobalLink Settings, that are linked to different sites within my settings folder, I have to provide different names for the GlobaLink Settings.

However in the client extension the name is hard coded, which currently allows only one setting:

coremedia-globallink-connect-integration/apps/studio-client/src/main/joo/com/coremedia/labs/translation/gcc/studio/GccStudioPluginBase.as

Line 145 in 889503f

var globalLinkSettings:Content = SESSION.getConnection().getContentRepository().getChild("/Settings/Options/Settings/GlobalLink");

Expected behavior
It should be possible to define multiple GlobalLinkSettings.

Links to mock facade documentation in README broken

Steps to reproduce:
Click on one of the links of the landing page that should lead to the documentation of the mock facade, and you will get a 404.

Other links are probably affected too. I guess this is a regression from the extension refactoring of the 1907 release.

Update to GCC rest API 3.0.0

Is your feature request related to a problem? Please describe.
There is a new release of the GCC Rest API on GitHub:
https://search.maven.org/search?q=g:%22com.translations.globallink%22%20AND%20a:%22gcc-restclient%22

AFAIK the current API version still works fine. We should at least evaluate the impact of an API update.

Describe the solution you'd like
Stay close to the latest release of the GlobalLink API to benefit from improvements.

Describe alternatives you've considered
Keep the current API version if it still works.

Failing test in DefaultGCEExchangeFacadeTest

apps/workflow-server/gcc-workflow-server-facade/gcc-restclient-facade-default/src/test/java/com/coremedia/labs/translation/gcc/facade/def/DefaultGCExchangeFacadeTest.java

There are two tests here:
#169 (Test for successful submission)
#204 (Correctly deal with communication errors)

That fail when running in US time zone CST with the following error:

java.lang.IllegalArgumentException: DueDate must be after current date

I believe it is an issue with time zone handling.

Allow configuring username, password and key via Spring properties

The current mechanism for configuring the globallink API username, password and key is to put them to a Settings object and then reference this in the Linked Settings of the homepage. From a security viewpoint this is unacceptable if there is a way to retrieve that Settings object (from the public internet), which would expose the secrets. For example some API of the headless server or a similar API might expose the secret content. Nb. the homepage is published and so the linked Settings object has to be published as well.

The proposed solution is to allow configuring these secrets using Spring properties, as a fallback to the current mechanism.

Trying to otherwise hide the secret Settings object is impractical. At least Studio users would be able to see it and we don't need any Studio users to see globallink API secrets.

Update to latest gcc-restclient 2.3.0

Update to the latest gcc-restclient that is available on Maven Central to ensure compatibility with GlobalLink Connect Cloud.

Change directory structure to match CoreMedia 10 extension mechanism

The current directory structure of the connector (everything being under modules/extensions) is from CoreMedia 9 and the recommended directory structure for extensions was changed in CoreMedia 10. In other words, extensions for each app are now under the apps directory, below each app in a subdirectory modules/extensions.

Please change the directory structure to match the CoreMedia 10 recommendations.

For example:

modules/extensions/apps/workflow-server/pom.xml -> apps/workflow-server/modules/extensions/gcc/pom.xml
modules/extensions/apps/workflow-server/gcc-workflow-server/pom.xml -> apps/workflow-server/modules/extensions/gcc/gcc-workflow-server/pom.xml
modules/extensions/apps/workflow-server/gcc-workflow-server-facade/gcc-restclient-facade-default/pom.xml -> apps/workflow-server/modules/extensions/gcc/gcc-workflow-server-facade/gcc-restclient-facade-default/pom.xml
modules/extensions/apps/workflow-server/gcc-workflow-server-facade/gcc-restclient-facade-disabled/pom.xml -> apps/workflow-server/modules/extensions/gcc/gcc-workflow-server-facade/gcc-restclient-facade-disabled/pom.xml
modules/extensions/apps/workflow-server/gcc-workflow-server-facade/gcc-restclient-facade-mock/pom.xml -> apps/workflow-server/modules/extensions/gcc/gcc-workflow-server-facade/gcc-restclient-facade-mock/pom.xml
modules/extensions/apps/workflow-server/gcc-workflow-server-facade/gcc-restclient-facade/pom.xml -> apps/workflow-server/modules/extensions/gcc/gcc-workflow-server-facade/gcc-restclient-facade/pom.xml
modules/extensions/apps/workflow-server/gcc-workflow-server-util/pom.xml -> apps/workflow-server/modules/extensions/gcc/gcc-workflow-server-util/pom.xml

Provide documentation on handling of XLIFF import errors.

Is your feature request related to a problem? Please describe.
Editors don't know what to do, when an import of a translation fails because the XLIFF from GlobalLink is invalid. The Studio just mentions that the XLIFF failed and the erroneous files are not directly located at the message.

Describe the solution you'd like
The handling of import errors should be part of the documentation. The error message should also give advice on the next steps. Like 1) download ZIP in the detail view 2) Send the ZIP that contains the error description and the XLIFF to GlobalLink and ask them to fix it 3) ...

Studio shows a technical submission id instead of the PD submission id.

Describe the bug
The workflows details in the Studio show the technical identifier of the submission which does not help editors when talking to Translations.com.

To Reproduce
Steps to reproduce the behavior:

1. Start a Translation with GlobalLink workflow in the CoreMedia studio
2. Open the workflow details in the Control Room and check the submission ID
3. Compare it with the Submission ID shown in GlobalLink's Project Director or the Connect Cloud Dashboard.

Expected behavior
The UI only shows the PD Submission ID. This ID is also shown in the GlobalLink UIs.