Skip to content

Add locale to the url#14432

Merged
fblupi merged 44 commits intodecidim:developfrom
i-need-another-coffee:feature/i18n-param
Dec 4, 2025
Merged

Add locale to the url#14432
fblupi merged 44 commits intodecidim:developfrom
i-need-another-coffee:feature/i18n-param

Conversation

@alecslupu
Copy link
Copy Markdown
Contributor

@alecslupu alecslupu commented Mar 31, 2025

🎩 What? Why?

Note for reviewer below

In this PR we are changing the url structure of the content pages to support as the first parameter the locale.
The page like /processes/hereslug/f/57/elections/5 would become:

  • /en/processes/hereslug/f/57/elections/5 if seen in english
  • /ca/processes/hereslug/f/57/elections/5 if seen in catalan

All the main pages, would have a fallback, so, if someone has a link to /processes/hereslug/f/57/elections/5, it would be automatically redirected to either locale of the browser, user set locale, or the default language of the app

Note for the reviewer

There are many files that have been changed because i have got into a situation where, if i would have played with the default url attributes, i would have got links like : /en/processes/hereslug/f/57/elections/5?locale=en due to fact that we have multiple stacked engines, and each would need to use default, causing strange urls.

Is a big PR, but most of the changes are related to adding the locale parameter to various files.

📌 Related Issues

Link your PR to an issue

  • Related to #?
  • Fixes #?

Testing

  1. Checkout to this branch & boot your application
  2. Go to homepage, then start to browse the application.
  3. You will see that all the space related pages do have a locale prefix
  4. Check the platform pages ( help pages ) and see they also have a locale params
  5. You can change the locale of the website, and you will see the url and locale is changing acordingly
  6. In user profile page, all the links for resources generated by that user would have a prefix for locale

📷 Screenshots

Please add screenshots of the changes you are proposing
Description

♥️ Thank you!

Copy link
Copy Markdown
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This pull request does not contain a valid label. Please add one of the following labels: ['type: feature', 'type: change', 'type: fix', 'type: removal', 'target: developer-experience', 'type: internal']

github-actions[bot]
github-actions bot previously approved these changes Nov 23, 2025
@andreslucena
Copy link
Copy Markdown
Member

This is ready for the review @alecslupu ?

@alecslupu
Copy link
Copy Markdown
Contributor Author

This is ready for the review @alecslupu ?

@andreslucena I would say that it is ready.

github-actions[bot]
github-actions bot previously approved these changes Nov 27, 2025
github-actions[bot]
github-actions bot previously approved these changes Dec 4, 2025
github-actions[bot]
github-actions bot previously approved these changes Dec 4, 2025
Copy link
Copy Markdown
Member

@fblupi fblupi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@fblupi fblupi merged commit 9775b9f into decidim:develop Dec 4, 2025
76 checks passed
@alecslupu alecslupu deleted the feature/i18n-param branch December 4, 2025 18:01
@andreslucena
Copy link
Copy Markdown
Member

Just skimming this a bit, but is there any reason to not doing the default_url_options approach?

Because the default_url_approach will pollute all the core urls with locale query string.

Also, we have engine, in engine in engine ( decidim_meetings is mounted in decidim_participatory_process which is mounted to the decidim_core). To have working urls, i would need to patch the each engine default_url_options.

I have tried to play with the mounted_params in both components and participatory space, and did not worked correctly.

In short, i have tried it, and did not worked as i was expecting.

Answering this at #16544 (comment) - 1 year later!! You just have to wait for the good things :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants