From #3336532-3: General feedback on MultiLangNG-Translations:
> https://www.drupal.org/sandbox/reyero/3337204
Adds a $srcLang to t()'s $options. Great idea, it makes srcLang available without string parsing.
- Add $srcLang to t() options in this module too
- Crosslink the LocaleExtend sandbox on the module page, OR better, add it as sub-module of this package
- In a followup, make if and how non-english source language is translated an option
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 3337232-multilangng-locale_extend-01.patch | 4.05 KB | jose reyero |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
geek-merlinComment #3
geek-merlinResearch: To stay compatible with the world-dominating PO model, we can not add arbitrarty fields.
Because the mapping
(msgid, msgctx) => msgstrMUST 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"
EDIT:
Or maybe better:
Context = "[src-lang=es][some-other=metadata]Some existing context"
because of easier regexp handling.
Comment #4
jose reyero commentedInteresting.
Added this one for locale_extend, #3337265: Fix support for PO Export / Import
Comment #5
geek-merlinGood 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.
Comment #6
jose reyero commentedThis 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.
Comment #7
geek-merlinHey 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.
Comment #9
jose reyero commentedWell, 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
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
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.
Comment #10
geek-merlinYes, this may make sense for some.
Comment #12
geek-merlinBanzai!