Our application is built in the AppBuilder environment with smartObjects from the adm2.
Now we start to integrate ProDataSets and .Net components. Who has experience to use the Translation Manager from Progress on .Net GUI. and Within ABL OO GUI objects.
Or do we need an other approach to support a multy language application.
Regards,
Peter Wokke
Our application is built in the AppBuilder environment with smartObjects from the adm2.
Now we start to integrate ProDataSets and .Net components. Who has experience to use the Translation Manager from Progress on .Net GUI. and Within ABL OO GUI objects.
Or do we need an other approach to support a multy language application.
Regards,
Peter Wokke
Flag this post as spam/abuse.
Technically Translation Manager and GUI for .NET are compatible.
But…. When using the Visual Designer to build screens, I recommend to use a different localization approach. When you start building Forms in the Visual Designer, the InitializeComponents method which is generated to build the layout of any GUI for .NET Form, User Control and custom Component also contains lots of Character values. Progress allows you based on a preferences setting in Eclipse to :U all strings or none. It’s a workspace setting, so applies to all Forms or none. The beauty with the AppBuilder was, that Progress knew which strings should be :U’d and which ones should get other Translation attributes.
Progress does not offer this distinction for .NET Controls. So the fact, that the Text Property of a Form (title bar) should be translatable, it’s Name property probably not, that the :SharedProps:Caption property of a Button on the UltraToolbarsManager should be translatable and the :Key property should not is not honored. You can :U all or nothing.
I typically :U all. As the risk is too high, that Tranman (and it’s users) would translate to much and break the application.
The .NET Framework allows Control vendors such as Infragistics or Microsoft to annotate properties as being translatable or not. This applies to Character properties or binary properties like a Toolbar Buttons images that might need a different image for certain cultural regions and structures such as the Location and Size of a Control (in case to R-t-L or just very long strings).
You can turn on a Form’s or a UserControls “Localizable” attribute in the Visual Designer and then select a “Language” in the property sheet as well and the Visual Designer will start extracting all translatable properties to a separate .resx file. You may end use with .resx files like this:
MainMenuForm.resx (language neutral)
MainMenuForm.de-DE.resx (Germany german)
MainMenuForm.de-CH.resx (Swiss german)
MainMenuForm.de.resx (all other German locales)
MainMenuForm.en.resx (all English)
…
these .resx files can be generated using various tools that are available. Google “resx file editor” is your friend.
We’ve written our own tooling based on ABL routines to read and write resx files that is based on a dictionary in a Progress DB (our own or a custom one).
We’ve recently (11.3.2) logged a but, as Progress generates wrong code in InitializeComponents when you are using TableLayoutPanels. So I recommend you not to use them (they also perform bad J).
Hello,
Is this bug corrected in the last version of openedge dev studio ? or what should we use insteed of the TableLayoutPanel component ?
thanks,
Marc.
The answer is Yes ! (Corrected on Openedge 11.6)