Re: [l10n-dev] Thoughts on Localization
On Mon, 24 Dec 2007 00:52:45 +0200, Jean-Christophe Helary [EMAIL PROTECTED] wrote: On 23 déc. 07, at 19:21, Yury Tarasievich wrote: However, I do care about lack of meta-information which renders many actual translation issues hard to resolve. Your scheme does not address that matter and actually would postpone its resolvement. No, it does not. XLIFF is equivalent to SDF in terms of the possible availability of context information. ... Etc. etc. Wouldn't it be nice if all things were nice. Aren't you deliberately ignoring such factors as the workflow and manpower? I'll be opting out of this discussion now, I guess. --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] Re: [native-lang] Merry Christmas and Happy New Year from Chinese Community!
Dear Cheng Lin, Merry Christmas to you and above all, Merry Dong Zhi (solstice celebration) to you, Zhang Xiaofei and the whole Chinese Community! Next Year will be very exciting! Best Regards, Charles. ChengLin a écrit : Hi, all I forward an email from zh.OOo to wish you： Merry Christmas and Happy New Year！ If you can read Chinese, it's very great; If you can't, never mind, you'll get a great chance to learn Chinese, because the next year is Chinese Olympic year! Welcome to China! Regards! -- ChengLin 2007-12-24 === Original Message 2007-12-24 14:28:01 === From: Zhang Xiaofei[EMAIL PROTECTED] Date: 2007-12-24 14:28:01 To: [EMAIL PROTECTED][EMAIL PROTECTED] CC: Subject: Re: [zh:dev]圣诞快乐！元旦快乐！ Hi all, 最近收到一条短信，觉得送给蛋蛋蛋中文社区的朋友们非常合适 :-P 今年送礼真难办， 挑来挑去三个蛋， 首当其冲是圣蛋， 祝你康健又平安， 接着要送是元蛋， 祝你薪水翻一番， 最后送个小鸡蛋， 祝你聪明又能干！ 祝新的一年蛋蛋蛋中文社区更加繁荣！ Best Regards, Felix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Thoughts on Localization
On Mon, 24 Dec 2007 11:29:59 +0200, Jean-Christophe Helary [EMAIL PROTECTED] wrote: On 24 déc. 07, at 17:09, Yury Tarasievich wrote: On Mon, 24 Dec 2007 00:52:45 +0200, Jean-Christophe Helary [EMAIL PROTECTED] wrote: On 23 déc. 07, at 19:21, Yury Tarasievich wrote: However, I do care about lack of meta-information which renders many actual translation issues hard to resolve. Your scheme does not address that matter and actually would postpone its resolvement. No, it does not. XLIFF is equivalent to SDF in terms of the possible availability of context information. ... Etc. etc. Wouldn't it be nice if all things were nice. Aren't you deliberately ignoring such factors as the workflow and manpower? This is specifically what I am trying to address. Why has SUN moved from a workflow that ensures the most efficient use of previous translations to a workflow that does not ? Because it's not their priority? Because at the time this seemed (or actually was) the best available solution? Because the world-wide populariry of the OOO translating caught them unaware? How hard would it be to have a few Java programmers improve the current OLT filters so that SDF is supported there ? The OLT itself seems to be sort of put on ice, as it seems. Or so I gathered in Spring, when accessing the possibity to XLIFF-migrate the OOO translation I'm taking care of. How hard would it be to give translators access to the full source of the help files for context ? Ie, what can be done in practical terms, besides for PO hacks, to improve the translators' work and the output quality ? I.e., to add meta-information, be it Nth extra field of SDF or whatever carrier format, which would be an enterprise all by itself. The PO hacks, ugly as they are, work, and translations are coming in. The new way to go, pretty as it may seem in theory, has yet to be implemented *and* to prove itself. What about *other* translating teams, after all? --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Thoughts on Localization
Two ideas for the discussion, - SDF is not a localization format. Nobody localizes using SDF. It is just an intermediary format that has the available information, and which simplifies the steps of gathering the necessary information and putting it back in the source. - Localization formats that we are using are PO and XLIFF. In order to maintain process metadata, and strongly reduce the necessary work for upgrading to new version, it is necessary to use XLIFF, as this information can be stored in XLIFF files. The process information is not transfered to SDF format. It is maintained always in XLIFF. Once the first XLIFF files are created, they are upgraded to new versions (new XLIFF templates), keeping the process information in the XLIFF, and then exported to SDF when necessary. If any steps involve going through other formats, then the information is lost. We are working on new SDF-XLIFF, XLIFF-SDF and XLIFFUPGRADE filters that we hope to finish soon. The filters will be integrated in the upcoming version 0.5 of the WordForge off-line localization editor. Javier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Localization work after second hand-off
En/na Aijin Kim ha escrit: Hi Jordi, All the contents of Pootle were imported into the OO.o database for 2.4 and still exist on Pootle. You can continue your work on Pootle and your work can be imported before next translation cycle. Merry Christmas and Happy New Year to you and Catalan community! Ok, clear. thanks a lot! Jordi, -- Jordi Mas i Hernàndez, HomePage http://www.softcatala.org/~jmas/ Bloc personal http://www.softcatala.org/~jmas/bloc/ Planeta Softcatalà: http://www.softcatala.org/planet/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Thoughts on Localization
On 24 déc. 07, at 22:27, Javier SOLA wrote: Two ideas for the discussion, - SDF is not a localization format. Nobody localizes using SDF. It is just an intermediary format that has the available information, and which simplifies the steps of gathering the necessary information and putting it back in the source. I do use SDF because its contents matches the TMX provided by SUN. And I am not the only one. - Localization formats that we are using are PO and XLIFF. I don't use (and don't advise to use) the current implementation of the oo2po tool which produces the PO files a lot of people are using, because the contents produced do not match the contents of the TMX provided by SUN. And I am not the only one. The current PO files create a huge overhead for translators, who need to play with \ characters so that their work is properly validated. This comes from PO over-escaping strings that are alsread escaped in SDF. We are working on new SDF-XLIFF, XLIFF-SDF and XLIFFUPGRADE filters that we hope to finish soon. The filters will be integrated in the upcoming version 0.5 of the WordForge off-line localization editor. If what you do is compatible with the TMX contents that is great. Now if the final idea is to use and XLIFF workflow, the best would be to have SDF contain the original XML and _not_ escaped strings that have no meaning when used in processes that include XLIFF or TMX. XLIFF and TMX have all the necessary functions to protect the XML of the translatable strings. Jean-Christophe Helary http://mac4translators.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Thoughts on Localization
On Mon, 24 Dec 2007 15:27:45 +0200, Javier SOLA [EMAIL PROTECTED] wrote: We are working on new SDF-XLIFF, XLIFF-SDF and XLIFFUPGRADE filters that we hope to finish soon. The filters will be integrated in the upcoming version 0.5 of the WordForge off-line localization editor. Nice to know that! And are there any ideas on how to share meta-info between the translators, possibly? --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Thoughts on Localization
On 24 déc. 07, at 21:34, Yury Tarasievich wrote: On Mon, 24 Dec 2007 11:29:59 +0200, Jean-Christophe Helary [EMAIL PROTECTED] wrote: Why has SUN moved from a workflow that ensures the most efficient use of previous translations to a workflow that does not ? Because it's not their priority? Because at the time this seemed (or actually was) the best available solution? Because the world-wide populariry of the OOO translating caught them unaware? Because the communities were unaware of the existence of the tools and were drawn by a PO centered workflow that is mainstream in other FOSS communities. Nothing else. How hard would it be to have a few Java programmers improve the current OLT filters so that SDF is supported there ? The OLT itself seems to be sort of put on ice, as it seems. Or so I gathered in Spring, when accessing the possibity to XLIFF-migrate the OOO translation I'm taking care of. OLT the editor does not need to be modified. Only the small utility that is the OLT Filters needs to add SDF support. And that would only to provide yet another way to translate, with a professional tool. How hard would it be to give translators access to the full source of the help files for context ? Ie, what can be done in practical terms, besides for PO hacks, to improve the translators' work and the output quality ? I.e., to add meta-information, be it Nth extra field of SDF or whatever carrier format, which would be an enterprise all by itself. The PO hacks, ugly as they are, work, and translations are coming in. The new way to go, pretty as it may seem in theory, has yet to be implemented *and* to prove itself. What about *other* translating teams, after all? It is not pretty in theory, it already works. I've documented how to use SDF directly to get direct matches from the TMX in tools that are developped for translation work. Here is the link in case you are interested: http://mac4translators.blogspot.com/2007/12/openofficeorg-localization-and-easy-way.html oo2po has failed to produce files that match the TMX data that SUN is providing the community with and even though PO based translations keep coming, using the current PO process _does not contribute to make the translation workflow easier_. But obviously, for communities that only know the current PO hacks such an assertion does not mean anything... Jean-Christophe Helary http://mac4translators.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Thoughts on Localization
On Mon, 24 Dec 2007 15:53:42 +0200, Jean-Christophe Helary [EMAIL PROTECTED] wrote: ... oo2po has failed to produce files that match the TMX data that SUN is providing the community with and even though PO based translations keep coming, using the current PO process _does not contribute to make the translation workflow easier_. But obviously, for communities that only know the current PO hacks such an assertion does not mean anything... Right you are. Propose and implement what you wish, you still omit people in translating communities needing to re-learn etc. Take me for example — I get quite a fair re-use ratio with Kbabel, I don't feel comfortable with the feel of any free XLIFF-capable tools, and I have yet to see some good demonstration of translation-workflow-related advantages of the new way to go. What I saw in my experience with OmegaT wasn't better, it was better some, worse some. Can't recall — did I say I'm opting out of this discussion already? --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Thoughts on Localization
Yury Tarasievich kirjutas: On Mon, 24 Dec 2007 15:53:42 +0200, Jean-Christophe Helary [EMAIL PROTECTED] wrote: ... oo2po has failed to produce files that match the TMX data that SUN is providing the community with and even though PO based translations keep coming, using the current PO process _does not contribute to make the translation workflow easier_. But obviously, for communities that only know the current PO hacks such an assertion does not mean anything... Right you are. Propose and implement what you wish, you still omit people in translating communities needing to re-learn etc. I agree with you Take me for example — I get quite a fair re-use ratio with Kbabel, I don't feel comfortable with the feel of any free XLIFF-capable tools, and I have yet to see some good demonstration of translation-workflow-related advantages of the new way to go. What I saw in my experience with OmegaT wasn't better, it was better some, worse some. I VERY agree with you Can't recall — did I say I'm opting out of this discussion already? I cant recall how I did start to read this thread at all, maybe I've seen some known names? ;) Charles - knowing something about translation process technical details isn't surely mandatory for NL project lead, but there's no need to talk about things you aren't familar with. Every your positive or negative opinion can influence people because of your position as project lead. Please think twice next time. Citation: May this be read and used by as many localisers as possible! ??? Fortunately I was away from computer this evening when this message hit my mailbox and also fortunately Pavel responded to this. More gently I could ever do. Merry Christmas to everyone! ain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Thoughts on Localization
On 24 déc. 07, at 23:13, Yury Tarasievich wrote: Propose and implement what you wish, you still omit people in translating communities needing to re-learn etc. Yes, re-learn to be more efficient. Anything wrong with that ? See what is wrong with the current process and try to improve it. As I wrote before, using the TMX in OmegaT with the SDF files directly allowed me to have about 50% of the GUI strings almost automatically translated, 25% had very close matches and the remaining 25% were new strings. So I am saying that by spending 15mn to read what I wrote, another 15mn to read the software tutorial, one can save 75% on the time spent to translate. Take me for example — I get quite a fair re-use ratio with Kbabel, I don't feel comfortable with the feel of any free XLIFF-capable tools, and I have yet to see some good demonstration of translation- workflow-related advantages of the new way to go. What I saw in my experience with OmegaT wasn't better, it was better some, worse some. It was not better because until now there was not way to easily use the contents of the SDF file. It was not easier to me neither even though I use OmegaT professionally. It was not easier because the files that are served to us are not properly converted and don't match the TMX contents. Can't recall — did I say I'm opting out of this discussion already? But you never attempted to discuss in the first place. I am not being uselessly critical, I have proposed solutions that work and that allow translators and coordinators to be more efficient. And I know that because I have tried them, and I have completed and delivered translations with them. Have you even tried the methods before ranting ? Of course not, otherwise you would have seen that what I wrote _did_ make sense. Jean-Christophe Helary http://mac4translators.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Thoughts on Localization
On 25 déc. 07, at 05:12, Ain Vagula wrote: I agree with you I VERY agree with you What is the point VERY agreeing with a useless rant that does not propose anything but criticize people who try to propose new and working solutions ? Charles - knowing something about translation process technical details isn't surely mandatory for NL project lead, but there's no need to talk about things you aren't familar with. Every your positive or negative opinion can influence people because of your position as project lead. Please think twice next time. Citation: May this be read and used by as many localisers as possible! Obviously, it was not the _contents_ of the article that prompted this discussion. Fortunately I was away from computer this evening when this message hit my mailbox and also fortunately Pavel responded to this. More gently I could ever do. Ok, and what is your take on the fact that the TMX contents and the SDF contents match but not the PO ? How do you think it is possible to improve that so that translators can make better use of previously translated strings ? Because _that_ is what is being discussed... Jean-Christophe Helary http://mac4translators.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
