Newbie to XML publishing. What role does XML, DTD, Stylesheets

[Tig519]

Hi all,

I'm new to XML publishing and want to support a simple workflow for translation. Goal is to...

Format an existing InDesign file using tags and stylesheets, export XML-->translation vendor-->import new translation in file (using exact same structure and formating of master language file). I have a few questions:

Do I need to have to a DTD if my paragraph styles match the tag name?

I assume the XML structure controls the order of publishing?? Does this mean I must use one connected text box, or can there be multiple containers. It should be noted that the doc contains- headers, paragraph, bulleted, tables with inline graphics throughout.

Following some other guidance video I found online, I have no cloned styles/tags. Each section is defined for both. When I export the XML, it appears to be a well-formed XML with table tags and href calls. It fact, the XML can be imported into a field based content tool (ultimately the goal).

However, when I make a simple content change in the XML to reimport, it blows up the doc. I used Merge & Append both with no success. I also used a checked XLST and non-checked. I'm using INDD 2022 on OS 13.0.1.

I'd be super grateful if someone can state the process I should use to achieve the automation I'm looking for by exporting and importing XML.

Is it because I don't have a DTD??

Is there a way to create one by manually tagging everything to have a tag that matches a paragraph style?

If I do need a DTD, can someone reference a good source to learn the basics of creating one?

Thanks in advance! I've attached a screen capture of one small section that illustrates an example of the tables which contain the more complex formatting. The rest are different section header & paragraph formats- with bulleted and non-bulleted text.

[James Gifford—NitroPress]

As InDesign does very little with XML, I think you must have meant to place this in the FrameMaker forum, which is very much an XML/DTD-driven app. In any case, you will get much more useful answers there, I think.

(Flagged for moderator attention.)

[Joel Cherney]

I'm new to XML publishing and want to support a simple workflow for translation. Goal is to...

Format an existing InDesign file using tags and stylesheets, export XML-->translation vendor-->import new translation in file (using exact same structure and formating of master language file). I have a few questions:

I do, too. Why do you want to do it this way? 

No, but seriously. I will totally take a stab at answering your questions, but first, I want to know why you've started with such a complex translation workflow. InDesign can export a file of the type "IDML" which is a markup language rendering of an InDesign document. It successfully captures everything but placed images, and I think pretty much every CAT tool and TMS in existence can consume and generate IDML. There must be exceptions, but I can't think of them at the moment. So, you're starting your translation process in a place where you seem to be doing way more heavy lifting than is necessary. Why have you skipped IDML and gone straight to XML export/reimport? 

Do I need to have to a DTD if my paragraph styles match the tag name?

Nope. 

Does this mean I must use one connected text box, or can there be multiple containers.

There can be as many text frames as you like, so long as you tag 'em all in the Structure panel. In fact, one set of threaded text frames - one "story" - winds up getting a single tag. Stuff inside those threaded text frames (e.g. paragraph styles that you've mapped to tags) appear under the tagged frame in the Structure panel. 

Following some other guidance video I found online, I have no cloned styles/tags.

That's good advice for an XML translation workflow in InDesign... can you post a link to the video? 

It fact, the XML can be imported into a field based content tool (ultimately the goal).

So, what's the goal again? You have English-language content in an InDesign file, and at the end you don't want a non-EN InDesign file? It's just a step on the way to your goal of content management? I'm not completely sure what your field-based content tool is, in this context, but if your main goal is to get all of your content into it, I can offer you some suggestions. If you're going to be using a language service provider of some kind (that's the "tranlsation vendor" in your post), then it should be Extremely Easy to get them to deliver your translated content in a way that makes it very easy to hoover up into your content management tool, which is what I am guessing your field-based content tool is. 

Said another way: if you have content in English, and you want it in a lot of languages, and your English content isn't already 100% in InDesign documents that are already well tagged and ready for XML export, then there is approximately a 99.44% chance that there is a better way to get your content management tool full of translated content. 

I could be wrong! Maybe, after you explained your workflow to me, I would respond, "... aw, jeez! You're right, the fastest & least error-prone way for you to do this is to house your English content in InDesign, and tag it up there, and export XML for your LSP." But I really doubt it. If it needs to be in XML, there are better places to work than InDesign, and if it needs to be in InDesign, there are better ways to translate it than exporting XML. Usually. 

[James Gifford—NitroPress]

