• State Suggested Answer
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 433 subscribers
  • Views 1196 views
  • Users 0 members are here
Options
Related

MultiTerm not updating

Willem Dubelaar

Good morning Paul,

I noticed in your response so Skye that the current version for MultiTerm should be: SDL MultiTerm 2017 - 14.1.2471.5.

When I look in "About SDL MultiTerm" of my version of MultiTerm, I get: SDL MultiTerm 2017 SR1 - 14.1.2441.0

When I press "Check for Updates", I get the following messages:

Failed to get archive directory listing
Failed to load update data file

After that, I can actually load my .sdltb and edit it.

When I go to my account on sldtrados.com, the only setup file available for download is SDLMultiTermDeskTop2017_SR1_2441.exe, dated 2017-07-25. As recently as 2018-01-01, I downloaded that file again and reinstalled MultiTerm, but it did not update anything, the version is still 14.1.2441.0.

So, my question is: Where can I get version 14.1.2471.5, please?

Best regards,
Rate translation
×
Suggest better translation
×
Moderator UI
×
  • Get AI Suggestion
Parents Reply Children
  • 0 in reply to Lydia Simplicio
    Good morning Steven,

    Eventually, it worked. I first tried to solution suggested through the first link. Though, the solution related to Studio and not to MultiTerm. For Studio, the UserInterfaceLanguage value is set to de-DE and there it works (for Studio) without any problems. So, instead, I have added the value (en-US) under MultiTerm14, where it did not exist at all. I logged off and logged back on, in order to have the registry reread, but it still did not work. Or perhaps it did, but I failed to check under "About". However, if it had worked, I should not have got the warnings. Then, I downloaded the *.msp files and installed those. It updated to the latest version, but I had to manually disable the warnings. That means, of course, that I will miss the next update.

    One thing comes to mind, as to why this might happen. I run a 64 bits system and if, when installing new 32 bits software, I am given the option of selecting the installation directory, I always do so and then choose a dedicated directory on my D drive. This, so as to spread the load and reserve the C drive as much as possible for actual 64 bits software. Could that be the reason? Could it be hard-coded somewhere that the update procedure is looking in C:\Program Files (x86)\, instead of where the software actually lives? If so, either the procedure must be recoded to look for the actual installation directory, or it must be recoded to remove the option to select the installation directory. These are just my thoughts, but I am by no means an expert in such matters.

    Many thanks,

    Willem Dubelaar