Oracle Forms : dynamic translation tool

The purpose of this tool is to allow dynamic translation of the Oracle Forms modules.

The translations are stored in Oracle tables and read on loading of each dialog.



A dialog is provided to manage the translations (TRANSLATE.FMB).
The lists allow to select the particular module and the language you want to translate, then show all objects of the corresponding module.

 The Options tab allow to translate the Radio group options button labels, Alert buttons and LOV column titles.




The translations are stored in 4 database tables:

TRANS_LANG that store the different languages
TRANS_ITEMS that store the items translations
TRANS_OBJECTS that store the single object translations (Window, Alert, LOV)
TRANS_OPTIONS that store the multi-option values for Radio Group option buttons, Alert button labels and LOV column titles.

How to populate these tables ?

A PL/SQL library is provided with the solution (translate.pll)
It contains a package (PKG_TRANSLATION) and 2 procedures.

One to store the information in the tables : store_translations()
One to read information and dynamically translate the module labels at runtime : read_translations()

1. When you want to populate the translation tables, use the following instruction in the When-New-Form-Instance trigger of the module:

   PKG_TRANSLATION.store_translations('language_code');

Where language code in one of the code stored in the TRANS_LANG table.

e.g.     PKG_TRANSLATION.store_translations('EN');

Once the translation are stored, you can remove this instruction and modify them with the TRANSLATE.FMB dialog.

2. To translate the screen, use the following instruction in the When-New-Form-Instance trigger of the module:

   PKG_TRANSLATION.read_translations('language_code');

Where language code in one of the code stored in the TRANS_LANG table.

e.g.     PKG_TRANSLATION.read_translations('FR');



As you can see, some objects are not automatically stored in the database, because it is not possible to get them at runtime:

   . Option buttons for radio groups
   . Alert buttons' label
   . LOV column's title

So you will have to manually add them in the TRANSLATE.FMB dialog


Installation:

   . Get the translate.zip file
   . Unzip the translate.zip file
   . create the database tables with the create_objects.sql SQL script
   . add the languages you need in the TRANS_LANG table
   . compile the TRANSLATE.FMB module
   . attach the translate.pll library to your modules to store, then translate them at run time.

Comments

[Komla]

how do i register to download this brilliant tool please?

[Francois]

Ok the zip file is uploaded to a new free location.

[Francois]

I will upload ASAP the zip file to another location more easy to reach.

[Evelin Nußbaumer]

Hi Francois Degrelle,


first, thanks for your site, there are many examples, which can help us. My question is concerning to your dynamic translation tool.


Did you invest any time to enhance this example in the last view years. I think of solving the proplems with getting properties for the following object at runtime:


Option Buttons for radio groups

Alert button labels

LOV column's properties (I've found Oleg Tishchenco's Java Bean)



Have any of you experience with Oracle TranslationHub?


Thank you


Evelin


  

[Francois Degrelle]

No, this tool has not been updated. It was 100% PL/SQL made of, and would need Java (JDAPI) to find the label that cannot be handled by Forms at runtime, like Radio Button labels.
Oracle Translation Hub has nothing dynamic in the way that it build as many different .FMB files that you have different languages.

[Aneel Kanuri]

Hi. It is a bit confusing what you are saying and the tool is behaving. Just clear me one question:1. Do we need to manually enter the French strings against each English string or translate.fmb will do it for us?                      If it does, please tell me characterset of database we need to set it to and any other such pre-requisites.Sorry for bothering much as I did complete tool test yesterday, I found it is not translating anything. Thanks,Aneel Kanuri

[Francois Degrelle]

It is not a translator! It allows displaying the same Forms module with different languages, by dynamically reading the translations from the database table.

[Aneel Kanuri]

Do you mean that I need to keep the corresponding translations manually in the fields?? Because when I select French in the drop-down box, it is showing forms error "Query caused no data to be retrieved".

[Francois Degrelle]

The goal of the Store_Translation() is to create in the database table one row for each item found in the given module's name. The translate.fmb file is provided to enter translations in front of
each item, in as many languages as you need.

[Aneel Kanuri]

Hi,      I really appreciate your quick reply. I opened the translate.fmb and not sure what is the functionality of it as it is not mentioned in your article. In translate.fmb it is showing the module name and language as "English". I guess that translate.fmb is just for confirming whether it is populating the trans_objects/items tables in backend. Is there any further usage of that? Could you please tell how to translate my form from english to French using translate.fmb?                       If you are free to contact on some other mode / time, please let me know as this is a very interesting article and I want to know how it works. Thank You,Aneel Kanuri.

[Francois Degrelle]

Yes, the purpose of the translate.fmb sample dialog is to put translation face to the objects read by a previous Store_Translations() procedure.
Select a language in the translate.fmb poplist, then put the corresponding translations in the fields.