How to create custom backend admin menu in different languages?

Question

So I've found absolutely nothing about this subject online.

What I've done: I successfully programmed a custom admin menu in english for my wordpress backend, according to https://webkul.com/blog/how-to-add-menu-in-wordpress-admin-panel/, so that's all good.

What I need: If I change the language of the backend (via the user settings in the wordpress backend), every admin menu gets translated to the new (selected) language, except from my custom admin menu, which of course still appears in English. My question is: How / Where do I need to store custom admin menus in other languages, such that they also get their language changed according to the language selected for the backend ??

Update: Ok meanwhile I developed a plugin as it should be done, and learned all the stuff about .pot, .po and .mo files. The only thing missing now is that the internationalization only works if I put the .mo and the .po files into the root wp_content/languages/plugins directory, although I used:

if ( ! class_exists( 'MyPlugin' ) ) {

  // Used class for plugin configuration to avoid naming collision
  class MyPlugin {

    // Used hooking functions on class constructor
    public function __construct() {

      // Hook Admin Menu Creation callback onto admin_menu action hook
      add_action( 'admin_menu', array( $this, 'create_admin_menus' ) );

      // Load Plugins Text Domain
      add_action(
        'plugins_loaded',
        array( $this, 'my_plugin_load_plugin_textdomain' )
      );

    } // end of constructor function

    // Define corresponding callback functions

    public function create_admin_menus() {
      // Admin Menu code, which worked successfully

    } // end of create_admin_menus callback definition

    public function my_plugin_load_plugin_textdomain() {
      load_plugin_textdomain(
        'my-plugin',
        false,
        plugin_dir_path(__FILE__).'languages/'
      );

    } // end of my_plugin_load_plugin_textdomain function definition

  } // end of class MyPlugin definition

} // end of check if MyPlugin class exists

// Initiate class object
new MyPlugin;

What am I missing out here? Is thiy may due to the polylang plugin (the only one I use atm..). I double-checked all the text domains etc. they're all good, and the specified path should also be good, so how I can I make sure that the internationalization of the MyPlugin works with the .mo files inside the wp-content/plugins/my-plugin/languages/ directory, and not in the wp-content/languages/plugins/ directory?

What happens currently is that the localized strings appear in English (so translations not found), but are successfully and perfectly translated when I copy the same .po and .mo files into the wp-content/languages/plugins/ directory.

P.S.: Thanks a lot Tom for your hints already, was completely worth it learning the stuff you've told me!

Answer 1

You need to use the internationalisation APIs, these let you swap out hardcoded strings for localised versions, e.g.

<p>Hello world</p>

versus:

<p><?php _e( 'Hello world', 'joes_plugin' ); ?></p>

Then, you can use .po/.mo/.pot files to provide alternatives, e.g. a file with french translations, a file with russian etc.

You'll need to declare your translation text domain in your theme/plugin ( joes_plugin in the example above ), as well as the domain path so WP knows the folder to look in for translation files. You'll also need to call load_plugin_textdomain on the plugins_loaded hook

Here's the handbook for the Internationalisation API:

https://developer.wordpress.org/apis/handbook/internationalization/

And the page for plugins:

https://developer.wordpress.org/plugins/internationalization/how-to-internationalize-your-plugin/

And for generating the localisation files themselves:

https://developer.wordpress.org/plugins/internationalization/localization/

Each of these is a huge subject in of themselves, so I recommend asking multiple new follow up questions about specific parts

Note that this API cannot be used to translate things in the database, and you should never pass dynamic variables into these APIs. For multilingual frontends, you will need a plugin