🇩🇰Denmark @ressa

Thanks for a fast response @nicxvan, in that case, maybe that could get a mention in the README?

PS. Great show with Andy Marquis the other day! For me, the killer feature of Custom Field is how easy it is to import multivalue fields with Migrate, compared to setting up a migration for Paragraphs: https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →

Also, the ability to copy content from one field to another with https://www.drupal.org/project/field_updater_service → using Drush is fantastic, but somewhat buried in the "Quick start", where it looks like complicated update hooks are needed, when they're not.

Thanks for sharing @christopher james francis rodgers :)

Though in this case, the question is not so much about resurrecting pages, but making sure that users are redirected to a page or section about the topic. So a user may not be looking for a one-minute set up, but info about "default.settings.php" and "settings.php" and find that link in the search engine. But it's a dead end on drupal.org. So we could instead redirect them to something that is as close to that subject.

So the second example I used could be redirected to https://www.drupal.org/docs/8/core/modules/file/overview → .

Thanks for a fast reply @drumm. I have experienced a fair number of drupal.org 404's recently, after doing a search for Drupal stuff in the search engines lately, so my best guess was that a bulk deletion had been done, without redirect. So when this issue appeared in my dashboard, I was reminded of it.

So those two pages are just examples I quickly looked up, to use as examples as dead links, so I don't have an opinion on a redirect, sorry.

Until the new Drupal is launched (and possibly automated search on title?) we could have a "404 Not found documentation pages" issue, where we continually add 404's, and then set up redirects?

Thanks for sharing your opinion @timanderson, though possibly, mostly proponents of the Forum are following this issue ... To reach a wider audience, the Modern design issue linked to above is probably more efficient.

And by the way, thanks for all your great answers in the Forum @stefan lehmann recently, I very much appreciate it!

Thanks @benjifisher!

Will it be possible to get a top 5 list of modules, which are the biggest bottle necks? Like, we know that Pathauto slows things down, but it would be nice to get a list of module bottle neck number #2, #3, etc. as well.

Add tip about getting --instrument in Drupal 11.

This would be a fantastic feature, so thanks for working on it! I looked for this after I found this Drupal 7 documentation page, recently migrated into the new documentation system, Expand the range of data tracked by the timer instrument during a migration → .

I tried applying the patch from #12 (thanks for re-rolling) against the latest Migrate Tools 6.0.5 release (it does not apply against dev ...) but get this error:

~/dev/drupal$ drush migrate:import mymigration  --instrument
  [error]  Error: Class "Drupal\migrate\Instrument\MigrateInstrument" not found in Drupal\migrate_tools\Drush\Commands\MigrateToolsCommands->import() (line 501 of /var/www/html/web/modules/contrib/migrate_tools/src/Drush/Commands/MigrateToolsCommands.php) #0 [internal function]: Drupal\migrate_tools\Drush\Commands\MigrateToolsCommands->import()

• Drupal 10.4.7
• Drush 13.6
• PHP 8.3.21

Adding link to Drupal 10/11 module https://www.drupal.org/project/migrate_boost/ → as number#1 in the list, since the rest of the items look like they are for Drupal 7.

Thanks @nicxvan! The 2.x dev version of the module works well in Drupal 10.

ressa → created an issue.

That's a good call @dydave, I agree 100% -- those issue are more urgent, and this issue can easily wait, since it's a minor problem. So really great to get 3.6.1 released to fix bugs, thanks!

Sounds good that you were able to recreate the scenarios here, and addressing this issue (and its tasks) in its own time is a good plan.

It's really great with all the clean up, though many Drupal 7 doc pages indexed in search engines now give a 404, since they have been deleted, without having a redirect to a replacement page, probably because there wasn't one.

This is unfortunate, since these pages may both be linked to from other pages on the internet, or on drupal.org, and the topics are still themselves relevant in Drupal 11, 12 etc. so people will still be looking for the info.

It's Drupal 7 pages like these:

