Menu
▾
▴
#957 Priority TM to override project_save.tmx
It is often necessary to override the translation memory in the project_save.tmx by a more recent translation memory. Example: due to an SVN error, older translations replaced newer ones, and you want to override those older translations with the latest translation memory.
Another example is getting a proofread/edited TMX (possibly, done in another program), and needing to insert updated translations into the project.
Right now, this can be only achieved with a workaround: remove old project_save.tmx, insert the latest translation memory from tm/auto, then put old project_save.tmx to tm/autotm/auto to make sure any new translations that might have been added to it in the meantime are inserted as well.
A potential solution would be making OmegaT use a subfolder tm/priority (or a more apt folder name), from where OmegaT would override TU's from project_save.tmx with the TU's from TM's in this subfolder, if the target differs. Otherwise tm/priority would work the same as /tm/auto.
It would be nice if that /priority/ folder could include a priority number, so that you had as many as needed,that is, priority1, priority2, etc. The number would be interpreted as a priority order (priority1 would have the highest priority).
Maybe that functionality could be replicated both in the /auto/ and /penalty-XX/ subfolders, so that you could override the default order in which OmT processes TMXs there.
As of now it can be achieved by naming TMX files appropriately. For example, memory01.tmx is processed before memory02.tmx no matter in which subfolders of /tm those files reside. So one of the easiest way to define order is to prepend numbers to filenames.
Independent of the solution chosen this would be a great help to more easily get unexperienced translators up to speed with quality translations.
Now in 3.1.0 the requested behavior looks principally possible with this feature implemented: https://sourceforge.net/p/omegat/feature-requests/963/
Here's what I tried to see how it works.
Looks pretty hopeful, but the above procedure it a bit too cumbersome to be practical.
Kos,
Can't you merge the TMX based on the modification date ?
Or, as you wrote, you can assign names so that the old project_save.tmx is loaded from /auto after the updated segments present in new_project_save.tmx.
Or did I miss something ?
It's not about merging, it's about being able to override already
existing translation in a simple straightforward way.
Say you finish your translation, give it to someone else to be
edited or proofread. Many times this proofreading or editing is
done outside of OmegaT, but it might be relatively easy to produce a TMX
that would contain original source and edited translations. But how do
we get them back into OmegaT project? A workaround is described above:
move /omegat/project_save.tmx and copy/move new edited TMX
into /tm/auto so that the new TMX is used before the old
project_save.tmx, reload the project. Not optimal, but not too bad. Now
try that with a team project.
--
Kos
Last edit: Kos Ivantsov 2014-03-15
It seems to me the conflict resolution interface offers what you need, but not where you need it.
Conflict resolution now happens when 2 users work on the same project_save.tmx file remotely, but if we can have OmegaT apply the conflict resolution process to a localy selected TMX, the user would be able to effectively do what you request.
Let's say the translator receives a modified TMX, he puts it in a "/tm/conflict" folder, loads the project and the Conflict resolution panel appears. The translator can then accept all the modifications or only some, or modify his translation based on the correction etc.
When everything is validated, project_save.tmx is automatically updated and the new translations are taken into account.
What about that ? If that's what you want, may I suggest that we create a new RFE called "implement conflict resolution locally" or something similar.
Jean-Christophe
On Mar 15, 2014, at 9:04, Kos Ivantsov kosivantsov@users.sf.net wrote:
Related
Feature Requests:
#957You may consider this to be a request to import changes made to target files, back to OmegaT. Not quite, but still pretty similar. I often export my projects to html table to get a fresh look at them, and I find it very useful. This table can be easily edited in any old word processor/spreadsheet application/whatnot tool. Getting a tmx file from a two column table is not necessarily something difficult. But importing the changes back to OmegaT is.
--
Kos
Last edit: Kos Ivantsov 2014-03-15
I like what you're suggesting. Can this RFE be renamed and changed instead of creating a new one?
Renaming done.
So, the idea would now be to have a local implementation of conflict resolution between project_save.tmx and TM data put into a specific folder, like /tm/conflics (or a name that better shows that the function is about validating external modifications or the TM).
If the local conflict resolution is going to be implemented, it could work with /tm/auto folder. That way if there's a conflict with the existing translation (updated TU), it gets resolved through SuperTMXMerge, and if there are TU's for untranslated segments (no conflict), those segments get auto-populated. Or auto-populating starts first (as we have it now), and then conflict resolution kicks in.
Last edit: Kos Ivantsov 2014-03-16
If what the user wants is overwriting existing translations, conflict management is overkill, which is why I restore the initial title.
(If you think conflict management would still be useful, then create another RFE.)
I will implement the simple solution described initially. The only difference is that the "enforce" folder will not be a subfolder of auto, otherwise it's difficult to ensure that it is read after the auto folder. Previously, this wouldn't have been necessary, but it is now that unedited translations from the auto folder are overwritten.
Didier
Last edit: Didier Briel 2014-03-18
As usual, I'm not suggesting how to do it as I know next to nothing about almost anything. But I like JC's idea about conflict resolution, whether it'd be a part of this RFE or a separate issue.
If I remember correctly, SuperTMXMerge can be launched to perform a certain action by default. If that is true, there could be two folders used by SuperTMXMerge: /tm/conflict (where conflict resolutions will be triggered) and /tm/priority (or /tm/overwrite or something, from where SuperTMXMerge will silently put all the updated translation into the project). I don't know how well SuperTMXMerge works with non-OmegaT TMX's, though. But it's only a thought, for what it's worth. I'm not to tell how to implement it.
--
Kos
Implemented in SVN (/trunk).
In addition to the "auto" folder, an "enforce" folder can now be used in the /tm folder.
If a TMX comes from /tm/enforce, all translations from this TMX will overwrite existing default translations unconditionally.
As "enforce" is after "auto", translations from this folder will always be inserted last.
Didier
I tried this new feature and I like it — very nicely done, thank you very much, Didier. I still have one request concerning this feature, but I don't know whether the discussion should go on here or be started over in a new RFE.
As it works now, every translation found in /tm/enforce that has corresponding source is pushed into the project, no matter whether the target is the same or different. Which is fine in many cases, but there are cases when the new TMX that is used from /tm/enforce has been edited in or produced by another tool that doesn't respect OmegaT metadata (and most third-party tools don't), and when its translations are pushed into the project, there is no way to tell what actually has been updated, when, by who, how much etc. It is desirable to push only updated TU's in.
I realize that in order to strip metadata to be able to compare only the text of TMX and project targets for the segments whose source is the same, might be a slow thing. If so, maybe this enforcement can be made into a user-invoked action, like "Tools -> Update project from edited TMX" or something, instead of an automatic thing as it is now.
And then as I've discovered (well, it's mentioned in the corresponding RFE, but here's my observation https://sourceforge.net/p/omegat/feature-requests/957/#ce92), auto-populated segments can be repopulated if the translation is changed. I don't know if it's based on the time stamp (which won't help for this request), or on the actual text of the translation, but if the latter, maybe that can be used here too.
--
Kos
It's based on the "auto-populated" status (which can be saved or not, see option in Editing Behaviour). When a segment was auto-populated, and has not been edited, it is overwritten. As soon as the segment is edited, the auto-populated status is removed.
Didier
That was the requirement. To be able to enforce (hence the name) any "official" translation, whatever choices might have been made in OmegaT previously.
In the other RFE, the segments that have been auto-populated, but not edited in OmegaT, will be overwritten (it's not a question of time stamp, it's a question of status). Depending on Save auto-populated status, a segment has to be really edited in OmegaT to be protected against being overwritten, or it has just to be saved and reloaded in a next session.
Didier
We seem to miscommunicate, or I rather seem to fail to explain or get the point. I'll just describe my recent work situation:
I have completed a project in OmegaT. Now I need to get it to an editor that I haven't worked with before. When I get the work back from him, it's not only the actual linguistic material encapsulated in TMX format that I'm getting, but also a way to estimate how valuable a worker he is.
The editor prefers to work not in OmegaT, but with "editable text documents", so I export the project into a HTML table (with all the OmegaT tags preserved and nicely highlighted, similar to Wordfast review, if you know what I'm talking about). The editor works in MS Word, OOo/LO or whatever other tool he choses, and sends the completed file back to me. I parse the text from the table and produce a TMX with perfect OmegaT matches (but sans metadata, unfortunately).
Now, my idea was putting this newly produced TMX into the /tm/enforce folder and getting only changed segments forced over the project's translations (ideally, with initialCreationDate and initialCreationId kept intact). Than way I could fairly easily filter the editors work, estimate it and/or change it as needed, plus keep the metadata for all the unchanged segments so there would be a way to manage translations based on who and when have done them.
It's not too crucial as much of it can be achieved through different third party tools, but if it's possible to provide for "selective enforcement" in OmegaT, it'll could be very, very helpful at times.
--
Kos
My impression is that it is not an issue of miscommunication, but simply that the new feature doesn't do what you would like it do to do, or what you would expect it would to. It happens that some people needed the current "enforce" behaviour. If you want another one, that's fine, but it should be the subject of another RFE.
I believe you could do that with SuperTMXMerge in Combine mode.
Didier
Thanks, Didier. What a great relief to realize that I did manage to communicate something :) Sometimes I just feel I get others lost in my verbosity, but I fear keeping it brief would lead to ambiguity. Constant struggle :)
I'll create another RFE for local conflict resolution as JC suggested.
--
Kos