Hi,
I exported a project from Mac Scrivener to MultiMarkdown (a variant of the default template), and the ‘Link to document’ links were not exported. They are just plain text.
Was there some switch to turn on, somewhere?
Paolo
Well, apparently not. So, as an alternative, I have to enter them manually, as explained here:
Paolo
Document links work fine. Did you enablethe Compiler “Convert links…” setting:
So for example this in Scrivener (a link to Moon from Sun):
…becomes this markdown:
…which Pandoc converts as so to create working links:
<h1 id="sun">Sun</h1>
<p>These are the voyages of the <a href="#moon">Starship Enterprise</a>.
Its continuing mission, to explore strange new worlds, to seek out new
life and new civilizations, to boldly go where no one has gone before.
We need to neutralize the homing signal. Each unit has total
environmental control, gravity, temperature, atmosphere, light, in a
protective field. Sensors show energy readings in your area. We had a
forced chamber explosion in the resonator coil. Field strength has
increased by 3,000 percent.</p>
<h1 id="moon">Moon</h1>
<p>These are…
For Pandoc, the rules for link generation are here:
2 Likes
Sure I did, but I must have clicked Cancel after doing it, and it was reset to off. In any case, now it is checked:
However, the link (that I checked, and is working internally to Scrivener) is empty. Here you can see the generated code:
[This is the link][]
as opposed to the manually inserted link:
[This is the link](#This-is-the-link)
What else should I check?
Paolo
You need to make sure document headings are enabled in the Scrivener compiler?
DocLinks.zip (23.4 KB)
Here is the test project I created, look at the section types there.
Did you try the result that Scrivener gave you? It should have worked, and that is not technically “empty”. Valid cross-reference links in Pandoc include:
- [Name of section]
[Name of Section][](⇐ Okay, Discourse refuses to allow[]to be escaped.)- [visible text the reader sees][Name of Section]
- [Name of Section](#name-of-section)
We only use the latter if we insert our own custom anchor ID override into the generated heading line. We use the middle two for other cases. Here is what a Scrivener override looks like, and this is only done if you having multiple headings with the same text:
Link to [something duplicated](#ref1).
## Binder Title Used Multiple Times {#ref1}
Blah blah.
Using the simplified bracket form avoids having to maintain parity with Pandoc’s algorithm for how it reduces visible headings to safe anchor attributes for all of the different outputs involved. Plus, it’s just a cleaner way of internally linking, using brackets and the [human-friendly heading text](#instead-of-having-stuff-like-this-to-read-around-in-your-source-file).
3 Likes
Oh, I see.
Unfortunately, I can’t make use of it. I work with several languages, and the name of the documents in the Binder is always in English (otherwise, I wouldn’t be able to navigate through documents in a language I don’t known).
Incidentally, this is the same issue I have with running headers, when the only way to make them is using a variable returning the name of the Binder’s document.
So, I will use one of the other formats. Shame the name mirroring can’t be automated.
Paolo
Depending on how you are populating the names, it might be possible. I don’t know how you are doing that, but assuming it’s custom metadata in the section layout, try something like, [<$custom:localised-name>], where the part in between the square brackets is hyperlinked to the target. That will cause the compiler to pull the value from the link target rather than the item the placeholder is in. Plus, if Replacements are changing the custom metadata field (like “DE-localised-name”, “EN-localised-name”, “IT-localised-name”, etc.) the same replacement that hits the section layout would hit these too. Thus, it should become [English Title] which points to ## English Title and so on.
You would need to use the Markdown brackets though instead of the link conversion, because a link on a placeholder is considered syntax rather than linking, if that makes sense.
Here is a very simple example: localised_titles.zip (81.9 KB)
4 Likes
This solution is amazing, that Scrivener’s compiler uses format-specific replacements to specify the actual metadata for titles and links, then that the link resolver uses the correct target info to pull the proper values across documents is so cool! I intuitively imagined this wouldn’t work, but it does 
2 Likes
I am to think deeply to this solution, but a problem that I foresee is that having this type of information as metadata would be prevented by having to export the documents for translation.
My strategy is to give the translators documents from the Scrivener project as exported DOCX files. As far as I could see (with default settings), metadata are exported as separate documents.
This would mean that the documents have to be manually rebuilt when receiving the translations back, and reassembling the project as a translated one.
So, the ideal solution would be something keeping even the metadata inside the main body of the document. Maybe as a styled paragraph that will be hidden at compile time.
Paolo
This is a more general limitation of Scrivener, irrespective of the metadata being used or not. Collaboration with others requires manual reintegration. You could maintain the chapter titles translated separately and not worry about them until all translations are in and you do the final compile (i.e. add metadata at the end). With export the document links will be lost (though not the placeholder text), and any other Scrivener features you may use will need careful revision (tables etc). As long as you copy-paste from the translations rather than import, you can still keep the metadata, otherwise you will need to renter it, but this seems only a small wrinkle in a task that is already manual and hard to automate…
1 Like
I would like to keep it at a minimum. Not only for the time needed, but because I’m not sure I’m doing the right thing in a language I don’t know.
I feel using Markdown links could be the safest way. Translators will work on the link text, and leave the link as it is.
Paolo
Sounds sensible to me! You can still use custom metadata and the compiler to inject the target anchors so each heading has a fixed language-insensitive anchor. So for example:
# Sole {#sun}
Blah. A link to [Luna](moon).
# Luna {#moon}
Blah. A link to [Sole](sun).
The translator only changes the text in [ ] and you manage the unique refs like (sun) and (moon). The {#sun} ID for headers are injected at compile time. Replacements and metadata can still help out.
3 Likes