Hello Community,
I created a translation project to translate the assets (DITA Topics/Maps) from source language folder (say en_us) to a new target Ianguage (say es). I used the OOTB Microsoft's Machine Translation (free license) for doing the same. After assets are translated, when i go to CRXde and open the jcr:content of any translated DITA topic , I see that fmUuid value is exactly same as the fmUuid value of source language DITA topic. Is this behaviour expected?
The same behavior (consistent fmUuids) is expected when we try to integrate it with any 3rd party integrations like Lionbridge? Or it depends on the vendor?
Views
Replies
Total Likes
It depends on how the third-party applications process it. In Guides, the fmUuid of the translated topic is same as the source language topic but it has a translated locale code appended at the end.
Eg: GUID-ea7a35ad-9c55-4269-934e-873a07d8235d (source)
GUID-ea7a35ad-9c55-4269-934e-873a07d8235d-es (translated)
Views
Replies
Total Likes
@AswiniLakshminarayanan Thanks for your reply.
You mentioned that translated locale is appended to GUID, but I don't see that happening in OOTB Microsoft Translation. Can you provide more details of your configuration and any steps to reproduce the same?
Views
Replies
Total Likes
Which version of Guides are you using? UUID filename patterns can be configured in the fmdita configuration com.adobe.fmdita.config.ConfigManager under UUID Filename Patterns property.
Views
Replies
Total Likes
I am using 4.0.2 UUID version.
I got your point that we can add <locale> to fmUuid peroperty from ConfigManager, but it is not OOTB behavior where it adds <locale> right?
My question revolves more around whether fmUuid property values remains same even if translated given no changes are made to UUID Filename patterns from OSGI.
Views
Replies
Total Likes
OOTB behavior (without making config update) where fmUuid value has the locale code appended at the end is applicable from version 4.1
Views
Replies
Total Likes
Views
Likes
Replies