We are using P.E.M.T. (Post Edited Machine Translation) and have built a system that generates
OmegaT project that work very well. We would like to use the console mode to automaticly update
the translations (we have a seperate OmegaT-Team area and copy back the project_save.tmx file to
the Master project). We are using version 4.1.5 Update 2 (10465) and have about 230 projects (more
to come, many more).
This test is on fedora and the command
omega omega/zh-hans (the project is in the omega/zh-hans directory) generates what is seen
in the attache txt file (I used the full path thinking that that might be the problem)
I confirm I can reproduce it.
Didier
Great I hoped that I was not doing anything sutpid
I made a patch to fix this issue. It happens because Core doesn't have a segmenter by the time it's required by ProjectTMX. GUI codepath initialize segmenter earlier, so we don't see any problems. Funny that there's a comment in RealProject.LoadProject saying that segmenter is not required for loading translation which is wrong.
The comment was consistent with my mistake, thinking a segmenter was not required (because the GUI codepath initializes the segmenter, as you noted).
Didier
Didier, Lev's fix conflicts with your fix for [#864] ([r10082]). Can you take a look? I think instead of moving the segmentation setup earlier (as Lev did) we need to move
loadTranslations()to after the segmentaiton setup.Also
loadFilterSettings()probably needs to be moved after the rebase. (Also the segmentation setup should be refactored toloadSegmentationSettings()to match the filter settings.)Aside: This is another example of major architectural problems in OmegaT: so many things are static, global state that it's very hard to know what uses what. In this case it's
ProjectTMXrelying on segmenters, but there is zero indication of this dependency in the API. ReallyProjectTMXshould require a segmenter be passed on construction.Related
Bugs:
#864Commit: [r10082]
I couldn't find a conflict with r10082. The only problem I see in
loadProject()is thatloadTranslations()happens before rebase, and rebase can change project TMX. So yeah, it's better to move it after segmentation setup instead of moving segmentation setup earlier.I failed to understand why
loadFilterSettings()should be moved after rebase.Extending
ProjectTMXconstructor is a good idea though it may break some scripts or plugins.Last edit: Lev Abashkin 2018-10-26
It's not a code conflict; I meant your change is incompatible with the goals of [r10082], which is that project rebase results in new segmentation settings taking effect.
loadFilterSettings()needs to be after rebase as well because rebasing can pull in new filter settings, which the user would rightfully expect to take effect.Changes to
ProjectTMXare really outside the scope of this ticket; I was just spitballing.Related
Commit: [r10082]
This is what I have done.
I don't think it's needed. The filter configuration is loaded earlier, by
remoteRepositoryProvider.copyFilesFromRepoToProject.Done.
Fixed in SVN (/trunk, [r10471]).
Didier
Related
Commit: [r10471]
Closed in the released version 4.1.5 update 3 of OmegaT.
Didier