Provide convenient interface for localization of Payload CMS i18n UI by community using Weblate or another translation tool #13361
MurzNN
started this conversation in
Feature Requests & Ideas
Replies: 2 comments
-
As an option, want to suggest integrating Mozilla's localization system - Fluent: https://projectfluent.org/ |
Beta Was this translation helpful? Give feedback.
0 replies
-
Also, Paraglide JS looks very promising, especially with the tree shaking feature! |
Beta Was this translation helpful? Give feedback.
0 replies
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.
-
For now, Payload CMS translations are located in the Git repo https://github.com/payloadcms/payload/tree/main/packages/translations and are simple TypeScript files with key-value JS objects.
As it looks easy and convenient for usage in the code, it is not convenient for translators at all!
Therefore, I suppose, not a lot of community users are involved in the translation process, because just searching for missing translations or adding a new translation string requires a lot of manual actions!
So, my appeal is to start using a web-based continuous localization tool to manage Payload CMS user interface internalization and translation strings in a convenient and manageable way.
A good candidate for this is Weblate that is opensource, copylefted, and libre. Or we can choose any other tool like Transifex, Crowdin, Texterify, Localazy, Tolgee, and others - any tool will be much better than handling of translation strings in many TS files manually! 😉
And we can configure scripts that automatically export translations from the tool to the same TS files with the same structure, so no changes from the Payload source code can be required!
This step should involve a lot of community users in the translation process to add new languages and add missing translation strings without using technical skills, just a couple of clicks in the browser. And the moderation and polling for controversial strings can be done using the community, too!
And the core development team will get rid of the burden to manage 30+ translations when adding a new translatable string to the code, just add only the main English translation, and the rest can be done by the community.
What do you think about this idea?
Beta Was this translation helpful? Give feedback.
All reactions