Question about changing the CMDB_CI name field to Translated Text

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-19-2024 09:51 AM
Hello CMDB experts!
We are looking at a request to provide multi language support in our platform and require that all CMDB_CI items could be available in other languages.
To accomplish this we think we could change the cmdb_ci.name field from a string(255) to a translated_text value.
We would like to avoid adding additional fields to the cmdb_ci table to handle this translation so we do not have as much rework on existing forms and future released products (i.e. adding a translated field that is the new display field)
We are aware that this might cause some performance issues. Has anyone done this before or had a similar requirement that they have addressed?
Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-20-2024 08:02 AM
I have no experience with Translated Text field types, but this strikes me as a VERY bad idea.
For the large majority of CIs (all 'infrastructure' classes) the name is the name and wouldn't make sense to translate.
Beyond that issue, it is just asking for problems. Upgrades, unknown errors, reliability, and many other cases are just going to cause you problems going forward. It may take more work to add a field upfront, but it will take you vastly more time to handle the unknowns inn the future. I have experience working with instances where a major change like this has taken literally years to unravel.
If translated names is a hard requirement, I would go the route of ADDING a translated text field at the right level, leave the name field alone and use the companies primary language for the name.
I'd have to dig more for other classes where a translated name makes sense, but the only ones I can think of are Services and it's children. I would start there as the top level class to add the field.
Then in forms where this could be needed, I'd update the display and search to add the translated name column.
Even with that possible solution, you're asking for trouble and limiting the use of some capabilities that ServiceNow provides. The Digital Portfolio Manager (formerly know as Service Portfolio Manager) interface is not customizable, so would become unusable for cases where translated names are required. ServiceNow is likely to add more of these in the future, so you're looking at more issues in the future.
In any case, please tell management there is NOT a viable solution to this requirement.
If they insist, refresh your resume and find a new job. This may sound hyperbolic, but if they don't listen to reason on something like this you're in for years of frustration.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-21-2024 09:23 AM - edited 04-21-2024 09:28 AM
In my opinion, what this points to is a fundamental gap in the CMDB, which is that there is not a separate Display Name field. Unless you customize the CMDB with additional fields and business logic, you are basically required to treat the CI Name field as both a display name and an identifying name. And these two are sometimes at odds with one another. Unfortunately, while it might seem relatively straightforward to do this customization so that a custom Display Name field is used for the display value of the CI, you will find that there are areas of the platform, some of which cannot be modified by customers, in which the CI Name field is used directly as the display value, rather than how most objects in the platform behave, by using the getDisplayValue() API, which triggers all of the basic rules for determining the display value, including the application of any translations. So while I have not attempted this, I am not confident that it would have the desired effect, and it might also be a difficult customization to maintain. Using a custom field to achieve this seems like a safer approach. At the very least you should approach this with some skepticism and careful and thorough testing, regardless of which direction you go with it.
The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.