2

I'm writing a plugin that needs some translatable strings at runtime, but I'm having trouble getting my language file to be picked up.

I've got the following:

  • /language/en-GB/en-GB.plg_system_myplugin.sys.ini
    This contains the translations for the plugin's config page. This is working fine.

  • /language/en-GB/en-GB.plg_system_myplugin.ini
    This contains the translations for the plugin to use at runtime. This is not working.

  • And both of the above referenced in the plugin XML file:

    <languages>
    <language tag="en-GB">language/en-GB/en-GB.plg_system_myplugin.sys.ini</language>
    <language tag="en-GB">language/en-GB/en-GB.plg_system_myplugin.ini</language>
</languages>

As noted above, the .sys.ini file is working just fine; my plugins config page shows up with all the labels, etc loaded correctly.

However the .ini file is not working. From what as I can tell, looking at the Joomla Debug Console, the .ini translation file isn't being loaded at all even when the plugin is being used.

I can't see what I'm doing wrong here. Similar code in modules and components works just fine, but I can't make it work in a plugin.

Can someone please tell me how to make a language file work in a plugin, or tell me what I'm missing.

Thank you.

Improve this question
1
  • Did you put the file manually to the Joomla site or only via the zipped installation file? The plugin language files have to be placed into the directory /administrator/language/en-GB/en-GB.plg_system_myplugin.ini Please add the content of the *.ini file too - maybe there is a failure in the language file itself.
    – Tom Kuschel
    Commented Feb 3, 2017 at 19:55

3 Answers 3

Reset to default
4

Since Joomla 3.1 it is not necessary to expand the constructor any more, like farahmand's answer. You can easily write / set the $autoloadLanguage like

 class myPlugin extends JPlugin
 {
    /**
    * Load the language file on instantiation.
    *
    * @var    boolean
    * @since  3.1
    */
    protected $autoloadLanguage = true;

    ...
Improve this answer
2
  • In some specific situations we should still use the constructor to load language files; for example: whenever you want to write a user plugin and use onUserAfterLogin event to send an email or enqueue a message with translatable text. Using protected $autoloadLanguage = true; is not enough.
    – Farahmand
    Commented Feb 5, 2017 at 8:06
  • Thanks for this answer. It seems too easy to be true, but I can confirm that it does work so I will accept this answer. However, I'd be interested to know if this is actually documented anywhere. It isn't in the documentation for writing a plugin (ie docs.joomla.org/Creating_a_profile_plugin/en, as suggested by @YolkNet), and I haven't seen it anywhere else, so I'm not sure how I could have discovered it without diving into the Joomla source code (I have done this plenty of times, but it's impractical to do it every time you need to know something).
    – Simba
    Commented Feb 6, 2017 at 10:44
3

Load the language files in the plugin's constructor like so:

function __construct(&$subject, $config) {
    $lang = JFactory::getLanguage();
    $lang->load('plg_system_myplugin', dirname(__FILE__));

    parent::__construct($subject, $config);
}
Improve this answer
6
  • it is more convinient to use autoloadLanguage see my additional answer.
    – Tom Kuschel
    Commented Feb 4, 2017 at 21:08
  • @TomKuschel In some specific situations we should still use the constructor to load language files; for example: whenever you want to write a user plugin and use onUserAfterLogin event to send an email or enqueue a message with translatable text. Using protected $autoloadLanguage = true; is not enough.
    – Farahmand
    Commented Feb 5, 2017 at 8:03
  • @Farahmand - thanks for the answer, and for the comment. Can you expand the answer to include a bit of info about why $autoloadLanguage is not enough in some cases. What makes it okay for some things and not others? Thank you. I'll try both answers and will accept the one that works, but I have up-voted both already. Thanks for helping.
    – Simba
    Commented Feb 6, 2017 at 10:16
  • By the way... why are you using dirname(__FILE__) rather than __DIR__?
    – Simba
    Commented Feb 6, 2017 at 10:16
  • @Simba - You're welcome. Some points: You hadn't mention Joomla 3.x tag in your question and the accepted answer is only for Joomla 3.1+. Moreover if you have PHP 5.3.0+ you can use __DIR__ instead of dirname(__FILE__). In fact, if you are using Joomla 3.x, you can use __DIR__ because the min PHP required is 5.3.1.
    – Farahmand
    Commented Feb 6, 2017 at 12:27
2

I assume you have done the following, but just to make sure:

The problem can be in your language file or in your script. To determine this you can try to override a constant in your language file. Go to Extensions --> Languages --> Overrides and click on the green New-button. Search for a value that should be in the language file. If you don't get a result it's in your file. If you do get a result it's in your script.

Improve this answer
1
  • Thanks for this. In fact, the correct answer was given by @TomKuschel, and isn't mentioned in the above documentation. It probably should be in there though. Even though your answer didn't help me directly, I am up-voting it because it is potentially useful for others looking for similar info. Thank you.
    – Simba
    Commented Feb 6, 2017 at 10:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.