Exporting Master Pages

[josephb44551697]

Hello,

In the TechComm department where I work, we export our FrameMaker files to XML to send them out for translations. The one issue that I have run into is that we are able to export all of the Body Pages content to XML, but because the master page content is not exported, it will not be able to be translated by our translation agency. This poses a problem as our regulatory information and page headings are boilerplate and need to also be translated, but it doesn't make sense to put it on the body pages.

Is there a way to export the master pages to XML so that we can translate them as well? I know that the template used in structured applications functions as a place to hold the master page information, but it seems like there would be a way to export this information as well. I would really appreciate any help with this issue.

Thank you,

Joseph

[Lynne A. Price]

Joseph,

   Consider putting each piece of boilerplate content in a separate file or flow. You can include them as text insets on your master pages

and export them individually to XML. If you need to provide the translation agency with a single XML document, you can use XSLT to assemble the various components into one XML document.

     --Lynne

[josephb44551697]

Lynne,

It would be best to include the boilerplate information in the same XML file as you describe. I am good with the idea of using XSLT, but would there be an automated way to strip the contents from the master pages (and replace after translation), or would it have to be a more manual copy-paste from the master pages to a separate file and back?

Joseph

[Lynne A. Price · Accepted solution]

Joseph,

  Yes, you should minimize the amount of cut-and-paste. I don't know how many master pages you have with how many headings and pieces of boilerplate text. Suppose you maintain each of these segments as a separate structured document. These numerous small files would be the only place you would edit this content. Modify each segment of boilerplate content on the master pages in the main template by replacing the segment with a text inset of one of the new boilerplate files. This would only have to be done once. From then on, whenever you edit one of the boilerplate segments you can just update your template and the boilerplate would be modified. Meanwhile, create a new book that contains all the individual files with boilerplate text and save it as XML. When you save a complete document as XML, use an XSLT post-process that combines the XML exported from the body pages of the document you are processing with the XML created by saving the boilerplate text as XML.

     --Lynne

[josephb44551697]

Lynne,

I see what you mean. This seems like the best way to do this. There are a few text frames on the master pages that are document specific (such as the titles and subtitles), which would have to be unique per each document (and we send hundreds of documents for translation per year). Would you recommend the same strategy for this case?

Joseph

[Lynne A. Price]

Joseph,

     Do your title and subtitle appear on a body page? If you are working with a single document, you can use running h/f variables to include them in background text on a master page. If you are working with a book and want to include something like fields from a title page on a master page, use cross-references to the title page in the master pages of all files.

     --Lynne

[Lynne A. Price]

Joseph,

   Ian's suggestions are also good. You may also consider a combination of different approaches.

   That said, several years ago, I heard Tommie Usdin of Mulberry Technologies say something like, "The purpose of XSLT is to eliminate endless hours of argument over whether some information is best stored in an attribute or in an element."

   If you have a string that is best stored in an attribute in FM but as content in XML, use XSLT to switch between them as needed. Remember also that the structures defined in an EDD and a DTD are usually very similar but they do not have to be identical.

--Lynne

[Lynne A. Price]

Joseph,

  You wrote, "Would there be an automated way to pull this information from the FrameMaker file and place it into the XML file? My department handles a lot of files at a time, so we would like to save as much time as possible when it comes to processing."

Automatic processing not only saves time, but it reduces errors and proofreading expense. Yes, put the needed information in the FM documents, in attributes if you don't want it to appear on the body pages. Then save it as XML with an application that uses XSLT to move it from attributes to element content.

--Lynne

[josephb44551697]

Lynne,

Could the XSLT pull directly from the master pages, or would it have to pull from the body pages?

Joseph

[Lynne A. Price]

Joseph,

   When you save a document or book as XML using an application with an XSLT post-process, the FM content from body pages is saved as a temporary XML document which becomes input to XSLT. However, the XSLT transform can open other XML documents as well. That's why I suggested maintaining the boilerplate text in other files so you can save it as XML and also copy it automatically onto the master pages using text insets.

  That suggestion was for boilerplate text that is used in multiple documents. For document-specific information that you want to include in the XML and on master pages, try using running h/f variables or body page attributes.

--Lynne

[josephb44551697]

Lynne,

I see. Thank you for the clarification.

Joseph

[Ian Proudfoot]

Joseph,

Another approach (if you can edit the DTD/Schema or maybe just the EDD) is to store the text for the page headers as metadata in the main XML flow then use Running HF variables on the master pages to display the regulatory content as required. I've done that for a project with a lot of repeating regulatory content which was translated into 30+ languages. It's still going strong after eleven years!

To avoid having to hide the text in FrameMaker it could be stored as attribute content on the root element. The success of this method depends on the number of separate text items that need translating.

Ian

[josephb44551697]

Ian,

Thank you for the reply. The issue with this is that our translation agency would be translating only the content of the XML, not the attributes or anything contained within the XML tags themselves. So the heading/title attributes would not get translated.

Joseph

[Ian Proudfoot]

Joseph,

The regulatory data could be stored in elements in the XML environment, but transformed into attribute content in FrameMaker. This would need to be done in XSLT of course.

Ian

[josephb44551697]

Ian,

That makes sense, thank you for the clarification. Would there be an automated way to pull this information from the FrameMaker file and place it into the XML file? My department handles a lot of files at a time, so we would like to save as much time as possible when it comes to processing.

Lynne,

They do appear on a body page of a single document.

Thank you both for your great suggestions!

Joseph