Admin language is installed ok.
Front-end ini file is just ignored.

xml formatted normally i.e.

en-GB.plg_whatevername.ini

Dev note; tracker http://joomlacode.org/gf/project/joomla ... em_id=7727

Hacked the proper file  to get it to work. 

Code: Select all

<?php
/**
* @version      $Id:plugin.php 6961 2007-03-15 16:06:53Z tcp $
* @package      Joomla.Framework
* @subpackage   Installer
* @copyright   Copyright (C) 2005 - 2007 Open Source Matters. All rights reserved.
* @license      GNU/GPL, see LICENSE.php
* Joomla! is free software. This version may have been modified pursuant
* to the GNU General Public License, and as distributed it includes or
* is derivative of works licensed under the GNU General Public License or
* other free or open source software licenses.
* See COPYRIGHT.php for copyright notices and details.
*/

// Check to ensure this file is within the rest of the framework
defined('JPATH_BASE') or die();

/**
* Plugin installer
*
* @package      Joomla.Framework
* @subpackage   Installer
* @since      1.5
*/
class JInstallerPlugin extends JObject
{
   /**
    * Constructor
    *
    * @access   protected
    * @param   object   $parent   Parent object [JInstaller instance]
    * @return   void
    * @since   1.5
    */
   function __construct(&$parent)
   {
      $this->parent =& $parent;
   }

