How can Progress Translation Manager be used in a GUI .Net a

Posted by PeterWokke on 04-Jul-2014 08:46

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 

All Replies

Posted by Paul Clare on 07-Jul-2014 10:13

Hi Peter,
 
Translation Manager should still work.  You can use it with ABL class files and also from the Developer Studio.  So I don’t see why this can’t be used at least with ABL.
 
Regards,
 
Paul.
 
[collapse]
From: PeterWokke [mailto:bounce-PeterWokke@community.progress.com]
Sent: Friday, July 04, 2014 2:47 PM
To: TU.OE.Development@community.progress.com
Subject: [Technical Users - OE Development] How can Progress Translation Manager be used in a GUI .Net application development.
 
Thread created by PeterWokke

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 

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]

Posted by Mike Fechner on 07-Jul-2014 11:04

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).

 

Posted by Marc on 25-Jul-2016 07:19

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.

Posted by Marc on 22-Aug-2016 03:20

The answer is Yes !  (Corrected on Openedge 11.6)

This thread is closed