Store translations in the same file

[hdodov]

This idea builds on top of #523 and is about translation management. It might be more beneficial to store translations in the same file like this:

title:
  en: Site
  de: Seite
  bg: Сайт

Yes, you'd have to parse YAML, but with the current setup, you have to parse an entire new file and then merge it on top of the default content. The benefits of this setup are:

• All translations of a value can be analyzed at a glance
• You would have less files - just site.txt, not site.en.txt, site.de.txt and so on. This could reduce the complexity of Kirby core?
• You wouldn't have to merge the translation over the default content, which becomes nasty when structures are involved
• You could easily have translate: false in structures, which is currently unsolvable getkirby/kirby#1602

How would it work?

By using a prefix in the field key. For example, title is a regular field, title:lc is a localized field. The YAML spec allows for that. So you could have:

title:lc:
  en: Site
  de: Seite
  bg: Сайт
toggle: true

...and the title would be parsed because it ends with :lc, meaning that array values are treated as translations. The toggle would be interpreted as-is because it doesn't end with :lc due to translate: false, for example.

With this setup, you could very easily switch the default language too - it would just be a matter of which array key to look up.

[bastianallgeier]

Just to let you know: I removed Kirby 4 from the title to not give the impression in the ideas repo that Kirby 4 is on the horizon. This is far far in the future.

[lukasbestle]

So far we don't need to discuss this for the reasons @bastianallgeier mentioned (by the time Kirby 4 is on the horizon, our opinions will have changed anyway), but just so that you know why we currently use a file per language:

• There are sites with many many translations (upwards of 10), where each page or at least wide areas of the site are actually translated in each language. The individual content files would get massively big, which hurts performance. Only reading and parsing the languages that are currently needed is much faster.
• If you edit content by hand, you generally only edit one language at a time. Sometimes it can make sense to have two languages open in parallel, but the brain can hardly cope with more at once. So keeping the files separate makes it easier to keep the overview.
• If you send content to someone else for translation, sending and receiving individual files makes it much easier to merge the content from different translators later.

Of course this doesn't need to stay like this forever, so we'll see once it becomes relevant. Your reasons are definitely valid. :)