From @sthomen. Moving from https://github.com/backdrop/backdrop-issues/issues/704 because it's closed and proposes a very different approach to translating config:
I'm probably not expressing myself properly, the idea was to make something like this: https://www.youtube.com/watch?v=p-1z72YgPCc
In this example video there is no change to the site settings code. It uses the standard language selector block in the admin layout. The only difference is a little special handling in config.inc. Now this is a very crude thing I cooked up this afternoon, and calling the new method setLangcode in get() and set() is probably suboptimal, but it works and it's easy to make configuration strings translatable and it should make it much easier for end users to find them.
There could perhaps be a separate UI page for converting strings to be translatable, drupal8 does something like that I think. Profile builders, module builders could easily bundle translations with their default configs.
Perhaps I'm totally out sailing, but isn't this a better approach than going via t() and also having a configuration setting?
system.core.json looks like this:
"site_name": {
"_translated": true,
"sv": "Test sajt",
"en": "Test site"
},
[...]
"site_slogan": {
"_translated": true,
"sv": "Detta är ett häftigt test!",
"en": "This is a test."
},
Here's a zip with my changes: translatable_config.zip
Recent comments
Thanks for the response, Herb! Since I posted that I did some more testing and have posted this issue https://github.com/backdrop-contrib/tfa_basic/issues/33 In fact, if both email...
TFA - how to setup fallback options 'per user'
I'll test this tomorrow to see if I can replicate the problem and report back. It's not "per user" so it should be working.
TFA - how to setup fallback options 'per user'
As I work through things I flush the caches after every change I make. As far as I can tell I have the custom module in the correct place (/modules/custom/fix_zero_search) and the file...
custom module not showing up in modules list