Optimize i18n for plugins and themes

  1. Inactive

    I think i18n support for WordPress external elements should be clarified to ease their maintain and contributions.

    Here is a proposal of structure :
    + wp-content/
    +- i18n/
    -- catalog.pot
    -- fr_FR.mo

    +- plugins/
    +-- i18n/
    ---- provider/
    ----- catalog.pot
    ----- fr_FR.mo
    +-- sample-plugin/
    +--- i18n/
    ----- catalog.pot
    ----- fr_FR.mo
    ---- README.txt
    ---- sample-plugin.php

    +- themes
    +-- sample-theme/
    +--- i18n/
    ----- catalog.pot
    ----- fr_FR.mo

    * wp-content/i18n
    Contains all translation related to WP (the equivalend of the languages/ directory)
    * plugins/i18n
    Contains all global translations for providers (actually located in plugins/provider-fr_FR.mo for example)
    * plugins/sample-plugin/i18n
    Contains translations specific to a plugin
    * themes/sample-theme/i18n
    Contains translations specific to a theme

    It would be good to complete that with a textdomain_namespace('provider/; ./') to implicitly use i18n files located in i18/provider/{locale_LOCALE}.mo} and sample-plugin/i18n/{locale_LOCALE}.mo}. The goal is to avoid usage of __('Text', 'textdomain') which is a real pain.

    i18n files at the root of the plugin directory is not esthetic and difficult to explain to users.

    With that everything is coined up and can give ideas to introduce some conventions.

    Posted: 10 years ago #
  2. Plugins can choose where to put their translations. The convention is to use languages sub-folder.

    There is more information on:


    On the textdomain issue: all the solutions we have tried have been too hackish and unstable. The lack of namespaces disturbs any clean way to do this.

    Posted: 8 years ago #

RSS feed for this topic

Topic Closed

This topic has been closed to new replies.

  • Rating

    4 Votes
  • Status

    This idea has been implemented