   /**
    * Custom install method
    *
    * @access   public
    * @return   boolean   True on success
    * @since   1.5
    */
   function install()
   {
      // Get a database connector object
      $db =& $this->parent->getDBO();

      // Get the extension manifest object
      $manifest =& $this->parent->getManifest();
      $this->manifest =& $manifest->document;

      /**
       * ---------------------------------------------------------------------------------------------
       * Manifest Document Setup Section
       * ---------------------------------------------------------------------------------------------
       */

      // Set the extensions name
      $name =& $this->manifest->getElementByPath('name');
      $name = JFilterInput::clean($name->data(), 'cmd');
      $this->set('name', $name);

      // Get the component description
      $description = & $this->manifest->getElementByPath('description');
      if (is_a($description, 'JSimpleXMLElement')) {
         $this->parent->set('message', $description->data());
      } else {
         $this->parent->set('message', '' );
      }

      /*
       * Backward Compatability
       * @todo Deprecate in future version
       */
      $type = $this->manifest->attributes('type');

      // Set the installation path
      $element =& $this->manifest->getElementByPath('files');
      if (is_a($element, 'JSimpleXMLElement') && count($element->children())) {
         $files =& $element->children();
         foreach ($files as $file) {
            if ($file->attributes($type)) {
               $pname = $file->attributes($type);
               break;
            }
         }
      }
      $group = $this->manifest->attributes('group');
      if (!empty ($pname) && !empty($group)) {
         $this->parent->setPath('extension_root', JPATH_ROOT.DS.'plugins'.DS.$group);
      } else {
         $this->parent->abort(JText::_('Plugin').' '.JText::_('Install').': '.JText::_('No plugin file specified'));
         return false;
      }

      /**
       * ---------------------------------------------------------------------------------------------
       * Filesystem Processing Section
       * ---------------------------------------------------------------------------------------------
       */

      // If the plugin directory does not exist, lets create it
      $created = false;
      if (!file_exists($this->parent->getPath('extension_root'))) {
         if (!$created = JFolder::create($this->parent->getPath('extension_root'))) {
            $this->parent->abort(JText::_('Plugin').' '.JText::_('Install').': '.JText::_('Failed to create directory').': "'.$this->parent->getPath('extension_root').'"');
            return false;
         }
      }

      /*
       * If we created the plugin directory and will want to remove it if we
       * have to roll back the installation, lets add it to the installation
       * step stack
       */
      if ($created) {
         $this->parent->pushStep(array ('type' => 'folder', 'path' => $this->parent->getPath('extension_root')));
      }

      // Copy all necessary files
      if ($this->parent->parseFiles($element, -1) === false) {
         // Install failed, roll back changes
         $this->parent->abort();
         return false;
      }

      // Parse optional tags -- media  for plugins go in admin app
      //Language files go in their respective folders
      $this->parent->parseMedia($this->manifest->getElementByPath('media'), 1);
      $this->parent->parseLanguages($this->manifest->getElementByPath('languages'));
      $this->parent->parseLanguages($this->manifest->getElementByPath('administration/languages'), 1);
      /**
       * ---------------------------------------------------------------------------------------------
       * Database Processing Section
       * ---------------------------------------------------------------------------------------------
       */

      // Check to see if a plugin by the same name is already installed
      $query = 'SELECT `id`' .
            ' FROM `#__plugins`' .
            ' WHERE folder = '.$db->Quote($group) .
            ' AND element = '.$db->Quote($pname);
      $db->setQuery($query);
      if (!$db->Query()) {
         // Install failed, roll back changes
         $this->parent->abort(JText::_('Plugin').' '.JText::_('Install').': '.$db->stderr(true));
         return false;
      }
      $id = $db->loadResult();

      // Was there a module already installed with the same name?
      if ($id) {

         if (!$this->parent->getOverwrite())
         {
            // Install failed, roll back changes
            $this->parent->abort(JText::_('Plugin').' '.JText::_('Install').': '.JText::_('Plugin').' "'.$pname.'" '.JText::_('already exists!'));
            return false;
         }

      } else {
         $row =& JTable::getInstance('plugin');
         $row->name = $this->get('name');
         $row->ordering = 0;
         $row->folder = $group;
         $row->iscore = 0;
         $row->access = 0;
         $row->client_id = 0;
         $row->element = $pname;
         $row->params = $this->parent->getParams();

         // Editor plugins are published by default
         if ($group == 'editors') {
            $row->published = 1;
         }

         if (!$row->store()) {
            // Install failed, roll back changes
            $this->parent->abort(JText::_('Plugin').' '.JText::_('Install').': '.$db->stderr(true));
            return false;
         }

         // Since we have created a plugin item, we add it to the installation step stack
         // so that if we have to rollback the changes we can undo it.
         $this->parent->pushStep(array ('type' => 'plugin', 'id' => $row->id));
      }

      /**
       * ---------------------------------------------------------------------------------------------
       * Finalization and Cleanup Section
       * ---------------------------------------------------------------------------------------------
       */

      // Lastly, we will copy the manifest file to its appropriate place.
      if (!$this->parent->copyManifest(-1)) {
         // Install failed, rollback changes
         $this->parent->abort(JText::_('Plugin').' '.JText::_('Install').': '.JText::_('Could not copy setup file'));
         return false;
      }
      return true;
   }

