The issue in the title not so rarely arises before the owners of Joomla sites. Now you need to add your own text, now to change the clumsy or uninformative (and quite often - full of mistakes) text compiled by the developers of third-party extensions. There is a fairly intelligible interface for overriding the constants in the Language Manager of the site's administrative section (Solution 2), and one can actually be content with it. But if you, like me, are interested in thoroughly understanding the language structure of Joomla, then this article is for you.

In the article about replacing the outdated captcha of JComments component with reCAPTCHA v2 (NO CAPTCHA) from Google, changes in the component code are described. Herewith, since this new captcha does not require entering the alphanumeric code from the image, it was also necessary to replace the error message.. The original English message was loaded from the language file of the component by a constant:

ERROR_CAPTCHA="Please enter security code displayed in the image!"

The new text, in full accordance with Google's, should be this: "Please verify you're not a robot!".

In terms of solving this seemingly simple task, I will try to sort out all the details of working with language constants. We will consider alternative solutions and state the logic of choosing the final one.

Solution 1. At the template level

Before we go directly to captcha, let's make a short tour into the theory and review the structure of language folders and the format of language file names.

In Joomla 1.5, the language files of template (as well as of all other extensions) were copied by its installer to the subfolders of system folders language - for the site, and administrator/language - for the admin area. Starting with version 1.6, it became possible to use language files directly from the extension folder. At the same time, for backward compatibility, Joomla developers retained the support of files from system folders. The engine checks if there is an appropriate file in the folder

[site root](/administrator)/language/[language tag],

and if it finds one, it loads it. If the engine does not find the files there, it checks the language folder of the extension. For a template, this will be a folder:

[site root]/templates/[active template name](/administrator)/language/[language tag],

and the standard format for the name of the file itself -

[language tag].[extension type]_[extension name](.sys).ini

The language tag is a full five-character language name (en-GB for British English, ru-RU for Russian, etc.).

Let's return to our captcha. We will consider the case: language - British English, part of the site - front-end, template name - my_template. The prefix [extension type] for templates is tpl. The path to the language subdirectory of the system folder will be:

[site root]/language/en-GB,

and to the same in the template folder:

[site root]/templates/my_template/language/en-GB.

The file names will be identical:

en-GB.tpl_my_template.ini.

If the installer of your template has copied the language file from its language folder to the system folder, work with the file in the system folder. If you did not find it there - edit, respectively, the file in the folder of the template itself.

Let's try to add a constant ERROR_CAPTCHA:

ERROR_CAPTCHA="Please verify you're not a robot!"

Save the language file, refresh the page in your browser and receive evidence that the message text has not changed. This indicates that the constant was loaded by the JComments component earlier than by the template. Accordingly, at the template level, it is not possible to override the constant value specified in the language file of another extension. (For JСomments, this file is en-GB.com_jcomments.ini).

But if you replace the name of constant ERROR_CAPTCHA by a new one - ERROR_RECAPTCHA_V2 in the JComments code, and then add the following line in the template language file:

ERROR_RECAPTCHA_V2="Please verify you're not a robot!"

- the message will change to the required one.

Conclusion. At the template level, you can only add your own language constants. The engine does not allow to override those that are already specified in the language files of other extensions. The method has very limited application: it is reasonable to implement it in case the site uses more than one template, and a certain constant in some of the templates must have different values. At the same time, I considered it useful to examine this option for a full understanding of the mechanism for connecting language files and loading language constants.

Solution 2. At the website-wide level ↑

Here will be reviewed options for using the functionality of Joomla admin interface, as well as manual work. The analysis is made again on a real example of this site, and it should be finally clear what considerations led me to the decision of assigning my own constant. So, step by step.

1. In the Administrator service, open Extensions - Language(s) - Overrides:

   

   You get into the appropriate section:

   

   As you can see, I already have two overridden constants. Let's add one more constant to the list.

