Authoring multilingual business rules allows you to create multilingual messages, values and options within your business rules. In this post, we are going to discuss multilingual messages. This will provide the ability to use the correct translation on runtime and design time for business rules messaging. This is very useful, especially when there are multiple applications using the same business rules or there are multiple users using an application all around the world, as well as rule authors and business analysts working on business rules with different language preferences.

Previously, we discussed how to load different translations of your business rule messages (notification feedback) from an external datasource. In this post we are going to show you how you can add these as part of your rule project instead of an application.

Embedding Multilingual Messages in Business Rule Models

Another option is to include the messaging as part of your ruleset package. Using FlexRule Designer to maintain messages enables you to share these messages across multiple applications. Also, it offers you suggestions based on your system settings (Culture) while modeling multilingual business rules. To do that, you can simply add a resource to your rule project in FlexRule Designer:


Then you maintain different translations for messages.

The default message translation:


And the rest of the translations:



On execution of the rule, these will be loaded automatically. There is no need to register them, unlike the other approach described in our previous article.

The other benefit of this approach is that when modeling rules, the multilingual resource will be used to provide hints during rule entry based on the current system culture:


Now if you had set the language in the Control Panel of your operating system to Italian:


Then the suggestion box will provide the appropriate messaging (Italian translation):


On the runtime side of business rules execution, as discussed in the previous post regarding multilingual, the value of locale (Culture) is picked from Threading.CurrentThread.CurrentUICulture, not your operating system settings. That gives you the ability to process different translations on each thread.

We have not created parameterised messages here, but remember, you are always able to parameterise all of these messages when necessary.


When notification messages are managed as part of the business rule project, and eventually will be rolled out as part of your ruleset (i.e., rule package), then all the applications using the business rules will receive the same consistent localised messages as feedback from executing business rules.
On top of that, the authoring environment will provide hints while modelling rules according to your language preferences.
You can also extend this behaviour to let the system load different messages (in a different locale) from any other data source, either on rule execution or authoring.
To learn more visit


Multilingual user feedback in a business rule platform are important, and simply can be achieved by providing different translations of rules in your rule project. Or you can load those translation resources from an external data source (e.g., database, application file, etc.).

There is more to multilingual capabilities when it comes to business rules. For example, these affect the Business Glossary and the value options that are defined in the glossary. We will be discussing the glossary for multilingual business rules in a future post.

Read More

  1. Authoring Multilingual Business Rules
  2. Multilingual Business Rules Messages

Last updated April 3rd, 2023 at 11:09 am, Published October 26th, 2015 at 11:09 am