Related to #1849564: Add the symfony validator component to core despite Symfony potentially releasing BC-breaking updates after 2.3. and #1845546: Implement validation for the TypedData API
Turns out, we'll need the symfony TranslatorInterface for being able to use the symfony validator - see http://drupal.org/node/1845546#comment-6781950. Question is how we deal with that?
a) Add the whole component just because of that? It's rather small (~300kB), but still it's quite some unused code just because of the interface.
b) Copy over the interface class only, e.g. below core\lib\Symfony - or somewhere else.
I must say, that personally I'd tend to prefer solution b). Adding the whole component and basically leaving it unused doesn't sound right. As it is not immediately clear the added implementation is not used it might be a bit confusing for newcomers looking at the codebase.
Comment | File | Size | Author |
---|---|---|---|
#11 | symfony_translator_interface.patch | 3.43 KB | effulgentsia |
Comments
Comment #1
fagoOr ideally, c) it would be solved upstream - see https://github.com/symfony/symfony/issues/6129
Comment #2
fagoalso see the related symfony validator PR: https://github.com/symfony/symfony/pull/6137
This potentially adds a composer dependency on the symfony translation system. We could work around that by adding the interface only, but that's obviously hacky.
Comment #2.0
fagoUpdated issue summary.
Comment #3
Gábor HojtsyI'd love to not have parallel solutions for the same thing, and especially not change course on the Drupal translation system 2 days before feature freeze :/
Comment #4
fagoTalked to Gabor on how well the interface matches our system. He found one problem with multiple formatting though: We generally take both (single, plural) messages as argument to format_plural().
Comment #5
Gábor HojtsyComment #6
effulgentsia CreditAttribution: effulgentsia commentedWe need to somehow resolve #5, because it would be a real shame for Drupal to not be able to use Symfony's Validation component due to that incompatibility. Somehow, we need to bridge Symfony validation with Drupal translation.
If the resolution results in a changed or new interface in the Symfony\Component\Translation namespace that works for us, then it would make sense to me for us to add something like a core/vendor-interfaces directory into which we can copy interfaces from other projects without having to copy their implementations.
Comment #7
clemens.tolboom@fago another XREF #1570346: Let Symfony Translation component handle language messages
Comment #8
webmozart CreditAttribution: webmozart commentedThere is a chance that the
TranslatorInterface
, along with other core interfaces, will be split into a separate composer package "symfony/api". Whether this will actually happen is still up for discussion (you are invited to join ;) ).Comment #9
catchThe PR isn't in yet, so I don't see how this can be major.
Comment #10
fagoIssue for detailed discussion on how we can solve translating violation messages: #1853096: Integrate symfony validation violations with Drupal translation
Comment #11
effulgentsia CreditAttribution: effulgentsia commentedTo be honest, I haven't followed the details of #1853096: Integrate symfony validation violations with Drupal translation and related discussions too closely, but it seems to me like that issue reached some resolution, so posting a patch here for what I suggested in #6. #8 would be nice, but I don't think we should hold up Drupal development on it. We can update to using Composer for this component whenever it's ready.
Once this is in, my assumption is that we can unpostpone #1849564: Add the symfony validator component to core despite Symfony potentially releasing BC-breaking updates after 2.3.. If that's not the case, please explain, and set this back to needs work.
Comment #13
fago#11: symfony_translator_interface.patch queued for re-testing.
Comment #14
fagoProblem with a manual fix like that is that symfony/validator now has the composer-dependency on translator, thus it will still get the whole packages when we do a composer update.
Maybe, we could just go with the package added by composer and modify .gitignore such that we only commit the interface? If someone else wants to add the full symfony translator I suppose he'd have a composer file out of Drupal anyway and just pull the full component out-side of Drupal - thus there should be no harm in the .gitignore approach?
Comment #15
fagoOn IRC effulgentsia mentioned that the .gitignore approach works or him, so going for that in #1849564: Add the symfony validator component to core despite Symfony potentially releasing BC-breaking updates after 2.3..
Comment #16
fagoLet's handle this in the other issue as well now.
Comment #16.0
fagoUpdated issue summary.