https://www.drupal.org/node/1995428 →
Step 4 - Rename default.settings.php to settings.php
Install Drupal 7 in one-minute (or Drupal 6) Using Webhost Control Panel ... Step 4 - Rename default.settings.php to settings.php · Step 5 - Putting WAMP ...

https://www.drupal.org/node/2608620 →
Increase Maximum File Size
11 Jul 2017 — Although many other PHP settings are configurable by using ini_set() in the settings. ... Administer user profiles in Drupal 7 · Administering ...

As I see it, there are two options:

1. Handcraft precise redirects

   Either add a redirect to the corresponding page, if it exists, or a fitting section or page on drupal.org. This is labour intensive, and may not be realistic. Though, it could be considered for the top 50 of 404'ing Drupal 7 documentation pages?

2. Do an automatic search

   If a node is not present on drupal.org -- if possible, do a look up to somehow get the title of the deleted node, and do a search like https://www.drupal.org/search/site/Increase%20Maximum%20File%20Size?f%5B... → , perhaps with a text like "Sorry, this page is gone, but we did a search, maybe it can help?"

Adding link to the Devel issue on GitLab TypeError: Drupal\Component\Utility\Html::escape(): Argument #1 ($text) must be of type string, null given in the Issue Summary.

Perfect, thanks @tirupati_singh :)

I just discovered the same thing I originally saw with "Disabled, show on scroll-up", but which is fixed in the current MR:

With "Disabled", if I hover over the too low placed <thead> element and inspect it, it jumps into place at the top. Note: The dev-tool (F12) cannot be opened, then it won't jump to the top :)

Thanks for verifying @tirupati_singh! That's interesting ... perhaps you can share your browser version, in case that plays a role?

Sounds great, and thanks for all your work with facets and agents already here.

About blocking scrapers, one method could be a rule about number of hits over a certain period (maybe five minutes?) and being able to block an IP if a threshold of requested URL's is exceeded. The reason I thought about a more generalized "hits per time period"-rule is because I have a web site where five or six facets by human is to be expected. But an intense pounding by a bot is problematic mostly due to the rapid requests, not the number of facets.

Thanks everyone for looking at this and providing solutions, it's great to see so much activity!

The latest patch works well for "Disabled, show on scroll-up", but but the table header still hangs 80 pixels too low for the "Disabled" option ...

Disabled, show on scroll-up: Works, table header slides away, and reappears
Disabled: Table header hangs 80 pixels too low

Tested in Drupal 11.1.7 with Claro, DDEV PHP 8.3.21, Debian 12 Firefox and Chromium browsers.

@jatingupta40: Thanks for the feedback, maybe you can check how "Disabled" looks as well?
@tirupati_singh: Thanks! Did you test both options?

And I agree, the transition is slightly janky, but it may be difficult to get right?

You're welcome @dydave, thanks for taking a look at it. And definitely no worries, I have seen all the activity in the other issues! ... and we all have a limited number of hours, for volunteering our free time to Open Source.

Great extra additions to the MR, and good call to fix those details mentioned in other issues -- it now says "Toolbar sticky" everywhere 🙂 I also think using <br> should be safe, but the final test will be releasing it, and see if the translation systems accepts it, though I can't see why it shouldn't ...

I don't see any more textual elements that needs adjustment or to be improved on, before releasing a 3.6.1 patch version, it looks great now!

Thanks for checking @sokru, it would be great if you could share your Operating System and PHP version, if possible?

@stasadev from DDEV graciously provided the commands to allow running quick-start using PHP's built in web server in DDEV, for development:

git clone https://git.drupalcode.org/project/drupal.git qs && cd qs
ddev config --project-type=drupal --webserver-type=generic --disable-settings-management
cat <<'EOF' > .ddev/config.drupal.yaml
web_extra_exposed_ports:
    - name: "drupal"
      container_port: 80
      http_port: 80
      https_port: 443
EOF
ddev start
ddev composer install
ddev php -d memory_limit=256M core/scripts/drupal quick-start demo_umami -vvv --host=0.0.0.0 --port=80 --suppress-login

