Create a standard for naming keys of settings, lexicons, etc

[Ruslan-Aleev]

Feature request

Summary

Lexicons

There is confusion in the keys, for example, there are duplicate lines with different keys (for example, new_tv | tv_new | add_tv), there is also excessive terminology.

I propose to mark the standard of the name of the keys, and bring the current keys to the new standard (many duplicates will be deleted for lexicons).

For example:

element - the name of the element, for example, template;
element_create - Creating an element (template_create);
element_edit - Editing an element (template_edit);
element_delete - Delete an element (template_delete).

It also makes sense to designate the lexicon file in the name, for example:

chunk.chunk_create
or
chunk__chunk_create
or
CHUNK_chunk_create
or
SETTING_site_name
SETTING_site_name_desc

Settings

Also it makes sense to connect other elements through the key, if they are connected according to logic, for example in the system settings:

site_enabled (instead site_status)
site_index (instead of site_start);
site_404 (instead of error_page);
site_503 (instead of site_unavailable_page).

The key must clearly indicate its "essence" and "location" of the element, and only then the "action" or "characteristic":

mgr_source_icon
mgr_browser_sort_default (but not modx_browser_default_sort)

Using the example "mgr_browser_sort_default" key, we see what needs to be written:

1. "mgr_" - because this prefix clearly gives an understanding that the key belongs to the Manager, the "modx_" prefix is wider and the "mgr_" prefix is already used in other keys.
2. "mgr_browser_sort" - here we understand that the key refers to sorting in the browser, instead of "modx_browser_default" - here the key refers to the browser itself, which is confusing.
3. "mgr_browser_sort_default" - here we understand what sorting state is needed, and in the "modx_browser_default_sort" variant we only now understand that this is sorting in the browser and its state.

There are many discussions, but there is no standard, it is necessary to designate it and always refer to it.

Related issue(s)/PR(s)

#13554
#1188

[JoshuaLuckers]

Lexicon keys should be easy to group, sort, filter and describe their purpose.

A lexicon named setting_site_page_error can be open for interpretation because it does not clearly describe its purpose. For example is this key used in a situation where an error occurs if I edit a setting related to setting site page or does it used for something else?

[Ruslan-Aleev]

About the sorting of the settings was also a thought - #14254
In this case, I gave an example with keys so that they are next to the list, perhaps more intelligently name, for example:

setting_site_index
setting_site_404

[JoshuaLuckers]

To describe a key's purpose I think it would be better to name them like this:

• setting_name_site_index_id
• setting_description_site_index_id

Without context it's more clear for a translator that values for those keys should describe the name/description for something referring to an "site index identifier" setting.

[Ruslan-Aleev]

The problem is not so much in the writing of keys, but in the fact that there are too many variants for keys, for example, the section "Back-end Manager" in the "System Settings":

manager_week_start (more correct mgr_week_start)
mgr_source_icon (mgr_source_icon)
modx_browser_default_sort (mgr_browser_sort_default)

[Ruslan-Aleev]

Related with - #12493

[Ibochkarev]

@JoshuaLuckers @alroniks @Jako @Mark-H @opengeek Guys, we are ready to start this work! But we need your thoughts on how to do it better!

One PR will make a replacement in one lexicon file. Each key change in the lexicon file and in the places where they are specified will be a separate commit.

We need to prompt again by the rules of naming and we start!

Work is important!
I ask to take part, that would not work - that we will do and will be in vain and the PR will not accept.