Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

Issue in AEM's translation mechanism to get XLIFF from TranslationObject

Avatar

Level 3

We are building a connector for AEM 6.2 using AEM's translation API. For translating AEM page, we use getTranslationObjectXLIFFInputStream().

Reference: https://docs.adobe.com/docs/en/aem/6-2/develop/ref/javadoc/com/adobe/granite/translation/a pi/TranslationObject.html#getTranslationObjectXLIFFInputStream(java.lang.String)

The generated XLF doesn't convert 'less than' sign properly, if the page contains HTML tags. The XLIFF has no issues in case of a simple page without any Rich text content. Attached are the references.

We suspect OKAPI isn't able to convert the XLF properly but we are not sure about it. Any experiences on the same?

Thanks, Dipti

4 Replies

Avatar

Level 7

Hi Dipti,

In the screen shot some of the < signs are just fine and some of them are &lt;

I could see you are using java.lang.String to serialize over Object IO stream. try doing a replaceAll("&lt;","<"); 

This is just a wild guess, so could not work but should be worth a shot.

Thanks

Tuhin

Avatar

Level 3

Hi Tuhin

Thanks for the update. The signs < which are fine are primarily of XLIFF, but not for the tags present in RichTextEditor. 

The hack to replace the tags is for sure present but we want to ensure that AEM Translation API is working fine. Primarily why "getTranslationObjectXLIFFInputStream"  isn't returning correct XLIFF, is our area of concern.

Since we have to use translation APIs for connector implementation, we want to ensure that the API is free of P1/P2 issues and is safe to use.

Thanks

Dipti

Avatar

Level 7

Hi Dipti,

 

As it seems to be a product issue, log a ticket and close this one.

 

Thanks

Tuhin

Avatar

Level 2

We are also facing same issue with this API.  From what I can tell, the API implementation needs to be updated to handle this. This is a product bug.

Thanks
Ashish