I’m trying to understand which one could be the best workflow, to exchange files with translators using CAT software.
The goal is to (1) leave the project structure intact, (2) send them files in a format they can read and save, (3) be able to reuse their work for future updates.
Since compiling generates something different from a Scrivener project, I guess that exporting is the right way. I would get a folder containing RTF (or MD) files organized into folders, that any CAT software can access and rewrite. Having them automatically numbered will preserve the original structure.
When I’ll receive back the translated text, I can rebuild the original project in a new Scrivener document, boasting the same structure as the original. At this point, I can generate the translated book by compiling it.
At the next update, I will just mark and export the updated original documents. As an additional courtesy and increased safety, I can also mark and export the older translated files. The CAT software will find the text to be translated, and the translator will give me back the updated documents. I’ll be able to replace the older documents with the new, updated ones.
That sounds functional as far as I can tell.
Except that, should it be me, I wouldn’t create a new project for the received files, but would rather place them as subdocuments.
Using collections, or global search by label or keywords etc, you could see only one or the other.
As for updating files and comparing them later on, I’d use snapshots.
I see the rationale behind this. However, I fear it can become too big a project, when all the languages are added, but I might try when I’m working on the actual data.
I have to let the translator do the comparison with their tools. I will never be able to extract myself meaningful snippets of text to be translated in languages that are not the ones I know very well. And will never be able to restore snippets of translated text in them.
I will for sure make a comparison to be used as guide for those translators that are not using CAT software. It is, however, a task that I will not be following myself, and will be left only to the partner companies deciding to go on that route. For tasks I’ll manage myself, we’ll go CAT. Meow!
Another reasons I see for leaving each language into a separate project is that Replacements (used as Text Variables) are global to a project. I would need them to be compiled in a different way in different languages (for example, something like <$edit_command> replaced with “Edit” in English, and “Modifica” in Italian).
Also, I wonder if I can easily apply a different Language (for spelling checking and hyphenation) to separate sections of a project.
Unfortunately no.
And that is presently quite a bugger, as you can’t even set it per project either.
(You need to go in the options and change it every single time you switch to another language.)
But that aside, indeed, if there is no advantage for you to have the original documents and their translation readily available side by side, it is best to handle the thing as two completely separate projects.
I see. All considered, this is maybe better left to the publishing program that will be used to do the very last make-up steps on the compiled document.
Excellent! Hyphenation remains a different matter, but admittedly it would make little sense if not used in the final publication (done, for example, in Affinity Publisher).
