Using a translation memory tool would be the best approach! Shouldn't be too
hard to find out how/if we can create a filter to process xmi files using
OmegaT mailing list. Requirements for the filter could for example be:
1. select text nodes and attribute values in xml documents (using regular
expressions for example)
2. html in xml documents so the filter/OmegaT needs to know how escape
and de-escape those html fragments.
1. The escaping de-escaping needs to be custom I think to
match/accommodate the way EPFC is doing it.
Best Regards,
Onno
On Fri, Nov 12, 2010 at 2:35 PM, Paulo Moreira <[email protected]>wrote:
> 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_imported>
> *
> **http://epf.eclipse.org/bp/epf_practices_1.5.1_20101007_epft_exported/*<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]* <[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/*<http://epft.googlecode.com/svn/trunk/libs_exported/epf_practices/>.
> An example of an 'exported' xmi file is the task assess_results.xmi.
>
> The original file is
>
> -
> *assess_results.xmi*<http://epft.googlecode.com/svn/trunk/libs/epf_practices/practice.mgmt.iterative_dev.base/tasks/assess_results.xmi>
>
> After export this results in library file and resource files
>
> -
> *assess_results.xmi*<http://epft.googlecode.com/svn/trunk/libs_exported/epf_practices/practice.mgmt.iterative_dev.base/tasks/assess_results.xmi>
> -
> *assess_results.xmi.epft.properties*<http://epft.googlecode.com/svn/trunk/libs_exported/epf_practices/practice.mgmt.iterative_dev.base/tasks/assess_results.xmi.epft.properties>
> -
> *assess_results.xmi_mainDescription_1.epft.html*<http://epft.googlecode.com/svn/trunk/libs_exported/epf_practices/practice.mgmt.iterative_dev.base/tasks/assess_results.xmi_mainDescription_1.epft.html>
> -
> *assess_results.xmi_purpose_1.epft.html*<http://epft.googlecode.com/svn/trunk/libs_exported/epf_practices/practice.mgmt.iterative_dev.base/tasks/assess_results.xmi_purpose_1.epft.html>
> -
> *assess_results.xmi_sectionDescription_1.epft.html*<http://epft.googlecode.com/svn/trunk/libs_exported/epf_practices/practice.mgmt.iterative_dev.base/tasks/assess_results.xmi_sectionDescription_1.epft.html>
> -
> *assess_results.xmi_sectionDescription_2.epft.html*<http://epft.googlecode.com/svn/trunk/libs_exported/epf_practices/practice.mgmt.iterative_dev.base/tasks/assess_results.xmi_sectionDescription_2.epft.html>
> -
> *assess_results.xmi_sectionDescription_3.epft.html*<http://epft.googlecode.com/svn/trunk/libs_exported/epf_practices/practice.mgmt.iterative_dev.base/tasks/assess_results.xmi_sectionDescription_3.epft.html>
> -
> *assess_results.xmi_sectionDescription_4.epft.html*<http://epft.googlecode.com/svn/trunk/libs_exported/epf_practices/practice.mgmt.iterative_dev.base/tasks/assess_results.xmi_sectionDescription_4.epft.html>
>
> Note 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*<http://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*<http://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*<http://epft.googlecode.com/svn/trunk/libs_exported/epf_practices/index.epft.csv>
>
> I created a bugzilla for this work/Poc * Bug
> 328679***<https://bugs.eclipse.org/bugs/show_bug.cgi?id=328679>so 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]*<[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]*<[email protected]>
> >
> To: Eclipse Process Framework Project Developers List <*
> [email protected]* <[email protected]>>
> Date: 10/20/2010 12:12 AM
> Subject: Re: [epf-dev] Res: Contributing with translations
> Sent by: *[email protected]*<[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]*<[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]*<[email protected]>
> >
> To: Eclipse Process Framework Project Developers List <*
> [email protected]* <[email protected]>>
> Date: 09/29/2010 06:19 AM
> Subject: [epf-dev] Res: Contributing with translations
> Sent by: *[email protected]*<[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]*<[email protected]>
> >*
> Para:* Eclipse Process Framework Project Developers List <*
> [email protected]* <[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]*<[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]*<[email protected]>
> >
> To: *[email protected]* <[email protected]>
> Date: 09/24/2010 06:46 AM
> Subject: [epf-dev] Contributing with translations
> Sent by: *[email protected]*<[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*<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]* <[email protected]>*
> **https://dev.eclipse.org/mailman/listinfo/epf-dev*<https://dev.eclipse.org/mailman/listinfo/epf-dev>
>
>
> _______________________________________________
> epf-dev mailing list*
> **[email protected]* <[email protected]>*
> **https://dev.eclipse.org/mailman/listinfo/epf-dev*<https://dev.eclipse.org/mailman/listinfo/epf-dev>
>
>
>
> _______________________________________________
> epf-dev mailing list*
> **[email protected]* <[email protected]>*
> **https://dev.eclipse.org/mailman/listinfo/epf-dev*<https://dev.eclipse.org/mailman/listinfo/epf-dev>
>
>
> _______________________________________________
> epf-dev mailing list*
> **[email protected]* <[email protected]>*
> **https://dev.eclipse.org/mailman/listinfo/epf-dev*<https://dev.eclipse.org/mailman/listinfo/epf-dev>
>
> _______________________________________________
> epf-dev mailing list*
> **[email protected]* <[email protected]>*
> **https://dev.eclipse.org/mailman/listinfo/epf-dev*<https://dev.eclipse.org/mailman/listinfo/epf-dev>
>
>
> _______________________________________________
> epf-dev mailing list*
> **[email protected]* <[email protected]>*
> **https://dev.eclipse.org/mailman/listinfo/epf-dev*<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
