Copy layer content between InDesign files

[SMark59]

Hello,

I'm trying copy layer content between 2 files, the sources file is a Spanish version of a training manual and the target is an English version. Essentially making a single multiple language file out of two single language documents.

I'm not well-versed in scripting.

Thanks

[Steve Werner]

What version of InDesign? How many pages in the publication?

It could be scripted, but if there aren't too many pages, you could copy manually. A useful thing to know when copying layered content: From the Layers panel menu, select Paste Remembers Layers. When you do that, selecting all, copying and pasting will retain the layer structure from the original file instead of putting all objects on the current layer.

[SMark59]

Hello Steve,

Thanks for your prompt reply. There are actually quite a few manuals that vary from 24 to 140 pages. Right now they are in two different versions. The files were originally created in CS5 but the translations were mistakenly performed with CS5.5. Either the creation staff has to upgrade to CS5.5 or we have to get the translators to export in IDML so we can open them back up in CS5.

Right now I can't even open the files that were created in CS5.5 so getting the translators to save in IDML seems like the first step unless a script could do the work without having to open the files. Doesn't seem likely given what little I know of scripting.

Mark

[Joel Cherney]

Right now I can't even open the files that were created in CS5.5 so getting the translators to save in IDML seems like the first step unless a script could do the work without having to open the files. Doesn't seem likely given what little I know of scripting.

Even if you could open all of the files, this workflow (relying on multilingual files with lots of layers with one language per layer) is, in my fifteen-odd years of experience in the translation industry, a horrible idea about 95% of the time.  What I'd do in your shoes:

1) Download a trial of 5.5

2) Open up a multilingual file

3) Delete all the layers but the one you currently want to copy/paste

4) Save with a new name indicating language content

5) Place that new ID file into your multi-language master file with all of the layers

I don't know if this will actually work for you - some translation workflows (indeed, some workflows in general) can't handle the ID-file-placed-in-another-ID-file technique.

[SMark59]

Hello Again Steve,

Perhaps if I shared a bit more detail.

We began with an English version. All content was placed on layer 1. At the time some of the manuals were created there was no thought of needing multiple languages.

