Thank you all for your hard work! I hope to see this go forward and you can count me in to help translate and code if necessary.
Alberto César Rodríguez Tejeda 2010/10/21 Onno van der Straaten <onno.van.der.straa...@gmail.com> > Hi Paulo, > > We really need some translation software to support this and to make this > work, something similar to the export/import feature that RMC offers, > otherwise I fear this will require superhuman discipline and hard work. > Because I'm convinced we need this I have taken it upon myself to produce > this software. I already have something that qualifies as a PoC I think > which I would like to demonstrate at some point. > > Now that you mention CVS: my PoC is based on Subversion, the solution I'm > working on is tightly integrated with Subversion to support version and > change management. Version and change management is cruciaal I think because > translating a library is one thing, keeping up with changes in the source > library is the 'key' thing, especially if we want to release translated > libraries together with the source libraries. I think this is possible and I > think this should be our objective with the translation work. > > I never considered using CVS to build this solution. IMHO Subversion is the > way forward for the EPF community. > > I have raised the CVS issue in the past, in some way I'm raising it again I > suppose. More and more Eclipse project are moving away from CVS. They are > moving to Subversion or GIT. Because the EPF community also consists of > content developers (and not only hard core Java Eclipse Plugin developers), > Subversion is the better choice IMHO, as it is still more user friendly and > more commenly used. The Eclipse infrastructure supports an automated move to > Subversion (or GIT). So there is no effort required to migrate data. A > bugzilla with a request to move is all that it takes. > > Best Regards, > Onno > > > > > > > On Wed, Oct 13, 2010 at 2:45 PM, Paulo Moreira > <p_r_more...@yahoo.com.br>wrote: > >> Hi Onno, >> >> I think we can use the current way to access libraries in cvs. There is >> already good documentation available on EPF web site to assist in the >> process of setting up a cvs client to access libraries. >> >> There are already libraries in the nl_libraries csv folder, I just do not >> know if these folders can be the "branches" you mentioned. If yes, I can >> create a folder for the practice library and start the Portuguese >> translation. >> >> Cheers, >> >> Paulo Moreira >> >> ------------------------------ >> *De:* Ricardo Balduino <baldu...@us.ibm.com> >> >> *Para:* Eclipse Process Framework Project Developers List < >> epf-dev@eclipse.org> >> *Enviadas:* Segunda-feira, 11 de Outubro de 2010 12:58:10 >> *Assunto:* Re: [epf-dev] Res: Contributing with translations >> >> 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 <p_r_more...@yahoo.com.br> >> To: Eclipse Process Framework Project Developers List < >> epf-dev@eclipse.org> >> Date: 09/29/2010 06:19 AM >> Subject: [epf-dev] Res: Contributing with translations >> Sent by: epf-dev-boun...@eclipse.org >> ------------------------------ >> >> >> >> 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 <onno.van.der.straa...@gmail.com>* >> Para:* Eclipse Process Framework Project Developers List < >> epf-dev@eclipse.org>* >> 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 >> <*baldu...@us.ibm.com*<baldu...@us.ibm.com>> >> 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 >> <*alberto.c.rodrig...@gmail.com*<alberto.c.rodrig...@gmail.com> >> > >> To: *epf-...@eclipse.org* <epf-dev@eclipse.org> >> Date: 09/24/2010 06:46 AM >> Subject: [epf-dev] Contributing with translations >> Sent by: *epf-dev-boun...@eclipse.org*<epf-dev-boun...@eclipse.org> >> ------------------------------ >> >> >> >> >> 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* >> **epf-...@eclipse.org* <epf-dev@eclipse.org>* >> **https://dev.eclipse.org/mailman/listinfo/epf-dev*<https://dev.eclipse.org/mailman/listinfo/epf-dev> >> >> >> _______________________________________________ >> epf-dev mailing list* >> **epf-...@eclipse.org* <epf-dev@eclipse.org>* >> **https://dev.eclipse.org/mailman/listinfo/epf-dev*<https://dev.eclipse.org/mailman/listinfo/epf-dev> >> >> >> >> _______________________________________________ >> epf-dev mailing list >> epf-dev@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/epf-dev >> >> >> >> >> _______________________________________________ >> epf-dev mailing list >> epf-dev@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/epf-dev >> >> > > _______________________________________________ > epf-dev mailing list > epf-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/epf-dev > >
_______________________________________________ epf-dev mailing list epf-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/epf-dev
