Common Terms/Concepts
In order to account for different regions having different terms for the same thing, certain terms/concepts are referenced via some common NLS so they can be easily replaced everywhere in the system and do not have to be laboriously replaced everywhere they appear.
Common terms are defined in an NLS file just like other strings, and can be overridden as shown above, under the 'common' path. These common strings are referenced in the NLS as embedded variables using the same format as other NLS substitutions, for example:
{
...
menus.editEvent = 'Edit {COMMON__.event}',
...
}
 
Unlike other NLS strings, the key of the common term can be capitalized to capitalize the end result, for example, 'Edit {common.Event}' will become 'Edit Event'. This avoids having duplicates of all the capitalization options in the common NLS.
An example of overriding common NLS terms can be found in exampleCustomConfig.jsonc:
"nls": {
"common": {
"an_event": "a job",
"event": "job"
},
...
Note on Grammar Issues
There are some issues around grammar when doing this, so, in addition to event, in the common terms above we also have a_event, defined as "an event". This is because if we wanted to call events jobs, we couldn't just replace event with job, as "an job" is not grammatically correct. Having an event defined as "an event" allows it to be changed to "a job" and so the substitution works grammatically.
Similarly, we have openSwitch and openedSwitch, to account for the instruction versus the state.
Testing Changes
To test changes made to configuration files simply log out and log back into the Flex Ops client. This should work, but, if you do not see your changes reflected in the UI, complete the following steps.
1. Check the browser console log for an error indicating a problem with your configuration.
2. Edit your JSON files in a JSON aware editor, such as VS Code, to see any syntactical errors that would prevent Flex Ops from loading the configuration. If used with WinSCP, you can open the files on your server directly in VS Code, edit them, and changes will be saved to the server.
3. While very unlikely, you may need to force the browser not to cache the files because browsers are sometimes reluctant to check for new versions of files that they have recently downloaded. The most reliable way to do this is to use the browser development tools to disable the cache and, when you refresh the page, you should immediately see any changes reflected in the UI. Only do this if you experience issues with your changes not reflecting in the client, a simple refresh is all that should be required.