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