Hyland Connect

aussen2 · ‎07-29-2011

I am currently implementing a multi-lingual website on the basis of Web Quick Start (Alfresco Community 3.4d). As there is no out-of-the-box support for managing different translations of the same content in Share yet, I put the translations into different language folders and connected them via my own type of associations (ws:tranlsationOf and ws:translations). These associations are automatically established when a new translation is added (via workflows).

This method works just fine but form the viewpoint of the Alfresco repository the different translations are still just different content objects that exist independently of each other. Thus, multi-lingual support for search and other relevant things is limited. So I was happy to discover what seems to be your plans for introducing a translation manager for Web Quick Start in the code on HEAD. I assume that this will provide UI support in Share for facilitating the built-in multi-lingual capabilities of Alfresco. Could you provide some more information on this approach? I would also be interested in any information on how stable this feature already is.

Multi-lingual content management is a ver important aspect of my current project and if there is some native solution emerging in Web Quick Start I definitely want to adopt that for my project in order to guarantee the best possible compatibility with future versions of Alfresco.

bremmington · ‎07-29-2011

I have just posted a page on the wiki that provides a brief overview of this functionality.

Although this functionality is complete except for QA, there are other changes going on in Share at the moment - changes relating to Share extensibility - that are making HEAD quite unstable. I don't actually know right now what the position is. By all means take a look.

radar1975 · ‎08-29-2011

I have just posted a page on the wiki that provides a brief overview of this functionality.

Although this functionality is complete except for QA, there are other changes going on in Share at the moment - changes relating to Share extensibility - that are making HEAD quite unstable. I don't actually know right now what the position is. By all means take a look.

Is there a way to know if this feature will be available soon ?

Or is there a alternative way to make content multilingual support in quick start … perhaps a new content types would be a good alternative while waiting for the Translation Manager ?

Thanks

vincent_saulnie · ‎08-30-2011

Hi,

The functionality is documented to be available at the end of this month. I'm wondering if Alfresco is still on target with the original plan.

Regards,

bremmington · ‎08-31-2011

I'm not certain what documentation you're referring to, but the appropriate document is the 2011 roadmap which places the Community release in Q3 - that is to say by the end of September. I believe that this is still the plan.

radar1975 · ‎08-31-2011

I'm not certain what documentation you're referring to, but the appropriate document is the 2011 roadmap which places the Community release in Q3 - that is to say by the end of September. I believe that this is still the plan.

We are talking about that here http://wiki.alfresco.com/wiki/Multi-lingual_Web_Quick_Start

Thanks

aussen2 · ‎10-11-2011

Now that Alfresco Community 4.0.a is out and the Translation Manager is available in WQS I was looking for the corresponding part in the client api in order to get the translations of an asset. I found the web script for the repository tier but couldn't find anything in the client api that seems to talk to that web script. Is this functionality implemented yet?

bremmington · ‎10-11-2011

The approach that we've taken to website localisation is to make it an editorial function rather than a delivery function. Each locale ends up with its own tree of sections which mean that URLs can be translated (the names of the sections) as well as the content addressed by the URLs. Therefore, each translation of a particular piece of content is treated as an entirely separate asset at delivery time - we haven't provided a means to navigate between translations in the WQS API. Perhaps that was a mistake. What were you hoping to do?

aussen2 · ‎10-12-2011

First of all I want to display links to the translations of the current asset in the web site and would need some way to request this list via the client api. Once I am able to lookup the translations of an asset in the web site I could also draw their metadata into the page that displays this asset. A common use case for this would be an article that is a translation of another article and needs to display the initial publishing date of the original language version alongside its language-specific publishing date.

The web script for looking up the translations of a node in already present in the repository tier and I could just use this to get the nodeRefs and then use client api's getAssetById to receive the assets in the web tier. But this approach would circumvent any of the web tier's caching mechanisms. A solution that integrates nicely with the caching already in place would probably have to work along the lines you already outlined here: https://forums.alfresco.com/en/viewtopic.php?f=52&t=40033

On a second thought maybe I could even use that approach to implement both functionalities (multilingual content with monolingual properties and monolingual content with multilingual properties) in a similar way. I would then always get the full stack of multilingual data when requesting an asset from the repository and could easily display any property in any language in the web site. But that would probably be a bigger change to the WQS project that I would like to perform especially in regard to compatibility with future versions of WQS.

bremmington · ‎10-12-2011

I see. Publishing would probably need some attention to achieve what you're describing. Translated nodes link back to a multi-lingual container (of type cm:mlContainer). All translations of a given node link to the same mlContainer. When publishing a node in WQS, the resulting node (the published node) does not link to an mlContainer. This is the case for a couple of reasons - mainly because we didn't expect linkage between translated nodes in the delivery tier to be needed, and secondarily because it complicates the publishing logic to an extent. This would have to be resolved to ensure you could navigate between translations in the delivery tier.