   /**
    * Custom uninstall method
    *
    * @access   public
    * @param   int      $cid   The id of the plugin to uninstall
    * @param   int      $clientId   The id of the client (unused)
    * @return   boolean   True on success
    * @since   1.5
    */
   function uninstall($id, $clientId )
   {
      // Initialize variables
      $row   = null;
      $retval = true;
      $db      =& $this->parent->getDBO();

      // First order of business will be to load the module object table from the database.
      // This should give us the necessary information to proceed.
      $row = & JTable::getInstance('plugin');
      $row->load((int) $id);

      // Is the plugin we are trying to uninstall a core one?
      // Because that is not a good idea...
      if ($row->iscore) {
         JError::raiseWarning(100, JText::_('Plugin').' '.JText::_('Uninstall').': '.JText::sprintf('WARNCOREPLUGIN', $row->name)."<br />".JText::_('WARNCOREPLUGIN2'));
         return false;
      }

      // Get the plugin folder so we can properly build the plugin path
      if (trim($row->folder) == '') {
         JError::raiseWarning(100, JText::_('Plugin').' '.JText::_('Uninstall').': '.JText::_('Folder field empty, cannot remove files'));
         return false;
      }

      // Set the plugin root path
      $this->parent->setPath('extension_root', JPATH_ROOT.DS.'plugins'.DS.$row->folder);

      // Because plugins don't have their own folders we cannot use the standard method of finding an installation manifest
      $manifestFile = JPATH_ROOT.DS.'plugins'.DS.$row->folder.DS.$row->element.'.xml';
      if (file_exists($manifestFile))
      {
         $xml =& JFactory::getXMLParser('Simple');

         // If we cannot load the xml file return null
         if (!$xml->loadFile($manifestFile)) {
            JError::raiseWarning(100, JText::_('Plugin').' '.JText::_('Uninstall').': '.JText::_('Could not load manifest file'));
            return false;
         }

         /*
          * Check for a valid XML root tag.
          * @todo: Remove backwards compatability in a future version
          * Should be 'install', but for backward compatability we will accept 'mosinstall'.
          */
         $root =& $xml->document;
         if ($root->name() != 'install' && $root->name() != 'mosinstall') {
            JError::raiseWarning(100, JText::_('Plugin').' '.JText::_('Uninstall').': '.JText::_('Invalid manifest file'));
            return false;
         }

         // Remove the plugin files
         $this->parent->removeFiles($root->getElementByPath('images'), -1);
         $this->parent->removeFiles($root->getElementByPath('files'), -1);
         JFile::delete($manifestFile);

         // Remove all media and languages as well
         $this->parent->removeFiles($root->getElementByPath('media'));
         $this->parent->removeFiles($root->getElementByPath('languages'));
         $this->parent->removeFiles($root->getElementByPath('administration/languages'), 1);
      } else {
         JError::raiseWarning(100, 'Plugin Uninstall: Manifest File invalid or not found');
         return false;
      }

      // Now we will no longer need the plugin object, so lets delete it
      $row->delete($row->id);
      unset ($row);

      // If the folder is empty, let's delete it
      $files = JFolder::files($this->parent->getPath('extension_root'));
      if (!count($files)) {
         JFolder::delete($this->parent->getPath('extension_root'));
      }

      return $retval;
   }

   /**
    * Custom rollback method
    *    - Roll back the plugin item
    *
    * @access   public
    * @param   array   $arg   Installation step to rollback
    * @return   boolean   True on success
    * @since   1.5
    */
   function _rollback_plugin($arg)
   {
      // Get database connector object
      $db =& $this->parent->getDBO();

      // Remove the entry from the #__plugins table
      $query = 'DELETE' .
            ' FROM `#__plugins`' .
            ' WHERE id='.(int)$arg['id'];
      $db->setQuery($query);
      return ($db->query() !== false);
   }
}

As far as I understand, this is not a bug...  I have attached a conversation between myself, schlu and Rob on this issue.  First are my misguided thoughts and then Rob's insights...

Ian

