Translation strings as Keys

Something i’ve seen in Laravel world Using Translation Strings As Keys but i think it could fit Kirby well.

The translation helper string becomes both the default language text/fallback and the key for translations t("Weclome to our website.") would output Weclome to our website. in the translation files i would have

// de.php
return [
  "translations" => [
    "Weclome to our website." => "Willkommen auf unserer Website."
  ]
];

Cons
At first this has main disadvantage of the default language string being the key so if you want to change it afterwards you loose the connection with other languages. In my experience this is quite rare and in these cases it be solved by using the default language file as before (or alternatively mass replacing the old string).

// en.php
return [
  "translations" => [
    "Weclome to our website." => "Weclome to THE website."
  ]
];

It’s not great, a bit confusing but again quite rare situation and it’s USER code.

Pros
There are quite few practical advantages with this approach.

1. I don’t have to make up names for the keys to be translated. Stuff like welcome.message becomes confusing to remember if you have multiple similar messages.
2. It’s more descriptive for translators later in files/panel than welcome.message.
3. Developer can preepmtively add these strings to then be later translated. This would be whole lot better if Kirby could check templates for the occourance of the translation and they would show up in panel automatically but thats same case with keys+fallback.

Code changes
The behaviour change i think could be very small. If any strings are valid as the translation keys (i am not sure) then one could already do simialr thing with t("Weclome to our website.", "Weclome to our website."). I wonder if the Key shouldn’t show up as fallback if there is none anyway. Because if i put t("welcome.message") somewhere and kirby won’t find any string in languages there is much higher chance that its a mistake and echoing “welcome.message” would show developer there is a problem instead of swallowing it like it does now (and if i want that behavior i be explicit and use t("welcome.message", "")).

Must say that I don’t agree at all. These strings are much harder to find and keep sorted into related groups of strings. I see this happening in another context where this approach ended up with many similar strings in a big messy file.

Our personal opinions aside i don’t think one approach would exclude the other? Like @Sonja i know you work on bigger structured projects and Kirby panel for example is like that too. But for smaller unstructured projects i work on i think this is actually pretty valid.
I’ve found this being pretty good for small things i do in Laravel. And there is maybe a reason why its the default there.

Yes, you are right, using the key as fallback should actually work fine.

My issue is i’ve never really grouped/nested strings in any Kirby project. It ends up being “big messy file” anyway and instead of “Welcome to our site.” we end up inventing “welcome_to_our_site” type of keys. Thats probably my fault but with content sites the same string tend to show up all over the place even things like footer.message in next revisions shows up in middle of contact page. And suddenly your template starts “footer.message”. Not sure if it’s better situation.

But maybe i am asking about very simple thing. Should or shouldn’t t() helper output key if it can’t find anything in the translations. Because it seems that that might be all i am looking for.

It depends. If you want to check if a translation string exists, you can only do that with the default null fallback. In any case, changing the default behavior would be a breaking change. In the meantime, you can achieve the fallback behavior with:

function tf($key, $fallback, $locale) {
  return t($key, $fallback ?? $key, $locale);
}

(only works with $key as string)

@Lukas Bestle thanks! I will replace the helper entirely and see as it works for us. But it would be cool if team gave this quick thought for the future. Even for visibility of missing translations i think its breaking but helpful default.
I will mention similar situation with K4 thumbnails throwing errors now many people found out their thumbs were never working. But i think for the better.