Is there a quick way to get images into translated mif files?

[mcclatcheyj]

I sent mif files out for translation and when I open them the images are all grey boxes. The images were placed by reference in the source file. When I asked my predecessor about it, here is what she said:

"For translations, they should reference the same image locations as for the English. Yes, that means repeating the process of finding each missing image for each language. But once you do it for a particular manual, you shouldn't have to do it again (unless someone moves the files)."

Is there a better way to do this?

Thanks,

Julianna

[FrameMaker-dk · Accepted solution]

When you open the translated FrameMaker files with they will prompt you for a location of the referenced images. The prompt will work like this:

In the first line FrameMaker will ask you to find a specific missing image.  You will locate that image in your folder hierarchy.  If you have checked "Update document to use new path", FrameMaker will locate the rest of the images. IF they are in the same folder. IF NOT, another missing images prompt, will ask you to find another location.

I believe the grey images in your document are missing images, and that you may have accidentally clicked "Ignore all missing files" when you opened the document.

[mcclatcheyj]

Thanks Bjørn. Your solution worked perfectly. I'm so relieved! 

[FrameMaker-dk]

Great! Good that  you made it work.

I would suggest that you take a look at FrameMakers built-in XLIFF tool for managing translations. It is quite neat and a timesaver.

Using XLIFF you export your entire book (or single document) to XLIFF. FrameMaker collects everything - (links, fm files, insets) into an XLIFF file, which you send to the translation agency. They will do the translation and send an XLIFF back to you. You import the XLIFF and presto - all links have been translated and all formatting is unchanged.

[Winfried Reng]

Hi Julianna,

When you get the translated MIF files back, and the images are all only grey boxes, then the path is not correct.

I do not know which images you have. Are they screenshots which are localised? Or vector graphics without text? Do you have any labels in text frames (recommended)?

Possibly referenced icons are in a separate folder.

When you open your MIF files and FrameMaker cannot find a referenced image, FrameMaker will show a dialogue to point to the image in the correct folder. When there are different paths (e.g. to icons in a common network folder and other images in another folder), then FrameMaker will ask whenever the path changes.

Therefore I always have a folder for each language. In this folder there are all FrameMaker files and a subfolder with all images. Then the relative path to the images is the same for the source language and the translations.

And for your information: When the path goes up to the root, then the path will be absolute and not relative.

Best regards, Winfried

[Bob_Niland]

What's the work-flow & stewardship strategy here?
It sounds like you may be sending out for translation, and then continuing document publication/maintenance of the translation in house.

If so, that's apt to present a lot of extra work, and risks, if the translators need to modify any of the imports (which they would for text insets, and might for images), you cannot simply copy those back to where they started from, without checking every one. You may also get back .book and .fm files that are from older releases of FM.

Back when I had this problem (in the FM7 Unix days), the original documents referenced imported content from all over the enterprise's networked file system. It would not have even been possible to send out the files in a .zip that mimicked the original paths. So I wrote some scripts to gather all the imports in a ./images/ subdirectory, and re-write all the MIF syntax to point there, as a relative file path. I think the subsequent (and now posssibly broken) Archive function in FM can do this. The enterprise only expected to get back a PDF, but when a .zip did come back, it would be treated as a completely separate document, stored as the pub number with ISO language extension, and with its own local ./images.