Menu
▾
▴
#902 Edits may be lost without warning when closing OmegaT
- Open a project in OmegaT (one of the segments is open for editing)
- Press space a couple of times. (spaces are added to the segment)
- Click on the menu item Project / Quit (OmegaT is shut down)
- Start OmegaT and open the project again
- Note how the spaces have disappeared.
Spaces are of course just an example. And if you move to the next segment, or close the project with Ctrl+Shift+W, edits are saved
Is it not possible to edit the Title of the Ticket? It should read:
"Edits may be lost without warning when closing OmegaT"
As a workaround, you can use Options > Preferences > General > Always Confirm Quit.
Didier
I understand what you're saying but it doesn't seem to help. I enabled "always confirm quit" and went through the steps in the bug report and the spaces still disappear.
Did you try it?
When you attempt to quit, after you added spaces, and you answer No to the question, the spaces are not lost. That's what I meant.
Didier
I just did the test.
In your steps, you add something to a segment but you don't validate it, so strictly speaking, you did not modify the project. If you go to another segment, then you validate actual one so you modify the project.
For me this is not a bug: this simply means that you don't save what you did not validate.
Thomas
Thanks for your comment and I can understand the strict logic of it,
as you point it out. But I'd still say it's unexpected behavior,
especially to a beginner. In fact, I discovered the behavior after
having helped my wife get started with OmegaT and she later had
complained of work "gone missing" and after some investigation I
pinpointed the behavior I reported.
I guess it's safe to assume most newcomers to OmegaT have some
background using an Office program. E.g in LibreOffice Writer, if you
type something and then try to close the document/program, it will
warn you of "unsaved changes" (or words to that effect)
Would it be a stretch for OmegaT to warn of "unconfirmed/unvalidated
changes" when closing the project? I haven't looked at the source, but
assume it would entail setting a 'dirty' flag on the project every
time the user types something and clearing the flag whenever the
project is saved.
PS: The proposed workaround of enabling "Always Confirm Quit" doesn't
really help as it doesn't mention unsaved changes.
PS2: Come to think of it, I'm not even sure what issue "Always Confirm
Quit" mitigates.
Last edit: Aaron Madlon-Kay 2018-05-30
Yes, except that neither MS-Office nor Libre Office make distinction between edited text and validated one.
On the contrary, Office-based CAT tools, such as WordFast (for Word) or Anaphraseus (for Libre Office) do make this distinction and would have exactly the same behaviour as OmegaT (namely: if you modify a translation but don't validate it, it is not saved)
There is flag when the project is modified, but as I said, the project is modified when almost one segment is validated. Then you receive a message on exiting.
A solution could be then, that the "Quit" action is always preceeded by validating the current segment.
Let's wait what other readers mean about this.
The issue in that case is that you might validate something you didn't want.
Didier
True. But I could say exactly the same when I do some changes to a segment and then go to another one using arrows or mouse, instead of ENTER. So, this is coherent with what OmegaT actually does in other situations.
[Addition] And I just realized that this is also true when you use "Project -> Close", which is explicitely preceeded, in the code, by validation of current entry.
Actually all kinds of segment leaving do validate the content except the "Project -> Quit".
Last edit: Thomas CORDONNIER 2018-05-23
Fair enough.
Validating the segment with Quit would be acceptable for me.
Didier
It prevents quitting when you hit (for instance) Ctrl+Q by mistake.
Didier
This patch seems to do the job correctly.
Regards
Thomas
Fixed in SVN [r10392].
Didier
Related
Commit: [r10392]
I'm not very happy with this, it should be an option, not hardcoded behaviour. And on a more important note than just personal prefference, how does this interact with "Insert source text"+"Allow translation to be equal to source"? It looks like a pretty big footgun.
What is your issue?
It doesn't really.
When you press Ctrl+Q, the segment is validated first, instead of the current edit being lost. I don't really see the interaction.
Can you elaborate?
Didier
Now if I understood the change correctly, you now end up with with the prefiled source text treated as an actual translation, which I guess no one would want.
Yes, but consider the following scenarios:
a. replace step 4 by "click to another segment"
b. replace step 4 by "press CTRL+U" (go to next untranslated segment) ;
(also valid for any "go to next/previous XXX segment)
c. replace step 4 by "close the project"
In all scenarios a, b and c, the prefilled source text is also treated as actual translation. Not sure this is what all people want. But it seemed to me that there was no reason why the scenario where 4. = Quit OmegaT is the only one where the segment is not validated. That is a question of coherence.
The alternative solution would be that we define some actions which really validate the segments while others don't. For example, forcing to press RETURN to validate the segment, while other actions, including a, b and c, would not validate it. No doubt that some people would prefer such a solution, so the two options are valid and could be switchable boolean options (suggested names : "validate when exit or close" + "validate only when using ENTER")
This new set of boolean options is not a bad idea, after all, this is better than undocumented behaviour. If other people agree, we could open an RFE (not a bug) for that.
Another solution, probably more complicated, is to save the translation but adding to it a draft status. See [feature-requests:#516] for example. But that is another story.
Related
Feature Requests:
#516Last edit: Aaron Madlon-Kay 2018-05-30
Understood.
I had the same reserve initially. However, as Thomas explains, if that's what we are doing for Close Project, there's no reason to not do it for Quit (which is de facto Close Project + Quit).
As an aside, now that you can validate "translation equals to source" on a case by case basis and explicitly (Edit > Register Identical Translation), I nearly never use "Allow translation equals to source" anymore, precisely because it's too "dangerous" when leaving the segment.
In addition to the cases mentioned by Thomas, there is also:
Do a fruitful search (for instance, select something in the Editor, then Ctrl+F), while having Auto-sync with Editor checked.
Right-click on a fuzzy match and select Go To Segment Source
(And I’m grateful all these cases validate the segment, otherwise I would often lose content.)
Didier
Last edit: Didier Briel 2018-05-30
Closed in the released version 4.1.5 of OmegaT.
Didier