- Issue created by @geek-merlin
- 🇪🇸Spain Jose Reyero
The idea looks good to me, we cannot wait for ever for Drupal core...
Some ideas:
- Make it modular. Blocking config updates from locale is one thing, translating configuration from other languages is a different one.
- About translating strings from other languages, I'd like you to give a try to my latest experiment, which I had in mind for some time... Locale Extend https://www.drupal.org/sandbox/reyero/3337204 →
- Have you tried this one? https://www.drupal.org/project/config_import_locale →
Also, this composable-inheritance looks like a really cool thing... though not sure it helps with DX and maintenance.. (?)
- 🇩🇪Germany geek-merlin Freiburg, Germany
@Jose, nice to have your feedback. Some remarks:
> Also, this composable-inheritance looks like a really cool thing... though not sure it helps with DX and maintenance.. (?)
Yay, it's another bold new thing that provides the only way of extending highly self-coupled services in a modular way. Of course people may need time to wrap their head around the concept first, as it is new.> Have you tried this one? https://www.drupal.org/project/config_import_locale →
Ah, it does a small part of this: make syncing config to interface translations an option. Thanks! Did not know that.> Make it modular. Blocking config updates from locale is one thing, translating configuration from other languages is a different one.
I have that conditioned reflex to make things configruable all the time. So on one hand i'd say, cool, please open an issue and roll a MR. Otoh, does that functionality pose any problem? But let's discuss that in said issue, i'll accept any make-x configurable MR in doubt.> About translating strings from other languages, I'd like you to give a try to my latest experiment, which I had in mind for some time... Locale Extend https://www.drupal.org/sandbox/reyero/3337204 →
Ah, you coded that down, and you addressed the same question "how to cleanly manage translation strings with non-english source", with a different approach. Instead of adding some "Source-lang: es" string to $context, you add $srcLang to the options array. Very nice and clean! And extend the translation UI. But what about the PO workflow? How hard is it to incorporate the new field there? Will all the existing toolchains eat that?
(I incorporated that thing to give an opinionated answer to the question, but that topic is not our main itch, as we always develop in english. But in know for others it is...!)Anyway, i'd like to take you and this ideas on board here, and opened 📌 Improve translate-from-non-english-source by adopting $srcLang from LocaleExtend Fixed as a first step.
Oh, and i see you like syntactic sugar for devs. Opened 📌 Add syntactic sugar for translating non-english source strings Closed: duplicate .
As a general direction, this is thought as a self-help for interested folk and agencies to pioneer NG of core, so i'll adopt whatever works and has core perspective. I can't push much time into this these days, but will merge all that fits into that frame.