Problems creating gql schema when using non-ascii characters in label

[gtolarc]

I am using i18n library to translate label. In this case, there is a problem in creating the gql schema. Perhaps the code below is relevant.
https://github.com/payloadcms/payload/blob/master/src/graphql/utilities/formatName.ts#L3

In my opinion, the label is the right thing to use for the part that is usually displayed. It would be nice to change it to create the gql schema internally using slug or name.

[DanRibbens]

@gtolarc Can you provide your collection so I can better understand?

I tried testing with a collection with a field that has: slug: 'löwen'. It looks like graphql explorer doesn't allow non-ascii. Is that similar to what you're trying to trying to do?

[DanRibbens]

I was able to test with a label that has non-ascii and it did seem to work.

const Lowen: CollectionConfig = {
  slug: 'lowen',
  admin: {
    useAsTitle: 'lowen',
  },
  access: {
    read: () => true,
    update: () => true,
  },
  fields: [
    {
      name: 'lowen',
      label: 'Löwen',
      type: 'text',
    },
  ],
  timestamps: false,
}

mutation CreateLowen {
  createLowen(data: {
    lowen: "gql create lowen"
  })
  {
    lowen,
    id
  }
}

query ReadLowens {
  Lowens {
    totalDocs
    docs {
      id
      lowen
    }
  }
}```

[gtolarc]

A problem occurs in the collection and relationship fields. Here is sample code. @DanRibbens

const Users: CollectionConfig = {
  slug: 'users',
  labels: {
    singular: '사람', // This is the Korean translation of user/users. The problem arises here when building gql schema.
    plural: '사람들'
  },
  fields: [
    {
      name: 'name',
      label: '이름',
      type: 'text'
    },
    {
      name: 'group',
      label: '그룹', // Also problem occur..
      type: 'relationship',
      relationTo: 'groups'
    }
  ]
};

[jmikrut]

Hi @gtolarc — I'd like to know about what you think in regards to the following solution.

Within our formatName function, we could check to see if there are non-ASCII characters within the labels. If there are, we could fall back to either the slug of a collection, or the name of a field - and use those fields instead of the labels themselves.

This way, we could support localized field and collection labels by simply falling back to the slug or name.

What do you think?

[gtolarc]

Looks good! And it would be nice if the document explains which properties of CollectionConfig are converted to gql query name and mongodb collection name. (with conversion rule)

[jmikrut]

You got it. We'll get this enhancement worked up and then revise the docs accordingly.

Thanks for bringing this up!

[DanRibbens]

I started looking in to this and I'm wondering, why not use the slug instead of label for graphql all the time?

[jmikrut]

Because best practice within GraphQL is to be as semantic as possible while naming your queries and mutations. And.. we need both singular and plural type names. So, our current use of singular and plural labels to name GraphQL types is ideal and better than automatically pluralizing or "singularizing" slugs. That should be the fallback, while being explicit should be the default IMO. Thoughts?

[DanRibbens]

Alright, I'm good with that. We can use this function to check for ascii and use the fallbacks described.

export const hasNonAscii = (value: string): boolean => /^[\u0020-\u007f]*$/.test(value);