Translating a Scrivener project

Scrivener
,
1

Hi,

I wonder which is the best workflow to translate a Scrivener project. The project will be updated or reused, so it is preferable to leave the translated versions in Scrivener.

A first solution I see is to compile the original project from Scrivener, and then let the translators work on the compiled format – be it DOCX, MultiMarkDown, HTML or InDesign/IDML.

Updating the project would mean compiling it again, and then updating the older translations after aligning them with the older original project.

The same for reusing in different projects: the translators would work on the compiled format.

A second solution would be exporting DOCX files from Scrivener, preserving the original structure. The translators would work on the DOCX files. The project manager would then reassemble the translated DOCX files into a new, translated Scrivener project.

The advantage of the first solution is that the translators would be able to check their work on the final product, either in Word, InDesign or web pages.

The advantage of the second solution is that the project manager could easily assemble an alternative version of the translated projects with no further assistance from the translators. Having to remove a feature from a manual? Uncheck it from Scrivener, with not need to find the passage in InDesign, and delete or hide it.

Are there other pro/cons you can see in the two workflows?

Paolo

2

Translators who use Scrivener exist. Some of them contribute to the forum. So if you can find one, that would probably be the best alternative.

An in-between solution would be to insert links back to Scrivener in the Compiled document, which would facilitate splitting the translated document back into pieces. See the Common Settings Compile options in Section 23.4 of the (Mac) Scrivener manual for more information.

I think the answer partly depends on whether the project manager is at least literate in the second language. If they’re not, asking them to assemble alternative versions without consulting the translator might be overly optimistic.

3

Thank you for your answer!

This is good to know, but I’m not in a position to choose the translators based on the tools they use. Even if not using tools that can help our work would make our collaborations plainly impossible (as with those who want to give me a translated InDesign document in DOC format, pretending I redo the layout work each time).

Since I’m in a highly specialized sector, translators are usually recommended by the distributors, or are working inside the distributor’s organization. Or, they are a small patrol I could select, and with whom I’m happy to work.

I was thinking to use the Export to DOCX function, because it should preserve the original structure. Translating separate documents shouldn’t be an issue, with translators working in a CAT tool (where separate documents are seen as a unique project).

I’m thinking to the Export feature because it seems to preserve the integrity of the original Scrivener document during import/export, and because the DOCX format can be read by any CAT tool with no alteration of the original format.

The nice part of being able to keep the translations in the Scrivener format is that much of a product upgrades happen by adding or replacing entire sections.

If the original project is as granular as possible, and the document titles are all in English, adding/replacing sections should be very easy. After having worked on the individual DOCX, translators should just have to proofread the final, compiled and finished PDF/InDesign/Publisher document.

Working in monolithic InDesign/Publisher files would require more care to identify the sections to be replaced, or where to add the new ones. This looks like something more time consuming, and prone to errors.

Translated projects in Scrivener would also be nice for corrections. For example, I’m currently correcting a nine-language project, and some corrections are to be propagated to the eighty documents that make each single-language InDesign project. It’s a maddening work, that I would be happy to replace with some gardening.

With Scrivener, I could simply search and replace a full project at once.

And then: I’m trying to demote PDF to a lower priority, and start producing Web Help and eBook files. It’s what times are asking, and have been asked for long. Having the translated projects in Scrivener would be a great help in single-sourcing them.

Paolo

4

Why not then duplicate the project (name-translation), sync it to an external folder, and give the translator the RTF files from that sync folder ?

The fusion of the two projects afterwards would also be as simple as drag and drop.

5

This is something that I had considered, but there are two main issues:

  • The naming in those folders would be hard to understand.

  • RTF has been interpreted in so many ways, that I would not be sure I would receive valid RTF from the translators.

The advantages of exporting to DOCX are exactly the opposite: easy to read file names and structure, and a very standard file format that Scrivener can deal with very well.

Another advantage of exporting is that this would clean the exported files from all my annotations. Working in InDesign, I’m now maintaining two separate versions of the master project, since I need one with all my annotation, snippets and graphic assets; and another one, cleaned up, to be sent to the translators.

With Scrivener, I could just maintain a single master, with all my annotations and snippets in a folder other than the Draft one. Translators would receive the exported version, that will then be imported to rebuild the translated projects.

Paolo

6

I don’t know. But to me it seems obvious that once you export the files they are no longer “connected” to Scrivener.
So no matter what you’ll do, the answer will always sound like “reimport the files afterwards in your project”.
If you voluntarily strip them of your annotations etc., you can’t quite hope for them to still be part of the file that will loop back to you after translation. (Likely the translator’s manipulation of your text, deleting a word to replace it by the translated one, would leave them either floating with no longer anywhere to be attached to – and probably ignored by Scrivener – or simply deleted as well anyways.)

So I would say that without using an external sync folder, you’ll have to reimport. And split if needed, so to reproduce the original binder structure. (If the translator doesn’t need individual files, might as well then compile as a single file. You could then insert a symbol as a prefix to your chapters titles, instruct the translator to leave it in place, and use that for automatically splitting back into individual files on reimport.)
Alternatively, if your annotations are not inline or attributed to specific locations in your body text (meaning that they’d be more like side notes), you could then perhaps copy/paste the translated text in duplicates of your original documents. (?) Or just the other way around. Copy the annotations to the corresponding translated document.
I just don’t see any of this happening on its own, is all.

The files in the sync folder are named as per their binder name and you can prefix them with a number that correspond to binder order.
(?)

Scrivener’s native format is RTF.
Scrivener-wise, you’d gain nothing out of opting for DocX over RTF.

. . . . . . . . . . . .
There is, of course, the possibility that I did not understand your question.

1 Like
7

No, but I don’t see this as a problem. As far as exporting preserves the original file hierarchy in the drive, and importing rebuilds the original Binder structure, I’m fine. The translator will work “disconnected” from me. I don’t want, nor need, to have it always synched with me.

Synching with all the translators would be unpractical, and require some sort of constant attention to what is going on. Something that I can’t do, nor ask someone else to do. Then, it would look a lot like continuous control on a freelance work, and I’m not even sure this is allowed by the law.

That’s what I want! I use annotations to guide the development of the original project. When it’s done, and I have to send it to the translators, I want the project to be clean, only containing the text and tags to be translated.

On the contrary, the files inside a .scriv project are named with unreadable names. I was thinking to that, when you were talking about giving the translators the original project. My misunderstanding, sorry.

Files and folders exported on a local drive preserve the original name they have in the Binder. That’s great to have them back as in the original, in particular with cross-references pointing to files with particular names.

Well, of all the programs I have that can deal with the RTF file format, there aren’t two that can understand it in the same way. It looks like DOCX is more standardized, and Scrivener looks to have excellent support for this format. So, I would expect that the programs used by the translator can read and write a DOCX file that Scrivener can then import with no significant change.

Paolo

8

From reading this forum it appears that the best way to make a DOCX files is to compile to RTF, then use Word to convert to DOCX. See these many posts for more info and background.

9

Wondering if this only happens with the Windows version, or also with the Mac one. The converters should be different. I’ve not tested really much the conversion (on Mac), even if my limited tests looked to be producing correct files.

Paolo

10

Our converters – for both Mac and Windows – are generally pretty good, but they do have a few issues in some well-defined cases. If your work happens to run into one of those exceptions, using Word’s converter is an easy way around the problem.

Since both RTF and DOCX were created by Microsoft, it’s not surprising that their tools lead the way.