Start a new topic

Segments added to read-only Total Recall memory

I have a very strange case where segments are added to the total Recall memory that is read-only.


Eventually this is the case because the TR memory is still loading segments (17 K segments in project, huge TR TM) while I was executing Memory > Add segments from project (after having filtered "checked segments").


Repeating the same step during the latter work (i.e. while segments are not loading) does not have the same result – everything works as it should (segments are added to the normal TM, not to the TR TM).


 Anyone can reproduce this?


After reopening the project with the same TM and TR TM the segments are no more shown in the TR TM pane.


This behaviour is a virtual one. This means the segments are in a kind of RAM of the Total Recall read-only TM. They are actually displayed, but of course they are not stored. This kind of virtual storing and/or the processes when loading the TR TM segments should be inhibited.

Torsten: This kind of virtual storing and/or the processes when loading the TR TM segments should be inhibited


I don't think it matters much, and neither can it hurt much. As you mentioned above, the TR TM is huge, and I bet you only contributed a (relatively) few segments to the TR TM. And I take it that CT "locks" the TR TM the minute the recall process stops.


H.

You are right, on first sight it does not do any evil (it is the same kind of behaviour as described in my 3rd posting here – TM segments are loaded virtually, but not saved)


But

  • it contributed all checked segments of a 17 K project
  • there might be situations where the question has importance whether a segment is in the TR or in the normal TM, e.g. you are working with a project TM, parts of the file were externally translated and you want to rely preferably on your own segments (in the TR TM)
  • in other words: the origin of translated segments might have a considerable importance

Sure, a small bug, but that might have some consequences, depending on your workflow. There are enough workarounds to avoid this.


There is always the fundamental question if you want a kind of error-prone tool for the "happy few" with a load of more or less complicated workarounds or a rather error-free tool for any translator ("the masses").



Torsten: There is always the fundamental question if you want a kind of error-prone tool for the "happy few" with a load of more or less complicated workarounds or a rather error-free tool for any translator ("the masses").


Your turn to be right. And I'm the perfectionist...


H.

This kind of virtual storing and/or the processes when loading the TR TM segments should be inhibited.


Why? All database systems allow for virtual (RAM only) storage. It is usually called in-memory or cache storage, and it does have its use cases (e.g when the user is not interested in any long-term storage of their data.)

IK: All database systems allow for virtual (RAM only) storage


I think Torsten has a (minor) point. If data are (not is) added to the TR TM by adding them from the current project, you can't possibly know where they're from. I also want to keep data from say the DGT "locked", and you can't do that in Torsten's situation. The alternative is of course to run TR before you start working, the only way I used TR so far.


H.

From a virtual point of view I see the use case too, but we are talking here about read-only memories, where you should not assume this feature.

  • In this case of MT memories, that were set as read-only when saving, the data ist not stored. From a logical point of view this is okay: you should not set a TM to read-only and then run the MT pretranslation procedure, or maybe you should only set it to read-only after running it through
  • even for writable memories,: Wouldn't you rather create a temporary memory if you are not interested in any long-term storage of their data?
  • even when using the use case promoted by Igor, the user is unable to make a distinction between the long-term stored and the virtual segments. Is this really an advantage then?

Alternatively a mere hint „Do not make this or that when recalling segments“ would be the fastest solution, indeed.

you can't do that in Torsten's situation.


You can. Uncheck "Segments memory" option either before you load the TM or after loading it via the right-click at the TM pane. Thus, the user is able to achieve anything she wishes adjusting the virtual handling to her needs. I agree that's not pretty straightforward.

IK: I agree that's not pretty straightforward.


To the point I have no idea what you're talking about. But you know what, I couldn't care less.

H.

I meant that if you uncheck "Segments memory" option either before you load the TM or after loading it via the right-click at the TM pane, no new segments will be added to that read only memory.

Igor, I have no problems at all with TR (apart from the terminology). But I do think that if you uncheck "Segments memory" for the TR TM, the TR segments shouldn't load. Anyway, it's not my problem, I'll have an arak or two.


H.

The two TM options:


- Segments memory - this TM is meant for segments 

- Fragments memory - this TM is meant for fragments


If you uncheck them, CT will not store either segments or fragment or both (permanently and virtually).

Login to post a comment