Making a component truly Multilingual (3)
Following on from our earlier post about item associations. we next turn our attention to look at the front end. This tends to be more complex since it is here that we are actually using the associations to impact the front end displays. To expand upon this, when a user chooses to display the categories in for example ‘German’ it is the ‘de-DE’ categories that should be displayed, along with the appropriate ‘de-DE’ translated text. Likewise if they then choose to display ‘English’ the ‘en-GB’ categories are displayed along with the English text. It is also reasonable to expect that any categories that are marked as ‘All’ languages would also be displayed in each case.
The specific ‘category items’ to be displayed for a chosen language would be the ‘specific’ language items, together with the items marked as ‘All’' languages’. The question of what about the un-translated items which are not associated with a ‘specific language version has also to be considered. This is best explained by considering a specific situation. Assume that we have our ‘Rialto’ component available with a English (en-GB) and a German (de-DE) translation. All of the categories are established with the correct associations, however they may well be a number of different ‘entries’ that are present in only one specific language, which would not then have any associational entries in the other language. In our Rialto example, the entries are ‘classified advertisements’, it is not unreasonable to assume that an advert for an item to buy/sell in German, may not be of interest to an English person, and that might therefore not be a translated version of the advert created. The question is then does one display the ‘German’ item to an English viewer?
We are assuming here that the ‘English’ viewer is displaying the site in the English language, and that a ‘German’ viewer is displaying the site in the ‘German’ language.
Taking this one stage further, assume that we wish to determine the total number of entries in a specific category. On the surface this sounds simple, but once we are multilingual we have a few additional complications. First we have the number of entries for which there is a single language specified (or all) for each of the different associated categories. This means that all the un-associated de-DE German entries in a category are counted together with the number of un-associated entries in the equivalent en-GB category are to be counted. Then we have the entries where we have an entry associated, in this case we only wish to count the entry once, even though there may be a de-DE and a en-GB translation they are effectively the same entry for counting purposes. This makes getting the total number of entries complex in terms of the SQL statement that is required, especially given the underlying table structure, involving sub-queries ( or numerous joins).
The approach we have taken is that we would only, by default display specific items in the selected ‘viewing’ language (plus items marked as being ‘all languages’). Switching the site language to one of the other possibilities would (probably) display different entries. i.e. This marked as ‘all’ and those available in the current selected language whether associated or not).
This might seem complex but should provide the site visitor with the entries in the chosen site language and those marked as visible for ‘all’ languages.
There is also the question of which entries are displayed in the ‘module’ which displays the latest ‘n’ (where ‘n’ is the number) of entries recently opened/created. The entries displayed are interpreted as being those created/opened in the displayed site language and those created/opened as being ‘all’ languages.
Similar to the changes for the back end we have to modify some of our code but the changes are different, mainly because it is only really the actual items created/maintained upon the front end that need the most work. We require changes to any ‘drop down’ selection boxes so that the displayed options are in the chosen site display language, which means changes to the ‘helper’ files. Other changes relate to the displays which are themselves more involved than for the back end, since we can create entries on the front end and (presumably) also need to probably create entry associations as well. This last task is something that, from our study code reading is not something that Joomla com_content does currently so may well be something that we ourselves put on the back burner, leaving the back end to create the associations between entries. Not ideal perhaps but it seems to be something that Joomla multilingual sites are currently having to wrestle with already, so will be familiar to them.
To be continued…