Loading .mo files for this plugin

  • Resolved itapress

    (@itapress)


    6 months, 4 weeks ago

    Hello.

    I’m doing some tests regarding loading your plugin’s .mo files.

    I noticed that when translating strings contained in .php files, the plugin loads the .mo file contained in the system path (wp-content/languages/plugins/wedevs-project-manager-xx_XX.mo) and, if it doesn’t find it, it loads the .mo file contained in the developer path (wp-content/plugins/wedevs-project-manager/languages/wedevs-project-manager-xx_XX.mo).

    Instead, regarding the translation of strings contained in .js files, which are handled by pm_get_jed_locale_data and pm_get_translations_for_plugin_domain functions, the plugin uses only the .mo file contained in the developer path (wp-content/plugins/wedevs-project-manager/languages/wedevs-project-manager-xx_XX.mo) and completely ignores the .mo file contained in the system path (wp-content/languages/plugins/wedevs-project-manager-xx_XX.mo).

    Couldn’t we use a procedure that is more compliant with the standards and other WordPress plugins?

    Thanks.

Viewing 1 replies (of 1 total)
  • Md. Tanvir Chowdhury

    (@tanvir101)

    6 months, 1 week ago

    Hello @itapress,

    Thank you for the detailed report. You are correct in your findings.
    At the moment, PHP translations follow the WordPress standard and correctly load from the global languages directory before falling back to the plugin’s own languages/ folder. However, JS translations currently load only from the plugin path, which prevents WordPress from using the global .mo/.json files or language packs.
    We agree that this should be aligned with WordPress standards. We are reviewing the JS translation logic, and if this behavior is confirmed as the recommended standard, we will implement the necessary changes to ensure both PHP and JS translations follow the same loading order.

    We appreciate your cooperation in this regard.

Viewing 1 replies (of 1 total)

The topic ‘Loading .mo files for this plugin’ is closed to new replies.