Copy the last part of the "One time login url" and use like this to launch in your browser:
ddev launch /en/user/reset/1/1749022638/TPUL789[...]123abcz/login

From Document or fix Drupal Quickstart command #7348.

To verify that PHP's built in web server is used with the DDEV set up above, check the "Response Headers" in your browser. You should see X-Powered-By: PHP/8.3.21, and not DDEV standard Nginx (server: nginx) or DDEV using Apache (server: Apache/2.4.62 (Debian)).

For anyone who needs to translate the custom "Reset text" value, you can copy the facets/templates/facets-result-item.html.twig file to your theme and add |trans here: <span class="facet-item__value">{{ value|trans }}</span>.

You're welcome, I am glad I could help :)

Just leaving a note, in case someone else also who simply want to translate a string finds this issue. Because without the patch, in a view which has results, in order to get Twig to render a string in a "Global: Text area" in the "Header" section in Drupal 10, I need to enable "Use replacement tokens from the first row" and only then is a string such as {{ ('My string.'|trans) }} translated.

The update to SQLite 3.45 in Drupal 11 can be a challenge, see Document or fix Drupal Quickstart command #7348.

Both https://www.drupal.org/download → and in the docs → use more memory (memory_limit=256M), so maybe that takes care of it?

I use DDEV to run quick-start, but am facing difficulties currently ... see Document or fix Drupal Quickstart command #7348.

The update to SQLite 3.45 in Drupal 11 is a challenge, see Document or fix Drupal Quickstart command #7348.

Thanks, it would be great if you shared a link.

That would be an interesting feature, but since HTTrack is a scraper, if the feature was added, this project could almost consider expanding its scope and name to https://www.drupal.org/project/bot_blocker → ? Scrapers can cause a lot of extra traffic, which might be a strain, even for web sites without facets.

Thanks @opi, should status here be "Needs review" as well?

ressa → changed the visibility of the branch 2.x to hidden.

Fantastic news @opi! This issue might be closed for good, and hard or not possible to reopen, so I created a new issue ✨ Add support for custom headers Active . Perhaps you can add the MR there? Thanks!

ressa → created an issue.

First the good news, the feed validates:

Congratulations!

[Valid RSS] This is a valid RSS feed.

https://validator.w3.org/feed/check.cgi?url=https%3A%2F%2Fcolan.pro%2Fta...

But the last Drupal post is from 2020 ... Maybe you can create a Drupal article or two, and change status to review, when published?

I am looking forward to seeing your posts, especially about Aegir on Planet Drupal.

You're welcome, I am glad I could help! As a bonus I finally understood somewhat what the requirements are for block placement inheritance :)

Have you tried turning on Twig debug for template name suggestions, to see lines like these in your source code?

<!-- FILE NAME SUGGESTIONS:
   ▪️ block--mytheme-views-block--machine-name.html.twig
   ▪️ block--views-block--machine-name-muni-machine-name.html.twig
   ▪️ block--views-block.html.twig
   ▪️ block--views.html.twig
   ✅ block.html.twig
-->

To quickly turn it on you can use the new (Drush 13.6) theme:dev command:

Toggle Twig debug, caching and CSS/JS aggregation with Drush

The easiest method to enable Twig debugging, turn off caching and CSS/JavaScript aggregation and clear caches is with the theme:dev Drush command, added in Drush 13.6:

• drush theme:dev on
  Disables caching, CSS/JS aggregation and enables Twig debugging.

• drush theme:dev off
  Enables caching, CSS/JS aggregation and disables Twig debugging.

When enabled:

• Disables render cache, dynamic page cache, and page cache.
• Enables Twig debug mode (e.g., dump() function, template suggestions).
• Disables Twig cache (templates always recompiled).
• Disables CSS and JS aggregation.
• Clears all caches.

See also the Drush theme:dev command documentation page.

Drush 13 requires PHP 8.3 or higher.

To use the same functionality on lower PHP versions, refer:  Custom Drush command for managing Twig debugging and CSS/JS aggregation →

