• State Suggested Answer
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 5 subscribers
  • Views 9457 views
  • Users 0 members are here
Options
Related

Reverse leveraging penalty in 11.1.0.3909

Michael Schroeder
over 3 years ago

Hello!

 

We are trying to get the reverse leveraging penalty enabled according to the information in the Admin Guide V11.1.0. Here is the relevant passage:

 

A configurable penalty is assessed to control auto-leverage.
The tm_score_reverse_leverage_penalty TM property in
tm.properties can be configured to penalize reverse leveraged matches. The
default value is 0. The allowed values must be in the range of 0 to 1. This penalty
is a leverage level penalty, and as such, it is applied to the entire match. (Many
penalties are applied to the segment element—such as a word or number in the
segment—that causes the penalty.) As a result, the impact of the penalty is not
affected by the length of the segment. For example, if the penalty is set to 0.02,
then the final score will be reduced by 2 percentage points. Based on this value, the
maximum score that a reverse leverage match could generate is a 98% score.
The penalty would be applied to all matches resulting from the TM reverse
leverage process. However, it will initially only apply to potential 100% and
fuzzy matches since the TM reverse leverage process will not initially generate
SPICE or ICE matches.

 

I have set the above parameter to 0.02 in all of the tm.properties I can find (webapps\ws, \ws-api, \ws-legacy), restarted the services for WorldServer and the FTS but it's just not working. I've started with a completely blank memory (reverse leveraging naturally enabled), added some TUs in the direction German->English, and then used these English translations to test reverse leverage in another project. Reverse leveraging is working fine, but it is delivering 100% hits instead of 98%. Checking the units from BW also shows scores of 100%.

