Translation attributes

In the OpenEdge Architect / Visual Designer preferences you can turn :U on (last checkbox) for ALL strings.

OEA cannot differentiate between translatable and untranslatable strings.

That's a limitation, but understandable as Progress cannot decide which strings are relevant for translation and which not.

thx mike

May be i need to 'hack' the initializecomponent when i check in the files....

The issue is not that OEA can't differentiate between translatable/untranslatable.  The issue is the Microsoft .NET code can't.  When OEA reads the code for VD, it turns the code into the structures that .NET wants to render the window.  These code structures don't understand :U and :L.  Then when you save the code we use the results from the Microsoft code which don't include those properties causing your settings to be lost.

You can translate strings, but you have to use the Microsoft resource files since that is what the designer understands.  These are the .resx files that are generated.  To use these, once you open the form change the 'Localizable' property to true, and select the language you want to enter strings for.  You can also use a third party resource file editor utility for translating strings in the .resx files.  These can then be added to the PROPATH and you can use them at runtime.

mattB

Fixed property name to be

Where would OEA/VD know from, that the Key property of a ButtonTool should not be translated, but the ButtonTool:SharedProps:Caption should be translated? You might create a list of translatable properties for the SWF and Ultra-Controls, but on a generic base?

To use these, once you open the form change the 'Translatable' property to true, and select the language you want to enter strings for.

I assume you are talking about the "Localizable" attribute, I don't have a "Translatable" property. That will indeed create a second .resx file.

When was this added/fixed?

The annotations on the properties of the controls defined in the assembly indicate to the designer what is translatable and what is not.  If this annotation is present, then the designer lets you provide alternate strings/integers/images for that particular property.  Then when the form is ready to be merged into the .cls file, the code dom serializer (Microsoft .NET code) checks which properties have actually been changed (there is a map stored in the designer with an entry for each language that contains the translated properties mapped to the object attributes), it generates a code dom that uses a reference to fetch the property value from the resource object instead of inlinig the value into the code.  Sorry for the run on sentence.  This is all documented in the code dom stuff for Microsoft designer classes.

Is that clear as mud?

Is that clear as mud?

The annotations on the properties of the controls defined in the assembly indicate to the designer what is translatable and what is not.

Yes, but it looks, like they are just used for the alternative .resx files - the :U is not affected by this.

These resource files all work very well in a .NET environment, but if you have a plain old ABL-system the ability of providing corect translation attributes is essential.

This system supports a legacy translation by extracting the xref information. this data go's through a translator and this gives the translated program which is compiled etc.etc.

I just want to use de .cls programs to build some fancy screen (charts for a start) that start from the menu.

I did'nt even check if there is even a xref for cls-programs. If this doesn't work I'll have to use the resx mechanism .....

There is a preference to turn on the :U for all strings generated by the designer.  This way you can translate the rest of the file using normal normal tranman type stuff, but the designer code would need to be translated via the resource files. Or you could use the resource files for the whole thing if you really wanted.

Classes have the same string-xref like procedures.