Active
Project:
MultiLangNG (deprecated, use TranslationBliss)
Version:
1.0.x-dev
Component:
Miscellaneous
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
25 Jan 2023 at 21:07 UTC
Updated:
28 Jan 2023 at 14:47 UTC
Jump to comment: Most recent
Comments
Comment #2
geek-merlinComment #3
jose reyero commentedThe idea looks good to me, we cannot wait for ever for Drupal core...
Some ideas:
Also, this composable-inheritance looks like a really cool thing... though not sure it helps with DX and maintenance.. (?)
Comment #4
geek-merlin@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 #3337232: Improve translate-from-non-english-source by adopting $srcLang from LocaleExtend as a first step.
Oh, and i see you like syntactic sugar for devs. Opened #3337237: Add syntactic sugar for translating non-english source strings.
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.