#734 Keep relative addressing in *.project when possible

[Guido Leenders]

We work with a number of translators. Most of them directly connect to our translation projects through Subversion. And some of them place the files on c: disk, some on h:, some on t:, and some somewhere deep in their directory hierarchy.

We use *.project files like these:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<omegat>
<project version="1.0">
<source_dir>__DEFAULT__</source_dir>
<target_dir>__DEFAULT__</target_dir>
<tm_dir>../../global/tm/</tm_dir>
<glossary_dir>../../global/glossary/en2es/</glossary_dir>
<dictionary_dir>../../global/dictionary/</dictionary_dir>
<source_lang>EN-US</source_lang>
<target_lang>ES</target_lang>
<sentence_seg>true</sentence_seg>
<support_default_translations>true</support_default_translations>
</project>
</omegat>

Please note that tm_dir, glossary_dir and dictionary_dir are relative paths. Since a translator sometimes open the project through Edit Project to allow the paths to be found, the relative paths are rewritten to the following when Edit Project is closed:

<tm_dir>H:/ws/translate/global/tm/</tm_dir>
<glossary_dir>H:/ws/translate/global/glossary/en2es/</glossary_dir>
<dictionary_dir>H:/ws/translate/global/dictionary/</dictionary_dir>

It would be handy if only entries that are touched by Edit Project were written back to the *.project file and the relative paths are kept as long as possible.

[Didier Briel]

In the context of a local usage, absolute paths are more robust, when project are moved, than relative paths.

So, switching the behaviour to relative paths would require an option, keeping the current behaviour as the default one.

Didier

[Guido Leenders]

Agree. Did some analysis some time ago. See at end of comment.

Proposal:
Maybe change the number 2 (current code) or number 5 (sample code) into a constant that might be user changable in the future?
And then include a patch similar to sample code below?

Please note that current code does not handle the scenario with more than 1 step correctly, since it does not test on root==null.

In ProjectFileStorage.java I have found that there is already some relative addressing. Suggested change:

--- C:/Users/gle3/AppData/Local/Temp/15/ProjectFileStorage.java-revBASE.svn000.tmp.java Sat Mar  3 20:26:02 2012
+++ H:/ws/sourceforge/omegat/src/org/omegat/util/ProjectFileStorage.java    Sat Mar  3 20:26:19 2012
@@ -193,9 +193,22 @@
File abs = new File(absolutePath).getCanonicalFile();
File root = new File(m_root).getCanonicalFile();
String prefix = new String();

-            for (int i = 0; i < 2; i++) {
+            //
+            // Try to derive the absolutePath as a relative path
+            // from root.
+            // First test whether the exact match is possible.
+            // Then on each try, one folder is moved up from the root.
+            //
+            // Currently, maximum 5 levels up.
+            // More than 5 directory levels different seems to be that the paths
+            // were not intended to be related.
+            //
+            for (int i = 0; i <= 5; i++) {
+                //
// File separator added to prevent "/MyProject EN-FR/"
-                // to be undesrtood as being inside "/MyProject/" [1879571]
+                // to be understood as being inside "/MyProject/" [1879571]
+                //
+                System.err.println("Testing " + abs.getPath() + " against " + root.getPath());
if ((abs.getPath() + File.separator).startsWith(root.getPath() + File.separator)) {
res = prefix + abs.getPath().substring(root.getPath().length());
if (res.startsWith(File.separator))
@@ -204,6 +217,13 @@
} else {
root = root.getParentFile();
prefix += File.separator + "..";
+                    //
+                    // There are no more parent paths.
+                    //
+                    if (root == null)
+                    {
+                      break;
+                    }
}
}
return res.replace(File.separatorChar, '/');

[Didier Briel]

<<
In ProjectFileStorage.java I have found that there is already some relative
addressing.
>>
Yes, if the path is one level above the project.

<<Maybe change the number 2 (current code) or number 5 (sample code) into a
constant that might be user changable in the future?>>

I would agree to integrate (after testing, of course) a patch based on a constant with value=2.

Didier

[Guido Leenders]

Ok. For our work, I would need value=3, but when the patch helps others with value 2 better, I have no problem having a permanent local change that just has to change one line reading '<=2' to '<=3'. Can you integrate it and test?

[Didier Briel]

For such things, it's better to define a constant.

Please send me the patch privately.

Didier

[Guido Leenders]

Patch on it's way.

[Didier Briel]

Implemented in TMX (/trunk).

Actually, 5 levels of relative addressing are kept.
After that, absolute addressing is restored.

Didier

[Didier Briel]

Implemented in the released version 3.0.7 of OmegaT.

Didier