Improve translate-from-non-english-source by adopting $srcLang from LocaleExtend

Research: To stay compatible with the world-dominating PO model, we can not add arbitrarty fields.
Because the mapping (msgid, msgctx) => msgstr MUST be unique.

Source: http://pology.nedohodnik.net/doc/user/en_US/ch-poformat.html

But i am not happy with the ad-hoc context extension i created, as it is not machine-parsable.

Hmm, better would be:
Context = "[src-lang=es&some-other=metadata]Some existing context"

Interesting.

Added this one for locale_extend, https://www.drupal.org/project/3337204/issues/3337265 🐛 Fix support for PO Export / Import Active

Good conversiation.

At first i liked the idea to have a structured storage of srcLang (and possibly other metadata) in a separate database field.

Now that it looks like we must fold structured metadata into $context anyway, i more tend towards that the context field should be the very storage, without denormalizing it into a separate field. But still assembling pros and cons.

This patch adds "srclang" parameter to strings, while still keeping the 'Langcode' context. So it wil work with and without locale_extend module.

It also avoids the need to render markup, by injecting and using the 'string_translation' service, so it should be cleaner and more performant.

Hey Jose,
i have been draggeg away for a while, but now i'm able to come back to this. THANKS for the patch!

I've thought a bit about this, and coded everything down in the MR (untested).
This needs some explaining of my train of thought:
- Yes, this can and should be simplified. Did that.
- Came to the conclusion that the source language is not optional here, so added that as a module and service.
- Wondered how the interface has to be - we had some conversations about that. Came to the conclusion that optional args (like in the last POC) are NOT a viable option. You can decorate TranslationManager with a service with an optional arg, but if someone decorates over your service, the fundtionality is gone. Service interface is service interface.
- So went with a SourceLanguageTranslationServiceFactory, the only viable options, and imho nice DX.
- Changed the context a better parsable: "[srclang=ru]MyContext". (This is extensible and we can fold in more such properties, but imho i dunno what for currently, but nice it is ;-.)

ALso i think, with a context format like this (remember, we need to fold all additional metadata into the context because for external tools like PO, context is the only metadata), i claim we do NOT need to change the DB schema to make srclang filterable. This can well be done in SQL, and the simpler, the more likely this goes into core! (If this can convince you, be invited to co-maintain!)

MR coming in a minute.

Well, looks interesting...

While I agree service decorators are a better option, adding a more generic decorator was not that easy for my case, it just gets too complex, https://www.drupal.org/project/3337204/issues/3337695 📌 Use Service Decorators instead of replacing TranslationManager Closed: won't fix

Anyway, I like this kind of decorators / wrappers you are proposing, one per source language, may be a good idea..

About the po exports, the idea is actually make one different PO per source language, so you can hand it over to a different translator... I need to work on this one, https://www.drupal.org/project/3337204/issues/3337265 🐛 Fix support for PO Export / Import Active

So I think you better just ignore my patch for now, and move on with MultilangNG and your new architecture, then I'll see about more options to make it pluggable here, which looks easier now with all these new services you are adding.

About the po exports, the idea is actually make one different PO per source language, so you can hand it over to a different translator... I need to work on this one, https://www.drupal.org/project/3337204/issues/3337265 🐛 Fix support for PO Export / Import Active

Yes, this may make sense for some.

Banzai!

Automatically closed - issue fixed for 2 weeks with no activity.