Plesk UI supports a wide range of languages. While supporting all of them is not a requirement for certification, we recommend you to localize your extension into at least the most popular languages (to determine those, use common sense and consider your target audience) to increase the number of your extension’s potential users. Also, if your extension integrates not only into the administrator’s panel, but into the customer’s panel as well, you should consider localizing your extension into a wider range languages.

To localize the UI of your extension, use the pm_Locale helper.

All locale keys must be stored in the locale file (plib/resources/locales/<locale-code>.php, for example, plib/resources/locales/en-US.php):

<?php
$messages = [
    'pageTitle' => 'My localized extensions',
    'controllerMessage' => 'Message from controller',
    'viewMessage' => 'Message shown in view',
];

Once stored, locale keys can be used in a controller to pass it to view:

public function indexAction()
{
    $this->view->pageTitle = $this->lmsg('pageTitle');
    $this->view->message = $this->lmsg('controllerMessage');
}

Or directly in view (index.phtml):

<h3><?php echo $this->message; ?></h3>
<h5><?php echo $this->lmsg('viewMessage'); ?></h5>

If your extension is only localized into English, all other locales will revert to English if no locale file for the user’s language is found. This is how it looks in UI.

But once you localize your extension, for example, into German (create the file plib/resources/locales/de-DE.php and translate the values in the localization strings, like in the example below):

<?php
$messages = [
    'pageTitle' => 'Meine lokalisierte Erweiterungen',
    'controllerMessage' => 'Nachricht vom Controller',
    'viewMessage' => 'Nachricht in Ansicht gezeigt',
];

and then switch the Plesk UI to German, you will see that the new localization has been applied.

Localizing Lists and Forms

In the Implement List and Implement Form topics it is discussed that you can create lists and forms as separate objects inherited from pm_View_List_Simple and pm_Form_Simple, respectively. It provides additional flexibility, such as separation of code, code reuse, and so on. Another benefit of this approach is that the lmsg method is available both for list and form, saving you the trouble of thinking about getting the current view.

Localization from any place of your code

Sometimes we need to use locale keys from some place of our business logic code (located in plib/library directory). As an example of such case it can be exception with localized message thrown from business logic class. For this case we can use static method lmsg of pm_Locale class.

Using placeholders in locale keys

There is a popular situation during localizing the extension when you need to put in the message some value depending on context (for example domain name). For such case you can use placeholders.

In localization file we put locale key with placeholder:

<?php
$messages = [
    'pageTitle' => 'Settings for %%domain%%',
];

And then fill this placeholder when we use the locale key and have all necessary information:

<?php
public function indexAction()
{
    $domain = new pm_Domain($this->_getParam('id'));
    $this->view->pageTitle = $this->lmsg('pageTitle', ['domain' => $domain->getName() ]);
}

And then check how the placeholder is replaced.