check if all strings visable in UI are translatable

I'm a bit sad that I have to reopen the issue here. I thought the error was with us and that we had forgotten to translate the module 100% before checking for non-existing translations, but unfortunately, that is not the case. In the German translation of Drupal, the module is 100% translated and yet it still displays English texts even when the display language for Drupal is set to German. As the two screenshots above show, English texts exist both in the module's popup dialogue and in the configuration form in the Drupal administration area.

Therefore, I unfortunately have to reopen the issue here.

The good news is I can reproduce the issue.

The bad news is that I do not understand where the problem is coming from. These strings are available for translation, but I think I may have HTML in these strings that is causing the Drupal.t() function to ignore them.

I hope to have a fix to you this week, but I am concerned I may need to break up a lot of strings into individual sentences, which will be very time consuming and break a lot of existing translation work.

Alright; I wrote some tests to compare strings and confirmed that most of the missing strings are due to HTML tags in the strings. This is definitely going to take me a few days to fix.

Question -- did you have this problem in 2.1? I could revert most of these strings to what they were in 2.1 for now, which would restore existing translation work.

That's a good one. Actually I don't t know but I can test it manually and reply here, if that. Helps. Don't worry about destroying any translations work, please we can re-translate that real quick. The smaller the peaces thee easier it'll be. Especially if there is just text in those additional strings. It's really late here.So testing and replying will take a while.

I will keep working on breaking up the strings then, since I know that will work.

The other translation option is to add a DE object to the library languages file. That would be much more robust between versions, and I would then just use the library translation rather than Drupal.t for the JavaScript strings.

Regarding the object for German.

I'm not sure if that's a good thing. Drupal supports 115 languages. Of these, some translations are less active others more. Thanks to our dedicated team members, we are often the first to notice this. Most of the time these kinds of bugs are valid to all languages Drupal supports. That's why I'm not sure if an extra object for a specific language makes sense here. I'll Compare the behavior of the two module versions as soon as possible and give feedback as promised.

I'm going to do both-- I'm reformatting the strings to support Drupal.t() for all languages. But people also use the library on other CMS platforms. And any languages I have natively supported in the JS library I don't have to pass through Drupal.t().

I hope to finish today or tomorrow.

Hopefully all fixed in 2.2.1 → , and I added a debug parameter to make it easier to review in the future.

That is almost perfect,

I quickly made suggestions and imported them locally into Drupal CMS.
Apparently, some placeholders are not recognized.

https://localize.drupal.org/translate/languages/de/translate?sid=2913738

Here is an example string:

https://localize.drupal.org/translate/languages/de/translate?sid=2913738

Apart from that, everything looks excellent, and the administration area's configuration page is now completely translatable.

Oh -- so those placeholders are gone now, so it is just outputting %headingExample as plain text. The text that used to be %headingExample is visible in your screenshot -- it is the nested bullets.

I don't actually see the new strings on the translation server yet. That example should now be made of 4 separate strings, with no placeholders:

headingExample : `
    <ul>
        <li>${Drupal.t("Heading level 1")}
            <ul>
                <li>${Drupal.t("Heading level 2: a topic")}
                    <ul>
                        <li>${Drupal.t("Heading level 3: a subtopic")}</li>
                    </ul>
                </li>
                <li>${Drupal.t("Heading level 2: a new topic")}</li>
            </ul>
        </li>
    </ul>`
  ,
headingEmpty : {
    title: Drupal.t("Heading tag without any text"),
    tip: () => `
      <p>
      ${Drupal.t("Headings and subheadings create a navigable table of contents for assistive devices. The numbers indicate indents in a nesting relationship:")}
      </p>
      ${Ed11y.M.headingExample}
      <p>${Drupal.t("Empty headings create confusing gaps in this outline: they could mean the following content is still part of the previous section, or that the text was unpronounceable for some reason.")}</p>
      <p>
        ${Drupal.t("<strong>To fix:</strong> add text to this heading, or delete this empty line.")}
      </p>`,
  },

I can change it manually for now, but it should be fixed, because other language teams might find this confusing when the issue got closed. So we need to take care and see when it is gone if new strings available on l.d.o

I'll keep this open until l.d.o gets the new strings then. I'm assuming there's nothing I can do at my end to help with that?

No, the strings got extracted when payout release a new version

Looks like 2.2.3 is up and ready with all the new strings. Is it ok for me to mark this fixed?

Let me check if %headingExample isn't shown anymore when translations are live. If it is still there, we need to fix it. Until we confirm it, we can change it to postponed. If the bug exists the translations containing %headingExample must be changed manually in each language by maintainers and that deed wouldn't be the best solution.

The correction notes are now in order.

I have found a single passage that cannot be translated. It is the string

https://localize.drupal.org/translate/languages/de/translate?sid=2913733

However, the translation is available and approved. That's why I find it strange.

As for the original issue, we can close it. The module can now be translated without any problems (except for the string mentioned)

The placeholder shown above is still displayed in the Ui and the placeholder %level is not replaced with text. Unfortunately, placeholders cannot simply be removed from strings because the translation server does not allow the affected string to be saved without placeholders in superset form. The placeholder must therefore either be reactivated or removed. Otherwise it will remain exactly as it is.

So I looked at this again and reset the translations in my installation of Drupal and imported them fresh. The module is 100% translatable. Many thanks for actively patching it. We can close the issue