The Universal Language of…Soccer?

With the World Cup in full swing, we are reminded yet again of the diversity of our planet. Personally, I’m also reminded of the fact that so many people actually like soccer…or football…or whatever they call it. But hey, with the hockey and basketball seasons completed and the embarrassment of Chicago baseball in full swing, I can at least appreciate the fact that all of these different countries and cultures unite every couple of years in the name of athletic competition.

Countries like Germany, France, Cameroon, Japan, Greece, Italy, Croatia, Ghana, and Argentina are all competing. Admittedly, I had to look that information up. Anyway, that’s a lot of different languages. In the midst of a game…or match…or whatever they call it, it’s probably not a big deal. In the business world, it gets a little more complicated.

When in Rome…or Houston…or Madrid

For example, when Hank in Houston uses your software, he needs to see the user interface (labels, dialogs, etc,) rendered in English; whereas Maria in Madrid wants it presented in Spanish. That’s localization. Building a localized product has typically been managed with resource files. These resource files contain all of the translations for the different languages your application needs to support. When your software gets built, the resource files get embedded along with the rest of the code. When the application executes, it then matches the machine’s language settings to the software’s appropriate resource file to use the proper translations. Nothing overly magical about it, but what happens if you need to localize results or output from your business rules? Or, even better, what happens if you don’t want to have to rebuild your entire application just because you had to change a translation in a resource file?

Keep it in Line

Use Inline Tables. You can define the columns, specify the data types (Boolean, String, Date, etc.) and build queries against these tables – all within irAuthor. However, unlike tables in an external database, all of this information is stored in the rule application, which means the person doing the rule authoring can also manage the translations too. Typically, this would support retrieval of messages or other output you want to surface back in the calling application.

Then, when you create a rule that needs to get the translation for a specific language, just do a lookup on the table using the LCID (localization ID) to find the matching value.

Attribute It to the Interface

When you define your data structure in irAuthor, you create entities where each entity is made up of individual fields. For example, you may have an entity called “Customer” that has the fields “Name”, “Address”, “Phone” and so on. What if you want the code in your calling application (the one that’s executing the business rules), to get the localized translation for those individual field names? Here’s where you can take advantage of attributes.

Create some key/value pairs that match LCID to the translation. In the example above, the “Name” field now has some additional metadata to support its localization. And now your developers can get the appropriate value using the InRule SDK like below:

Set Your Sights on the Goal

These are just a couple choices worth considering if you want to support your localization efforts from within your business rules. The nice part is that these are not mutually exclusive options. If you need to support output translations and user interface translations, you can easily work both of them into your rule application. Again, not only can the rule author manage the translations directly, but you also get the added benefit of eliminating any need for making code changes to do so.