Get rid of managing the unique translation string keys manually by using auto-generated ids for UI translation strings #17331
MurzNN
started this conversation in
Feature Requests & Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
For now, to create a new component with translatable strings for the Payload CMS admin panel, we need to invent a short clear unique key for each string, and add them manually to the huge vocabulary file like https://github.com/payloadcms/payload/blob/main/packages/translations/src/languages/en.ts
This is very inconvenient from the developer experience and not flexible at all! A much more modern and convenient way is defining the translation strings as values directly in the components where they are used! This approach is supported by a great library Lingui - you can learn the benefits of this approach on the page https://lingui.dev/guides/explicit-vs-generated-ids
So, switching from manual translation implementation to Lingui will make development much more easier and extendable! And, because we put the target strings in English inline directly in the code, all the code will work out of the box even without any vocabularies by displaying the English values as a fallback!
And this is not the unique Lingui approach, many other projects use the same model "source string as a translation key" without suffering to invent a new unique key for each new translation string, for example, Drupal CMS.
Also, it will significantly simplify creating translatable plugins, blocks and other components for Payload CMS, because they will contain all the translation source strings directly inside the component files.
All reactions