Translations in third party plugins

[scofalik]

I create this issue to open up a discussion about 3rd party plugins internationalization.

CKEditor 5 uses Transifex for translations handling. The translations are downloaded and built during editor build and then available in language files.

The problem appears when a non-core plugin is developed by an outside developer. AFAIU there is no way to easily make the plugin ready for different translations.

What can we do with this?

[Reinmar]

Related: https://github.com/ckeditor/ckeditor5/issues/763

[ma2ciek]

As I already wrote on the Gitter channel we provide 3 options for now (and all of them aren't perfect though).

1. A developer can add translations creating a repository with similar structure to our repositories, so the source code will match this regExp: /[/\\]ckeditor5-[^/\\]+[/\\]src[/\\].+\.js$/. Then all he needs to do is to create the .po file for each language and store it relatively to the repository root in the lang/translations/<LANGUAGE_ID>.po. This will work with a single language and multiple languages, so when multiple languages are used in the webpack configuration for that plugin, then for all of t() calls containing regular and custom translation keys their corresponding translations will be stored in the build/translations/<LANGUAGE_ID>.po files. It will also work with defined by us core translations. IMO, the disadvantage is that this approach requires creating many PO files.

2. Using the add method from the translation-service. This will increase the build size because all translations will be bundled to the build.

3. Adding translations before or just after the <script src="ckeditor.js"> script. This way a developer needs to write what internally is done inside the add method from the previous way. The advantages are that it doesn't require rebuilding the editor and it can also be optimized so for one language the developer can add only one translation file with translations for only that language.

[ma2ciek]

The 2nd and 3rd approach don't make sense if the CKEditorWebpack plugin is used :man_facepalming:. The translation string are changed to ids during the building process for multiple languages. Thus the translation-service can't be feed with the proper ones as they are generated during the building process.

[ma2ciek]

I'd raise the priority of this issue because we gonna add the i18n to the private plugins soon. The additional problem that we'll need to handle is the lack of translations for private packages available on the Tx.

The other issue is that currently there's no way to override an existing translation (AFAIR there was some request for it in the past)

Also, this should enable easier testing of the i18n

The solution I propose is to add a possibility to add translations to the CKEditor5WebpackPlugin directly, either as a path(s) to the translation files or as a map of translations like: { pl: { 'Cancel': 'Anuluj' } }.

Bear in mind that at some point we might gonna add support for plural forms but in case of plural forms, we could support arrays of possible translations like { pl: { 'Change %0 elements': [ 'Zmień %0 element', 'Zmień %0 elementów' ] } }.

Alternatively, we could add support for loading additional PO files. Not sure which one will provide the best DX.

cc @Reinmar

[CKEditorBot]

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

[CKEditorBot]

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may still be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.