Lektor: Attached image and alternatives

[lafrech]

I have a content directory with an image as attachment:

  contents.lr
  contents+es.lr
  my_image.png

In both contents.lr and contents+es.lr, I embed the image using markup:

![Alt text](my_image.png)

This works in debug mode but not when building.

Generated html for contents.lr and contents+es.lr:

    <img src="./my_page/my_image.png" alt="Alt text">
    <img src="../es/my_page/my_image.png" alt="Alt text">

Since images are exported only the primary alternative directory, this fails.

AFAIU, if using the image in a template, the url filter resolves the path correctly, but not when pointing to the image directly from the code, either using markup (or plain html).

Am I misusing Lektor? How are we supposed to use attachments with alternatives?

This is basically the same issue as https://github.com/lektor/lektor/issues/88, except my answer to @mitsuhiko's question

Is this in combination with markdown?

would be yes. Although the same happens when using plain html rather than markup so a solution relying on the markup rendering to sort this out, assuming this is even feasible, wouldn't be really satisfying, considering image markup is pretty basic and plain html is the only way around in many circumstances.

(Currently, our workaround is to duplicate the images in all alternatives manually after the build.)

[airone506]

Hello,

For the language alternative page contents+es.lr, instead of:

![Alt text](my_image.png)

use:

![Alt text](/my_page/my_image.png)

Then the generated HTML will contain the correct URL to the original image. This will work for the specific given example when using the editing mode, but also for the built pages. No need to duplicate the images then. Of course you have always to adjust the path in the markup accordingly to the original file locations. Using this way, the attached images can also be referenced via the markdown across the content of the whole website.

[derdritte]

I also would like to use attachments on pages using alternatives (in my case default en plus de).
I really dislike putting "absolute" paths into content, because that obviously means if I want to change the slug for the page I have to replace all links to attachments.

I guess this issues is not easily cleanly solved, because – i think – this should be down in the markdown processor. I figure that would be a pit of a pain and worse, would require a "plugin" or hack for the markdown processor which Armin might want to change out at some point (since they apparently all pretty bad).

I am going to go with "hardcoded" paths for now, looking forward to what you will come up with.

[bitwave]

👍 I have the same problem with attachments...

[tgpfeiffer]

In my setup I occasionally have contents where the primary alternative does not exist (when the content does not exist in that primary language), for example only contents+de.lr exists in /my_page, in which case the attached images are not copied to the target directory at all. I guess this means that neither access from Markdown nor the url filter works as intended. That is not good, even though I cannot immediately think of a good solution for that problem.

[tomgross]

Anyone found a solution for the html field type? It has the same problem.

[relikd]

Can't we simply put all attachments in a alternative-independent location?
Then all alternatives can link to the same target.

  contents.lr
  contents+es.lr
  my_image.png

will build into:

en/my_page/index.html
es/my_page/index.html
attachements/my_page/my_image.png

with ![Alt text](../../attachements/my_page/my_image.png)

[mountainash]

This is a very noticeable problem when linking to PDFs (eg /de/support/faq/manual-appletv-en.pdf) - it looks very strange to a user/visitor and "could" have SEO issues.