Unless there's some overwhelming need to use or involve InDesign, the right tool and ecosystem is FrameMaker. After a wobbly start under its own schema and a slightly fringe-y markup language (SGML) it was almost wholly rebuilt into an XML document management system.

ETA: Yes, for translation, especially this ID-to-ID translation and republication, there are many translation services that both use, and prefer, IDML.

[Tig519]

Thanks for the response... 

I'll back up a little. 

The docs already exist in InDesign and our teams are trained in IDD & Illustrator. 

The translation process today is handled by copying and pasting EN fields in a word table. After translation is completed per language- copy and paste back into IDD doc.  As the translations involve over 24 languages, making it field based is the only way for designers to know what goes where and ensures stylized text is also in the right place especially for Asian and Middle Eastern languages. Translation company would prefer XML and we would prefer a more automated workflow. They ensure they will keep the XML structure identical as their software just replaces live text in the XML. 

Having played around this weekend, I got it to mostly work. Two outstanding elements. It doesn't like two different fonts in one paragraph style (even though it's fine with stylied character styles like Bold and bold italic). One section uses a bullet graphic from dingbats and futura for the rest, even when I tag separately, it wants to make the paragraph all dingbats. 

The second issue that I'm still working on, as it worked for a very basic test I did with inline graphics, is bringing those graphics back into the doc when replacing the XML. 

The other reason for this workflow is to introduce a copy management tool to allow changes to be done there by the client and not by annotating a PDF.  If we split the content with that in mind, we will be able to populate the database from the XMLs. (crawl, walk, run... )

BTW, the style sheets are built with a core reference style to "base" all other styles on. As language in some cases requires a different font, we are able to easily edit the english style sheets to another font set for that language. So there are a lot of things that were done well in the IDD files already. 

Hopefully, that makes a bit more sense. I'm getting closer.. I can probably work around the two fonts with an inline graphic instead, but hoping there's a better way. 

thanks 

[Joel Cherney]

Thanks for your detailed explanation. I'm still a bit taken aback by the idea of a firm that doesn't say "Can't you just give us the IDML?" That is a huge red flag for me. Massive. Likewise, the fact that the current workflow is to, ugh, copy and paste from Word tables? That's how we did it twenty years ago, before IDML existed. I can think of no good reason to use this workflow. 

But, hey, let's pretend that this isn't a problem. If you remove that, it's just a question of getting your tagging process to work well enough to export & re-import without issue. 

In my experience, the styling has to be Absolutely Perfect. For example, you mention that one of the problem paragraphs has one font for the bullet and another font for the body text. In that case, you'd absolutely have to have a paragraph style defined with a bullet style, and the bullet font would have to be defined in a character style. If you have that set up,you should be able to export XML, and then make one tiny little change (induce a typo?) and then re-import that XML right away. If that works, then you have a chance of pulling it off with your twenty-odd languages. If that doesn't work, then I suspect that your tagging job is the problem. Can you post an actual INDD from your project where the XML reimport "blows up"? 

[Tig519]

I'll try tomorrow... as it's a client's content, I need to pick one that is a little less obvious in whose it is... I'll probably post a Zip of the InDesign, graphics. On top of it, my computer is up to date on software- but the fonts for this job aren't... bunch of Type 1 fonts which I can no longer load!! So for the test, I ended up changing all of them to Arial. I'm open to any ideas on a better workflow to accomplish (except using Framemaker). I thought of using InCopy in between, but that doesn't seem to add value to the workflow. 

In answer as to why Translation won't take an IDML, if they have XML they can just run it through their Translation memory and spit out the translations automatically. Having the IDD or IDML to open in an IDD file would require human intervention to enter the translation in the doc. 

[Joel Cherney]

Well... If you can post a sample, I can see if I can figure out what's not working. My own TM systems can apply translation memory to IDML without human intervention, but unless your supplier wants me to teach 'em how, I suppose they're not going to be able to do so. With that limitation, I can see why you're trying to use an XML workflow. So the success or failure of your XML export is going to be down to how you are tagging your documents for export, and how well the document is built to account for text expanison upon re-import. 

[Test Screen Name]

One more thought. If you are working with an external translation vendor, there isn't much point guessing what to do. They are likely to have very rigorous requirents for what they receive from you, and if it's XML I'd expect that THEY have a mandatory DTD and predefined workflow. It's nice to practice with the tools, but don't put too much into the detail at this stage.