Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Language overrides do not work in SEF 1.8.9 and Joomla 3.6.5 #16
I like Simple Mail Form very much, mainly because it can be used in modules. Not everyone wants a mail for in content, and for many components solutions like Components Anywhere do not work!
Plus Simple mail form is ... eh, well, simple!
But I found one problem (Joomla and SMF both latest stable versions): the language overrides do not work.
For example: I created one for MOD_SIMPLEEMAILFORM_button_submit and nothing shows up!
Can it be fixed easily?
Met vriendelijke groet,
Here's my report on this request. I'll wait for your decision before I start coding.
Issue – A user reports that Joomla's language overrides don't work in SEF.
Language overrides – This Joomla feature allows users to replace a default text with a custom one, either manually (by creating language files) or through the CMS' administration interface.
Using the admin interface, changes are done in Extensions>>Language(s)>>Overrides. Only one constant's value can be changed for only one language at a time, either for the site or the admin interface. Creating a language file manually is much faster and rather straightforward.
The main benefit of language overrides compared to SEF language files is that user changes won't be lost when Joomla or SEF is updated.
Relevance – The user's comment seems relevant, as the Joomla documentation mentions that language overrides can be used to edit text from the CMS kernel, but also from extensions. A user can therefore legitimately expect to be able to use this feature in SEF.
It is not a bug, however, as SEF wasn't designed with language overrides in mind.
Work required – Joomla looks into the /language/overrides/ folder to see if there's a .override.ini file for the language in use. For this feature to work, the overridden values and their constants must be in /language//.mod_simpleemailform.ini (if we use the English language as an example).
Therefore, each file that currently sits in SEF's language_files folder would have to be installed in the appropriate language folder, for instance /language/en-GB/. To do so, changing the mod_simpleemailform.xml file could prove to be enough.
We would also need to replace the $translang property with Joomla's JText class. For example, line 1 555 in modsimpleemailform.php:
Please note that, in this example, the constant is entirely in capital letters. That's because Joomla automatically replaces small letters with capital ones when the administration interface is used to create a language override.
Risks – Unforeseen problems could make it difficult to complete all changes in time for the Joomla 2.1 deadline.
It remains to be seen if adding files outside of the SEF repository could run into permission issues in some installations. Joomla's module installation process might have all the necessary rights to install files in language folders, reading the settings from an .xml file.
Adding this feature would also create minor backward compatibility breaks. Users who edited some entries in their language files would discover that their changes have no effect in version 2.1.
Mitigating strategies – Some existing modules already implement the language overrides feature. Finding one or some of them to see how they did it might help us gain some time.
The documentation will be updated to account for the changes. If required, it could mention that language files might have to be installed manually in case of a permission problem. Manual installation of language files may also be required when a new language is added to a website.
Comments could be added to the current SEF language files in order to explain the new way to work. They could also link to the relevant documentation.
Conclusion – This new feature would be a welcome addition to SEF as it fits right in with the efforts to better integrate the module with Joomla.
However, since it would create minor backward compatibility breaks, it might be better to wait until version 3.0 to add it.