• State Verified Answer
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 434 subscribers
  • Views 5182 views
  • Users 0 members are here
Options
Related

Studio 2017 AutoSuggest candidates not displayed

MMM

Issue may be related to inability to add or generate AutoSuggest dictionaries.

(Attempting to add a dictionary gives error message "The AutoSuggest dictionary file could not be read," and trying to generate one fails after extracting phrases, with message "unable to open database file," details attached (hopefully).) AutoSuggest dictionaries are one of my selected AutoSuggest providers, but after excluding them, still no display of any candidates from other providers.


All settings in Studio 2017 are identical to those in Studio 2015, where everything works fine. Tried repairing the installation, reinstalling, and restarting. Looking forward to seeing AutoSuggest candidates when I start typing, but so far, nothing at all. Any help would be appreciated. Thank you. P.S. Looking forward to Regex Match Autosuggest Provider for 2017.

Fullscreen sdlerror-20161118-11h46m21s.sdlerror.xml Download 
<SDLErrorDetails time="11/18/2016 11:46:33 AM">
  <ErrorMessage>unable to open database file</ErrorMessage>
  <Exception>
    <Type>System.Data.SQLite.SQLiteException, System.Data.SQLite, Version=1.0.103.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139</Type>
    <ResultCode>CantOpen</ResultCode>
    <ErrorCode>14</ErrorCode>
    <HelpLink />
    <Source>System.Data.SQLite</Source>
    <HResult>-2147467259</HResult>
    <StackTrace><![CDATA[   at System.Data.SQLite.SQLite3.Open(String strFilename, String vfsName, SQLiteConnectionFlags connectionFlags, SQLiteOpenFlagsEnum openFlags, Int32 maxPoolSize, Boolean usePool)
   at System.Data.SQLite.SQLiteConnection.Open()
   at Sdl.LanguagePlatform.TranslationMemoryTools.PhraseExtraction.DatabaseConverter.CreateBiligualPhraseFile(String path)
   at Sdl.LanguagePlatform.TranslationMemoryTools.PhraseExtraction.DatabaseConverter.Convert(String flatFilePath, String dbFilePath)
   at Sdl.LanguagePlatform.TranslationMemoryTools.PhraseExtraction.PhraseExtractionProcessor.CreatePhraseDb(DataLocation location, String dbFilePath)
   at Sdl.LanguagePlatform.TranslationMemoryTools.PhraseExtraction.PhraseExtractionProcessor.Process(String tmxFilePath, CultureInfo sourceCulture, CultureInfo targetCulture, Int32 maxIterationCount, Int32 maxTUs, String dbFilePath)
   at Sdl.TranslationStudio.Common.Jobs.PhraseExtractionJobRequest.Execute(IJobExecutionContext context)
   at Sdl.Desktop.Platform.Implementation.Services.Job.<_worker_DoWork>b__3()
   at Sdl.Desktop.Platform.Implementation.Services.Log.Resources(Object message, Action action)
   at Sdl.Desktop.Platform.Implementation.Services.Job._worker_DoWork(Object sender, DoWorkEventArgs e)
   at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e)
   at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)]]></StackTrace>
  </Exception>
  <Environment>
    <ProductName>SDL Trados Studio</ProductName>
    <ProductVersion>14.0.0.0</ProductVersion>
    <EntryAssemblyFileVersion>14.0.5746.0</EntryAssemblyFileVersion>
    <OperatingSystem>Microsoft Windows 10 Pro</OperatingSystem>
    <ServicePack>NULL</ServicePack>
    <OperatingSystemLanguage>1041</OperatingSystemLanguage>
    <CodePage>1252</CodePage>
    <LoggedOnUser>TEN\MMM</LoggedOnUser>
    <DotNetFrameWork>4.0.30319.42000</DotNetFrameWork>
    <ComputerName>TEN</ComputerName>
    <ConnectedToNetwork>True</ConnectedToNetwork>
    <PhysicalMemory>8388132 MB</PhysicalMemory>
  </Environment>
</SDLErrorDetails>
Rate translation
×
Suggest better translation
×
Moderator UI
×
  • Get AI Suggestion
Parents
  • 0
    Just a few final follow-up comments for posterity, and I will abandon this solo thread.
    - Some AutoSuggest candidates are now displayed for me. (I double-checked this setting and used a viable segment for testing: AutoSuggest > Translation Memory and Automated Translation > Minimum suggestion length... + Minimum number of characters...) However, not as many candidates as usual, probably because my AS dictionaries cannot be loaded. (See below.)
    - I still think there might be an AutoSuggest dictionary bug in Studio 2017, at least for me, because the error message "The AutoSuggest dictionary file could not be read" is always displayed when I attempt to add any of my regular dictionaries. Another chronic error message is "unable to open database file" (see 1st msg above).
    - Cannot insert recognized terms with registered keyboard shortcuts.
    I suppose the issues will eventually be resolved. Thanks to the developers, anyway.
Reply
  • 0
    Just a few final follow-up comments for posterity, and I will abandon this solo thread.
    - Some AutoSuggest candidates are now displayed for me. (I double-checked this setting and used a viable segment for testing: AutoSuggest > Translation Memory and Automated Translation > Minimum suggestion length... + Minimum number of characters...) However, not as many candidates as usual, probably because my AS dictionaries cannot be loaded. (See below.)
    - I still think there might be an AutoSuggest dictionary bug in Studio 2017, at least for me, because the error message "The AutoSuggest dictionary file could not be read" is always displayed when I attempt to add any of my regular dictionaries. Another chronic error message is "unable to open database file" (see 1st msg above).
    - Cannot insert recognized terms with registered keyboard shortcuts.
    I suppose the issues will eventually be resolved. Thanks to the developers, anyway.
