Support Offline : Mon - Fri / 10am - 6pm (GMT +6)

Your Time: Our Time:

Multilingual support for SP Property - hardcoded strings and incorrect queries?

Featured Lock Resolved Issue

we've noticed when setting up a multilingual site that we've run into a couple of issues, so far:

- How can we translate the "Read more Text" string which, instead of being read from the translation files, is being read from the component settings - we can set it for one language, but then that string will be used for all of them - this is a multilingual site, so that's out. We tried using a hard-coded translation string and then using an override for it, but it doesn't work for us.

- When using the Categories module, it loads all categories in one language (those that should load as well as categories in other languages) and none in another - even though our categories/menus do have language settings applied, same as the modules themselves.

Any ideas? Thanks!

Attachments (1)

  • spproperty-modulebug.png
    spproperty-modulebug.png 455.1 KB

11 Answers

Toufiq - Staff

More than a month ago #Permalink
Hi there,

Thanks for contacting us. Your screenshot doesn't exist the read more string. Would you please share a screenshot & share your site URL to check the issue.

Can't give you a link, so I made a screenshot from the component - list of properties view (option=com_spproperty&view=properties) and included the backend location where the string is entered AND what happens if I turn on language debugging (the string doesn't seem to be set up for multilanguage?)

By the way, the same happens on this menu view: option=com_spproperty&view=maps

Attachments (1)

  • spproperty-more-string.png
    spproperty-more-string.png 61.9 KB

Toufiq - Staff

4 weeks ago #Permalink
Can't give you a link, so I made a screenshot from the component list (option=com_spproperty&view=properties) and included the backend location where the string is entered AND what happens if I turn on language debugging (the string doesn't seem to be set up for multilanguage?)

Hi, @Boštjan Gorenšek# Thanks for giving me the feedback. Without checking your issue how can i solve your problem? Thanks
I don't think it's necessary here, and I can't give you a link to the site being developed for privacy reasons.

Only thing I can think of is if we were to install a secondary instance of a site and reproduce the issue there, then give you admin access to that.

I guess I'll go do just that.

Done. Observe how the same "more" text appears in both languages when it comes to both component views (this is the string that's defined in ADMIN BACKEND, not language files), yet the lower module view can be translated just fine. Also note how with the lower module view, when language debug is turned on, those links get *parsed*, while the component view ones don't have ** around the strings, as if they're not set for multilingual support.

Also observe how the categories show up in both languages in the category list menu calls, but appear correctly in component view.

Where do I send admin credentials? Thanks.

Toufiq - Staff

3 weeks ago #Permalink
Hi there,

Thanks for your feedback. Please check the screenshot

...what does that have to do with our issues? It's just turned on to illustrate the multilanguage problem, the same happens if it's off - I'll set it to off but the problems will remain.

Toufiq - Staff

3 weeks ago #Permalink
...what does that have to do with our issues? It's just turned on to illustrate the multilanguage problem, the same happens if it's off - I'll set it to off but the problems will remain.

Hi there, Please provide me the Joomla administrator access & FTP access via PM. Thanks
Credentials sent.

Regarding your reply via PM, why is this problem so hard to understand and why can't you see what the problem is, even after looking at the backend?

So far I've fixed one issue myself, the other I'm still trying to solve.

The multilingual support in this component and its modules seems unfinished.

Once again: The "more" button's text in certain scenarios (outside of most of the modules where it works correctly), instead of getting the language string from language files, is getting the string from the backend setting field instead. So instead of a different string for each language, it loads just one string for all of them!

So instead of this happening:
English: "More..."
Slovenian: "Več..."

what happens is either:
English: "More..."
Slovenian: "More...", which is wrong

English: "Več...", which is wrong
Slovenian: "Več...".

Basically using whatever is typed in the backend on all languages. If a string is being loaded from a general settings field, how are we to set different strings for each language?

So since I didn't see how I'll get any help here with this issue, I've fixed it myself. In case anyone else runs into this issue, this is how you fix it:

Navigate to /components/com_spproperty/layouts/properties
Edit the file "property.php"
Near the top you'll see this:

$property_rm_btn = $this->cParams->get('prpry_rm_btn_text', JText::_('COM_SPPROPERTY_PROPERTIES_BTN_TEXT'));

Change it to:

//$property_rm_btn = $this->cParams->get('prpry_rm_btn_text', JText::_('COM_SPPROPERTY_PROPERTIES_BTN_TEXT'));
$property_rm_btn = JText::_('COM_SPPROPERTY_PROPERTIES_BTN_TEXT');

The first line was the original, which I commented out, then provided the second line.

I do suggest that instead of changing the core files themselves, you do this via an override.

This way, instead of it looking at the global backend string setting for "Read more" that it's grabbing from the Parameters, it will grab the strings from the appropriate language files, thus ensuring proper multilingual support for this string.

My guess is that it's supposed to be written in a way that if the user writes something in the backend, it'll use that, but if they don't, it'll use the language files. However, you can't leave that field empty - it will auto-populate upon saving with the default "Read more".

The other issue with the module which loads categories is tougher for me to grasp why it's happening - it will load categories, regardless of whether the language set to the category matches the current language or not - as if they'd be set to "All" instead of a certain language!

So for example, if you'd have the following categories:

  • Cat 1, lang. set to English
  • Cat 2, lang. set to All
  • Cat 3, lang. set to Slovenian

you'd expect that, when viewing the page in English, the module would show Cat 1 and 2, while looking at it in Slovenian, the module would show Cat 2 and Cat 3. Instead, it's showing all 3 in any language. And yes, the modules themselves do have the appropriate languages set. I tried it with it set to "All", and the issue persists anyways.
I was able to fix the second issue myself as well. It's a hack and not efficient, but until this component gets patched, at least it works.

Here's how:

Make an override for this file: /modules/mod_spproperty_categories/tmpl/default.php

Towards the top, under the user query, add this:

$lang = JFactory::getLanguage();

That will enable you to see, what language the CMS's session is currently set to.

Then, just after the foreach loop's initialization (but before its contents), add this:

if ($lang->getTag() == $category->language || $category->language == "*"):

and then close the if check properly before the loop's contents end.

That'll tell the module to, before rendering out the category, to first check if it's either set to the same language as the sessions' is, or if it's set to "all".

Again, it's not the best solution, but I can't wait any longer so it'll have to do.

I'm really disappointed with the level of support here, I've been using Helix for years now and have generally been impressed and thus expected better. I guess I should be angry at myself for not initially taking the time to debug this myself in the first place.

Having said that, I do apologize if I've been unintelligible in communicating what the issue was

Oh well - at least this may help someone else until the component and its modules get patched.

There are no replies made for this post yet.
Be one of the first to reply to this post!

Leaderboard (30 days)

Paul Frankowski

Paul Frankowski

Total Accepted Answers: 122


Total Accepted Answers: 112
Mehtaz Afsana Borsha

Mehtaz Afsana Borsha

Total Accepted Answers: 58
Ofi Khan

Ofi Khan

Total Accepted Answers: 57
Rashida Rahman

Rashida Rahman

Total Accepted Answers: 35




Community Users


Don’t miss any updates of our new templates and extensions and all the astonishing offers we bring for you.
We never spam

Joomla! ® name is used under a limited license from Open Source Matters in the United States and other countries. is not affiliated with or endorsed by Open Source Matters or the Joomla! Project.

Connect Us