payload icon indicating copy to clipboard operation
payload copied to clipboard

Localized gets ignored when using groups on postgres

Open hesselberg opened this issue 10 months ago • 4 comments

Describe the Bug

Using groups inside a localized tab ignores localized for the fields in the group, only adherring to the last configured locale (in this reproduction English).

If I were to guess, looking at the payload-types all IDs are now numbers instead of strings. I'm no DB expert but this could be related somehow.

Video of the bug:

https://github.com/user-attachments/assets/59a8cfbb-32b7-452b-8256-2290f2cebaca

Link to the code that reproduces this issue

https://github.com/hesselberg/payload

Reproduction Steps

Prerequisuite: Make sure you have a running postgres db instead of the mongodb.

  1. run pnpm i
  2. run pnpm dev _community 
  3. visit http://localhost:3000/admin/collections/posts 
  4. Click the post
  5. Verify you are in the Danish locale
  6. Add text to "Heading" field, e.g. "Danish heading"
  7. Press Save. Confirm the field is blank.
  8. Switch to English locale in top right corner
  9. Add text to "Heading field", e.g. "English heading"
  10. Press Save. Confirm field is "English Heading"
  11. Switch back to Danish locale in top right corner
  12. Confirm the field is now "English Heading"

Which area(s) are affected? (Select all that apply)

db-postgres

Environment Info

Tested on both Payload 3.24.0, 3.27.0, 3.28.0
Node.JS: 21.1.0
Next.JS: 15.2.2

hesselberg avatar Mar 12 '25 10:03 hesselberg

Have you found a fix/workaround by any chance?

As a band-aid for simple cases I'm using a localized JSON field but this only works for very simple things (like groups of text fields, but not rich text, etc.), or apply localized to each nested field instead of the groups.

elierotenberg avatar Jun 15 '25 14:06 elierotenberg

I ended up not using groups and switching to collapsibles instead.. Not ideal but a workaround

hesselberg avatar Jun 15 '25 17:06 hesselberg

Additional investigation notes: it looks like having a group with localized: true actually BREAKS localization in all descendant fields (whether they are explicitly localized or not). However, when NO group is localized, adding localization to individual fields works.

elierotenberg avatar Jul 07 '25 12:07 elierotenberg

any update on this one?

giorgiPapava avatar Dec 02 '25 12:12 giorgiPapava

We've been able to reproduce this bug and found a specific trigger:

Setup:

  • PayloadCMS v3.54 with @payloadcms/db-postgres
  • A Global with a group field that has localized: true
  • Localization config ['de', 'en', 'hu'] with defaultLocale: 'de' and fallback: true

Root cause:

The bug occurs specifically when multiple locale entries exist in the _locales table for the same parent record.

  • Fresh database with only 1 locale entry (de) → saving works fine
  • After switching to other locales (en, hu) and saving → additional entries are created in _locales table
  • From that point on, saving on the defaultLocale (de) breaks silently - no errors, but data is not persisted
  • Other locales (en, hu) continue to work

Database state comparison:

-- Working (fresh seed): single locale entry
SELECT * FROM global_settings_locales;
-- id | _locale | _parent_id | ...
-- 1  | de      | 1          | ...

-- Broken (after saving in multiple locales):
-- id  | _locale | _parent_id | ...
-- 118 | de      | 1          | ...
-- 119 | en      | 1          | ...
-- 120 | hu      | 1          | ...

Workaround:

Remove localized: true from the group and only localize individual fields that actually need it.


In the docs of the group field it says specifically https://github.com/payloadcms/payload/blob/92dcb836b680b9685f8c9e2355c3bc138c992098/docs/fields/group.mdx?plain=1#L47

jancbeck avatar Dec 10 '25 13:12 jancbeck