Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Translations in third party plugins #1471

Closed
scofalik opened this issue Jan 18, 2019 · 7 comments
Closed

Translations in third party plugins #1471

scofalik opened this issue Jan 18, 2019 · 7 comments
Labels
domain:i18n The issue reports a problem with internalization / translation mechanisms resolution:expired This issue was closed due to lack of feedback. squad:collaboration Issue to be handled by the Collaboration team. type:question This issue asks a question (how to...).

Comments

@scofalik
Copy link
Contributor

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
Copy link
Member

Reinmar commented Jan 18, 2019

Related: #763

@ma2ciek ma2ciek self-assigned this Jan 18, 2019
@ma2ciek
Copy link
Contributor

ma2ciek commented Jan 18, 2019

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 ma2ciek added the type:question This issue asks a question (how to...). label Jan 18, 2019
@Reinmar Reinmar added this to the backlog milestone Mar 25, 2019
@ma2ciek ma2ciek removed their assignment Mar 26, 2019
@ma2ciek
Copy link
Contributor

ma2ciek commented Jan 15, 2020

The 2nd and 3rd approach don't make sense if the CKEditorWebpack plugin is used 🤦‍♂️. 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
Copy link
Contributor

ma2ciek commented Jan 15, 2020

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

@ma2ciek ma2ciek modified the milestones: backlog, iteration 29 Jan 17, 2020
@ma2ciek ma2ciek self-assigned this Jan 17, 2020
@ma2ciek ma2ciek modified the milestones: iteration 29, iteration 30 Feb 13, 2020
@Reinmar Reinmar modified the milestones: iteration 30, backlog Mar 10, 2020
@ma2ciek ma2ciek added the domain:i18n The issue reports a problem with internalization / translation mechanisms label Apr 10, 2020
@Reinmar Reinmar added the squad:collaboration Issue to be handled by the Collaboration team. label May 25, 2020
@pomek pomek removed this from the backlog milestone Feb 21, 2022
@CKEditorBot
Copy link
Collaborator

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
Copy link
Collaborator

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.

@CKEditorBot
Copy link
Collaborator

We've closed your issue due to inactivity. We understand that the issue may still be relevant. If so, feel free to open a new one (and link this issue to it).

@CKEditorBot CKEditorBot added resolution:expired This issue was closed due to lack of feedback. and removed status:stale labels Nov 29, 2024
@CKEditorBot CKEditorBot closed this as not planned Won't fix, can't repro, duplicate, stale Nov 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:i18n The issue reports a problem with internalization / translation mechanisms resolution:expired This issue was closed due to lack of feedback. squad:collaboration Issue to be handled by the Collaboration team. type:question This issue asks a question (how to...).
Projects
None yet
Development

No branches or pull requests

5 participants