[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [epf-dev] Res: Res: Contributing with translations
|
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:
- select text nodes and attribute values in xml documents (using regular expressions for example)
- html in xml documents so the filter/OmegaT needs to know how escape and de-escape those html fragments.
- 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
<p_r_moreira@xxxxxxxxxxxx> 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 <bmacisaa@xxxxxxxxxx>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
bmacisaa@xxxxxxxxxx
408-250-3037 (cell)
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
<onno.van.der.straaten@xxxxxxxxx>
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
After
export this results in library file and resource files
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
. 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 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 <balduino@xxxxxxxxxx>
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 <onno.van.der.straaten@xxxxxxxxx>
To:
Eclipse Process Framework Project
Developers List <epf-dev@xxxxxxxxxxx>
Date:
10/20/2010 12:12 AM
Subject: Re:
[epf-dev] Res: Contributing with translations
Sent by:
epf-dev-bounces@xxxxxxxxxxx
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 <balduino@xxxxxxxxxx>
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 <p_r_moreira@xxxxxxxxxxxx>
To: Eclipse
Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>
Date: 09/29/2010
06:19 AM
Subject: [epf-dev]
Res: Contributing with translations
Sent by: epf-dev-bounces@xxxxxxxxxxx
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.straaten@xxxxxxxxx>
Para: Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>
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 <balduino@xxxxxxxxxx>
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.rodriguez@xxxxxxxxx>
To: epf-dev@xxxxxxxxxxx
Date: 09/24/2010
06:46 AM
Subject: [epf-dev]
Contributing with translations
Sent by: epf-dev-bounces@xxxxxxxxxxx
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
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
