Globalization

[fredck]

How we gonna implement internationalization into CKEditor 5 and what localization features we want to provide?

Short answer: the same as in CKEditor 4, just having all tools in node+grunt.

But, do we want to change anything else here?

[wwalc]

I think that using Transifex for translations was a good choice.

(1) There is one thing that I don't like in V4 though: 3rd party open source plugins can't easily benefit from the TX localization service. I believe we should try to fully automatize this process on our side, somehow. But this is tricky.

(2) Second problem: in case of V5 there might be significant changes in language files between major versions of plugins, so ideally the system should support more than one "version" of a plugin which requires different translations.

Ad (1): Introducing vendor name as a part of the plugin name (see #15) may help in distinguishing plugins on Transifex, if we mix "our" plugins and various 3rd party plugins there in a single place.

[Reinmar]

There are always those PR with translations... It would be great if we could base everything on Github PR's, but I don't think we'll have enough contributions this way.

So Tx seems to be the only way. In this case we need to format and comment language files kept in the repo in a way that no one will touch them :D.

[fredck]

I've recently faced this: https://translatewiki.net/

It looks cool as well. I would love to have an opinion from @wwalc and @AnnaTomanek.

[wwalc]

https://translatewiki.net/

-1 from me

Their UI is more confusing than working straight on source files with git. Besides I have some doubts how long that service will be running in the future. Transifex has proved to be reliable, they have a really good command line client which may simplify doing tasks with grunt.

The only alternative for me to Transifex is working with language files straight on Git. But I quickly abandoned this idea knowing that getting the source code will be even more complex in V5 and one would have to jump between several dozen repositories. Not all translators are developers, some of them are just site builders who know how to install software with CKEditor inside.

[AnnaTomanek]

Unless there are some serious technical limitations to the current solution (and gains by moving somewhere else), I'd stay with Transifex. A few reasons:

• It's really NOT easy to find translators, recruit them, ask them to do something for free, especially for anything beyond the 5 most popular languages. It's taken me years to build our community of translators and creating any additional hurdles for these people (registering on yet another site, learning a new technology or interface) is just asking for trouble.
• Many translators are not developers, some of them have never downloaded or installed CKEditor by themselves (I ask every single one that joins us at Tx what his/her background is and believe me, there are as many scenarios as there are people). We cannot count on them using GitHub, cloning repos etc.
• Tx is reliable, has a huge client base, large and well-known projects in that (Firefox, Joomla, CC, WordPress, Django, Suse etc.). We are not paying them a cent and the support we are getting has always been excellent.
• From a translators perspective, Tx is the right tool for the job, with a good translation interface, tools like translation memory & history etc., even keyboard shortcuts that the translators know from their CAT tools which makes it really pleasant to work with. It's well-known, so people are able to show their portfolios/contributions which may contribute to their willingness to help us in the first place.
• TranslationWiki just looks like an effort to bend a tool (mediawiki) to do something it was not really designed to do. It may work OK for the Wikimedians ;-) but personally I'm not a fan of such solutions. KISS and choose the right tool for the job.

[fredck]

Ok, so Tx will be kept as our main localization tool.. We may eventually make changes to the way we handle internationalization in the code, but this will be discussed in the documentation directly.

I'll keep this issue alive for now while the minimum documentation is not available.

[fredck]

#26 pointed out a problem, related to the localization of icons. We may take this in consideration.

[wwalc]

Interesting problem. If we want to do this, I think we might want to create separate sprite images for each language for the release version. Then the rest should be relatively easy.

[wimleers]

I've asked @goba to chime in here :)

[goba]

I would agree you should stay on a system where translators are comfortable and they already know. Also from experience, source control will lead to less involvement, an easier UI works better, if that ties into some source control, the better.

As for localized icons, that would be hard to put into an external system in my experience, although Drupal did not need to deal with these in core. So including per language sprites works.

[fredck]

A first version of the globalization documentation is available in the wiki:
https://github.com/ckeditor/ckeditor5-design/wiki/Globalization

It's a bit of blah blah blah... but may be important for those not used to globalization in general. The real shape of it will be given by the code that will be implemented to satisfy the requirements described there.

[fredck]

Additional translation service (for future reference):
https://crowdin.com/

[Reinmar]

If we'll implement the t() function as in #136, then it will make the https://github.com/ckeditor/ckeditor5-design/wiki/Globalization totally outdated.

[Reinmar]

Cleaning up outdated discussions. See #186