2. Since we are working with English language and the user part of the website, the default value English (en-GB) - Site of the Filter field is OK. Click the New button. You get to the Edit Override page.

3. Joomla developers gave us the opportunity to check whether a constant exists in one or more language files. Search can be carried out both by the name of the constant, and by its value.

   Enter the name of the ERROR_CAPTCHA constant in the search field. From the Search For drop-down list, select the Constant option. After clicking Search button, you will get the search results:

   

4. In our case, we found two ERROR_CAPTCHA constants with different values. To find out which extensions they belong to, move the mouse cursor one by one to each constant name in the results list. The tooltip contains the name and path of the language file in which the constant is found. The results for our case:

   

   

   So, the constant ERROR_CAPTCHA is used by two components: AcyMailing and JComments. Overriding the existing constant will change its value for both components. In the case of captcha, you can go for it, since the message "Please verify you're not a robot!" is universal for any type of captcha. But our original goal is to change the message text only for JComments, without affecting other existing extensions. It is also possible that in the future you will install other extensions that use the same name. The introduction of your own constant reduces the risk of uncontrolled side effects. Of course, this has its downside: you have to make changes to the extension code and keep them when upgrading versions.

   The fact that integration of reCAPTCHA v2 (NO CAPTCHA) into JComments is itself followed by customization of the component code was for me the decisive argument in favor of adding a new constant - ERROR_RECAPTCHA_V2. Follow-up just illustrate this process.

5. You can click on one of the existing constants in the list of search results. As it is written in the help, the fields Language Constant and Text are automatically filled with the name and value of the constant, after which you can edit the contents of both fields. Or, just enter the name and value into the empty fields. The result in any case will be:

   

6. Save changes. Constant has been added. You can test and make sure that the message now looks like it should.

But we do not stop there. We wonder, in fact, where our constant and its value were physically added. In the same window at the bottom left there is the File field. When you move the cursor over the title, you will see an explanation:

However, the contents of the field are not editable, and the value does not fit into the static rectangle of the text entry element. But if you click on it and press Ctrl+A, then Ctrl+C, the contents of the field will be copied to clipboard. After inserting it into any text document, you can see the whole line and make sure that the information we entered is saved in the file

[site root]/language/overrides/en-GB.override.ini.

After you find this file and open it for editing, you can see that it contains all the added or overridden constants:

ERROR_RECAPTCHA_V2="Please verify you're not a robot!"
COM_CONTENT_REGISTER_TO_READ_MORE="Register to read entire article..."
COM_CONTENT_READ_MORE_TITLE="Read entire article..."

By manually changing any data and saving the file, we make sure that the changes are picked up both in the admin panel and on the site itself.

Thus, we found out that there is a manual method for implementing the goal set in the title of the article. For language files in the Administrator part - all the same, only the path to the file would be:

[site root]/administrator/language/overrides/en-GB.override.ini.

In general, the path and name of the file that contains the overridden language constants can be specified as follows:

[site root](/administrator)/overrides/language/[language tag].override.ini

In the original distribution of Joomla there are both overrides folders, but they do not contain language files. The engine generates the corresponding file when (re)determining the first constant through the Language Manager interface. In the case of manual method, you can create the file yourself according to its format.

Let's summarize

Hopefully, all this long discourse helped you to understand the language mechanism of our favorite CMS. Let me finally outline the basic principle of this mechanism. It consists in the sequence of loading language files by Joomla engine, and this sequence is as follows:

1. Files in the "overrides" folders;
2. Files of extensions from system language folders;
3. Files of extensions from the language folders of extensions themselves;
4. Files of active template from system language folders;
5. Files of active template from the language folders of the template itself.

I will remark in passing that some extensions can change this sequence. The same JComments component, for example, in the absence of its constant in the additional language, looks for it in English.

And the main practical conclusion: do not edit language files of extensions. Override their constants (or enter your own) in accordance with the methods described here.