The future of Payload localization and routing #4004
HarleySalas
started this conversation in
Feature Requests & Ideas
Replies: 1 comment 1 reply
-
You may want to check out next-intl for that. It supports locale detection and redirects. You can generate localized pathnames at build time or dynamically. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I understand that many plugins, such-as
@payloadcms/plugin-nested-docs
will be improved and addressed in the near future.However, I wanted to take the time to chime in and mention some of the things that I think should be considered when moving forward with nested documents and/or pages in general.
A fully localized application (for good SEO and user experience) means translating all slugs and pathname urls, completely.
Currently, I understand the structure of /payload/templates/website, however, you can see that some of those paths, such-as
posts
orprojects
are hardcoded and in a scenario where you're trying to build a fully localized website, that isn't acceptable.In my websites right now, I am using hooks to generate a
slug
, as well as a fullpathname
for eachPage
that I create. Another problem with this, depending on how you do routing for your localized pathnames, is that a user might receive a link to your website with/sp/spanish/pathname
, but their language is English and they wish to visit the English version, so they may modify the path before even visiting your site, to/en/spanish/pathname
and with that localized pathname, at least for the way I'm doing it now would create an issue. I understand there are ways to resolve this. However, I think Payload could do many things to make the process of routing and localization easy for any scenario.Especially since the future of Payload is leaning in to NextJS, I really think you should aim to achieve some sort of feature parity with the next app router. What about taking advantage of nested layouts? Unless we hardcode things, I'm not sure how we can really take advantage of those sort of things.
What if we could have a setup similar to nested docs now, where blog posts would be under a separate posts collection, but we could create a
template
page in our Pages collection? I think there are many scenarios where the data structure is consistent, but the page design, or components would want to be changed. I can see myself wanting to have aProducts
collection for example, where I record all of the data about my product, but a product template in my pages, where I would then be able to plug that data in to different fields.I understand the level of complexity is quite a bit, but if you can accomplish:
I genuinely believe it would be a major factor towards substantial growth of Payload. If those things can't all be achieved via the payload core package, or an official plugin, I think there should at least be an effort to publish more documentation, or learning materials for accomplishing these things.
I'd love to hear some other thoughts as well, or even perhaps how some of the issues I brought up can be resolved. It'd be really nice to know what the position of the Payload team is on these topics, to know if these sort of things are on the map and how much of a priority they may, or may not have.
Beta Was this translation helpful? Give feedback.
All reactions