Do you ever wish you could just code your way past a software limitation instead of waiting weeks, months, or indefinitely for the provider to address your problem?
If you’re in tech, you know there’s only so much room on any given roadmap, and tough calls must be made. Our developers would address every last client concern in the next build if they could, but they can’t.
So they peppered Exago BI with code extension points.
These software hooks allow admins to supplement the application’s code with code of their own. There are hooks for when users interact with things like buttons and menus (action events), hooks for the application’s main processes (server events), and hooks for manipulating BI report data (custom functions).
We’re hooked on hooks because they make our clients’ lives so much easier. Instead of waiting for third-party roadmaps to catch up to their customers’ needs, SaaS providers can implement their own custom solutions exactly to their specifications and on their schedule. (Or, better yet, they can devote some of the service hours included in their Exago contracts to having a solution written for them.)
This is the story of one such extension, a custom function bridging language barriers in not one, but multiple SaaS applications today.
The Challenge: BI Report Translation
Many Exago BI clients have non-English-speaking users and translate their applications accordingly. Exago BI and its reports must be translated as well.
For the purposes of translation, an Exago BI report consists of two discrete user-facing elements: data records and static text. Both must be translated for the entire report to be legible in another language. The only issue is, they’re stored in different places.
Data records are stored in the database while static text (anything typed directly into a report cell) is stored in the report definition. Performing a language translation in the database, therefore, would only solve half the problem. Not only that, but it would be a non-trivial amount of work to build the language lookup tables, adjust all data models to include them, and edit the tenanting schema accordingly. Unless a SaaS provider has a lot to translate, translating in the database simply isn’t worth the effort.
The easiest and most comprehensive solution would be to build a custom function that could be applied to whichever report elements the author needs to translate.
The Translate() function, built by Exago Services on clients’ behalf, uses session information to locate the correct language file and translate the argument. A language file is customizable XML that allows application admins to map ids (the text to be translated) to text (the translations themselves). Those translating reports into multiple languages would use the same set of ids in each language file, substituting different translations.
In most cases, Translate() takes only one argument: the language to be translated. Data records are passed to the function dynamically, and everything else is submitted as static text. If there’s a risk of similar phrases being confused, applications may adopt a naming convention, such as this one for data field names: DataField.[Object].[Field].
The Translate() function is also written to accept multiple arguments as part of a handful of predefined phrases, such as “The report [report name] was run at [time].”
With the help of this custom function, multiple SaaS providers have been able to meet their translation needs without making changes to their database or Exago BI configurations.
Here is a real Exago BI report before and after translation:
They can easily add languages and new translations to those languages without outside help, ensuring that all users are able to consume their reports without confusion.