Hi Jean-Christophe,
thank you for verifying the file format provided.
Based on all discussions, I think that now we have 2 possibilities:
1) to provide you with 2 tmx files 1 for UI and 1 for OLH (unfortunately
splitting the tms OLH file into single components it's really time
consuming and also, there are some parts which are shared among other
modules so I think that having 1 OLH tmx is much better). These tmx
files will be based on all translated strings which will be used for the
2.3 and which do not need any update (what we flag as translated and
reviewed)
2) to provide you 2 tmx files: 1 for UI and 1 for OLH with exactly the
same strings you received for translation as sdf files. This tmx file
will contain what we call new and changed strings, exactly the same you
have in the sdf file. This way you would be able to see - if I
understand it correctly - the previous translations directly in the
OmegaT window.
Just let me know what works for you best.
Rafaella
Jean-Christophe Helary wrote:
On 19 juin 07, at 18:28, Rafaella Braconi wrote:
Hi Jean-Christophe,
attched you can find a TEST tmx file created out of the Calc Help
project. This test file should be used to verify if you can read it,
use it, etc. Once you verify the file and everything is fine (let's
keep the finger crossed) I will proceed doing a full extraction of
tmx files out of the database.
Just let me know the results.
It loaded properly. I see that the whole package eats up a lot of
memory:
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD
RSIZE VSIZE
7123 java 0.0% 9:30.89 18 523 333 108M 54.6M
126M 2.56G
And I noticed matches (even low level ones) early in the file. So it
seems to work.
The French file has not been split by application but if it were
possible to get a split TMX that would be make the set more useable
in the future.
Regarding the escape sequences:
I suppose you created the TMX directly from the material that gives
you the .sdf files ? So basically the TMX seems to contain the exact
same level of escaping. Let's say it keeps the file at an arbitrary
"level 1".
When I use the "level 1" .sdf to create a po file with oo2po, the
process escapes the escape sequence character "\" so I get to a
"level 2" escaping. "Level 2" contains one more "\" character for
each escape sequence group.
So basically, my .po file and your .tmx file do not match at the
number of "\" for escape sequences.
I had the same issue with the oo2po + po2tmx process (see the other
thread on the list).
the .sdf is at "level 1", the oo2po process puts the resulting .po at
"level 2", adding an extra "\" to each escape sequence and the po2tmx
process removes that extra character to lower the escaping to "level
1", which makes it incompatible with the .po source file.
In the case of your internal conversion I'd say it is bad luck for
me, but in the case of the translate-toolkit processes I think that
should not be the expected behavior: the .tmx should contain the same
contents as the .po file. I think there is a bug in the po2tmx
process somehow.
Regards,
Jean-Christophe
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
