Closed (outdated)
Project:
Drupal core
Version:
11.x-dev
Component:
markup
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
3 Jun 2015 at 12:51 UTC
Updated:
31 Mar 2025 at 12:53 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
maxocub commentedPostponed on #2454829: Configuration translation UI does not support plural sources/targets
Comment #2
gábor hojtsyComment #3
penyaskitoComment #4
maxocub commentedComment #5
andypostComment #6
gábor hojtsyLooks like this is not being worked on, so removing from sprint. Please add it back if so.
Comment #7
maxocub commentedComment #8
maxocub commentedComment #9
maxocub commentedHere's a first patch. I never used #inline_template before and it's not documented on the Form API page (should I open an issue about that?), so I looked at other usage in core.
Comment #10
andypostI think in most places you can leave that as render array (no need to render)
makes sense to move template definition out of loop
Comment #11
maxocub commentedComment #12
maxocub commented@andypost: Do you mean something like this:
I tried that and it just prints 'array' on the page. I guess I could just use the 'render' function instead of calling the 'renderInline' from twig, would that makes it better?
Or maybe I am not using the render array correctly?
Comment #13
andypost@maxocub please try to change render array to prevent rendering, it looks really strange that we need render in build
Comment #14
maxocub commentedNew patch where I replace the 'item' form elements by 'inline_template'. We do lose some auto generated CSS classes and IDs, but AFAIK it doesn't matter, since it's just markup to show the source string to be translated.
Comment #17
maxocub commentedThis test was failing on #2571655: ConfigNamesMapper::hasTranslatable has flawed logic too, and I corrected it there too, not sure what's the best approach for this situation.
Comment #19
maxocub commentedOh, silly me, the test is looking for CSS IDs that no longer exists.
Comment #21
maxocub commentedI really don't know if it's OK to set an ID this way, but I added it on the inline template to be used with the test.
Comment #22
penyaskitoIt's totally fine, nice cleanup :)
Comment #23
penyaskitoAdded beta evaluation template.
Comment #24
penyaskitoTested that works correctly.
Comment #25
penyaskitoWhy is this needed? If we are changing the HTML element ids this way, we may have duplicated HTML ids which makes our HTML invalid.
Comment #26
maxocub commentedRight, I forgot there may be more than one plural variant field on this long form, so there would be duplicated IDs. I'll find another way to test it.
Comment #27
maxocub commentedI removed the potentially duplicated IDs and modified the test to count the number of source elements with xpath.
Comment #28
maxocub commentedComment #29
gábor hojtsyThe modified code seems to be doing a different thing now? The fieldset title is the definition label and then it has a child element instead of the title contain the text?
Same here, the template seems to be in a different structure?!
Comment #30
maxocub commentedSome before/after screenshots showing the visual haven't changed.
Also, a diff of the HTML structure changes.
PlurialVariants.php


What changed here is that
<span class="visually-hidden>(English)</span>moved from the fieldset-lengend span to the fieldset-wrapper div. Also, some CSS ids ans classes are gone, but I don't see any side effects.TranslateEditForm.php


What changed here is that the
<span lang="en">is not anymore around the whole div, but around each source strings, which is more like normal singular strings are presented in this form. There's also some CSS ids ans classes that are gone.Comment #32
maxocub commentedComment #33
gábor hojtsyAll righto, I misread something then, let's get this in :) Thanks a lot!
Comment #34
alexpottAren't these missing the
forattribute - I think that for was wrong before though - so not sure that this matters.Comment #35
maxocub commentedThe label tags without a for attribute are on the source side. So they are not associated with an input field, but with a span. The label tags on the translation side have a for attribute with the id of their input field.
Before this patch, the two label tags (the source one and the translation one) had both the same for attribute pointing to the translation's input field.
Maybe we should use a tag other than label for those without an input field?
Comment #37
maxocub commentedIs there still work to be done here or can it be RTBC?
Comment #38
maxocub commentedComment #50
smustgrave commentedThis issue is being reviewed by the kind folks in Slack, #need-reveiw-queue. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge require as a guide.
Taking a look at the code for 10.1 and I see now it's using FormattableMarkup() does that resolve the issue here?
If so think this can be closed and credit moved over to #2958429: Properly deprecate SafeMarkup::format()
Comment #52
smustgrave commentedJust following up if still valid? If no follow up could close in 3 months
Comment #53
penyaskitoThis was fixed apparently in #2958429: Properly deprecate SafeMarkup::format() and #1938916: Convert locale theme tables to table #type, but it's hard to track 😅
I reviewed HEAD and definitely not an issue anymore.