From https://www.drupal.org/docs/develop/development-tools/disabling-and-debu... →

For even more suggestions, install https://www.drupal.org/project/twigsuggest → -- though in your case, it might not add anything useful (same block as above):

<!-- FILE NAME SUGGESTIONS:
   ▪️ block--views-block--content.html.twig
   ▪️ block--views--content.html.twig
   ▪️ block--content--mytheme-views-block--machine-name.html.twig
   ▪️ block--content.html.twig
   ▪️ block--mytheme-views-block--machine-name.html.twig
   ▪️ block--views-block--machine-name-muni-machine-name.html.twig
   ▪️ block--views-block.html.twig
   ▪️ block--views.html.twig
   ✅ block.html.twig
-->

Add tip that rendering twice may be needed for InvalidArgumentException: $string ("Array") must be a string errors.

I got it to work for field labels as well, by rendering the title value in /claro/templates/form-element-label.html.twig twice, before translating it:

<label{{ attributes.addClass(classes) }}>{{ title|render|render|trans }}</label>

This trick is also mentioned on the doc page:

You may have to render an item before you filter it:
{{ item|render|filter }}

https://www.drupal.org/docs/develop/theming-drupal/twig-in-drupal/filter... →

I updated the documentation pages:

• https://www.drupal.org/docs/develop/theming-drupal/sub-theme-inheritance →
• https://www.drupal.org/docs/develop/theming-drupal/creating-sub-themes#s... →

Update "Block placement" text to "See Inheriting Block Placement → " which has links.

Clarify the gotcha of why sub-theming an admin theme needs the config folder -- since it's not the default theme.

Add note under "Inheriting Block Placement" that you may sometimes need to copy over the /config folder.

Add note about inheriting Block placement, and that you may need to copy over /config folder as well.

I can confirm this, and that copying over and editing the config folder is a workaround. I am adding the issues where this will be fixed in.

About inheriting block placement, the issue 🐛 Extending Claro theme not inheriting Claro blocks Active has a solution.

Twig format_number would be an awesome feature to have. It would be so much easier to just wrap a number in that formatter for Thousand and Decimal separator, while we wait for contrib modules and Drupal core issues, which may take some time to be completed ...

I was looking for a method to separate a field's content, suffix and prefix values, to be able to translate suffixes, so thank you very much for sharing a method @webmestre!

Just to clarify to others finding this issue, there is no need for any extra Twig module to get separate content, suffix and prefix values. Just adds this in for example field.html.twig file (tested in Bootstrap5 → ):

