Feature Request: Support Non-ascii Characters in Label for GraphQL Schema #124
Replies: 9 comments
-
@gtolarc Can you provide your collection so I can better understand? I tried testing with a collection with a field that has: |
Beta Was this translation helpful? Give feedback.
-
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
}
}
}``` |
Beta Was this translation helpful? Give feedback.
-
A problem occurs in the collection and relationship fields. Here is sample code. @DanRibbens
|
Beta Was this translation helpful? Give feedback.
-
Hi @gtolarc — I'd like to know about what you think in regards to the following solution. Within our This way, we could support localized field and collection labels by simply falling back to the What do you think? |
Beta Was this translation helpful? Give feedback.
-
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) |
Beta Was this translation helpful? Give feedback.
-
You got it. We'll get this enhancement worked up and then revise the docs accordingly. Thanks for bringing this up! |
Beta Was this translation helpful? Give feedback.
-
I started looking in to this and I'm wondering, why not use the slug instead of label for graphql all the time? |
Beta Was this translation helpful? Give feedback.
-
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? |
Beta Was this translation helpful? Give feedback.
-
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); |
Beta Was this translation helpful? Give feedback.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions