• State Not Answered
  • Replies 4 replies
  • Subscribers 387 subscribers
  • Views 1594 views
  • Users 0 members are here
Options
Related

how to store machine translation plugin settings correctly?

Kārlis Surname

Hello,

I have encountered  a problem where removing and adding a plugin with different  options  results in SDL Trados Studio 2011 using the options from previously added plugin. (Restarting the application resolves this) 
I emailed sdk-feedback about this problem, and they suggested that storing settings the way we did was "non-canonical". 
Hence, the question is what is the correct way to store settings?

What we have is this:
 ITranslationProvider class which has a SOAP client object with the users username and password (which it needs to authenticate for the users machine translation systems) which is then used by ITranslationProviderLanguageDirection:: SearchSegment. It seems that ITranslationProviderLanguageDirection uses the ITranslationProvider object from the plugin that was removed. I have trouble seeing how any other way to store the soap object containing the username and password.

It is worth mentioning the user can see and select the systems in the “project options”, but as the user tries to translate the old object is used he uses the previously selected system and credentials.
Rate translation
×
Suggest better translation
×
  • 0

    This might be related to a problem I discovered with TermInjector in Studio 2011 (but not in 2009). There was a problem with updating the glossaries of the plugin. After debugging for a while, I noticed that whenever the Project Settings window is opened, Studio creates two more instances of the translation provider plugin (I tested this by adding a counter to the class). The changed settings apply to the newest plugin instance created, but the first plugin instance created is actually used in the editor. This is why the settings did not update. This might also apply to removing and adding plugins: only the newest instance is ever removed, so the original instance remains in use.

    I notified SDL about this two weeks ago, but I haven't received any news yet.
  • 0

    My MT providers don't seem to have this problem (although I haven't done extensive testing of multiple provider instances since SP2 was released).  Are you storing your settings in unique URIs for each instance of your provider that has different settings?

    If you are not doing that already, perhaps the following rough description of how I arrange it might help:

    -- I retrieve/store credentials in the ITranslationProviderWinFormsUI and ITranslationProviderFactory using the ITranslationProviderCredentialStore passed to the methods of these classes.

    -- I use an 'Options' class similar to the one used in the SDK example and store/retrieve settings for the provider in the provider's URI.  The one in the example project  already has a TranslationProviderUriBuilder object.  You can add your own properties to the Options class with getters and setters that read/write URI parameters and values from/to the URI.

    -- If you need the provider settings to vary depending on user-set preferences or other circumstances, within the various properties/methods of the ITranslationProvider, you can check the value of options set for the Options class passed to the ITranslationProvider constructor (these will have been read from the unique URI for a given provider).

    -- To save user settings, for example, call the setters in the Options class, which should write these to the

    provider's URI.

    -- When the user deletes the current provider, I would imagine it should do it by URI.  In other words, when the user creates a new one with different settings, this new one will have a URI that differs from that of the recently deleted provider.

    Of course, you may already be implementing something like this, and this might just be a bug/issue with Studio.

  • 0 in reply to Patrick Porter

    Thank You for the answer.

    Yes I did something similar and it seems that with the last Trados Studio update I can no longer reproduce this and the bug seems fixed.

    But one thing remains true. It seems that  at no point is the URI deleted from credentialStore. And while  the plugin works I would like to not permanently store the credentials every time a user logs on with new username/password. Is there a way to do this when the user removes the provider? De you even use credentialStore, or do You store the credentals/provider specific data in the URI?
  • 0 in reply to Kārlis Surname

    I do use the CredentialStore, which associates a set of credentials with a particular URI (it does not store the URI itself).  

    It is a little unclear to me what you are trying to accomplish, but if you only want the username/password to persist for the session, and not be stored, you could just do that with the proper variable scope/persistence.  For example, put  internal/public static variables in one of your classes and update them as needed from your code (e.g. from the ITranslationProviderWinFormsUI instance when a new provider is added).  The only time you should need to save credentials to the CredentialStore is when you want the credentials to persist for the user after shutting down and re-starting  Studio.  

    As far as saving them to the URI, according to the SDK documentation, this is not a good practice.  The reason given is that the URI is stored in XML of the project file, which can be easily opened with a text editor and read by anyone.  Also the project file is included in any return packages created by users.  So storing user credentials in the URI is not very secure.  If you do that, the possibility exists that your users might unwittingly compromise their credentials (assuming that this is an important factor in your case).