Multi-language images and page bundles

support
1

We have a number of simple multi-language sites. There are few pages, and we like to keep the directory structure as flat as possible. Language-code appended files fit perfect for this project! (index.md, index.es.md, index.ru.md, etc.)

We add additional translations, and image translation on a per-needed basis, and rarely do “full-site translations” as that gets expensive, and largely unnecessary. So if I add a Spanish version of example.svg (example.es.svg), ideally it would get renamed to example.svg during publish, but that is not happening.

structure

content/
├── about/
│   ├── a-global-example.svg
│   ├── example.es.svg
│   ├── example.svg
│   ├── index.es.md
│   └── index.md
└── _index.md

config.toml

defaultContentLanguage = 'en'
defaultContentLanguageInSubdir = false

index.es.md

+++
slug = "acerca"
+++

renders

public/
├── about/
│   ├── a-global-example.svg
│   ├── example.svg
│   └── index.html
├── es/
│   └── acerca/
│       ├── a-global-example.svg
│       ├── example.es.svg ⬅️
│       └── index.html
└── index.html

Wouldn’t it make sense in this case for Hugo to rename example.es.svg to example.svg? That seems intuitive, and kind of a missed opportunity IMHO.

Quoting Multilingual mode | Hugo

Page Bundle resources follow the same language assignment logic as content files, both by filename ( image.jpg , image.fr.jpg ) and by directory ( english/about/header.jpg , french/about/header.jpg ).

Which is talking about language assignment inheritance, (which it accurately does do), but doesn’t rename, like perhaps it should.

Any thoughts regarding this?

I understand at this point I will likely have to either 1) Split languages into different contentDir’s
or 2) Utilize [[module.mounts]] and have translated content inherit that way.

2

Hi @vga

one thing I love with Hugo is I don’t have to provide images for each language it can basically copy the image from main language. what I do is place all images in assets and then call from there so I can easily resize and add webp format.

thanks

3

Is this a cosmetic issue (e.g., I don’t like the file name) or is something broken?

4

We use text overlayed on images often. We increasingly try to avoid this as much as possible, but is unavoidable in some cases. So we legit have different versions of an image across translations. Another case of this is say neighborhood.jpg, where in en-us is a photo of an American suburb, and in es-mx is of a Mexican one.

5

Ideally we would be able to add neighbor.es.jpg later, (after initial translation), without having to adjust the line in the index.es.md

![A Welcoming Neighbor](neighbor.jpg)

The more we touch markdown files the more we have to sync changes, and workflows get more complicated. And using different contentDirs in Hugo allows this inheritance, but same filenames in different folders.

Language-code-appended filenames is not 1:1 compatible with different contentDirs, which is a shame, cause it would have been the perfect balance for us, that maintains simple, easy directory structures. And in thinking more about it, it’s not obvious why this shouldn’t have been the case. Which led me to believe something was broken.

I will follow up with a reply of how our structure will soon be. I will miss having index.es.md and index.md in the same folder, cause that visually helps understand what content we actually have in a section, instead of traversing directories.

6

Here’s the solution we have on the docket.

structure

content/
├── en/
│   ├── about/
│   │   ├── a-global-example.svg
│   │   ├── example.svg
│   │   └── index.md
│   └── _index.md
├── es/
│   ├── about/
│   │   ├── example.svg ⬅️
│   │   └── index.md
│   └── _index.md

config.toml

defaultContentLanguage = 'en'
defaultContentLanguageInSubdir = false

languages.toml

[en]
	contentDir   = 'content/en'
	weight       = 1
[es]
	contentDir   = 'content/es'
	weight       = 2

/content/es/about/index.md

+++
slug = "acerca"
+++

renders

public/
├── about/
│   ├── a-global-example.svg
│   ├── example.svg
│   └── index.html
├── es/
│   └── acerca/
│       ├── a-global-example.svg
│       ├── example.svg ⬅️
│       └── index.html
└── index.html

Which does what we want it to do, but unfortunately have to traverse many more directories across languages to match up content between language (imagine the difference of effort taken when managing hundreds of pages/bundles) Ideally you deal with all translations in the same folder, and language-code-appended filenames does that, to a point. ::person_shrugging:

7

Not a solution, just some related notes…

8

Try this:

git clone --single-branch -b hugo-forum-topic-37325 https://github.com/jmooring/hugo-testing hugo-forum-topic-37325
cd hugo-forum-topic-37325
hugo server

You would start with one image, to be displayed for all languages:

content/about/
├── example.png
├── index.es.md
└── index.md

Your markdown for all languages would be: [1]

![example](example.png "This is an example")

At some point you create a language-specific version of an image:

content/about/
├── example.es.png
├── example.png
├── index.es.md
└── index.md

And it will just… work. No changes to markdown are required.

If you will need to reference images in your static directory using markdown, you must mount the static directory to assets.

[[module.mounts]]
source = 'assets'
target = 'assets'
[[module.mounts]]
source = 'static'
target = 'assets'

Finally, as to whether or not the existing behavior is expected, see:
https://github.com/gohugoio/hugo/issues/9557

  1. The alt and title attributes would be localized of course. ↩︎

2 Likes
9

@vga Have you had an opportunity to try this yet? I don’t think there’s any need to wait for #9557 to be resolved.

10

Yes I tried this. =) It works, and I’ll see shortly whether we would go this route.

Thanks for your effort in this!

As a P.S. I do love markdown render hooks… They definitely have some specific advantages compared to shortcodes. I’m personally on the all the things render hooks support. :wink:

1 Like
11

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.