Founder and Lead Developer of Macrotone Consulting Ltd.

Making a component truly Multilingual (4)

Continuing on from our earlier posts about item associations. we continue our look at the front end.  As explained this is slightly more complicated.

We require changes to the following files:

There is the module in place required by JMultilingual that performs the ‘switch’ between the various installed available languages. We need to pick up the current displayed language and modify the displayed data based upon the determined value.

We need to implement the following changes:

Models that display lists such that there is an additional statement in the SQL query to detect the language. Such a statement might look similar to the this:

        $query .= " WHERE c.language in (" . $db->quote(JFactory::getLanguage()->getTag()) . "," . $db->quote('*') . ",'')";

This will pick up all the current displayed items for the determined language and also any items that are marked as ‘All’ or undefined. Hopefully there will be no undefined items but this allows for that possibility.

The front end views need modifying to display the ‘language’ field if deemed necessary.  We need to add the ‘language’ field to any select statement so that it is then available.

Any drop down select lists (if present) similarly need modifying so that the ‘language’ criteria is also applied. i.e. If being viewed in Spanish, we do not want to display any drop down list selectable item in English. The appropriate entries would have been defined in the admin side of the site, along with the required associations.

Any list view models will probably need to have some additional criteria added to the select statement along the following lines:

if ( JLanguageMultilang::isEnabled() ) {
if (JLanguageAssociations::isEnabled() ) {
// Criteria where associations will change the displayed values.       // …    } else {       // Any criteria where associations are not used.
      // ……    } } else { // Criteria for non multilingual sites.    // Effectively the code we had before we implemented multilingual. }

Any displayed module using the component data would similarly require the language criteria to be added to any select statement. Whilst on the subject of modules it is worth mentioning that any link which might be present in the module, to display more specific data would need inspection to ensure that they still work. We found that if a menu id (itemid) is specified in the link that it did not always result in the correct data being displayed.

If we are allowing items to be deleted in the front end then we also have to modify the appropriate model delete code to handle any ‘associations’ that may exists for the item to be deleted. We can choose to use similar code to that used in the back end.

The creation of item associations in the front end was touched upon in our last post upon the subject. Further investigation reveals that there was a conscious decision by the Joomla Multilingual team not to implement associations on the various ‘base’ Joomla components, instead relying on the back end functionality to perform the necessary actions. In the lack of more information at the current time we have decided to adopt the same approach, but may change this at some later time..

To be continued…

Making a component truly multilingual (5)
Withdrawal of Support for Joomla 2.5
 

By accepting you will be accessing a service provided by a third-party external to https://macrotoneconsulting.co.uk/

Go To Top

The Macrotone Consulting Web site would like to use cookies to store information on your computer, to improve our website. Cookies used for the essential operation of the site have already been set. To find out more about the cookies we use and how to delete them, see our Privacy Policy.

I accept cookies from this site.