language independency of menu items

Author: wva@gypsilon.de (gypsilon)

Since ages the menus are language-dependend. That means, a defined menu needs to be duplicated (as source!), when running the application in another language.

In 100% of all known cases, it would be better to let the menu-definitions language-independend, and use $text(xxxx) as menutext instead. Becuase we don't want to use different menus for different languages. We just want to have the menutext to be translated. AFAIK $text doesn't help in menus.

Is there a chance? I havent' got the experience with $inlinemenu. Possibly can this help to swith the language within a menu (without duplicating Code)?

Thanks Wolfgang

7 Comments

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


    Author: ulrich-merkel (ulrichmerkel@web.de)
  2. 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"


    Author: ulrich-merkel (ulrichmerkel@web.de)
  3. 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


    Author: gypsilon (wva@gypsilon.de)
  4. 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


    Author: ulrich-merkel (ulrichmerkel@web.de)
  5. Hi, i have the same problem, but i work with Uniface 8.2 ¿can anybody help me? Uli, ¿could you explain your Generator?

    Thanks.

     


    Author: uniface8 (spanish_uniface@hotmail.es)
  6. 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


    Author: ulrich-merkel (ulrichmerkel@web.de)
  7. Thanks Uli.


    Author: uniface8 (spanish_uniface@hotmail.es)