In previous blog posts I've talked about the idea of hard-coded strings in certain Methods and API's and how bad they are (because those strings aren't translatable when they are hard-coded. A few years ago I wrote an app in one of our internal hackathons, to go and scan an instance to find such hard-coded strings so that an Admin could easily find them and rectify them.
You might be wondering, "why haven't you released it? it sounds like it could be super useful", and whilst it is pretty neat I didn't want it to overlap another feature that is already available to you, which we'll get into in a little bit.
What we need to look for
The first challenge is knowing what we need to look for and knowing how to fix it. So as a quick recap of the 5 translation tables, we only need to concern ourselves (in this scenario) with what we would expect to put in the [sys_ui_message] table. If we have a quick recap from our "In-Platform Language Support Guide" we have a nice handy table of what we're talking about here:
| API | Type | Correct example |
| alert() | Client-side |
alert(getMessage('hello world')) |
| confirm() | Client-side |
confirm(getMessage('hello world')) |
| addInfoMessage() | Client-side |
g_form.addInfoMessage(getMessage('hello world')) |
| addInfoMessage() | Server-side |
gs.addInfoMessage(gs.getMessage('hello world')) |
| addErrorMessage() | Client-side |
g_form.addErrorMessage(getMessage('hello world')) |
| addErrorMessage() | Server-side |
gs.addErrorMessage(gs.getMessage('hello world')) |
| addWarningMessage() | Client-side |
g_form.addWarningMessage(getMessage('hello world')) |
| addWarningMessage() | Server-side |
gs.addWarningMessage(gs.getMessage('hello world')) |
| setLabelOf() | Client-side |
g_form.setLabelOf([field],getMessage('hello world')) |
| showErrorBox() | Client-side |
g_form.showErrorBox([field],getMessage('hello world')) |
| showFieldMsg() | Client-side |
g_form.showFieldMsg([field],getMessage('hello world')) |
| prompt() | Client-side |
prompt(getMessage('hello world')) |
This isn't an exhaustive list but it's a good place to start, because generally speaking we can see that for a Client-side script we need to ensure we have "getMessage()" in the chosen method, and for Server-side scripts we need to ensure we have "gs.getMessage()" in the call as detailed above.
For those who like something a bit more visual (and it also shows what we need to do for portal Widget's) here's a little slide:
What can we do to find our infractions?
So, in theory we are just dealing with data. It's just a different form of data. In this example, our data is in specific fields in specific records on specific tables. E.g. the "script" field for Business Rule's is [sys_script] and so on and so forth.
A few releases ago a super handy tool called "Instance Scan" came out. And some very clever people have over time made all sorts of "checks" and definitions for finding all sorts things you would want to keep on top of for best-practice considerations. Ranging from certain properties being enabled, to use of "var gr" (yeah I went there 🙂) to more advanced things.
Realistically then, there's no reason we can't use it to also find the types of things we want (detailed above). Instance Scan has the ability to scan an entire instance, an Application Scope or even an Update-set which is ideal for what we want to do here.
I was in a call with a Customer just last week who wanted to know how compliant their Portal was in prep for adding multiple languages. Well, this is for you (and everyone else who needs it).
This is a prototype
What I'm sharing here today is just my team's first version. We will refine it over time and look at adding more checks in the future. However, currently it will check for the following:
Incorrect use of:
Now this last one is super super super complex, partly because we can't just rely on checking "html" fields but because HTML could be anywhere. It could be in a declared string variables in JavaScript, or it could be in XML (Jelly I'm looking at you), and it could be on one line or multiple. Hence it does have the potential to throw a false positive in scenarios like:
<div>${this is <h2>my</h2> message}</div>
Outside from that it should be good.
It's also important to note that there are many more checks I'm looking to add, but this should serve as a good starting point for now.
Here's an example of a test run I did on one of my instances to show you how the output would look like:
And if we look into the first result in more detail:
And indeed the infraction (I've highlighted it for this specific "check") is here;
Also, due to the massive complexity of the checks in question, if you are performing a full instance scan - it will take possibly a few hours to run.
I also can't promise every "find" (as Instance Scan calls them) is going to be 100% correct each and every time. As nice as that would be, it simply isn't realistic. So if you come across a few quirks, drop a comment below.
The update-set
This update-set is not an official product by Servicenow, it is offered without any warranties or support and it should just be considered as a "Proof of Concept" at this stage. Maybe one day it will become part of the product ootb, but currently it's not.
Please only use this on a DEV / Sub-Prod instance for the typical development best-practices (it's important to note that these types of tools should not be used a PROD environment).
And if you have any questions or suggestions, put them down below and we'll review them for future ideas. Also keep an eye on this thread as we will be occasionally adding more "checks" very soon so it's worth "following" this thread to be notified when we post an update.
As always, if you found this useful, please like, share and subscribe for more as it always helps