Can anyone figure out what I'm missing? Thanks for any help!
Rate translation
×
Suggest better translation
×
  • 0 over 3 years ago
    are you using the WS_config environment variable? Where is that pointed to? The webapps folders are the very last place that services will look for config info.
  • 0 over 3 years ago in reply to Eric Bishop
    Hi Eric,

    thank you for your answer! We have a folder set up here C:\WS_Config that also contains ws, ws-api and ws-legacy subdirectories, but these merely contain copies of the general.properties file. From what I understand, I need to change the tm.properties file, but there are three of these strewn about under webapps.

    How can I check where the WS_config environment variable is pointed to? Perhaps that will give me a clue.
  • 0 over 3 years ago in reply to Michael Schroeder
    you can check the WS_CONFIG env variable by opening a command prompt (cmd) and run
    echo %WS_CONFIG%

    or, from UI: Start->Right-click on Computer->Properties->Advanced system settings->Environment Variables-> System variables->WS_CONFIG

    You shouldn't ever modify the config files from the webapp, those will be overriden by an upgrade. The config system works on the "more specific, higer priority" principle. So, configure it in WS_CONFIG/tm.properties so both ws-legacy and ws-api have the same configuration. Delete the key from the ws-legacy's and ws-api's tm.properties. Make sure you don't have duplicate entries for the same key.

    anyway, you said you already configured it the same on all locations. Can you send the config snippet that contains the value?
  • 0 over 3 years ago in reply to Stefan Bulzan
    As an FYI, you can put as many properties files as you need in the WS_CONFIG directory and it's sub folders. As Stephan notes you really shouldn't configure things in the webapps folders anymore
  • 0 over 3 years ago in reply to Stefan Bulzan
    Thanks to you and Eric for the very helpful information. I did not install WorldServer myself (our support guy did), but the only file located in C:\WS_CONFIG is general.properties (as well as the three subdirectories ws, ws-api and ws-legacy, each with general.properties and sometimes another file, e.g. ui.properties or api.properties.

    Are you saying that if I copy tm.properties directly to C:\WS_CONFIG (root), that this will be used as the "master" tm.properties that I can edit as needed? I guess I'm curious why my support guy didn't do this.

    Here is the change I've made in all 3 tm.properties files in the webapp folders:

    # Defines the penalty for reverse TM matches. This penalty applies to all
    # leverage matches the result from reverse TM lookups. A TM must be configured
    # to support reverse leveraging. Value range should be between 0 and 1.
    tm_score_reverse_leverage_penalty=0.02

    Does anyone know if this has to do with a) whether the server is in live or non-live mode and b) whether it has anything to do with the Studio-based scoping mode?
  • 0 over 3 years ago in reply to Michael Schroeder

    This will be a bit complex, but here we go.

    1. As Stephan (and SDL guy with intricate knowledge of this config file architecture) notes. You need to stop configuring any files in the webapps folders.
    2. To determine where your WS_CONFIG directory is you should run the steps that Stephan notes above.
    3. Once you know it's location (from what you say C:\WS_CONFIG is a possibility but you need to make sure you have a system environment variable pointing to that location.
    4. in the WS_CONFIG folder as you have already found there is a ws-legacy, ws-api, and a ws folder
    5. WorldServer has several places it will look for config files
      1. The first place that WorldServer will try to find configuration info is first in the registry if you do not rename the entries there then any related config locations will be ignored in the config files
      2. It will then check to see if there is a system environment variable called WS_CONFIG
      3. If it finds one it will first look in the WS_CONFIG\ws-legacy, the WS_CONFIG\ws, and the WS_CONFIG\ws-api folders
      4. It will then look directly in the WS_CONFIG folder
      5. The last place it looks is in the tomcat\webapps\ws-legacy, the tomcat\webapps\ws, and the tomcat\webapps\ws-api folders (where you are currently configuring your files
    6. You can put all the properties files that you've been able to configure in any one of these locations, as Stephan notes you would want to put your tm.properties in the root WS_CONFIG folder so that the ws, ws-legacy, and ws-api apps can all be referencing the same configuration.
    7. As a note you can define and have a property file in both locations (the WS_CONFIG and the WS_CONFIG\[app]) and WS look for all the properties in each and will use the first one it finds (i.e. the WS_CONFIG\[app] folder)

    With all that said, i have found that there are some attributes that no longer control anything in WorldServer. This change seems to have occurred since SDL acquired Idiom. Unfortunately, i can find no documentation on which are still used and which have not been. I asked SDL support a while back for that info and didn't ever get any documetnation. It possible that the setting you are setting is no longer used. An SDL employee would have to speak to that.

     or  feel free to correct any thing that i have misspoken above.
  • 0 over 3 years ago in reply to Eric Bishop
    Eric, once again many thanks for taking the time to help! When I get some free time (in short supply at the moment), I will start having a look at this on our test server. My support guy is saying that this is something that no longer works due to the changeover to Studio-based scoping. I am confused, however, since the information is still in the 11.1 WS help documentation (Admin Guide) with no mention of the scoping mode playing a role. Maybe others have additional information on this?

    In the meantime, thank you!
  • 0 over 3 years ago in reply to Eric Bishop
    Eric, that's a great explanation of how the config works. I'd add just one thing: you should configure in the WS_CONFIG structure, as you described, only the values that are changed for your environment. For example, if you just want to change the tm_score_reverse_leverage_penalty config in tm.properties, you should have a tm.properties in WS_CONFIG that contains only a single line:
    tm_score_reverse_leverage_penalty=0.02

    WS knows to take this configuration from WS_CONFIG and the rest from the tomcat/webapp folder.
    In this fashion, you'll use the defaults from the provided configuration file and if they change, your system will be up to date.

    regarding the issue, indeed, Studio-mode will have a different behavior than WS-mode. I'll followup with how the penalties should be applied in Studio-mode.
  • 0 over 3 years ago in reply to Stefan Bulzan
    Ah, that's very useful information, thank you! That should allow me to upgrade-proof our installation for all of our non-default settings. Am very interested in your follow-up, thanks again!
  • 0 over 3 years ago in reply to Michael Schroeder
    Hi Michael,

    that change in tm.properties in each subfolder under C:\WS_CONFIG should actually do the trick since this is where WS first checks for properties/configuration keys before it checks in the webapps folder.

    Have you restarted WorldServer after applying that change and have you re-tested?