[Sun Sep 9 2007 19:15:47] Ian MacLennan: why should there be different plugins for frontend and backend?
[Sun Sep 9 2007 19:16:15] schlulou: thecore also tries to load the frontend language of plugins but you have no chance to install it
[Sun Sep 9 2007 19:16:33] … ian, think my english is too limited to explain this
[Sun Sep 9 2007 19:16:45] Ian MacLennan: I understand exactly what you are saying
[Sun Sep 9 2007 19:16:46] schlulou: I mean not plugins
[Sun Sep 9 2007 19:16:48] Ian MacLennan: I just disagree
[Sun Sep 9 2007 19:17:31] schlulou: but a plugin should have a frontend lan file and  abackend lang file if it is needed
[Sun Sep 9 2007 19:17:46] Ian MacLennan: that is your opinion...
[Sun Sep 9 2007 19:17:56] … in my opinion, there should be one language file per plugin
[Sun Sep 9 2007 19:18:06] … it could be kept in the frontend or the backend, I don't really care
[Sun Sep 9 2007 19:18:15] schlulou: why does the core tries to load a frontend language file if you son't have a chance to install it
[Sun Sep 9 2007 19:18:31] Rob Schley: it was an oversight
[Sun Sep 9 2007 19:18:32] Ian MacLennan: I explained that already
[Sun Sep 9 2007 19:18:34] … read above
[Sun Sep 9 2007 19:18:48] … Rob what are your thoughts on this?
[Sun Sep 9 2007 19:19:18] Rob Schley: Generally, I would say plugins should only need a back-end language file.  They are not really meant to display text
[Sun Sep 9 2007 19:19:20] schlulou: I noticed your remark...and I already said I can workaround it
[Sun Sep 9 2007 19:19:52] Rob Schley: The content plugins are just poor examples and things that have been carried over for legacy reasons
[Sun Sep 9 2007 19:19:54] Ian MacLennan: what about say comment plugins?
[Sun Sep 9 2007 19:20:02] Rob Schley: most of the other plugins don't display text
[Sun Sep 9 2007 19:20:07] Ian MacLennan: debug plugin
[Sun Sep 9 2007 19:20:28] Rob Schley: I think commenting should be done with modules
[Sun Sep 9 2007 19:20:33] schlulou: but I also think that then it should be solved generally all the same..no special cases for the core ones cause they don't need any installation
[Sun Sep 9 2007 19:20:43] Rob Schley: you should have a comment module that shows up and then have a framework level comment handler
[Sun Sep 9 2007 19:21:12] Ian MacLennan: but how would you specify the module to only appear when full article text is displayed?
[Sun Sep 9 2007 19:21:38] Rob Schley: It would require logic in the whatever content component was being used
[Sun Sep 9 2007 19:21:50] Ian MacLennan: hmmm...  okay.
[Sun Sep 9 2007 19:22:22] … but provided that the logic isn't there?
[Sun Sep 9 2007 19:22:41] Rob Schley: There will be cases where translations are needed for the front-end stuff, that is obvious but I don't think we will need it as much in the future as we do now
[Sun Sep 9 2007 19:22:43] tjaaaay: grrrrrrrrr
[Sun Sep 9 2007 19:22:54] Ian MacLennan: okay...
[Sun Sep 9 2007 19:22:55] Rob Schley: front-end plugins I mean
[Sun Sep 9 2007 19:23:08] Ian MacLennan: I had assumed that the logic was that plugins are not unique for frontend and backend
[Sun Sep 9 2007 19:23:17] … thus, we should only have language files in one place
[Sun Sep 9 2007 19:23:31] … thus, for plugins, it is fine to put them in the admin directory
[Sun Sep 9 2007 19:23:48] … but IMO the language files should be loaded from there when the plugin loads in the frontend
[Sun Sep 9 2007 19:23:53] Rob Schley: Well, that is true but in theory you could just load different language files for each because they have different contexts in each application
[Sun Sep 9 2007 19:24:14] Ian MacLennan: hmmmm...  perhaps...
[Sun Sep 9 2007 19:24:20] Rob Schley: for example
[Sun Sep 9 2007 19:24:32] … Plugin configuration strings... are defined in the plugin language file
[Sun Sep 9 2007 19:24:37] … you only need those in the back-end
[Sun Sep 9 2007 19:24:47] Ian MacLennan: but I could more easily think of examples where you would need translations for frontend plugins as for different strings in frontend and backend
[Sun Sep 9 2007 19:24:55] Rob Schley: Several of our plugins currently don't do anything in the front-end
[Sun Sep 9 2007 19:24:58] … especially the content ones
[Sun Sep 9 2007 19:25:02] Ian MacLennan: sure
[Sun Sep 9 2007 19:25:05] schlulou: k...not sure if I understood all, but that means for a search plugin to force loading the admin language file in the forntend
[Sun Sep 9 2007 19:25:18] Rob Schley: sorry, s/front-end/back-end/
[Sun Sep 9 2007 19:25:40] Ian MacLennan: right, because the admin content component doesn't fire any events, does it?
[Sun Sep 9 2007 19:26:02] Rob Schley: I think it fires a couple but not as many
[Sun Sep 9 2007 19:26:03] schlulou: the content search plugins currently loading the s

