Expand my Community achievements bar.

SOLVED

Translation Integration

Avatar

Level 2

In AEM 6.2 SP1 when user creates translation project Title of the project is used for creating the projects folder and this is not available on the actual projects inside folder. These actual projects are named by language codes. Translation connectors cannot read the folders as they have scope on projects, because of this all translation project names shows as language codes in world server. This is not the case in AEM 6.1 because projects are created directly under /projects folder. Did any one encountered this issue. Looks to me like another translation defect.

1 Accepted Solution

Avatar

Correct answer by
Level 2
In AEM 6.1 we didn't have the concept of folders, so the projects had a name. But with 6.2 and above, the folders are one level above the project nodes and the API doesn't read that. Since the TMS/GMS vendors didn't bother for the folder name we didn't build support in the API. We will look into adding this in future if there is a strong use case. In the meantime you can use the workaround mentioned by @diptinarang.

View solution in original post

2 Replies

Avatar

Level 3

You are absolutely right. I have also recently worked on Translation Connectors implementation. In our case we were always generating unique projects name at TMS, so even if language codes are being used in project names, it doesn't matter much.

But in case the folder and project name is of any relevance, then in 6.2 the projects jcr:content contains a property coverUrl which contains name of the folder. This is of-course just a workaround.

I am not sure if this is a defect or a feature because in AEM 6.3 Beta, I saw similar behaviour.

Avatar

Correct answer by
Level 2
In AEM 6.1 we didn't have the concept of folders, so the projects had a name. But with 6.2 and above, the folders are one level above the project nodes and the API doesn't read that. Since the TMS/GMS vendors didn't bother for the folder name we didn't build support in the API. We will look into adding this in future if there is a strong use case. In the meantime you can use the workaround mentioned by @diptinarang.