Our current workflow involves publishing each locale one at a time this is due to us relying on an external CAT tool for localizing the content. I know we can use
to hijack publish however this would involve adding new fields if i'm not wrong? If there is an example would be happy to follow along. Thanks 🙂
FYI: We are doing two POCs one w/ Strapi and another w/ Payload.
@jmikrut @jacobsfletch Please help 🥺
hey @yhn5790 — I can give some answers here
so, Payload uses "field-based localization", and not document-level localization. Currently, there is no way to maintain separate draft / published states of different locales on a single document, because all the locales are stored on the document itself. But, as you said, this could probably be done with some new fields for sure, and though hijacking the
I do think that Payload should solve for this in an official way though. So, you've just inspired me to add this to our roadmap. I can't say that it will be completed within the next month, but I do see the importance here, so I would like to see what you end up building in the meantime until we support this officially. Keep me in the loop!
also happy to help brainstorm how to do this
is one of the features that we require and something that I love about Payload. Strapi at the moment offers this only for top level fields (but not for components (block) or dynamic zone (blocks))
In an ideal world,
in collections would be a
field. In the UI, we already have context about the current
the user is on and based on that when we publish we update the status of that locale. This could be an opt-in feature if others like the current workflow of publishing all at once
When viewing versions we repeat the same thing. We only show the drafts for the current locale (default) and if folks want to view other locale they could use the select option like how it is right now.
Not sure if this is going to mess up
For our use case, we were planning to have a
and do what I mentioned in the first part of the previous ping. I don't think i'll be able to affect the version view screen
your approach is actually what the team and i envision for this