PDF Report translate in execution time

Support
#1

According to the Cuba platform documentation, to translate the names of entities and attributes in the User Interface, it is enough to create special message packages containing the entities and their respective translations (https://doc.cuba-platform.com/manual-latest/entity_localization.html).

For example, to translate an entity called Customer, with the properties Name and Address, into the language PT_BR, it would be enough to create the following message package “messages_pt_BR.properties”:

Customer=Cliente
Customer.name=Nome
Customer.address=Endereço

Could this translation method be used to automatically translate elements (label and content) created from an SQL query into a PDF report, generated at runtime? I couldn’t understand a way to do this using the “messages.properties” or “messages_pt_BR.properties” file. If there is a way to do this, could you give an example?

#2

To get localized messages you should use the Messages bean.

To use it in a report, perhaps you need a Groovy Dataset which will allow you to process the data loaded from the database.

#3

Thanks for your recommendation, Konstantin.

The question was “whether it would be possible to use only the Messages bean, native to Cuba Studio, to translate the report elements and their respective values”. But as you explained, another form is needed (like a Groovy script or in our case an SQL script).

The solution we found to translate elements (fields and values) of a report uses a component that we developed for translation at Tupy, and it is a SQL Dataset. To do this, we load the data (for example, field “model_type” with the value “explosion engine”) from a specific table (for example, “equipment”), and its corresponding translation (the value “explosion engine”) from a translation correlation table, and then we display it in a report, passing the language as a query parameter (for example, pt_br for Brazilian Portuguese).

So, if it is necessary to translate the field names and their values ​​in the reports into another language (such as Spanish, for example), we just need to register the field names and their values ​​in the new language in the database.

This approach we used serves us well: We leave the Messages bean for translating messages and fields displayed on the screen, and use our component to translate SQL Dataset elements used in reports.

What do you think of our approach?

#4

Hi Fabiano,

Sure, why not.
If you store translations in a database table, you can use them in a SQL dataset directly.