{# get prefix and suffix #}
{% set prefix = element['#items'].getFieldDefinition().getSetting('prefix') ?? '' %}
{% set suffix = element['#items'].getFieldDefinition().getSetting('suffix') ?? '' %}

... and you can use the prefix and suffix elements like this:
{{ suffix|trans }}

I just remembered the two Twig contrib modules, and there was a solution for separating a field's content, suffix and prefix values.

Removing quotes, since you don't need to quote a string, as long as the first character is not a special character. For more, see 📌 Remove quotes from olivero.info.yml Fixed .

I ran into this error when trying to translate as much as possible via .po files, by exposing strings as translatable Twig elements. But suffix wasn't translatable in a Bootstrap5 based theme (bootstrap5/templates/form/form-element.html.twig):

With <span class="field-suffix">{{ suffix|trans }}</span> I got:

The website encountered an unexpected error. Try again later.
InvalidArgumentException: $string (" kr. per m²") must be a string. in Drupal\Core\StringTranslation\TranslatableMarkup->__construct() (line 132 of core/lib/Drupal/Core/StringTranslation/TranslatableMarkup.php). t() (Line: 100) __TwigTemplate_d423ca3a82915c4d447ecaf81034

On the other hand, this works fine for Block titles (bootstrap5/templates/block/block.html.twig) and Field names (bootstrap5/templates/field/field.html.twig):

Blocks:
<h2{{ title_attributes }}>{{ label|trans }}</h2>

Fields:
<div{{ title_attributes.addClass(title_classes) }}>{{ label|trans }}</div>

Great, thanks @adriancotter! Though, it would be great to get it working, since like you write there can be quite a lot of tables ... Hopefully someone has a suggestion at some point. (Also restoring a drush I left out).

ressa → created an issue.

Thanks for creating the issue and adding the patch. I am new to the Configuration Translation module, so I have a difficult time seeing how I can reproduce the problem, and verify if the patch solves it ...

Perhaps you can add more details to the steps in the Issue Summary? Like, under which paths are some of the operations done, what string or change is expected where, and what is actually seen? Perhaps adding a few screendumps can be most effective for some parts ... ? Thanks!

Thanks @adriancotter, there can be a lot of tables after that process, so this is a great tip. I think it's best to use full commands in documentation, so it's clearer for users unfamiliar with the command.

I tried the drush sql:query "DROP TABLE [...] command, but it only seems to drop a single table at a time ...:

~/dev/drupal$ drush sql:query "show tables like 'migrate_%'" | while read TABLE ; do
  echo "Dropping $TABLE" && drush sql:query "DROP TABLE $TABLE"
done
Dropping migrate_map_content
~/dev/drupal$

Does it work for you?

Thanks for the updates @daddison, the page now reads easier.

Just changing info text in the beginning to use an info box.

ressa → created an issue.

I also saw this when I tried the very cool api.drupal.org install script https://git.drupalcode.org/project/api/-/blob/2.x/demo/api-demo.sh and got the error three times:

[Error] GuzzleHttp\Exception\ClientException: Client error: `GET http://doc.php.net/downloads/json/php_manual_en.json` resulted in a `404 Not Found`

It's so great to see the suggestions in 📌 Remove Drupal 8.9.x and Drupal 9.5.x from api.drupal.org and redirect to 10.3.x or 11.x Active got implemented, and old API doc pages (https://api.drupal.org/) are now linked to the latest version :)

ressa → created an issue.

I created ✨ Allow export filtering, for example to include customized configuration translations Active .

ressa → created an issue. See original summary → .

I was looking for a way to not export all the configuration translation, and this works perfectly, thanks @svendecabooter!

At first, I thought that adding the "Export options" for interface translation (/admin/config/regional/translate/export) could be added, i.e.:

Export options

• [ ] Include non-customized translations
• [ ] Include customized translations
• [ ] Include untranslated text

But that could be addressed in another issue.

ressa → made their first commit to this issue’s fork.

This is great, both that there is a module which offers export and import of translated configuration, but also that a Drush command is close to being available.

The patch worked well for me (I created an MR to get a patch to test) the only thing I would suggest is perhaps add a few examples, like there is in the locale:export and locale:import commands?

EXPORT

$ drush locale:export -h
Exports to a gettext translation file.

See Drupal Core: \Drupal\locale\Form\ExportForm::submitForm

Examples:
 drush locale:export nl > nl.po                           Export the Dutch translations with all types.       
 drush locale:export nl --types=customized,not-customized Export the Dutch customized and not customized      
> nl.po                                                   translations.                                       
 drush locale:export --template > drupal.pot              Export the source strings only as template file for 
                                                          translation.                                        

Arguments:
 [langcode] The language code of the exported translations. 

IMPORT

$ drush locale:import -h
Imports to a gettext translation file.

Examples:
 drush locale-import nl drupal-8.4.2.nl.po     Import the Dutch drupal core translation.                           
 drush locale-import --type=customized nl      Import the Dutch drupal core translation. Treat imported strings as 
drupal-8.4.2.nl.po                             custom translations.                                                
 drush locale-import --override=none nl        Import the Dutch drupal core translation. Don't overwrite existing  
drupal-8.4.2.nl.po                             translations. Only append new translations.                         
 drush locale-import --override=not-customized Import the Dutch drupal core translation. Only override             
nl drupal-8.4.2.nl.po                          non-customized translations, customized translations are kept.      
 drush locale-import nl custom-translations.po Import customized Dutch translations and override any existing      
--type=customized --override=all               translation.                                                        

Arguments:
 langcode The language code of the imported translations.                                     
 file     Path and file name of the gettext file. Relative paths calculated from Drupal root. 

It doesn't have to be as many examples, but 2-3 maybe? Also, I think the odd path situation should be mentioned, where the two commands are "rooted" -- for export in the current folder, but import uses /web.

I added a new section "Deploying Drupal interface translations with Drush" on "Translating site interfaces" the other day, and a similar section for
"Translating configuration" just now, since I could have really used a mention, when I visited that page the other day. Perhaps they can be used for inspiration?

• Translating site interfaces →
• Translating configuration →

Add link to Translating configuration > Deploying Drupal configuration translations with Drush → .

Add link to Interface translations page.

Add tip about contrib module  Config Translation PO → .

I looked a bit more, and found a module which does exactly what I am looking for, called https://www.drupal.org/project/config_translation_po → :)

I just created a web site with two languages, and I love how with Drush, I can export a .po file which contains all the translations with relates to strings in modules and themes, wrapped in t('my string') or Twig strings with {{ 'String'|trans }} ("interface translations").

This not only makes it easy to move translations, but I can also bulk edit multiple strings directly in a single export file. (See the section "Deploying Drupal interface translations with Drush" on https://www.drupal.org/docs/administering-a-drupal-site/multilingual-gui... → )

But for configuration translation, it looks like you need to open each block, each view field, each content type field etc. one by one and manually add the translation ...

It would be great if configuration translation was also exportable and importable, the same as interface translation. This would allow us to translate all strings in a single file, if we want to add a new language.

Is a .po file solution for config translation something this module could consider offering, or maybe another module offers this? Thanks!

Congratulations, I am glad I could help! 🎉 Feel free to add [Solved] first in the title, like here → .

Just a correction to my previous comment. I verified that it works, but you need to use "Taxonomy term: Term ID (Default: Taxonomy term ID from URL)". Good luck!

Great that you got another Drupal instance up and running, for testing :)  (... This takes 1 minute in DDEV, just saying.)

And your finding is exactly why I recommended that you get a fresh instance, for comparison.

About getting a term description in a block, can't you just create a "Taxonomy terms" View, add the "Taxonomy term: Description" field, and add a contextual filter, using "Provide default value" and "Raw value from URL"?

That's totally all right, I think I just wasn't sure what to look for ... And each taxonomy has its own Display page (/admin/structure/taxonomy/manage/tags/overview/display), so what you are looking for should be possible.

But it certainly looks to me as if Descriptions are shown under a Tag by default, like under /taxonomy/term/1.

If you haven't yet gone the DDEV route, and now able to create a fresh Drupal installation, perhaps use https://simplytest.me/ to get a working proof of concept?

1. Create a fresh site
2. Create an article with a tag
3. Edit the tag and add description
4. Go to /taxonomy/term/1 and see the description

Do you see it?

Yeah, I was headed out so it was brief. I left out this: "Now I get description under the tags, when viewing an article".

I think you should try to write in a brief sentence or two, how and where you want to show tags with descriptions.

I got the description to show by updating the content type Display page (For Article, /admin/structure/types/manage/article/display):

From: Label -- Link to the referenced entity
To: Rendered entity -- Rendered as Default

Thanks @anybody for sharing how to set up a View up correctly to filter for current language in Drupal 10 Views: Only show items in current (content) language! (which is where I found this issue) It's not intuitive, and your article helped me a lot.

I tried using "Original language" as filter (though that didn't also make total sense ...) but the solution was simply to use "Default Translation: True" as filter, and I got the expected result.

Sounds great, I am looking forward to reading your articles on Planet Drupal :)

Feel free to change status to Needs Review as soon as there are more article(s) published, because then you fulfil the requirements of recent content, and your feed can get included.

The two articles look very interesting, but are from Nov 2024 and May 2025, so maybe you can write some more articles?

Just an observation: The default language in my installation is English (under /en), with Danish as the other language, without language prefix (under /) like this:

1. Add Danish language in an existing English installation
2. Open "URL language detection configuration" (/admin/config/regional/language/detection/url)
3. Update "English (en) path prefix (Default language)" to en
4. Remove da under "Danish" and click Save
5. Get message about "The prefix may only be left blank for the selected detection fallback language → ."
6. Open link in new window and set "Language" to Danish
7. Go back to "URL language detection configuration" which can now be saved

The default language is now Danish at example.com (English is under example.com/en) and I get the text "Velkommen!" on the front page.

From Use URL language detection configuration? →

It mostly works, but sometimes, the system somehow gets stuck in its old ways, and only English labels get indexed ... I tried many things like clearing cache, rebuilding Solr index, etc., but this is what seems to work:

Open the edit form for a node under Danish (/node/259/edit), and see English translated field names. If I then clear caches, Drupal "wakes up" and realizes there is a default language (/en), but the fallback language in the current page is Danish. The fields are now rendered in Danish, and now, when I index, the correct translated field labels are used in the rendered HTML fields, in the Solr index content.

I am not using this module, but indexing multilingual nodes in Search API Solr, with default language English (under /en), and Danish as second language, set as fallback language, without language prefix (under /), for Rendered HTML in Search API Solr.

I tried many things like clearing cache, rebuilding Solr index, etc., but this is what seems to work:

I open the edit form for a node under Danish (/node/259/edit), and see English translated field names. If I then clear caches, Drupal "wakes up" and realizes there is a default language (/en), but the fallback language in the current page is Danish. The fields are now rendered in Danish, and now, when I index in Solr, the correct translated field labels are used in the rendered HTML fields.

I have some more comments about the subject in the referred issue, the patch enables indexing of rendered HTML.

Thanks for the suggestion @anybody! I have added it in the Issue Summary to highlight your great initiative.

Though that also seems to include number manipulation (such as rounding), which could add complexity, whereas the scope here is purely presentation, and visualizing numbers by defining Thousand and Decimal separators ... But if the added features are not blockers, it's no problem. Also, I do see the benefit of thinking more holistically about it, though that may also cause an issue to balloon, and get bikeshedded. It's a balance :)

