Hi Wolfgang

As you said: to have to duplicate the menu only for language reasons is hart to swallow.

Not to the active part:

I played a bit with $inlinemenu and it looks like this can be used to have a more dynamic PULLDOWN menus.
But the menu-bars can not be modified using this functionality.

Another option: a 3GL/windows-programming tool to modify the menu-texts "on the fly";
Question here are modifications of the hint-texts etc.

Success, Uli

Hi Wolfgang,

just a dITo idea:

we provide a mechanism which runs trough the menu-sources and fills description, hints etc. using $text.
$text-definitions may be stored in the comment.

After running trough this procedure, the description etc. are hard-coded again,
but you can at least use $text in messages as well as menues.

Assuming you have $text for a new language;
all you have to do is to copy the menu from language 1 to language 2 and process the $text adjustment.

SUccess, Uli

P.S. It is a "this can be used right now",
a direct support of $text would be much more flexible, but needs resources from "the Lab"

Hello Uli,

Thanks for the answer. In all projects I worked for, we did find solutions, which are more or less similar to your solution. (it dependence on the interface to the translation process, and release processes). The point, where I am not happy with is: all ends up in copying the menus. However the solution is, there is always  an exception either in the development - deployment - releasing or translation process.

Why spending time for workarounds, since there is (in my point of view) a logical error in the model? (and this since ages!! I remember, there was a change in Version 5 concerning menus, which was then rebuild for reasons, I couldnt' understand...). Can someone tell me, for what the language is necessary within the USMENU and USITEM? In all known projects I work for, the language-independency is not wished for the menus, but for the menu text within the menu.

My question was more in direction of the Lab:

Is there a chance of getting the behaviour changed in one of a future uniface-release? (Let's say: 9.4.ß3 ?) Or is it definitly not possible to change it, because of other technical reasons, which I do not know yet.?

Ignore the Language-field in the USMENU - USITEM and just allow the $text() facility instead. For migrations issues insert a switch in the assignment file which tells:
Use either the classical variant or the extended variant in the language-question of menus.

W

Hi Wolfgang,

as I said in my P.S.: a "Lab" solution allowing $text would be the far better concept (and getting rid of language in the process).

My "current" way of achieving a similar result is a Generator (will document this in more detail shortly):

Working with a SINGLE template menu in language "XXX".
Different languages are generated in the repository during the conversion process.

Success, Uli

P.S. To your question "why?": looks like menues have been handled completely outside the uniface shell

Hi, i have the same problem, but i work with Uniface 8.2 ¿can anybody help me? Uli, ¿could you explain your Generator?

Thanks.

Hi uniface8,

just a short description of the process:

I specify a single menu with the language XXX.
The fields may read like $text(abcdefg) or you can put any other text in.

The GENERATION process

I change the current $language for the IDF:

old_lan = $language
$language = my_lan

The generator retrieves the XXX version of a given Menu

LAN = "XXX"
retrieve/e
release/mod
LAN = my_lan

... I traverse all the fields of the menu, if i find "$text(abcdefg)" it is replaced by the real $text(abcdefg)

store/e
commit

; perhaps activate the compile of the menu

At the end, I restore $language for the IDF:

$language = old_lan

Success, Uli

Thanks Uli.