Start a new topic

REQ: Some Total Recall glitches/questions

Some minor points about Total Recall:

  • it would be nice to have a warning if TR language pair and project language pair do not match instead of a cryptic SQLite message (same is true in general for any senseless TM/TB/file mix)
  • it would be great not to open an additional, but senseless tab in this case (= less clutter on the UI)
  • when loading segments a 6000 TR DB counts up to 40.000 – does this also include subsegments and indexed bling-bling (in this case it would be nice to point this out = better information of the user)
  • when opening a TR table from the Dashboard, the tab is named 'Total Racall TM', when recalling a table it gets of course the table name. Assuming that you will in many cases only open one table, wouldn't it be nice to have the table name displayed also in the first case? And to call the tab "Total Recall TMs" when marking more than one table?
  • when importing a TM into TR there is a time lapse of several seconds before showing the "Importing .." dialogue – long enough to make the user swear and forget his good education, nad in some cases reinitiate the process – can anyone reproduce this or is this due to my slow machine? Would it be possible to have a seamless lind of interaction, even with huge files?

Two more questions:
  • there is no possibility to overwrite duplicates, if I understand correctly? Doesn't that mean that the workflow Translate > Get proofed files back and update TM cannot be achieved with TR, well, at least not without keeping both TM and TR up-to-date and/or constantly deleting and recreating the same TR table?  
  • there should be a possibility to find and replace – I have a whole bunch of legacy segments with "{}segment text gioes here{}", it would be nice to be able to replace them more easily


As far as I'm concerned, "Total Recall" works as advertised, and not surprisingly, I see no reason at all to implement any changes.

H.

I'll try to get into this a bit more seriously, although I still think part of the "problems" are a result of confusing "SQLite tables" with the TM resulting from those tables. And I'll number the points (your order) for easier reference.


  1. I think that's the confusing I mention above. It's great to be able to open tables in another language pair. It's no more than logical SQLite protests if you try to turn a table in another language pair than the one in the project into a TMX file.
  2. Don't know what you mean. If it's a tab in the table, you only have yourself to blame. You could/should have mentioned it in the table settings.
  3. This can easily happen in the resulting TMX file in case several words show up in several segments of the table. After all, the extraction is on a per word basis.
  4. You can't open a table from the Dashboard, only the resulting TMX TM.
  5. Importing a TMX file into a table takes some time because of the indexing process.
  6.  There are two ways (I think) to edit tables: Export them to TMX, delete the table, edit the TM in CT, import it again in SQLite. This may take some time because of indexing. The other way would be to edit them in SQLite, for example in SQLite browser (the easiest on I found so far). This may take some time because you'll have to learn SQL commands/queries...
  7. See 6
H.



The following is for Recall memory function, not the TR Tables per se.


Say your TR table in in en-US - fr-FR and your project in en-GB - fr-FR.


You can still use it for the project with Recall memory, selecting the TR memory and setting the language variants/pairs to those used by the table: in this case, en-US - fr-FR and NOT en-GB.


Note: I didn't try yet with a project where the target variant differs.

idim: The following is for Recall memory function, not the TR Tables per se.


And not only for Recall Memories, for all TMX files. CT simply ignores the regional aspect of the source language. Always.


H.

There seems to be the wrong attitude here. With the "everything's fine" attitude most translators would still sit on their trees. Though you might be unsure if they all have descended already.
  1. there is in most cases no sense in opening a tab if TR language pairs do not match.
  2. (and 1) Or simply the SQLite error message should be suppressed or there should be a prompt for "open anyway" or "do not open"
  3. if the TR function tells me "Loading 40.000 segments" though there are only 6000 segments, this is misleading. Period. Or it must say "Loading 40.000 segments, subsegments and words"
  4. this is a question naming the tab concerns the clearliness of the  UI, not if it is a table or a TM
  5. it is the gap without any UI action, not the time that I mentioned
  6. this is exactly what I meant, but it is no solution - the administration and maintenance is a basic task, so using SQLite editors or learning SQLite commands cannot be a serious advice
  7. (okay, see 6)


Torsten: There seems to be the wrong attitude here


I agree.