Children
  • 0 in reply to MMM
    Hi MMM,

    Maybe check your dictionary is the same flavour as your project languages? The AutoSuggest Dictionaries have to match exactly, so en(US) cannot be used for en(GB) for example.

    Did you try and use project templates from an older version of Studio? Never a good idea to do this, always better to recreate them from scratch.

    Based on your shortcut problems maybe try a reset as well... no specific reason for suggesting this other than it cures a number of ills. Rename this folder (just add _old to the end or something, it's not important what you rename it to) and restart Studio:

    c:\Users\[USERNAME]\AppData\Roaming\SDL\SDL Trados Studio\14.0.0.0

    Regards

    Paul

    Paul Filkin | RWS Group

    ________________________
    Design your own training!
    You've done the courses and still need to go a little further, or still not clear? 
    Tell us what you need in our Community Solutions Hub

  • 0 in reply to MMM
    Hi MMM,

    >Some file paths are therefore unusual network file path

    I suspect that a lot of your issues are coming from the network file paths.
    Have you tried local paths and see if the errors stop?
  • 0 in reply to Paul
    Update: Unusual (network) file paths apparently not supported for AutoSuggest Dictionaries (when adding existing ones, or as destinations for new ones that are generated)

    Thank you, Paul, for your sensible suggestions. Good advice about not using older project templates. FYI, I had already tried various troubleshooting and upgrading techniques with the Roaming and Local folders.

    There seems to be a bug, at least for me, in the file paths of AutoSuggest dictionaries that are supported.
    For Parallels users (for example), these dictionaries cannot have file paths such as \\Mac\Lorem\Ipsum\Ω Dolor\Sit.... (Personally, I use an omega character for sorting in macOS, but the \\Mac at the beginning instead of C:\Users\ might give Studio 2017 problems.)
    This apparent bug causes the initial error message of "Unable to open database file" for me. Using a local file path with C:\Users\ solves it.
    Thanks again. Very much looking forward to using Studio 2017, now that I seem to be on the right track.
  • 0 in reply to Jesse Good
    Jesse, thank you. I just happened to have replied about this to Paul before reading your message.
    You seem to be right. Thanks for the tip.
  • 0 in reply to MMM

    Hi MMM,

    I'm glad you sorted it out.
    Now, one big difference between Trados Studio 2015 and 2017 is they upgraded the version of SQLite they are using.

    I believe you hit the following bug, which occurs when you use Sqlite version greater than 1.0.86.0.
    It just so happens Trados Studio 2017 upgraded from 1.0.60.0 to 1.0.103.0, so that is why you did not have problems in 2015:

    system.data.sqlite.org/.../bbdda6eae2

    It also explains why this error occurred, so Trados needs to update their code for this change:

    The root cause of this issue is the new connection string parsing algorithm
works.  Backslash is now the escape character when it is followed by another
reserved character
  • 0 in reply to Jesse Good
    Indeed, I noticed SQLite in the error details in my first post but did not feel like mucking around (as if I were qualified to muck). I suppose the file path bug will be resolved eventually, but I am glad that it is a known issue. I seem to recall similar file path bugs in previous versions of Studio that were resolved.

    A benefit of using Windows on a Mac, as you know, is that all "network" folders (used for projects and various other files, such as AS dictionaries) can be accessed in macOS and backed up by Time Machine (and other software, as needed) instead of some Windows alternative.
    I see that the Studio Migration Utility copies all project files to a local destination, but this is no good for users such as myself who prefer our existing, "network"-based file management with Studio 2015. Looks like I will be adding required project files to Studio manually instead of using the utility for that.
    Anyway, thanks again for the constructive feedback.
  • 0 in reply to MMM

    Glad you managed to resolve this... thanks Jesse!

    Unknown said:
    A benefit of using Windows on a Mac, as you know, is that all "network" folders (used for projects and various other files, such as AS dictionaries) can be accessed in macOS and backed up by Time Machine (and other software, as needed) instead of some Windows alternative.

    A benefit of using something like dropbox for this is that you can use the migration utility as the folder is in effect a local one that is backed up.  I'm not familiar with Time Machine but maybe you can map your folders to one in windows somehow and achieve the same thing?  Does this article help?

    lifehacker.com/.../how-to-set-up-time-machine-to-back-up-to-a-networked-windows-or-linux-machine

    Paul Filkin | RWS Group

    ________________________
    Design your own training!
    You've done the courses and still need to go a little further, or still not clear? 
    Tell us what you need in our Community Solutions Hub

  • 0 in reply to Paul

    Thank you for sharing the Dropbox suggestion and Time Machine article, Paul. Sorry for the delay in replying.

    Time Machine is convenient. However, the article you kindly mentioned seems to show how to back up to a Windows destination, not from a Windows source.

    Parallels and Fusion have made backing up virtual machines slightly easier, but unless I am mistaken, backup still involves an essentially monolithic VM file instead of individual folders within the OS. Not sure about any recent innovation in this regard. Anyway, that's one reason to keep those folders outside of Windows, unless one uses various Windows backup solutions.

    Dropbox never really appealed to me, but I admit to using CrashPlan for remote backup. (A Windows version of CrashPlan is also available, but that seems indirect, in my case.) Not a big fan of CrashPlan, but it's secure and reliable.

    Personally, I still find it interesting to mix OSes this way, despite the network file path issues. From my perspective, Windows seems like some kind of theatrical stage. If I wheel it away, so to speak, I see the folders that have been residing in macOS all along. I'm probably not the only translator who likes to tinker with things and live between worlds.

    Anyway, thank you for all of the helpful advice you have shared with the community through the years.