Re: [l10n-dev] mnemonics
Alessandro Cattelan, 19-06-2007 04:16: I know this must have been asked before, but I don't remember whether mnemonics have to be changed or simply deleted. In the following case does the ~ have to be removed or should it be put on another letter? en: Macro ~from it: Macro da It's nice to have an consistent behavior. Some people thinks consistence across languages of the same program matters more, while others think consistence across differente programs on the same language matters more. I, personally, do prefer the consistence across different languages of the same program. So, you should use the same letter, if possible, if not, look for an *unused* letter. If you prefer the other approach, you can look at another applications and use the mnemonics from there. Tip: put mnemonics on upper case letters, if possible. If not, avoid as most as possible letters such: g, p, j, q, y. Also avoid thin letters, as i, l and t, if possible. a, w, o, d, c, b, m, s, are good choices. Think that it should be intuitive (a letter that relates to the action) and it should be easy to read the letter alone underlined (for this reason thin letters and letters that use the lower parts of the grid are not recommended). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] OmegaT and PO files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jean-Christophe Helary ha scritto: > > On 19 juin 07, at 17:12, Alessandro Cattelan wrote: >> I don't understand why you need to create .pot instead of .po files. I >> converted the sdf to po files and OmegaT just ignores the msgstr >> content, so what is the use of having a pot file with empty msgstr >> fields? > > Because I am pretty sure OmegaT would not overwrite the msgstr part > since it does not know about it. So this is likely to result in a buggy > target file. But maybe I am just too careful. I've checked the target files and it seems to me that they have been properly compiled by OmegaT: the original msgstr content has been replaced by my translation. Ale. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGeEtgdpk3ZlYYJ+gRAth9AJ9NL3LHPqXa2Yw6EYHJlLB36txBhwCfRBDM oAiOCVKjkyuf7P8cgRRe3Ls= =oh8r -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] OmegaT and PO files
Thank you Alessandro... Best, Charles. Alessandro Cattelan a écrit : > Charles-H. Schulz ha scritto: > > Hi, > > > sorry this is a side question, as I'm trying to understand the way to > > work with OmegaT and how we end up enriching / easing the localization > > processes. > > What exactly is translation memory and TMX and how do they work? > > > Thank you, > > > Charles. > > > It's all here: > http://en.wikipedia.org/wiki/Translation_memory > > Translation memory is a technology widely used in the professional > translation market: it speeds up the translation process and allows for > a better quality and consistency in translation. > > > > Ale. > - 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]
Re: [l10n-dev] Re: OO translation - miniTM for French
Hi Jean-Christophe, Jean-Christophe Helary wrote: On 19 juin 07, at 20:52, Rafaella Braconi wrote: 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. I am not sure I understand the second option. Would that be a "pseudo translated" file that you turn into TMX, like I did myself ? Yes. That would be in the end the same you have done yourself. Or would that be the set of modified segments _before_ they were modified along with their correct translation ? The minimum I need is this set of modified segments _before_ they were modified, ie, the state of the (limited) corpus at the time of 2.2.1. I am afraid this is not possible. If that is possible I'll take that. If not, I'll take option 1 above. Ok. We will work to provide you with Option 1. Cheers, Rafaella Cheers, JC 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] Jean-Christophe Helary - 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]
Re: [l10n-dev] Re: OO translation - miniTM for French
On 19 juin 07, at 20:52, Rafaella Braconi wrote: 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. I am not sure I understand the second option. Would that be a "pseudo translated" file that you turn into TMX, like I did myself ? Or would that be the set of modified segments _before_ they were modified along with their correct translation ? The minimum I need is this set of modified segments _before_ they were modified, ie, the state of the (limited) corpus at the time of 2.2.1. If that is possible I'll take that. If not, I'll take option 1 above. Cheers, JC 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] Jean-Christophe Helary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Re: OO translation - miniTM for French
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]
Re: [l10n-dev] OmegaT and PO files
On 19 juin 07, at 19:51, Rafaella Braconi wrote: yes, I was also suggesting jean-Christophe to use that tmx files but I think that he really want to make sure to get the most updated tmx files... I am currently loading them and I don't see anything problematic. Are you referring to the tmx TEST file I just provided? Does this really work? Yes, I am replying to you offlist with some specifics but basically they work well. JC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] OmegaT and PO files
Hi Jean-Christophe, Jean-Christophe Helary wrote: On 19 juin 07, at 18:17, Rafaella Braconi wrote: Hi Alessandro, Jean-Christophe, Alessandro Cattelan wrote: Jean-Christophe Helary ha scritto: I think Rafaella should be able to provide you with proper TMX files that match the .sdf contents. Rafaella has already provided us with the OLH TMX some time ago. yes, I was also suggesting jean-Christophe to use that tmx files but I think that he really want to make sure to get the most updated tmx files... I am currently loading them and I don't see anything problematic. Are you referring to the tmx TEST file I just provided? Does this really work? Rafaella - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] OmegaT and PO files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charles-H. Schulz ha scritto: > Hi, > > sorry this is a side question, as I'm trying to understand the way to > work with OmegaT and how we end up enriching / easing the localization > processes. > What exactly is translation memory and TMX and how do they work? > > Thank you, > > Charles. > It's all here: http://en.wikipedia.org/wiki/Translation_memory Translation memory is a technology widely used in the professional translation market: it speeds up the translation process and allows for a better quality and consistency in translation. Ale. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGd7KDdpk3ZlYYJ+gRAtDNAJ0SDuNaN9GdfUWDQFcoebDdwI/o7gCfeKUZ mcqlqIyW6Y9pTwN3ekygbJg= =imVs -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] OmegaT and PO files
Hi, sorry this is a side question, as I'm trying to understand the way to work with OmegaT and how we end up enriching / easing the localization processes. What exactly is translation memory and TMX and how do they work? Thank you, Charles. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] escaping
OmegaT handles PO files pretty much as text files and thus does not
care about "\", for it, the "\" is just another character. Hence,
there is nothing that is generated by OmegaT in the screenshot I
showed. The files are displayed as they are.
Friedel,
I am not arguing for or against a certain way to display the data I
am just saying that OmegaT does not do anything to the data. And
considers the PO escapes as a "\" character.
Unfortunately a PO file isn't just a text file. It is a file format
that
presents data in a specific way. To escape the slash
(\) and the quotes (") is part of the format that we try to conform
to.
Which is very good and OmegaT does not interfere with that.
So, you see, the TMX does not exactly match the original .po file.
Although it does match the .sdf, but this is irrelevant.
When I created the TMX by using XLFEdit from Heartsome, I first too
the converted po, converted it to XLIFF and then exported it as TMX
and the TMX contained the same number of escapes as the po.
I would consider this behaviour by the Heartsome tool to be a bug,
to be
honest. Do they convert '<' to '<' ? Then they should also convert
the rest. I would say this is part of the rules of data conversion
between these formats.
I believe our conversion conforms to the XLIFF representation guide
for
PO files:
http://xliff-tools.freedesktop.org/snapshots/po-repr-guide/wd-xliff-
profile-po.html#s.general_considerations.escapechars
I think it follows logically that the same rules should apply for
converting to TMX.
I have no idea who is right and who is wrong. What I can say is that
Heartsome is _very_ strong when it comes to respecting standards.
Besides, the document you quote has contributions from Rodolfo Raya
who is also developer at Heartsome and who himself is extremely picky
when it comes to standards compliance.
In "3.4.Handling of Escape Sequences in Software Messages", the text
says, regarding a fragment that includes escape sequences like we
have here: "This fragment could be presented in XLIFF by preserving
the escape sequences:"
etc. Of course it proposes rules to handle special escape sequences
as opposed to generic escape sequences but there is nothing wrong
seemingly with keeping all the escape sequences.
What matters in the end is _not_ that the PO has been through an
XLIFF conversion process or not.
What matter is that:
1) I have a source po with \\\
2) my reference TMX should match that with > because it is created from a similar po file
3) but for some reason it provides only \\
Let me repeat myself. I have no issue with your processes and with
your level of compliance with the proposed standards.
The only problem is that somewhere, the TMX conversion process looses
data and that impairs my ability to get leverage from it.
A somewhat separate issue for me is that the \< in the SDF file is
also
an escape of that format. In reality it refers to just a left angular
bracket. The SDF format is however a bit strange in the way these are
used, and we might not want to change the way we handle the SDF
escaping
while Pavel's POT files has a semi-official status. If we can agree
how
we interpret the escaping in the SDF file and coordinate the
change, we
can probably make the lives of translators far easier by eliminating
much of the escaping.
I don't think the problem is in the oo2po process. Whatever the
result we are all starting from po anyway.
What is at stake here is that if I take a po created from .sdf and I
use po2tmx on that same file, the data that the TMX contains is
different from the data in the po.
JC
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] OmegaT and PO files
On 19 juin 07, at 17:12, Alessandro Cattelan wrote: I don't understand why you need to create .pot instead of .po files. I converted the sdf to po files and OmegaT just ignores the msgstr content, so what is the use of having a pot file with empty msgstr fields? Because I am pretty sure OmegaT would not overwrite the msgstr part since it does not know about it. So this is likely to result in a buggy target file. But maybe I am just too careful. JC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] OmegaT and PO files
On 19 juin 07, at 18:17, Rafaella Braconi wrote: Hi Alessandro, Jean-Christophe, Alessandro Cattelan wrote: Jean-Christophe Helary ha scritto: I think Rafaella should be able to provide you with proper TMX files that match the .sdf contents. Rafaella has already provided us with the OLH TMX some time ago. yes, I was also suggesting jean-Christophe to use that tmx files but I think that he really want to make sure to get the most updated tmx files... I am currently loading them and I don't see anything problematic. The only problem I see with the method you propose is that we would end up having two TM. The TM I have is pretty big (over 12MB) and OmegaT takes a long time to analyse it. If I put another big TM in the tm folder I think it would end up being too slow. However, I'll have a look at that. I am not clear about this. Why would you end up having 2 TMs? Cannot one sinply use the most recent tMX files? Anyway, as far as OmegaT is concerned that does not matter. It is only the total number of segments to match that will lengthen he load process. I have just loaded the 8000 segments + 2 x 2000 segments TMXs matching to the whole .sdf->pot file and it took less than 2mn on my machine (MacBook duo core 2ghz/2gb) I also assigned 2gb to OmegaT -in Java seerver mode (faster in general): java -server -Xmx2048M -jar OmegaT.jar JC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] OmegaT and PO files
Hi Alessandro, Jean-Christophe, Alessandro Cattelan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jean-Christophe Helary ha scritto: Basically OmegaT's PO handling is only (just like for monolingual files) to put in the target editing field the contents of source, for edition. OmegaT is not able to know that a target already exist and to propose it for editing. What I have thus done is the following: 1) convert the .sdf file to .pot (oo2po -P etc) to remove all the msgstr contents 2) create a TMX from the pseudo translated .sdf (oo2po and then po2tmx, cf my comments on that process in a different thread) 3) put the .pot in /source/, the tmx in /tm/ and OmegaT will automatically match the .pot strings to their pseudo translated counterparts in the tmx, thus allowing you to have the msgstr contents in target. It is a little non-trivial, but remember that OmegaT is not made to work with bilingual localization files. It works with a monolingual file in source and bilingual TM files for reference. I think Rafaella should be able to provide you with proper TMX files that match the .sdf contents. Rafaella has already provided us with the OLH TMX some time ago. yes, I was also suggesting jean-Christophe to use that tmx files but I think that he really want to make sure to get the most updated tmx files... The only problem I see with the method you propose is that we would end up having two TM. The TM I have is pretty big (over 12MB) and OmegaT takes a long time to analyse it. If I put another big TM in the tm folder I think it would end up being too slow. However, I'll have a look at that. I am not clear about this. Why would you end up having 2 TMs? Cannot one sinply use the most recent tMX files? Rafaella I don't understand why you need to create .pot instead of .po files. I converted the sdf to po files and OmegaT just ignores the msgstr content, so what is the use of having a pot file with empty msgstr fields? Ale. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGd4/udpk3ZlYYJ+gRAksmAKDIwVSahA9STieJZ6hI/AklQreOPACgwWTI GmkkHUh4ZZsWkO1b9p2NBGg= =yOoO -END PGP SIGNATURE- - 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]
Re: [l10n-dev] mnemonics
Just let me add, for clarification that if this is not a menu entry or a pushbutton, you can delete it since it will be assigned automatically. Here some inforamtion on mnemonics and the list of the Italian mnemonics as they have been set in the main menu entries: http://wiki.services.openoffice.org/wiki/Mnemonics_Localisation Rafaella Petr Dudacek wrote: Oops, now I see that my reply is not really an answer to your question :) I described the situation where you are *changing* an *existing* translation. For new translations, the best way really is to look at the other items and try to assign the mnemonics in a way that there are no duplicates. Petr Petr Dudacek napsal(a): Hi Ale, where possible, mnemonics should be kept on the same letter. If the letter is not there, like in your case, the best solution is to look at the menu (or dialog) for the other mnemonics and to assign the mnemonic to an unused letter. The purpose of this is to avoid two items sharing the same letter. If the mnemonic is deleted, OOo will assign it automatically to a random letter, but AFAIK the algorithm doesn't look for other mnemonics in the same menu/dialog, so it may happen that the mnemonic is assigned to a letter that is already used by another item. Regards, Petr Alessandro Cattelan napsal(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I know this must have been asked before, but I don't remember whether mnemonics have to be changed or simply deleted. In the following case does the ~ have to be removed or should it be put on another letter? en: Macro ~from it: Macro da Ale. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGd4LFdpk3ZlYYJ+gRApR4AKC/LpOxW7qPjkTBqPKDJcowXPshJQCeLAao ZiaOXHT2dmMXeZ2M9PsHqRg= =O4S2 -END PGP SIGNATURE- - 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] - 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]
Re: [l10n-dev] OmegaT or poEdit?
Hi Arthur, Arthur Buijs wrote: Hi JC, Jean-Christophe Helary schreef: [...] I have just modified your text a little bit to clarify the project setting up and the glossary export from SunGloss. Thanks you. Again this saves me quite some time. If Rafaella agrees I would like to copy the contents to http://wiki.services.openoffice.org/wiki/Translation_for_2.3 yes, please: This saves me some time as well :-) And if you want to add the link to your native wiki, please go ahead. That's our wiki for our work not mine! Rafaella - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] mnemonics
Oops, now I see that my reply is not really an answer to your question :) I described the situation where you are *changing* an *existing* translation. For new translations, the best way really is to look at the other items and try to assign the mnemonics in a way that there are no duplicates. Petr Petr Dudacek napsal(a): Hi Ale, where possible, mnemonics should be kept on the same letter. If the letter is not there, like in your case, the best solution is to look at the menu (or dialog) for the other mnemonics and to assign the mnemonic to an unused letter. The purpose of this is to avoid two items sharing the same letter. If the mnemonic is deleted, OOo will assign it automatically to a random letter, but AFAIK the algorithm doesn't look for other mnemonics in the same menu/dialog, so it may happen that the mnemonic is assigned to a letter that is already used by another item. Regards, Petr Alessandro Cattelan napsal(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I know this must have been asked before, but I don't remember whether mnemonics have to be changed or simply deleted. In the following case does the ~ have to be removed or should it be put on another letter? en: Macro ~from it: Macro da Ale. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGd4LFdpk3ZlYYJ+gRApR4AKC/LpOxW7qPjkTBqPKDJcowXPshJQCeLAao ZiaOXHT2dmMXeZ2M9PsHqRg= =O4S2 -END PGP SIGNATURE- - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] OmegaT and PO files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jean-Christophe Helary ha scritto: > Basically OmegaT's PO handling is only (just like for monolingual files) > to put in the target editing field the contents of source, for edition. > > OmegaT is not able to know that a target already exist and to propose it > for editing. > > What I have thus done is the following: > > 1) convert the .sdf file to .pot (oo2po -P etc) to remove all the msgstr > contents > 2) create a TMX from the pseudo translated .sdf (oo2po and then po2tmx, > cf my comments on that process in a different thread) > 3) put the .pot in /source/, the tmx in /tm/ and OmegaT will > automatically match the .pot strings to their pseudo translated > counterparts in the tmx, thus allowing you to have the msgstr contents > in target. > > It is a little non-trivial, but remember that OmegaT is not made to work > with bilingual localization files. It works with a monolingual file in > source and bilingual TM files for reference. > > I think Rafaella should be able to provide you with proper TMX files > that match the .sdf contents. Rafaella has already provided us with the OLH TMX some time ago. The only problem I see with the method you propose is that we would end up having two TM. The TM I have is pretty big (over 12MB) and OmegaT takes a long time to analyse it. If I put another big TM in the tm folder I think it would end up being too slow. However, I'll have a look at that. I don't understand why you need to create .pot instead of .po files. I converted the sdf to po files and OmegaT just ignores the msgstr content, so what is the use of having a pot file with empty msgstr fields? Ale. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGd4/udpk3ZlYYJ+gRAksmAKDIwVSahA9STieJZ6hI/AklQreOPACgwWTI GmkkHUh4ZZsWkO1b9p2NBGg= =yOoO -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] mnemonics
Hi Ale, where possible, mnemonics should be kept on the same letter. If the letter is not there, like in your case, the best solution is to look at the menu (or dialog) for the other mnemonics and to assign the mnemonic to an unused letter. The purpose of this is to avoid two items sharing the same letter. If the mnemonic is deleted, OOo will assign it automatically to a random letter, but AFAIK the algorithm doesn't look for other mnemonics in the same menu/dialog, so it may happen that the mnemonic is assigned to a letter that is already used by another item. Regards, Petr Alessandro Cattelan napsal(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I know this must have been asked before, but I don't remember whether mnemonics have to be changed or simply deleted. In the following case does the ~ have to be removed or should it be put on another letter? en: Macro ~from it: Macro da Ale. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGd4LFdpk3ZlYYJ+gRApR4AKC/LpOxW7qPjkTBqPKDJcowXPshJQCeLAao ZiaOXHT2dmMXeZ2M9PsHqRg= =O4S2 -END PGP SIGNATURE- - 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]
Re: [l10n-dev] escaping
On Di, 2007-06-19 at 00:44 +0900, Jean-Christophe Helary wrote:
> On 18 juin 07, at 23:28, F Wolff wrote:
...
> >
> > So this is the PO file, am I correct? Does OmegaT handle the
> > escapes in
> > the PO file? Does the actual PO file (opened in a normal text editor)
> > have \\\" or something else? This would of course mean \" since both
> > the backslash and the double quote must be escaped in PO files (along
> > with newlines and tabs). In TMX they are of course put in unescaped as
> > \" since the escaping is not necessary for TMX.
> >
> > Would this explain what you are seeing?
>
> OmegaT handles PO files pretty much as text files and thus does not
> care about "\", for it, the "\" is just another character. Hence,
> there is nothing that is generated by OmegaT in the screenshot I
> showed. The files are displayed as they are.
>
Unfortunately a PO file isn't just a text file. It is a file format that
presents data in a specific way. To escape the slash
(\) and the quotes (") is part of the format that we try to conform to.
> To make sure I am not wrong, let me reproduce the process here with
> an example string:
>
> 1) the .sdf I have contains:
>
> > helpcontent2source\text\sbasic\shared\01\0613.xhp 0
> > help
> > par_id3149124 20 0 en-US To create a new
> > macro, select the
> > "Standard" module in the \Macro from\ list, and then
> > click \New\. 2007-04-11
> > 15:55:00.0
> > helpcontent2source\text\sbasic\shared\01\0613.xhp 0
> > help
> > par_id3149124 20 0 fr Pour créer une
> > nouvelle macro, sélectionnez
> > le module "Standard" dans la liste
>
> (lines 3 and 4 of HC2_93824_89_2007-06-05_33.sdf)
>
> When I use oo2po (oo2po --language=fr --nonrecursiveinput
> HC2_93824_89_2007-06-05_33.sdf HC.po), I get the following strings:
>
> > #: 0613.xhp#par_id3149124.20.help.text
> > msgid ""
> > "To create a new macro, select the \"Standard\" module in the \
> > \Macro "
> > "from\\ list, and then click \\New\\. "
> > msgstr ""
> > "Pour créer une nouvelle macro, sélectionnez le module \"Standard\"
> > dans la "
> > "liste \\Macro de\\ et cliquez sur \\ > \>Nouveau\\. "
> > "Vous pouvez également créer un nouveau module. Pour ce faire, s"
> > "électionnez-le dans la liste \\Macro de\\ et
> > cliquez sur "
> > "\\Nouveau\\."
>
> You can see that a number of characters have been escaped.
>
>
> Now, when I create a TMX from this file (even though I know this file
> is a pseudo translation) ($ po2tmx --language=fr HC.po HC.tmx), I get:
>
> >
> > To create a new macro, select the "Standard" module
> > in the \Macro from\ list, and then click
> > \New\ .
> >
> >
> > Pour créer une nouvelle macro, sélectionnez le module
> > "Standard" dans la liste \Macro de\ > \> et cliquez sur \Nouveau\ . Vous
> > pouvez également créer un nouveau module. Pour ce faire,
> > sélectionnez-le dans la liste \Macro de\
> > et cliquez sur \Nouveau\ .
> >
>
>
> So, you see, the TMX does not exactly match the original .po file.
> Although it does match the .sdf, but this is irrelevant.
>
> When I created the TMX by using XLFEdit from Heartsome, I first too
> the converted po, converted it to XLIFF and then exported it as TMX
> and the TMX contained the same number of escapes as the po.
I would consider this behaviour by the Heartsome tool to be a bug, to be
honest. Do they convert '<' to '<' ? Then they should also convert
the rest. I would say this is part of the rules of data conversion
between these formats.
I believe our conversion conforms to the XLIFF representation guide for
PO files:
http://xliff-tools.freedesktop.org/snapshots/po-repr-guide/wd-xliff-profile-po.html#s.general_considerations.escapechars
I think it follows logically that the same rules should apply for
converting to TMX.
>
> > Well, not when converted to an XML based type, I would say. In the
> > same
> > way a left angular bracket (<) can be put normally (unescaped) in a PO
> > file, but in TMX it would have to go in as <
>
> Now, whatever is required or not in an XML document is not relevant
> here. What I need is that created TMX contents match exactly my
> source content otherwise I am going to edit each and every segment to
> add escapes so that my target matches my source... Which is defeating
> the point of using a TMX file. If the .po file contains 3 "\" and if
> I created a TMX with a .po that has 3 "\" I want the TMX to contain
> the 3 "\". Otherwise it is not useful at all anymore.
>
> JC
With the < I was just trying to explain why things might differ
between two different data formats with an example that is perhaps
slightly more well known because of its use in HTML.
A somewhat separate issue for me is
Re: [l10n-dev] OmegaT and PO files
On 19 juin 07, at 15:50, Alessandro Cattelan wrote: Now I have one more question to which I'm sure Jean-Cristophe has the answer... ;o) When opening a project with OmegaT I thought that the text in msgstr in the PO file would show up in the target segment, but that is not the case. I think that checking the PO file si quite useful because of the comments and of the changed strings extracted from the Sun database, but keeping OmegaT and a text editor with the PO file open side by side on a 15' monitor is not very comfortable... Is there any way to make OmT show at least the msgstr content? Yes. It is what I have been demonstrating here by creating a TMX from the .sdf file. Basically OmegaT's PO handling is only (just like for monolingual files) to put in the target editing field the contents of source, for edition. OmegaT is not able to know that a target already exist and to propose it for editing. What I have thus done is the following: 1) convert the .sdf file to .pot (oo2po -P etc) to remove all the msgstr contents 2) create a TMX from the pseudo translated .sdf (oo2po and then po2tmx, cf my comments on that process in a different thread) 3) put the .pot in /source/, the tmx in /tm/ and OmegaT will automatically match the .pot strings to their pseudo translated counterparts in the tmx, thus allowing you to have the msgstr contents in target. It is a little non-trivial, but remember that OmegaT is not made to work with bilingual localization files. It works with a monolingual file in source and bilingual TM files for reference. I think Rafaella should be able to provide you with proper TMX files that match the .sdf contents. Cheers, JC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] mnemonics
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I know this must have been asked before, but I don't remember whether mnemonics have to be changed or simply deleted. In the following case does the ~ have to be removed or should it be put on another letter? en: Macro ~from it: Macro da Ale. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGd4LFdpk3ZlYYJ+gRApR4AKC/LpOxW7qPjkTBqPKDJcowXPshJQCeLAao ZiaOXHT2dmMXeZ2M9PsHqRg= =O4S2 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
