Replies: 5 comments
-
@tisonkun thanks for raising this up! If Crowdin does not work well with Pulsar, it makes sense to choose another open-source CAT tool rather than git/markdown since CAT can improve overall efficiency with various benefits/features like:
|
Beta Was this translation helpful? Give feedback.
-
Yes, agree with this. For the CAT tools, we can have some great candidate tools, such as:
Both of them are adopted by some well-known open source projects. We can take them as references. |
Beta Was this translation helpful? Give feedback.
-
Crowdin brings a lot of problems, sometimes, it breaks some tag structures in MDX, and these are even unpredictable, problems occur frequently. From a technical point of view, I think it is better to use git to manage translation documents and to participate in translation in the community. The people should be more developers, and |
Beta Was this translation helpful? Give feedback.
-
@tuhaihe @Anonymitaet @urfreespace Thanks for your feedback. To prevent spreading discussion to the next solution of translation, I update the topic as "Archive Crowdin-based translation initiative" since an initiative without further contributors and no maintainer to shepherd can be archived instead of left alone. Whether CAT is a better choice or Crowdin can be added back later should be another topic. Now we archive a stalled initiative to avoid current build issues. |
Beta Was this translation helpful? Give feedback.
-
Par for the course when using Crowdin. There are no (?) successful libre software translation efforts on Transifex, but there are plenty on Weblate. |
Beta Was this translation helpful? Give feedback.
-
Motivation
Three years ago we created the pulsar-translation repository to try to handle documentation translation with Crowdin.
However, after three years, few (if not none) contents gets translated:
As we migrate the official site to the new framework, several incompatibility issues occur between Crowdin and MDX files. Basically, MDX is far more fruitful to insert JSX code or widget, like:
Crowdin treats
tip
here as a translatable item and mangles the result.@urfreespace can have more inputs on this kind of issue that can break the website build. And after a failed full build yesterday we already redirect all "i18n" pages to the default language.
Generally, an initiative without further contributors and no maintainer to shepherd can be archived instead of leaving alone.
Proposal
Crowdin is good for document workers that they will be familiar with. But most translation contributors should be developers for our project, just like Flink. For these people, Git is over Crowdin.
Also, Crowdin itself doesn't complete the whole i18n story. Technically, we use Docusaurus's i18n functionality and generate files under
i18n
folders from Crowdin inputs with homemade scripts.So, we can use Docusaurus's i18n support barely as how InLong does to overcome these issues.
Implementation
Risk
No risk as these translations currently simply don't work.
Appendix
Docusarus does provide support to integrate with Crowdin and talk about MDX workaround. But it's less than awesome while we don't need Crowdin in the first place. Also, this workaround cannot resolve the case that we write descriptions needing translation in the MDX block, like prompts for Tabs.
cc @tuhaihe @urfreespace @michaeljmarshall @dave2wave
Beta Was this translation helpful? Give feedback.
All reactions