The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.The slick.optionset configuration add prevArrow and nextArrow settings, which according to the slick settings documentations shall contain html like <button type="button" data-role="none" class="slick-prev" aria-label="Previous" tabindex="0">Previous</button>.
Unfortunately drupal passes configuration through t() / TranslatableMarkup(), therefore creating strings in translation containing disallowed html, see Drupal API for a list of allowed html tags.
The offending strings can be seen in german translations for example, but it is the same for all languages. Strings containing <button> will fail to import.
| Comment | File | Size | Author |
|---|---|---|---|
| #20 | 3075838-arrow-translation-20.patch | 604 bytes | gausarts |
| #17 | 3075838-arrow-translation-17.patch | 14.1 KB | gausarts |
| #12 | 3075838-arrow-translation-12.patch | 7.48 KB | gausarts |
| #9 | 3075838-arrow-translation-9.patch | 6.81 KB | gausarts |
| #6 | 3075838-arrow-translation-6.patch | 5.88 KB | gausarts |
Comments
Comment #2
gausarts commentedThank you! Do you have any suggestion?
Comment #3
volkerk commentedWell, is it really necessary to be able to replace the html tag through configuration?
Maybe it would be sufficient to set the button labels in config and add the button markup via
Drupal.themejavascript function.Comment #4
gausarts commentedGood idea, thank you!
No really. I didn't want to think much about the needs last time. It was there simply because it is an option ;)
There was one option I excluded due to its trivial usage, IIRC, and then later a user proposed a patch to include it. So as you see, options should always be available as options.
What bothered me is how to handle existing users with their own custom HTML markups, says with A tag, and additional classes or attributes?
It is not only about texts: Previous + Next.
It is also hardcoded in TWIG, so perhaps it is better to go in there rather than JS version?
Comment #5
gausarts commentedThis is the only standing issue we have at Slick as of this writing.
We need to put it into the latest development 2.x branch first, and then back port it as needed.
I don't have to worry much about themers, since these buttons are printed in Twig, I think they can always update it as needed.
Most end users, especially if the
Optimizedoption is enabled, will not be affected since the arrows HTML and most settings are never stored in the first place, anyway.Comment #6
gausarts commentedAttached is to remove the HTML tags from the arrow options and leave it as texts.
Comment #8
gausarts commentedLet's get the ball rolling one at a time.
Comment #9
gausarts commentedLet's see if any issue.
Comment #11
gausarts commentedAlso fixed few CS leftovers. We'll drill down.
Comment #12
gausarts commentedLet's see if any issue.
Comment #13
gausarts commentedOne more.
Comment #14
gausarts commentedToo fast.
Comment #16
gausarts commentedComment #17
gausarts commentedHopefully last 2 as it appears 8.x-1.x-dev failed with tests actually. Wrong green at #9.
Comment #19
gausarts commentedComment #20
gausarts commentedFixed for leftover.
Comment #22
gausarts commentedI will follow up tomorrow if anything I missed or you find any issue.
Let's close this for now. Thank you for contribution!
Comment #24
joachim namysloThis is still valid. Here are two examples from de
https://localize.drupal.org/translate/languages/de/translate?sid=2514073
https://localize.drupal.org/translate/languages/de/translate?sid=2514075
Varbase uses the latest 8.2.x branch and if we translate this the mallformed html filter detects theese strings as invalid although of this patch. So the bug still presists.
See updated dblog screenshot in referenced issue.
Comment #25
gausarts commentedThank you.
You are right about this particular branch.
I haven't released a new one since then:
8.x-1.2: 1 January 2020
The patch: 14 Jan 2020
If you meant something else such as the patch doesn't work, please let me know.
Comment #26
joachim namysloComment #27
joachim namysloI simply meant if the patches are committed to the dev-branch and downwards. The strings here are still untranslatable. In other words: If we translate them they still got skipped. So we can defacto not translate them. Maybe because the patch is not committed to all affected module versions right now.
This is not the only module struggling with this. So either we inform each module maintainer manually. Or a documentation change on API docs is necessary to inform all maintainers at once.
See: #3157707: Prevent strings unsafe for translation in code