I’m sure this must be existing, but I can’t find it. Scrivener has a native variable/placeholder for running headers (<$pageGroupTitle>). This gets the variable text from the actual name of the document.
However, I don’t use the actual name of a document in the output. The English name remains unchanged even in the translated documents, so that the project’s structure remains readable even with languages not everybody is supposed to know.
For example, I might have a document’s name in English, and the title to be output, as a styled heading inside the document, in Japanese.
I can’t find a way to use the styled headings as placeholders for running headers. Does a native variable exist? Or, is it a workaround to simulate it?
The only solution that could somewhat work, that I’ve found in my search, is the same proposed by Vincent.
However, this has a few problems:
You have to enter the metadata for each document. They are not even inherited by nested documents, so all of them have to be compiled and then translated.
When exporting the documents for translation as, say, DOCX files, the metadata are saved into separate documents, and have to be manually entered again.
It doesn’t look a viable solution, since it would take a huge amount of time, and be prone to errors.
Because translators need the source file, not the compiled one. Their output must be returned as source file, to be later compiled for the project in the corresponding language.
You can tell it to (don’t tell it to do anything – use a compile format that does nothing or close to) leave things as is, but process your specific replacements.
Any other way, if you don’t compile, don’t bother yourself with placeholders…
In fact, I don’t want my translators to bother with placeholders: they must ignore them and leave them unchanged, and return them to me untouched.
When compiling the translated project, the placeholders will be resolved by the Compile command. For this, they must remain as in the original text I sent the translators.
You could write them as <$&somethingsomething>, which should render them inoperant — and therefor compile as text —, and later use project replace to have <$& become <$
So this way you could compile, and have whatever placeholder you’d like to do their job at this stage work.
All you’d have to do for those is to write them properly, without the extra &.
Those that you break on purpose (<$&) will come back to you (from whoever you work with) just as ready to be tweaked and operate as they left. (Assuming whoever you work with doesn’t mess them up…)
That’s an interesting trick. However, there is another problem that I didn’t consider in the previous post: Compile assembles a monolithic file, while Export preserve the original structure of separate files and folders.
I need this latter for the translators, since (a) a new project must preserve the same structure of the original when translated, and (b) updates will have to be done on individual files ro snippets, and not on the full, compiled project.
Export looks like the correct procedure in this case, to me. It’s the original code, minus the metadata. Maybe there is an export format that can preserve metadata?
The checkbox I find in the Export dialog seems to only create a separate sidecar .txt file (Filename Metadata.txt). This file seems to remain separate when going back into Scrivener.
Are there ways to force the Export command to include metadata right into the exported file?
Well, you can certainly use an editor outside of Scrivener to incorporate the metadata file into the main output file.
But the fundamental issue is that the metadata is just text to any application other than Scrivener. There’s no way to say “this is metadata, treat it differently” to other applications, and therefore no way to flag it in a way that Scrivener will recognize when re-imported.
