Force switch language to image field

In a plugin it’s not aware of the current page or what language is set.

In a for example a route:

If I was able to figure out how to get the page with page('some/uri'); I can do this:

echo $page->url('en');

It echos the page url in english.

Then I want to do this:

Because Kirby is not aware of the language it thinks it’s in swedish but it’s in english.

foreach( $page->images() as $images ) {
    echo $images->text();

This code will echo a swedish file field but I want to force it to generate an english one, just like $page->url('en');.

What comes to mind

  • Switch the language before running the foreach, like set some global function state.
  • Use some convert function.

I have swedish as default language.


I tried this with no luck, did not work. It’s used in the loop above.

echo $images->content('en')->get('text');

Update 2 - Yet another ugly workaround

Downloading and parsing the text file myself.

foreach( $page->images() as $image ) {
	$path = $image->dir() . DS . $image->name() . '.' . $image->extension() . '.' . $lang_code . '.txt';
	$content = file_get_contents($path);

	$array = yaml($content);

	$explode = explode("\n----\n", $content);
	$text = str_replace( 'Text:', '', $explode[1] );
	$text = kirbytext($text);

        echo $text;

I think for files it’s:

echo $images->meta('en')->get('text');
1 Like

Yes, that work, thanks! I can let go of my ugly workaround then.

Why can’t it be consistent to the way we get content in pages? It would be easier. It’s still content, but image content.

I can only guess @bastianallgeier’s reasoning behind this naming. I guess that because it is essentially not the file’s content, he decided to go rather for meta.

I added an issue here:

It’s indeed a naming thing. When I came up with file meta data, it felt weird to name it content. Of course it might be more consistent, but I always try to balance between human readability and all the other factors.

There are practical reasons why the language is detected & loaded after plugins are. If it was the other way around, plugins would not be able to create their own routes. But the language becomes available to all methods, which are called in controllers, templates or snippets. So you can make use of that maybe.

I think meta() is the better naming, though it’s a bit inconsistent. I think adding it to the docs would be a good thing!?

I’ve added this to our long list …

I’m actually planning to continue updating the cheat sheet tomorrow. The $file object is one of the next in my todo list. :slight_smile:

I understand.

In my case I have created “image pages” in a multi-language setup:

An image page is a route that is based on an fiel field called slug. Then the image has content just like any other page.

The urls looks a bit like this:


I really needed to go to hell and back to make it work.

Routes does not know what page it is

That’s mostly because of that plugin routes does not know what page. Calling page() get the home page. Somehow I always run into that problem. It does not know what language it is eather.

That problem alone togehter with multi language added about 10 smaller problems to solve down the line. But I’ve done it and it’s probably the most ugly thing I’ve build this year, but it work.


I agree with @flokosiol that docs for it would be a great thing.

Wohoo, there it is:

The File and Media classes should now be up-to-date again in the cheat sheet. But as you can see from the diff, that stuff takes ages. :smiley:
But at some point, everything will be shiny again. :wink:

1 Like