These files had their one layer with all placed graphics and text renamed English. The Idea was all the graphics that have text embedded in them have been edited to add the second language onto a new layer in the graphic files. (Many of the manuals share graphics between them, so a common links folder was used to maintain the library of images. The graphics files have an "art layer" and "English" layer and a "second and in some cases a third language layer added.)

In InDesign the English layer was to be duplicated (duplicating both the graphics and the text) The text was then exported out as tagged type and translated into the second language and was to be flowed back in to the second language layer. InDesigns layer overrides would be applied to each of the duplicate images to turn off the English text layer and turn on the second language layer. One copy of all the graphics and one InDesign file containing each language layer with it's appropriate layer overrides.

To print the thought was to turn of the language layer visibility you didn't want and turn on the language layer you did want.

I hadn't anticipated the translation company would override the request to perform the translations in this manner and provided a single language file back instead.

I thought it was an efficent system. A single copy of each manual to deal with and single graphic files in a common library to be maintained. At some point e-publishing is being considered and I thought one e-book with all the languages in it could be created and within the e-reader the appropriate language could be enabled. Eventually, I anticipate, and hopefully prior to the e-book effort, we will be upgrading to CS5.5 to take advantage of it's enhanced e-pub features.

Like I said, I am new to this multiple language publication process and imaged the workflow to do the job rather slickly. Rather then having sequential languages one after another in the same book the languages would take advantage of the virtual Z dimension.

Fewer files to maintain, if a change was made to the english version the change could be made to all language layers on the same page.

Given your extensive experience I'd be interested in entertaining the pros and cons of sequential verses layered multlingual files. Seemed more efficient to duplicate the text in this manner then to duplicate all the graphic files. In some cases the manuals we are working with are so old (but not outdate) as to not even have digital versions. It's a big project and management within the company doesn't always think very far ahead. I'm attempting to develop a "plan" and not certain nor convinced it is the most appropriate so your advice and opinion would be recieved with great consideration. I haven't found a whole lot of resources regarding multilingual publishing. The project was sort of "thrown" at me and at the moment it's rather difficult to determine if I'm sinking or swimming. My head goes underwater but I could be doing the butterfly and that's suppose to happen.

Right now language needs are limited to the languages with land masses attached to ours North Central and South America. International Spanish was one choice, rather then having to support each dialect. That will likely change in the upcoming years but I know of no plans when.

Thanks again,

Mark

[Joel Cherney]

Hi Mark,

First off,  note that I'm not Steve.   You might feel like you're in an email conversation but actually you're in a public forum.

I'm kinda too busy with my real job to give you the kind of answer that you're looking for. The multi-layer thing is often suggested by people who don't feel comfy managing dozens of different files. I've never seen it work well. I've done it for clients - and billed for 2 to 3 times the number of hours, because of the extra file-management hassle.  Because, if you're used to handling twenty-language jobs, you're used to seeing 20 files with the same name and dfferent language tags. YOu're used to using a spreadsheet or database to track big projects.

In lieu of a complete answer (like I said, that would take quite some time), let me give you a quick summary. Feel free to ask questions; I'll answer, but probably not very quickly.

The Idea was all the graphics that have text embedded in them have been edited to add the second language onto a new layer in the graphic files.

In the future, keep your graphical content separate from your textual content. Your graphics files should be, insofar as is possible, free of text.

I hadn't anticipated the translation company would override the request to perform the translations in this manner and provided a single language file back instead.

What?! Maybe I'm missing some critical data, but fire 'em. If you give a translation firm an instruction like this, they're free to turn the job down, or to bill for more time for the extra work, but it's insane that they can just ignore your job spec.

Like I said, I am new to this multiple language publication process and imaged the workflow to do the job rather slickly. Rather then having sequential languages one after another in the same book the languages would take advantage of the virtual Z dimension.

You've obviously never had a multilingual file where all of your SPanish accents magically turned into Arabic characters.

Fewer files to maintain, if a change was made to the english version the change could be made to all language layers on the same page.

Think about having your "master content" somewhere that is not a page layout app. You know, like translation memory or content management systems or even a homebrew SQL database.

[SMark59]

Thanks Joel,

Sorry about my confusion.

Talking about things being different then they are doesn't make them so.

Why would I place one ID file into another instead of just building a book and treating the two languages as chapters? The translation company has provided a clean single layer file that could act just as well as a chapter in a sequential multilingual document, but why publish 280 or 420 pages when 140 could do the trick?

To be fair to the translation company they have built the content management system and used it to build the second language version, so the ID file isn't managing the content, It just assembles the differnt chucks of text; Spanish, English, French, it shouldn't matter it's just a string of characters. And with layer support and layer overrides why not take advantage to make an image library with less duplication?

I'm hoping OpenType will handle the glyph issue you mentioned, so no I haven't had Spanish Accents "magically" convert to arabic characters. That would be more indicative of a font substitution wouldn't it?

I've heard the recommendation to isolate text and graphics and even lectured on it, but that was a standard used before Illustrator layers and InDesign layer overrides. I use to do my layout with a razor blade and a wax stick too, but times they are a changing or so I've witnessed.

So... Joel, can you help with copying layer content between two ID files or take the time to elaborate on your opinions?

Living is the real job.

[Jon WorldAccent]

Hi Mark,

As someone else who makes a living working with multilingual artwork, I'm going to chip in my two cents' worth.

First off, I have to agree with Joel. If you gave your translators an instruction, it would seem reasonable to ask them to re-supply as per that instruction. If they have built a translation memory as part of the project, then all the easier for them I would have thought. At the very least, they should give you CS5 files (or idml if you are feeling generous and don't mind doing their conversion work for them)!

Once you have your Spanish CS5 files, you can decide whether to merge them with the English. Personally I would leave a separate set of Spanish files, but more on that later.

If you do want to merge the Spanish into the English to create a multilingual file with a language on each layer, then you might benefit from the Layer Groups plug-in:

"You can import layers including content from other documents. This is useful when you need to collaborate on content, send text for translation and re-import it."

I'm no expert on this plug-in but did use it once to do something very similar – and it worked great.  (And it looks like there's a 14 day trial version...)

Myself, I wouldn't go down that road as I prefer to keep languages separate. One set of InDesign files per language. That allows you flexibility to vary the layout. This can be useful as, in my experience, a text in translation does not get uniformly longer or shorter. So, for instance, you might want to adjust the positioning of diagrams or even the overall pagination.

Going a step further, this workflow also allows for languages less closely related to English eg languages that run right to left (eg Arabic, Hebrew).

In general, I advise people to make "clean" diagrams (ie with no language content) and then have all the text in InDesign, including diagram labels, keys, graph titles, etc. Sure, you can have diagrams with multiple layers that you turn on and off in InDesign, and I have done this on the occassional project. But, on the whole, I don't really see the advantage in terms of wrokflow as it seems to add unnecessary complexity (in my view). With "clean" diagrams you can still just have one set of graphics which drop into ALL your languages, but all of your "foreign" language is in one place.

Incidentally, having all the text in your InDesign file generally makes it a bit easier to leverage Translation Memory, etc to save translation time and cost. (It's not impossible the other way but I find having fewer files with language in makes for these workflows being more efficient).

As you say, if you have separate files but then need to combine into a single publication then you can just create a book.

Of course, all of the above is my general advice without knowing the full details of your project and so might not be applicable... but I hope it's of some help!

[Joel Cherney]

Why would I place one ID file into another instead of just building a book and treating the two languages as chapters?

I was suggesting this as a method of retaining your multi-lingual layered file; of course, assuming that the styles are identical across all documents, the book plan is better.

I'm hoping OpenType will handle the glyph issue you mentioned, so no I haven't had Spanish Accents "magically" convert to arabic characters. That would be more indicative of a font substitution wouldn't it?

No, it was actually a very old text encoding problem that you won't encounter - different app, different platform, different decade. However, because most of my work deals with complex scripts, solving text-encoding problems is something which I do fairly often - if you're only working with Western European languages these kinds of encoding issues won't be a problem for you. However, if you're going to be doing any non-Latin-script work, these concerns become more important, in terms of management of text styles, specific language settings within ID, et cetera. The Spansh-to-Arabic thing was just one experience I've had that has made me want to keep languages in separate files when possible, and it was an example that I thought didn't require lots of backstory to explain.

I've heard the recommendation to isolate text and graphics and even lectured on it, but that was a standard used before Illustrator layers and InDesign layer overrides. I use to do my layout with a razor blade and a wax stick too, but times they are a changing or so I've witnessed.

Well, both wax-stick light-table methods and source text buried in graphics apps present problems for translation memory management and for easy revision & content portability. Despite your concerns that you're getting obsolete advice from me, I'm actually making this suggestion out of contemporary concerns, not twentieth-century concerns.

I think I endorse Jon's commentary across the board.

Best of luck.

[SMark59]

Hello All,

I agree with the observation that graphics files with text in them complicate the tranlation process. The company that hired me does not agree with the level of assessment to the pros and cons of each approach. They continue to see the pros from the perspective of their use of the graphics files as over-riding the complexity within the translation process. The translation team we worked with said the same thing. Problem is, the client insists. Layering the graphics with the artwork on one layer and each languages text on a separate layer will move us forward toward cleaning up that mess. Slow and steady. The ability of InDesign to manage a placed graphics layer visibility is a manageable work around to this insistance.

Your contributions in this regard will be helpful when sharing this discussion stream with the decision makers. It is one thing for a single person to make a recommendation and another when a group of experienced individuals share the same opinion. So thank you. It remains to be seen if they will see the benefits within the limited application of translation as sufficient to adopt a different graphic strategy.

Jon,

I downloaded the Layer Groups plug-in but have had marginal success. Of the three files of ten that were provided in CS5 format 1 of them works with the plug-in and the other two crash InDesign while importing the needed layer. The plug-in also slows InDesign to a crawl and prevents the screen display from updating correctly. It is frustrating to work through the crashes and one questions concerns me, whether less time would be spent copying the content page by page then stuggling with a plug-in that isn't functioning the way it is billed. Don't know, but I appreciate the shout out as to it as a possible solution.

The translation company has been a bit politically correct, I suspect, with regard to their willingness, in what they say, to provide a multilingual layered file but have yet to perform in kind with what they have said. This may well be due to the leveraging of translation memory mentioned by you all as well.

In all of this it continues to be easier to separate layer content into individual files then it is to merge layer content into a single file. If the files are constructed as multilingual layered files, a save as process can be used to make them individual files far more easily then if the documents are created as single language files and have to be merged together.

On a personal note: having purchased many products that have user manuals and operators manuals published in multiple languages it really is a pain in the nads to wade through a 420 page document to find the 80 page section printed in the language you read. Often times I will simply tear appart manuals printed in this manner and recycle the un-needed languages. Talk about waste of resouces.

We will be maintaining  single language copies as backups.

I'm still looking for a solution to merging layers in separate InDesign files into a single ID document.

Mark

[Jon WorldAccent]

Sorry to hear Layer Groups is crashing on you.

Apart from Layer Groups, I don't know of any other plugins that will bring a whole layer over to another InDesign file. In which case, I think your options are:

1. Try and isolate what's causing your your crashing problem or contact the plugin maker and see if they can fix it
2. Copy and paste in place each spread manually (with Paste Remembers Layers on)
3. Attempt (again) to persuade the client that single language files are preferable
4. Make the translation company fulfil your original requirements

If it was me, I'd be loathe to go with option 2 but it begins to look like this "brute force" approach might actually be your quickest and simplest solution.

By the way, there is one consideration when working with multilingual files I didn't mention before. I like to set up style sheets for each language so I can tweak size, leading, etc for just one language should there be a problem fitting the text. Say I have a paragraph style "Body text" in English I make a new style called "Body text ES" for the Spanish, but based on the original "Body text" so any changes to that cascade through.

I know at the moment you must just want the Spanish resolved, but looking ahead at other North American languages, it's also worth bearing in mind good Canadian French typesetting has its own peculiarities...

[Jon WorldAccent]

Option 5. Tweak this script someone wrote to copy a layer between two CS3 files to do the work for you.

This is actually the option I would go with (and to be fair, what Steve Werner hinted at earlier on in the thread).

[SMark59]

Cool, but I'm not on a Mac.

Anyone know how to convert that script to JS?

[mjcopeland]

So helpful, Steve! thanks!

[karasmason]

If your graphics are the same and the layout is the same and you just want there to be different versions of the text, then the conditional text feature is what I would use.

[Henrik_Lideberg]

Hi, some 4 years later i might have the answer 😃

This javascript seems to solve the problem. Save this as a .js file in your script folder:

var sourceLayer = app.documents[0].layers.itemByName("Layer1");

var destLayer = app.documents[1].layers[0];

sourceLayer.pageItems.everyItem().duplicate(destLayer);

Or download the script here:

http://http://henriklideberg.se/?attachment_id=225

Please note, that your source layer need to be named "Layer1".

Open your source indd-file and your destination indd-file, in your scripts panel, select duplicate_layer.js and run the script.

Done.

[JTKDerio]

It doesn't work

[Peter Spier]

What happens when you try it?

[JTKDerio]

Sorry, I didn't explain myself very well... The link is down and I couldn't download the script.

thanks for your interest and quick response,

[Peter Spier]

I don't think you need the link. It looks like the script is only those three lines listed in the post, and you can copy them to a plain text editor and save with a .jsx extension.

I'm not a scripter, but it looks to me like it will copy the objects on "Layer1" of the first document opened to the second document you open. If you need a different layer name, you can edit that.

[JTKDerio]

GREAT!! IT'S AWESOME!

I have a catalog with more than 80 pages in three languages ​​and this simple script has saved me a lot of work and overtime.

1000 thanks!!

[Peter Spier]

I don't know that it makes a difference, but I suspect that if you turn on Paste Remembers Layers in the Layers panel flyout menu before you run the script it will create a new layer of the name you specified as the source layer.

I think Winterm forgot to change the target in his script to the new layer created in the first line....

[winterm]

In addition to Peter:

That 3-liner just copies object(s) from active document Layer1 to the topmost layer of your another opened doc. No new layer in your second doc will be created. This may be confusing.

So, creating new layer for copied objects in the second document might be a good idea.

Like this:

app.documents[1].layers.add ({name: "Copied Layer"});
var sourceLayer = app.documents[0].layers.itemByName("Copy Me");
var destLayer = app.documents[1].layers[0];
sourceLayer.pageItems.everyItem().duplicate(destLayer);

Technically, script doesn't duplicates layers, it just copies objects, that's why layers name may be the same or different, as you wish.

[JTKDerio]

@winterm

Sorry but I have applied your script and I see no differences compared with that published by Peter, the result is the same.

Thanks once again.

[winterm]

@JTKDerio

The only difference is the first line. It creates A TOPMOST (important!) layer in your destination document.

Sure, you can do it manually before running original 3-lines script, and you'll get identical results.

I changed nothing in original (except layer name just for fun, it's really irrelevant).

@Peter

Nope, turning Paste Remembers Layers on/off does nothing here...

Well, picture tells a story...

Here's source doc layers. We want to copy layer 'Copy Me' content:

Destination doc layers before running the script:

Destination doc layers after running the script:

'Copied Layer' here is identical to 'Copy Me' layer in the source doc.

Don't forget, you must run the script with both docs opened and Source doc active