I guess, this is the first addon, that is compatible with Cockpit CMS v1 and v2 
V2 is only partially supported (no filters, yet).
Feedback and pull requests are very welcome.
See more info about the concepts in the README of the addon repo:
Screenshots:
Cockpit CMS v2:
Cockpit CMS v1:
This is the first community addon for v2 in general, good job. Congrats! 
Thanks for the addon. I like the idea and I tested it (with Cockpit V2) and it works great when we add new locales!
But I have one question. In my case, all sites I do have French as the primary language, and some have both French and English.
So under settings/locales, I usually redefine the “default” to Francais and then create “en” to English if needed.
So when the user navigates into the admin content to see an entry, the default content is always French.
I tried Babel with this setup and it doesn’t work.
Do you think you could detect the languages to translate without reading settings/locales, which I think is more about front end locales rather than admin locales.
I’m not Cockpit expert, so let me know if you have other ideas or solutions
While developing Babel, I was thinking about mixing up (or better separating) languages and locales, too. It always feels a bit weird, how cockpit detects languages for entries and for the admin ui and where I have to check for default strings. Also the terms languages, locales, i18n are sometimes a bit confusing to me.
My typical use case is:
The current implementation is, to
i18n and languages from config.php in cockpit v1 or read $app->helper('locales')->locales(); in cockpit v2,default strings and'en' => 'English', if explicitly set.languages and $app->helper('locales')->locales(); are used for entry level languages. Admin ui languages don’t have any detection system besides the existence of <locale>.php inside config(/cockpit)/i18n folders.
I think, it would be better to use an explicit config key to read app languages in config/config.php, e. g.:
<?php
return [
'app.name' => 'My app',
// set entry level languages in cockpit cms v1
// use the gui instead to change locales in cockpit cms v2
'i18n' => 'de',
'languages' => [
'default' => 'Deutsch',
'fr' => 'Francais',
],
// set admin ui languages with an explicit config key
'app.languages' => [
'de' => 'Deutsch',
'fr' => 'Francais',
],
// alternative
'babel' => [
'languages' => [
'de' => 'Deutsch',
'fr' => 'Francais',
],
],
];
Now I’m not sure, how to name that new config key and if I should wrap it into a babel config key.
And I think, it would be useful to not fallback to the current implementation, which would also eliminate all these checks for default strings.
@sgirard84 What do you think?
I just realized that the users page reads the list of i18n files to get the list of UI languages as you said, so that’s not an information available already.
So yes, maybe it makes sense to create a specific Babel config with the list of non-English UI languages. And if for some reasons, you want to give your client the Babel module, but only to translate French, and keep your own Deutsch files, then you could by only specifying French in that config.
I agree that i18n and locales are a bit confusing.
@sgirard84 I just implemented the change.
config: GitHub - raffaelj/cockpit_Babel: Manage translations of Cockpit CMS v1 and v2 modules
commit: decoupled content languages from app languages · raffaelj/cockpit_Babel@da3c56e · GitHub
Thank you much! It works fine 
The v2 app is still not displaying the good language, but I’ve open an issue for this.
Have a nice day.
I might have found the solution for your translations not showing up. At first I thought, “Content” wasn’t translated, because it is a module name. But I stumbled upon an OPCache issue in the Babel addon, where the updated language files didn’t show up properly after including them again. So I invalidate these files for OPCache now on save in the latest version 0.3.2.
You can check, if OPCache is enabled, by going to “Settings” → “System info”, click “PHP” tab, scroll to bottom, see “OPCache Enabled”.
For reference: