Panel language content fallback

[jenstornell]

This topic started in another post but I think it’s an own topic.

@distantnative

I know the whole translation option discussion is yet unsolved

Translation optional

About translation: optional. Here is a pull request.

enter a translation for non-default languages but won’t pre-fill them with the fallback from the default language (so that they also can be saved as empty and stay empty in the panel)

We can just disable the translation “autocopy” (what I call it), no more prefills of empty fields? It sounds great!

I would like to do that on all my fields in my site. That would require alot of work, or a new global option would be needed, something like c::set('translation', 'optional');.

Confusion as default (the important part)

If I could decide, I would NOT show content from the default language when the content in a field is empty. Here is why…

It does not reflect content text file

If I look in the panel it has prefilled content from the default language. If I look in the content text file, the field content is empty. In a way the Panel is lying to us, presenting alternative facts like that.

It’s already prefilled, false positives

When it pre-populates all the fields with content, I get the sense of that everything is already done. It’s easy to forget to translate fields that already has content, much easier than if it would have been empty. I prefer empty, not prefilled.

It creates confusion

If two field contains the same text, it’s easy to get lost and not know on what language you are. Except from the two letters in the Panel menu, the two Panel language pages are identical. I don’t know how many times I’ve saved a field in the wrong language and I only own one multi language site.

When I created my Kirby Keyword Map I could not understand why my keyword tags was not saved correctly. I removed them but they kept coming back. I thought it was a bug in my plugin for sure, but it was this “autocopy” feature. I needed to do a nice little hack to get around this issue.

It creates new plugins

I built my Kirby Panel Flags because I often save things in the wrong language. It’s because my current language page is a duplicate with the default language page, so I think I’m on the default language when I’m not. That’s the main reason for it, but I did not know that when I was making the plugin. Now I know.

(I’m well aware of the reason for not mixing flags with translations, it’s another topic)

There is also Kirby Translations which might not be made because of this issue, but it’s still a good helper to solve the problem by manually check that every language does not contain an “autocopy” text.

There is also an issue to make the language more simple to spot.

But I still think the main reason for confusion is that fields are prefilled with another language.

Kirby often doesn’t try to be smart

I like that Kirby often does not try to be smart. In this case I think it’s tries to be. Kirby is guessing that I want to use my default text when I write a text in the new language. In many cases it might be good to have, but it also creates confusition. Which fields are uniquely translated and which are autocopied? Hard to tell.

My solution

Instead of using what I called the “autocopy” feature above, I would leave untranslated fields empty as default. Then as a helper to translate these field, I would add a button with each field which says “Get” or “Paste” to get the content from the default language. Then instead I would get the content by demand only when I need it. Add content, instead of remove content.

It’s not a breaking change even if it may seem like it. It would just change the behaviour for people working in the Panel. It would not affect the frontend.

distantnative solution

@distantnative

how about adding a visual cue (e.g. color) to a field which had no value for this language so far and has just been pre-filled from the default language? This way you would also be more aware that you editing a different translation, not your main one when suddenly all/most of your fields are e.g. highlighted in lilac.

I think this could be a nice workaround, in case my solution are not approved.

It’s better to have some cue than none at all. In that case I hope the Panel would still look clean. I think it would easily be messy if not careful.

@distantnative @bastianallgeier @texnixe @lukasbestle

I think I know you crew well and I bet that my solution is a too big turn for Kirby to take right now? At least now I got my thoughts out of the system. I hope that I at least gave some you some thought and maybe food for new ideas.

Thanks!

[flokosiol]

@jenstornell

Instead of using what I called the “autocopy” feature above, I would leave untranslated fields empty as default.

I don’t agree with this. I think it’s a big advantage if you translate pages with a lot of content, because

• some fields may stay the same (like image fields)
• it’s much easier to translate a field if it’s pre-filled wit the original value and you don’t have to switch back and forth to the original page

[jenstornell]

@flokosiol

it’s much easier to translate a field if it’s pre-filled wit the original value and you don’t have to switch back and forth to the original page

That’s why I in my solution have a “Get” button to fetch content when need it. It would prevent the need for back and forth switching.

some fields may stay the same (like image fields)

In general images does not need to be translated. Therefor I agree with you on this point. It also shows that this topic is a bit complicated.

[texnixe]

@flokosiol

it’s much easier to translate a field if it’s pre-filled wit the original value and you don’t have to switch back and forth to the original page

I agree. But I’d still like an option to disable this feature or at least have an option to save an empty field. Because what I find really irritating is that if I empty a field and save, the field is re-prefilled again.

[texnixe]

@flokosiol

some fields may stay the same (like image fields)

Yes, and these can be set to translate: false.

[jenstornell]

It feel like I’m already downvoted so I move on to the @distantnative solution. Here are a few possibilities:

Text color

I think it’s easy to discover if not color blind. It was not easy to see when using the Kirby delete red color because it was very dark in text, felt almost black.

Text opacity

It’s not real opacity but it kind of feels like it. I don’t think it’s clear. The text is not as readable and it’s not as easy to discover as a red text.

Line

It’s outside the field so it would work with any field without the field creator needing to take care of it. Probably the best solution of them. The only pitfall is that some fields may contain something to the left.

[flokosiol]

I like the 2nd version (text opacity) most, though it’s a bit harder to read. The red color (text or line) inidates, that something’s wrong, and if you want to keep the default value, it may confuse the editor.

[texnixe]

@flokosiol

I like the 2nd version (text opacity) most, though it’s a bit harder to read.

From an a11y point of view, this is a no-go though, I’m afraid.