When Igor set up the database, he had simple server sharing resources in mind, and simply querying huge resources without using heaps of RAM. A bit like TMLookup, though the CT database was in place way before that. Of all active (on the forums) CT users, I seemed to be the only one using it. Then he introduced indexing and Total Recall, and again, until very recently, I seemed to be the only one using it. Because it works. And it works without much ado.

Now you want it to behave like a full-fledged database, pretty darned difficult. I'm not sure that's possible (it may not be free as in free beer anymore if Igor offers it), but I'm pretty sure it's not cost-effective, because very few people - if any - will be interested in it. Igor will challenge it, but Total Recall isn't very transparent to begin with, trying to imitate DejaVu (Michael's favourite tool for this year) won't make it any clearer.


Total Recall just works (as we say).


H.

I do not think that these minor remarks I made above will change the basic behaviour of the TR feature. 


Concerning the Editing feature, CT itself would be the ideal editor for the TR databases/tables.


If you are the only user using TR (or if you have this impression, but at least the other Hans seems to abstain from it, as he remarked in another thread some days ago), there must be something wrong with this feature (I do not declare that my remarks would change this fundamentally). Sure, CT works quite well for most jobs without requiring TR. But a feature that lacks easy maintenance of its contents is not an ideal choice.


You seem to use the TR feature for the DGT TMs, that only need few maintenance (depending on how often you import new versions). Using the TR feature with more regulary updated/revised TMs needs more maintenance (apart from the import of "{}" mentioned above).

Torsten: If you are the only user using TR (or if you have this impression, but at least the other Hans seems to abstain from it, as he remarked in another thread some days ago), there must be something wrong with this feature


I don't think there's anything - like ANYTHING - wrong with the feature. I think people who don't use it, either don't understand it (and I blame Igor's explantion more than the user), or simply don't need it. Igor wants us to use it under all circumstances, I think you should abstain from using it for as long as possible: When the TMX file gets too big for use without delay.


You seem to use the TR feature for the DGT TMs, that only need few maintenance


Zero maintenance. I did the maintenance on the TMX file before importing it in the SQLite table. And I don't add a thing.

But I also imported my EN-NE Dig Mama - after maintenance, of course. And I don't add a thing either: I just started using a new Big Mama TMX, and I'll use it till it gets to slow (in my lifetime? I'm 63...). In that case, I will delete the table, merge the two BM TMX files, do the necessary maintenance, and import the merged Big Mama.


H.

> and I blame Igor's explantion more than the user

Indeed, I agree.

> Zero maintenance.

This might depend on if you prefer to use any DGT TM or only the newest version (2015, if I understand correctly). There might be more revisions to come.

That is a question also for the Total Recall feture. Most TMs need maintenance. Or do you never have clients who say "we want to have term X replaced by term Y", even after years working with term X?
Not to speak of those cases where you get a revised TM for every new job. Sure, using these external TMs – even the very big ones – as read-only does a fairly good job, but it would perhaps make more sense to have a "overwrite duplicates" and an Edit feature than having to delete an old table to replace it with a totally new one.

Actually, what Torsten proposes is only a better (more intuitive) error handling and some maintenance on Total Recall underlying database.


As for the latter, any direct action on SQL database, apart from searching it, is either very complex and error-prone. For example, imagine deleting duplicates in a few million segments database. The very idea of the duplicate is already controversial, and determining by software which is the correct duplicate to remain is impossible. Besides, it would take ages in huge SQL databases. Therefore, instead of the direct SQL actions, the user can filter out the duplicates during the recall process and perform any maintenance operations such (e.g. search and replace) on the recalled segments.    

Torsten: Or do you never have clients who say "we want to have term X replaced by term Y"


Of course. But those terms I will save in either the ProjectTM, or the termbase for the client. And they will enjoy the highest priority, whereas the TR TM - like the Big Mama - will only have the lowest possible priority.


H.

IK: Actually, what Torsten proposes is only a better (more intuitive) error handling and some maintenance on Total Recall underlying database.


I'm afraid I never saw an error message in the case of TR, and I think maintenance isn't really necessary. Not the way I use it, that is.


H.

>> idim: The following is for Recall memory function, not the TR Tables per se.

> And not only for Recall Memories, for all TMX files. CT simply ignores the regional aspect of the source language. Always.

 

Well, the EN-GB/DE-DE TR table does not work here for a EN-US/DE-DE file...

Login to post a comment