Sure it is not a bug. As template language installing was not before it was at last implemented... 
Just a feature easily added.

It happens that the reason why I was asking for it to be implemented is that a user has developped a search plug-in (keyword_density) that needs one front-end string. Not a content plugin.

I understand Robs statement but to implement this feature does not cost anything and may help 3pd (and, more important, international communities...), even if it may not anymore be needed in the future.

After all, it is not as if we were introducing in core something that would be a problem in 1.6 or later.

My personal opinion is that there should only be one set of language files for plugins.  These language files should be loaded whenever the plugin is loaded.  Reasoning for this is that plugins are application agnostic.

Ian

I have no idea about the application-agnosticism of a plug-in compared to a module, a template or a component. 

I would not mind if one language file only is implemented.
If it takes too much work though, my solution is pretty easy to commit.

As you can read in the chatlog Ian posted I came across the missing frontend language file for Plugins a while ago. Currently I just load the administration language file into the frontend:

Code: Select all

//Load the Plugin language file out of the administration
$lang = & JFactory::getLanguage();
$lang->load('plg_search_eventlist', JPATH_ADMINISTRATOR);


It's a search plugin which uses the new areas, ment I need a language file to allow translation of them. (string goes anyway through JText). I don't know what would be the best way or what is the best definition of what a plugin should do (output text or not). The current situation seems for me not really "specific". The core uses frontend language files for plugins, 3pd's can't. Some parts (search areas) are implemented in a way which needs to build a plugin with text output.
I'm fine with loading the administration language file, just don't understand why not allow a frontend language file for plugins. (no idea what application agnostic means or why legacy plays a role here). Maybe I don't understand the underlying concepts, but this all isn't straightforward.

Thanks to Schlu's hint on 10/19 about loading language files in plugins for the front end.  I used that approach and split the plugin language translation files into 2 files: 1 for the normal backend stuff, and one for my small front-end needs.  I named the files like so:

    en-GB.plg_content_mymod.ini
    en-GB.plg_frontend_mymod.ini

In my front-end plugin, I used this code (as per Schlu):

  $lang = & JFactory::getLanguage();
  $lang->load('plg_frontend_mymod', JPATH_ADMINISTRATOR);

This works and lets me keep the frontend part small and efficient.  I listed both files in the XML install file and they both installed in the admin language directory and all this worked fine.

Thanks!

  -Jonathan

Issue resolved?

tcp wrote:Issue resolved?

If fix I suggested is applied, yes. 

We would be consistent with other extensions and have back-end and front-end language ini files in their proper folders.
We should not have to use a trick to get front-end strings from a back-end ini file IMO.

Also the way back-end language is installed is not consistent with other extensions as ini files are not placed in an admin folder in the package.

Hi,

I'm the developer of the search plugin that created the whole issue here and I agree with infograf768 point of view.

I believe that even if the plugin displays only a short text string, since it displays it in the front-end, it should have its own front-end language file.
It makes more sense and it's more "egalitarian": if core uses front-end language files for plugins, why 3p devs shouldn't be able to?

After all it is just a quick fix that (as I understand it) doesn't give any problem with what's ahead in Joomla! development roadmap.

Regards,
Pietro

It seems like this issue just won't go away

There are a couple things that come into play here that make this a complicated decision, I will do my best to explain some of them:

