Formatted files for language variables



One feature I loved in K2 was adding language-specific variables in YAML files. I was really surprised that it no longer exists. Last time it simply wasn’t documented, so I decided to test. Unfortunately, it really isn’t implemented.

Why is that feature important? Well, it gives you a lot of flexibility. The ability to have the content in a formatted file (be it YAML, JSON, even CSV) is valuable because you can easily import/export data. You can create a plugin to manage the content from within the panel. For example, it was thanks to this functionality that I was able to create kirby-memsource for K2, which allowed you to translate all your content in a TMS.

Also, imagine hiring a translator and handing him a PHP file… It would be far better to give him a well known format he can easily understand. It would be even better to use a TMS plugin like the one I mentioned above and allow translators to work the way they are used to.

I think this functionality is very important for multi-lingual websites of larger scale.

I also think that language variables should be customizable from within the panel and behave like other translatable content. Imagine having a site in 3 languages and you decide to add a fourth one. You go to the panel, you add it and you start translating the content… at least most of it. For language variables, you need to open your project, create a PHP file, copy preexisting variables, translate them, add, commit, and push to Git, deploy to your server… It’s even more complicated if there’s a translator involved.

It’s also tricky to maintain those variables, even if they are in a formatted file. You need to manually synchronize them. With page blueprints, you simply add a new field, go to the panel, and add the content. With variables, you add a new one to the default language file and then copy it everywhere else manually. And if you no longer need it? Easy - just delete it from every file. Manually.


Language variables play a small part in a Kirby site, and that’s the reason they haven’t gotten much attention in K3 probably. However, the small things out of place are usually the most annoying. I think that language variables should get some love in the upcoming K3 updates. Even if there’s no variable management in the panel, adding variables in formatted files would be enough because you can easily create plugins for the rest.

Having this functionality is important for scaling multi-lingual Kirby sites. I know that because I have been, and currently am, working on one, with Kirby 2.


Hi, I agree. But this is possible: I have setup my languages variables in Kirby 3 as (example for English) a separate file in site/languages/vars/en.php. There you can do whatever you want with your translations, as long as you return an associative array.

In sites/languages/en.php you can then do:


return [
    'code'    => 'en',
    'default' => true,
    'direction' => 'ltr',
    'locale'  => 'en_US.utf8',
    'name'    => 'English',
    'translations' => require_once "vars/en.php"


If you want to use a yaml files or anything else:

  'translations' => yaml::decode(F::read(kirby()->root('languages').'/vars/en.yml'))

and in vars/en.yml

green: grün
blue: blau
red: rot

Edit: You can, in fact, even use any custom function that then returns this language variables array, giving you all the flexibility your are asking for, including, for example, defining all the variables in the site object via the Panel.

 'translations' => getTranslations('en')

In a plugin:

function getTranslations($lang) {
  $translations = [];
  // code that generates your variables array depending on language
  // from a Kirby text file, a spreadsheet, JSON, csv or whatever source
  return $translations;


Hm, that didn’t come to my mind for some reason. Pretty solid solution!