Hi all - I am working with languages for the first time on a project (2 languages), and I’m trying to guage if something is possible:
If I have a page with say a cover image field on it, which ultimately never changes based on a language, if I add an image in the english view and then go to the 2nd language, the image will still need adding a second time. I can see this causing some grief for admins and I’m wondering if there’s a flag to make some fields either just duplicated from the default language, or at least defaults to the first language unless an override is present in the 2nd language.
This would also apply to blocks; if I have an english page with 10 blocks on it now I need to add a second 10 blocks in the other language and tweak all the settings to match. I’m hoping I’m missing a way to have a lot of this just set in the default language (cannot find anything in docs).
Or perhaps I’m missing a better way to do it; right now I’m thinking if that is how it works I might be better off just setting up separate groups of fields for what really is language dependent separated by tabs (and work out how to do the frontend switching).
You can set such fields to translate: false to prevent this.
For blocks, this wouldn’t make sense.
When you create the first translation, Kirby will show the default language version and if you save that, all the block settings will be preserved. However, any changes after that, you will have to copy manually.
So ideally, you start translating only when the default version is sort of done.
I’m not sure I agree with the blocks not making sense for this; from my point of view that’s when it could make the most sense. For example, if on on a page I need to add 10 new blocks it would be great if those 10 blocks also were added to the 2nd language and I could just go through and change the tet that matters, rather than all the settings and images which would be the same through both translations. Do you not agree?
As I outlined above, this works if you first create a translation but not afterwards. This is true for the blocks field and also any other field (textarea with long form text).
Since there is no connection between the blocks in the translations, i.e. you can move blocks around freely in any language, or remove blocks from a single translation etc., it would be difficult to keep track of. In any case, it currently is as it is and you need to keep this in mind.
Thanks @texnine. Yes I think it would be great to have a workaround for this but understand the limitations. At least I know I wasn’t overlooking something.