• Replies 2 replies
  • Subscribers 137 subscribers
  • Views 1111 views
  • Users 0 members are here
Options
Related

customize metadata export for "Export For Translation" ?

Jay Baldwin

We are using LiveContent Architect 2014 (i.e. "version 11" of the application)

For a migration project, one LCA environment to another, we are exporting from one and importing that into another.

Regular export does not export metadata.

Publishing to DITA XML exports all the metadata we want (i.e. defined in App/Author/Configuration/ReqMetaDataExportForPublication.xml), but resolves the LCA DITA XML to portable DITA XML.

"Export for Translation" gives us both LCA DITA XML and metadata, but only very limited metadata:

<ishobject ishref="GUID-75F56933-EBA9-4FD5-8D15-A950197FCBA8" ishtype="ISHModule" ishlogicalref="185997" ishversionref="185998" ishlngref="185999">
  <ishfields>
    <ishfield name="FTITLE" level="logical" xml:space="preserve">MECT_Title</ishfield>
    <ishfield name="VERSION" level="version" xml:space="preserve">1</ishfield>
    <ishfield name="DOC-LANGUAGE" level="lng" xml:space="preserve">en</ishfield>
    <ishfield name="FSTATUS" level="lng" xml:space="preserve">Released</ishfield>
  </ishfields>
</ishobject>

Can the metadata exported by "Export for Translation" be configured/customized so that I can include much more object metadata, similar to what we can define in "ReqMetaDataExportForPublication"?

I looked at a lot of doc, and the ASP code for "Export for Translation," and am not able to figure this out.

Thanks!
Rate translation
×
Suggest better translation
×

  • Hi Jay,

    Within the configuration of the background task system you can extend the metadata properties which are exported during specific request.
    You have a configuration section for Inbox export / Report export / Search export and Publication export.

    I think in your use case you need to exted the configured fields list in the following parameter

                <parameter name="requestedmetadata">
                  <ishfields>
                    <ishfield name="FSTATUS" level="lng"/>
                  </ishfields>
                </parameter>

    within the handler configuration (sample below is OOTB configuration)

        <handler eventType="PUBLICATIONEXPORT">
          <scheduler executeSynchronously="false"/>
          <authorization type="authenticationContext"/>
          <execution timeout="01:00:00" recoveryGracePeriod="00:10:00" isolationLevel="None" useSingleThreadApartment="false"/>
          <activator>
            <net name="ExportObjects">
              <parameters>
                <parameter name="exportlocation">%ISHPROJECTDATAPATH%\ExportService\Data\DataExports</parameter>
                <parameter name="exportspeclocation">%ISHPROJECTDATAPATH%\ExportService\Data\WatchFolder</parameter>
                <parameter name="separatelng">yes</parameter>
                <parameter name="requestedmetadata">
                  <ishfields>
                    <ishfield name="FSTATUS" level="lng"/>
                  </ishfields>
                </parameter>
                <parameter name="raiseevent">ZIPFILES</parameter>
                <parameter name="filenameprefix">
                  <ishfields>
                    <ishfield name="FTITLE" level="logical"/>
                  </ishfields>
                </parameter>
              </parameters>
            </net>
          </activator>
          <errorHandler maximumRetries="0"/>
        </handler>

    Kind Regards,


    Raf
  • in reply to Raf Snijders

    Thanks, Raf. That worked! 

    I also learned that our methodology is even stranger than I initially understood. Someone figured out to use "Workflow management" from the version menu on a publication object in web client. That's how we export all source language objects in a pub with content the way the developer likes it.