1. The Core plug-ins, especially the content, search, and debug plug-ins are in a state of transition.  They were refactored a long time ago to work with 1.5 but they need to be refactored again (likely in 1.5.x) to utilize what we consider the best way to build a front-end plug-in that displays text.  Almost all front-end plug-ins that display text can be built so that the plug-in actually doesn't display anything but instead render a module.  Some of us have been using this method in our personal code and have found some great advantages (and a few disadvantages that will hopefully be fixed in another version).
2. Plug-ins are intended to be framework level extensions which does make them different than other extensions (components, modules, templates, languages).  All of those other extensions have an explicit difference in whether or not they are for the front-end or the back-end.  Plug-ins do not understand the difference between the front-end, back-end, or the XML-RPC application for that matter unless they have been internally programmed to do so.  So, there is a distinction that is made between plug-ins and other extensions and it is there on purpose.  (this is what Ian meant by application-agnostic).
3. With all that being said, this particular issue is obviously going to cause some strong opinions to be raised.  It is a different behavior than the other extensions and particularly with the search system, the core plug-ins are in a state of transition which makes them poor examples, at best.
4. I have written several plug-ins for Joomla! 1.5 and I have had to deal with this issue only once.  In my opinion, a plug-in really needing to load a JText string in the front-end is going to be an exception rather than the rule.  Since it is an exception, I don't see a problem with adding two lines of code to the plug-in to load the back-end language file in times of dire need.

I hope that helps explain the position.  I don't expect it to change your mind but it is a position that has been thought through very heavily and debated internally several times over the Joomla! 1.5 development cycle.

OK. I have renounced for a long time to even try to understand coders' reasoning.

The issue may not have gone away because it was never discussed in this forum but on other medias and we have no tutorial to refer to...
One can't expect that a private or semi-private conversation/decision be known from thousands of users...

Let's try to move on though.

There are still 2 things you could do, to make things easier for all.

1. As the xml should only install an admin language file, the install code should be consistent with other extensions.
i.e.
today, the admin ini file is uploaded with the following code, the file being at the same level as the xml:

en-GB.plg_myplugin.ini
fr-FR.plg_myplugin.ini

instead of, as for others extensions, ini in an admin folder and code being

en-GB.plg_myplugin.ini
fr-FR.plg_myplugin.ini

2. As you guys consider the use of frontend strings as an exception and there is a fix which is, if I understand well (correct me if wrong)
a) add a second ini file to load in admin/languages/ of the type en-GB.plg_frontend_myplugin.ini
b) add the following code in myplugin.php

$lang = & JFactory::getLanguage();
$lang->load('plg_frontend_myplugin', JPATH_ADMINISTRATOR);

Then this should be documented somewhere as a tutorial for all to know. This would avoid useless questions.

3. Let me quote you Rob

I have written several plug-ins for Joomla! 1.5 and I have had to deal with this issue only once.

It would be useful to have access to these as samples of what can be done as we do not have any in core with these solutions.
I guess these plugins are GPL.

Side Note:
You surely have understood that it is not as a coder that I raised this issue but as someone trying to help users on language matters.

From reading this thread, I understand that plugins should use a single language file which is put under J/administrator/languages, and that one can manually load the language file via the frontend using PHP code if required.  According to Rob this is the expected behavior.

This thread looks more like a discussion at this point.  Can I move it out of Q&A into general J! 1.5 Dev ?

tcp

Seems that way to me.

In the tracker it is already marked as closed.

I still consider this as inconsistent and ask for a change.

1. As the xml should only install an admin language file, the install code should be consistent with other extensions.
i.e.
today, the admin ini file is uploaded with the following code, the file being at the same level as the xml:

en-GB.plg_myplugin.ini
fr-FR.plg_myplugin.ini

instead of, as for others extensions, ini in an admin folder and code being

     
en-GB.plg_myplugin.ini
fr-FR.plg_myplugin.ini
     

Jean-Marie

I know  you do, but it should be in discussion, not in Q+t because  it is a general topic about how to handle this issue in general, not a specific bug that someone can make a patch for.

Thanks for keeping this issue active.