Thanks for clarifying the support options @quietone.

However, in the new design under https://new.drupal.org/ there is no link to Get support ( https://www.drupal.org/support → ), so the Drupal Forum ( https://www.drupal.org/forum → ) will be even less likely to be found. On the other hand, the proprietary system Slack has a direct link, and it is not ideal to funnel all support into a single container, since solutions shared in Slack will eventually disappear, cannot be found in search engines, etc.

Conversely, solutions shared on our own platform (in the Forum) will stay forever, and can be found on the internet.

Thanks for the reminder, the updates did also fix this bug, so closing the issue.

Great that you got it working. Getting Drupal to do as you want, can be challenging, where you have to try different things, until you finally find a solution.

_-_

I updated the Issue Summary ✨ Allow localizing of formatting on decimal fields Active , trying to summarize the latest comments here. Feel free to correct if anything is wrong, or unclear :)

And great suggestion @rkoller about adding support for user profile page as well, which I included in the Issue Summary.

.... or should parts of the Issue Summary from #2757111 (mainly "Proposed resolution", I guess) be moved to this issue, to keep it all in one place?

Updating Issue Summary based on great discussion in ✨ META: Provide locale (regional) formats framework for automated translation of non textual data Active .

Thanks for the feedback @xmacinfo and @rkoller. Placing the settings on the Regional settings page does sound like a better idea. The reason I suggested under Fields settings, is because prefix and suffix are also placed there, and they are all about presentation, right?

