Would moving localisation to its own collections similar to versions reduce fear of migration?
Currently if we want to migrate a field that is not localized before, we have to write a script to migrate so as to not lose data. What if we do localisations similar to versions where a new collection is created or new record is created within the same collection?
I assume we can do a similar approach for variants too?
https://discord.com/channels/967097582721572934/1132826511280459876I am new to payload, so exploring options on how to do several things. I am newbie so I might not have full context on these things so please excuse my navieness
Hey @mailaneel I think @denolfe or @dribbens might be able to lend a hand here. I'll surface this and we should be able to get you some answers. Hold tight!
We're working on changes to both localization and migrations so this question comes at an interesting time!
Migrations will be available so that you have a way of dealing with the moving of existing data as your config evolves.
I think that alone should be enough to provide a good path forward, but there might be more we can do to simplify this as we go into our localization (roadmap item)[
https://github.com/payloadcms/payload/discussions/1234].
It might be that when adding localization where data exists we could simply use the existing string value instead of dropping the value if it isn't an object.
As for handling localization in the same pattern as versions, I'm not sure exactly on this idea.
With how we plan to do this in relational databases, if I understand what you're suggesting, we are working towards doing this right now. For MongoDB, I don't think it makes as much sense.
Thanks that makes sense,
It might be that when adding localization where data exists we could simply use the existing string value instead of dropping the value if it isn't an object.
Continue the discussion in Discord
Star
Discord
online
Get help straight from the Payload team with an Enterprise License.