Open gagarine opened 4 years ago
(1) If a translation is missing for a given field and you have 5 languages, what translation of the available ones should be used? How does Kirby pick one? I think that's one of the reasons Kirby demands a default language - to always have fallback values.
Preventing translations of individual fields make this field not editable from other languages (but only from the default language)
Just don't add translate: false
and it will be editable in all languages.
A new page has to be created in the default language (but sometimes you do not want a translation in the "default language", or don't have it yet).
(2) I don't see a problem with having a default language page that has empty values. As I said in (1) - Kirby needs fallback values, even if they're empty.
Changing default language is not recommended
I guess that's the case because of (1) and (2) - if you suddenly change the default language, you may end up with pages that don't have fallback values.
For not translated value we could either duplicate the value in all language when edited or create a page.untraslated.txt that contain the untranslated value.
If a value is untranslated, it is still in some language. You can't have content that's not in any language, both in Kirby and in the real world. If you have page.untranslated.txt
what's the language of the content in that file?
I have to agree with @hdodov here. Our way of handling multi-language sites has some flaws – i.e. it's really hard to have untranslated pages – but we have been rethinking this concept many many times in v2 and v3 and it's the most straight-forward approach for "regular" multi-language sites. If you need more complex language scenarios (different pages per language, different files per language, etc.) you will always be better off with a multi-site installation instead of our core language handling.
In my opinion, If a translation is missing -> 404. The content does not exist.
But a "language fallback" is certainly usefull features. Language fallback should be an array so you test them in order. You could also use the browser language information for the fallback (much more user friendly).
I'm using translate: false
on date and image (so you edit them once for all your translations). I do not want to have to edit 5 translations just because I want to change the date of an event.
My main proposition is to store data with translate: false
in another file without language instead of the "default language" one.
This would allow for much greater flexibility. Typically data with translate: false
could be edited in all languages (just add "all language" on the field label to inform the user).
I like the ideas! There would need to be a way to define the fallback order, but that could be configured as a global default order in the languages config files (e.g. “the fallback for German is English”). Also the templates could request specific fallbacks for each field.
However this is something we could only change in a major release, so we will take a look at this for Kirby 4.
I'm really sorry, but I totally didn't get your point when closing the issue. Now I understand what you mean with the untranslated text file and I agree that it's a very nice idea.
Kirby needs a default language. I don't really understand why and in some scenario it doesn't make sense.
Having a default language brings some practical issues:
For not translated value we could either duplicate the value in all language when edited or create a page.untraslated.txt that contain the untranslated value.