Hi Bruce, I agree with you. I have used this way to help with translations.
Onno did a great job, creating a solution to generate html files from existing xmi libraries. This will help us a lot in the translation process. OmegaT has filters as plug-ins for different file types. If we could create a new filter to handle xmi files, we could use OmegaT to read content directly from EPF libraries. Maybe this solution might also be of interest to the Eclipse Community :) Cheers, Paulo Moreira ________________________________ De: Bruce Macisaac <[email protected]> Para: Eclipse Process Framework Project Developers List <[email protected]> Enviadas: Quinta-feira, 11 de Novembro de 2010 21:48:32 Assunto: Re: [epf-dev] Res: Contributing with translations The real challenge with translation is managing differences from version to version. Translation memory is, I think, the key to handling this. There are a number of tools that support translation memory. Whichever we use, I think it's important that is adhere to a standard translation memory format. http://en.wikipedia.org/wiki/Translation_Memory_eXchange OmegaT is one such tool that looks promising. http://en.wikipedia.org/wiki/OmegaT For the next translation effort that we embark on, I'd like to include an evaluation of how to leverage translation memory, either using OmegaT or some other like MemoQ or Virtaal. Bruce MacIsaac Manager RMC Method Content [email protected] 408-250-3037 (cell) From: Onno van der Straaten <[email protected]> To: Eclipse Process Framework Project Developers List <[email protected]> Date: 10/26/2010 11:13 AM Subject: Re: [epf-dev] Res: Contributing with translations Sent by: [email protected] ________________________________ Hi, The links to the sites are wrong, the correct links are http://epf.eclipse.org/bp/epf_practices_1.5.1_20101007_epft_imported/ http://epf.eclipse.org/bp/epf_practices_1.5.1_20101007_epft_exported/ Best Regards, Onno On Tue, Oct 26, 2010 at 8:07 PM, Onno van der Straaten <[email protected]> wrote: Hi all, I finished my little PoC. I now have some 'translation ware' that 'exports' a library by extracting HTML and plain text resource files from it. You can find an example of an exported library on line at Google code here epf_practices/. An example of an 'exported' xmi file is the task assess_results.xmi. The original file is * assess_results.xmiAfter export this results in library file and resource files * assess_results.xmi * assess_results.xmi.epft.properties * assess_results.xmi_mainDescription_1.epft.html * assess_results.xmi_purpose_1.epft.html * assess_results.xmi_sectionDescription_1.epft.html * assess_results.xmi_sectionDescription_2.epft.html * assess_results.xmi_sectionDescription_3.epft.html * assess_results.xmi_sectionDescription_4.epft.htmlNote that the HTML files contain valid HTML. The export/import methods take care of escaping and unescaping of HTML when it is added to or extracted from xmi files. As part of the PoC I tested the publish of an 'exported' library, results also on line epf_practices_1.5.1_20101007_epft_exported. Then I imported the exported resource files back in a library and published from that library, which resulted in epf_practices_1.5.1_20101007_epft_imported. Note the text '(EPFT)' before all content in the published site. Because I did not change resource files as part of the PoC I added this tag to demonstrate that this site was indeed published from a library that was created by importing resource files that I extracted in the previous step. The export method creates a csv file with a list of all content files: xmi files and resource files, see index.epft.csv I created a bugzilla for this work/Poc Bug 328679so if you are interested add yourself to the CC and/or leave your comments there. I will prepare some slides for next meeting to explain further how this can help us produce translated libraries in a structured way. Best Regards, Onno On Fri, Oct 22, 2010 at 4:32 PM, Ricardo Balduino <[email protected]> wrote: Onno, let's arrange that for the next EPF meeting, likely on the second Thursday in November. Details to follow. Ricardo. From: Onno van der Straaten <[email protected]> To: Eclipse Process Framework Project Developers List <[email protected]> Date: 10/20/2010 12:12 AM Subject: Re: [epf-dev] Res: Contributing with translations Sent by: [email protected] ________________________________ Hi Ricardo, Sounds fine, we can discuss it and include it in the release plan I think. Depending on when it is I might want to share a few slides and/or my desktop to illustrate some ideas I have on the subject . Can we arrange that? Best Regards, Onno On Mon, Oct 11, 2010 at 5:58 PM, Ricardo Balduino <[email protected]> wrote: Onno and Paulo, I think your ideas make sense, i.e. having separate branches in CVS to translate libraries, including all the benefits and robustness that you already described. The translation then can happen inside EPFC itself (element by element, field by field), or using an external translation tool that works with xml files. The impact is obvious though when there are new versions of the English libraries - all the other translation branches would need to be worked separately to accommodate the changes made to the English version, which poses a need for the community to be maintaining the various languages in the long run. If you both, and anyone else in the community, would like to interact and come up with a plan/strategy for how this would work and take care of setting up the infrastructure needed, we could discuss it on the next EPF call (TBD) and include the objectives/activities in the next release plan. What do you think? Thanks. Ricardo. From: Paulo Moreira <[email protected]> To: Eclipse Process Framework Project Developers List <[email protected]> Date: 09/29/2010 06:19 AM Subject: [epf-dev] Res: Contributing with translations Sent by: [email protected] ________________________________ Hi Ricardo, Onno and Alberto, I'd like to share my experience translating EPF libraries. I have been using OmegaT, an open source translation memory software which translates text segments from one language to another. This tool has some plugins to read different types of files. I used the HTML plugin and created a workaround to translate the EPF library xmi files in their original format, since i could not find any xmi compatible plugin. I agree with the proposal Onno wrote in his email: "Re: [epf-dev] Notes from January 14, 2010 EPF Project Release Planning call" "...to creating and maintaining language 'branches' in our CVS repository and then translating the XML-files directly and/or through EPF. Editing HTML does of course offer a different experience to editing XML. And everything will be version controlled so we should be able to recover from big mishaps..." IMHO if we could translate the library, publish the process and generate the wiki from the published site, it would be easier to share the translated content and keep it updated. Cheers, Paulo Moreira ________________________________ De: Onno van der Straaten <[email protected]> Para: Eclipse Process Framework Project Developers List <[email protected]> Enviadas: Quarta-feira, 29 de Setembro de 2010 7:09:18 Assunto: Re: [epf-dev] Contributing with translations Hi Ricardo, Alberto, We need some translation ware to support this. As part of EPF or as an external tool/utility. The objective of doing translation work should be to produce a translated library together with the original library. I think it can be done with some translation ware similar to what RMC offers. I don't think IBM has plans to backport the translation code from RMC to EPF. Can we ask IBM to donate the code? If IBM is not willing to donate I think we (the EPF community) should produce it ourselves. IMHO EPF Wiki is not the right way to approach this because the objective should be to produce a translated library. Best Regards, Onno On Mon, Sep 27, 2010 at 10:34 PM, Ricardo Balduino <[email protected]> wrote: Alberto, thank you for your interest in the project. We typically suggest people interested in translating content that they use the EPF Wiki. There is an OpenUP SP wiki site, as you said, that is partially translated. I agree with you that it has old structure, but I wonder if you have assessed how much can be reused from that site. As a next step, I would suggest this current site to be renamed to OpenUP/Basic SP - I'd keep it there for reuse purposes. Then I would suggest adding a brand new OpenUP SP wiki (published out of the most current English content) so you and the community can start translating it to Spanish. There is always a chance, as you mentioned, that the content may become obsolete when new (English) versions come up, although I suspect the practices content is clean and stable enough, so rework would be minimal in that case. Onno van der Straaten could kindly help us by adding this new wiki site. (Note: it would be convenient to publish OpenUP using the Spanish version of EPFC so you get the basic UI elements already translated). Paulo Moreira has tons of experience translating - and leading translation effort of - the OpenUP content to Portuguese, and could kindly share some ideas. Best Regards. Ricardo Balduino PS: As a side note, IBM has Rational Method Composer as a commercial offering based on EPF Composer, which provides a feature to export HTML content out of a library, so it can be translated and imported back. Also, RMC comes ready with content translated for different languages including Spanish. From: Alberto Rodríguez <[email protected]> To: [email protected] Date: 09/24/2010 06:46 AM Subject: [epf-dev] Contributing with translations Sent by: [email protected] ________________________________ Hello, I would like to contribute to the translation of the latest version of OpenUP into spanish. But I am having a hard time finding information about this. I found an OpenUP wiki in spanish (http://epf.eclipse.org/wikis/openupsp/index.htm ) but it seems to be an old version of the library, as it says OpenUP/Basic and has a different image in the Introduction page. I downloaded EPF Composer and the latest OpenUP library. I setup a local Mercurial repository and started translating from the EPF Composer and commiting my progress locally. But it is a very tedious work and I am afraid that it will not be compatible with newer versions of the library or that I could not share it back to the community because I am not using the recommended (?) way of doing it. Questions: Is there an easier way of translating than from EPF Composer? for example, is there a file that contains all the text separated from the source code of the library. i mean something like a "language file" that is commonly used if open source PHP programs. Is there a published wiki for spanish with the latest version of OpenUP to start contributing online? Where can I find information to help in the translation into spanish of the OpenUP library? Greetings, Alberto César Rodríguez Tejeda_______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev _______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev _______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev _______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev _______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev _______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev _______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev
