Babel - GUI for translations of Cockpit CMS v1 and v2 modules

I guess, this is the first addon, that is compatible with Cockpit CMS v1 and v2 :slight_smile:

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:

3 Likes

This is the first community addon for v2 in general, good job. Congrats! :bouquet::1st_place_medal::+1:

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 :slight_smile:

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:

  • I use Cockpit CMS v1 (v2 is still a play ground for me).
  • Personally, I always use English user interfaces. It is annoying to search for German error messages.
  • For non-English (or multilingual) front-ends, I provide app i18n files to translate some system messages.
  • For German and French clients, I provide app i18n files, so they have a translated user interface.
  • It never happened to me, that entry languages should differ from app languages → so thanks for your feedback.

The current implementation is, to

  1. read i18n and languages from config.php in cockpit v1 or read $app->helper('locales')->locales(); in cockpit v2,
  2. strip out default strings and
  3. ignore '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.