(Perhaps prefix and suffix ought to be moved to the Display tab? :) ... That's for another issue.)

I am still just a casual user of languages in Drupal, and don't know the details about language/locale, and don't have the larger picture of how it all ties together. But as long as I -- as a site builder -- can easily for each language, select from a drop-down settings, which results in for example thousand separator being dot (".") for Danish and (",") for English, and set a field display to use these localized separators depending on display language, that would work for me.

And thanks for the image, a possible inspiration for format/number/localization set up for each language in Drupal, that would work well. And having the option of not using the normal defaults for a language would be a nice feature, and the ideal set up.

So, it seems like these could be changes in the interface:

• Set custom separators for each installed language (da, en, fr, etc.) as in the image from #62 (I do only see the default language on that page ...)
• Allow setting which separator to use under Display (as it is currently) having the options "Decimal point", "Comma", etc. and then add >> "Default for display language"

That's a great idea @jigaurus! I suggested in another (duplicate?) issue, to move it from Display page to the Field settings page, as en extra option:

Perhaps move the "Thousand marker" and "Decimal marker" settings from the "Manage display" page (/admin/structure/types/manage/article/display) to the field settings page? (/admin/structure/types/manage/article/fields/node.article.field_number), and live together with similar setting options, such as prefix and suffix ?

