Being able to change segmentation in team projects is as important as in regular projects, but OmegaT does not provide any easy way to do so. The svn_commit_source_files.groovy script written by Yu Tang could be the answer.
Unlike other files currently synced by svn_commit_source_files.groovy, the segmentation.conf does not allow easy syncing, though. The problem is that after a rule is added, OmegaT does not update it until the project is reloaded or closed + reopened.
When it comes to closing and reopening the project to update the segmentation.conf, OmegaT updates the segmentation.conf, but then immediately overwrites it with the one from the server, so no go.
However, when the project is simply reloaded (e.g., with F5), OmegaT does update the segmentation.conf, while not overwriting it with the one from the server. This “loophole” could allow committing the segmentation.conf to the server as follows:
1. Add a segmentation rule.
2. Allow OmegaT to reload the project when it requests to do so = update the segmentation.conf.
3. Run svn_commit_source_files.groovy to commit the updated segmentation.conf. As with other files synced by the script, this must be done fairly quickly, so that OmegaT does not overwrite the updated file in the meantime.
More information is available in this discussion: https://groups.yahoo.com/neo/groups/OmegaT/conversations/topics/31741
@Didier, do we have any plans to include segmentation.conf to regular Team sync target like writeable-glossaries?
Not as far as I know. If needed, we could discuss it in dev-tech. The potential issue, if it is synchronised automatically, is that all translators would be able to update segmentation rules, thus potentially untranslating segments. While it would be useful in some cases, it might be problematic for some project managers.
Didier
Thank you, Dider. Now this is where a script comes in.
Feel free to assign me.
@Roman, I have a hazy idea that if the script will be separated new one from svn_commit_source_files.groovy.
If you have any problem with that, please let me know.
As you may use a different script, I have updated the title accordingly
Of course, not! Thanks, Yu.
I don't know if it adds to this particular request, and if my suggestion is not too crazy.
It seems beneficial if OmegaT could use a local unversioned segmentation.conf (named differently, of course, like local.segmntation.conf, for instance) instead of the project's segmentation.conf if such file is found in the same directory.
The benefit would be the ease of maintenance: the user copies segmentation.conf into local.segmentation.conf, experiments with it without the fear of his changes to be overwritten with versioned segmentation.conf (if the unversioned local file is found, OmegaT modifies it, not the segmentation.conf), and when they are satisfied with the results, it's then up to them to decide what to do with the file - leave it there as is, commit it to the server as segmentation.conf, send it to the project manager etc. If this behavior is implemented, then the script could commit local.segmentation.conf as segmentation.conf if the two files differ. The script could also copy segmentation.conf into local.segmentation.conf if such file isn't found.
What do you think of this idea?
It seems a bit convoluted to me. In addition, even if the local segmentation.conf is not committed, the user will still have a different segmentation than the other users, which means sending orphan segments to the project translation memory. I'm not sure this should be encouraged.
Didier
I made the new script. See an attachment.
There is one thing what I'm worried about.
I introduced event driven automatically execution mode for project managers.
You can manually execute it and (if you want) automatically execute it too.
Both modes seems working well here.
I like two-way usages in the beginning of developing.
But now I'm not sure if event driven automatically execution is good idea or bad one.
If you guys have any concerns, please let me know that.
Wow, can't wait to test! Thank you so much, Yu.
Implemented in SVN (/trunk).
Didier
Implemented in the released version 3.1.7 of OmegaT.
Didier