It could be an option the user can select, where either a global character is used, or a language specific. The current select options could be updated to this:

Thousand marker

• - None -
• Decimal point
• Comma
• Space
• Thin space
• Default for display language <<< Add this option

Decimal marker

• Decimal point
• Comma
• Default for display language <<< Add this option

You're welcome, but you really ought to do yourself the favour of getting DDEV up and running, so you can create and destroy new Drupal installations, without hesitation.

Otherwise, it may slow down your learning speed, since you will fear that changing something may cause Drupal to break down ... If conversely, you tinker, experiment, fail and start over in DDEV (or Lando), knowing that you can always start over in seconds, you will gain routine and confidence.

Anyway, it doesn't work when we're not logged in, because the path needs to be accessible for the user (See my previous comment: "where /my-page need to exist:"). I used /user/1 since that path exists in a fresh install ...

But I had a closer look, and it does look like the Ajax JavaScript library is not loaded in Olivero for anonymous users ...

Try this:

1. Create an Article (or just any node) with path /node/1
2.  Add Ajax library in Olivero by adding - core/drupal.dialog.ajax in web/core/themes/olivero/olivero.info.yml like this:
   

   [...]
   libraries:
     - olivero/global-styling
     - core/drupal.dialog.ajax
   [...]

3. Add this in web/core/themes/olivero/templates/layout/page.html.twig:
   

   <p><a class="use-ajax" data-dialog-type="modal" href="/node/1">Modal</a></p>

4. Clear caches, and check that the number of .js libraries goes up from ~10 to ~50 in the source

Anonymous users should now get a popup, when they click on "Modal".

Try creating a fresh installation, add the next line, log in as admin, and verify if it works or not, and take it from there:

<p><a class="use-ajax" data-dialog-type="modal" href="/user/1">Modal</a></p>

Add in this file: web/core/themes/olivero/templates/layout/page.html.twig

You don't need to read the entire page ... Like I wrote, I just tried entering the line I shared, and I got a popup. Sorry the last line was unclear I have added missing bits.

I got the "Migration did not meet requirements" error while importing translated nodes. In my case it had nothing to do with caching, but I am sharing the cause and solution here anyway, in case anyone else searches and finds this issue, like I just did.

It turned out there was a duplicate id, which caused a required migration (locations) to not complete:

$ drush migrate:status
 ------------------- -------- ------- ------------- -------------
  Migration ID        Status   Total   Imported      Unprocessed
 ------------------- -------- ------- ------------- -------------
  locations           Idle     796     795 (99.9%)   1
  locations_en        Idle       0     796 (0%)      796

I got the requirement error when I tried to run with --all --execute-dependencies or partial test migrations with locations_en:
drush migrate:import locations_en --limit=5 --migrate-debug

After fixing the duplicate id, the locations migration completed to 100%, and I could run partial locations_en test migrations, or full.

This page looks like it might have some info: https://www.drupal.org/docs/develop/drupal-apis/ajax-api/ajax-dialog-boxes →