Op Wo, 2010-06-23 om 07:55 +0200 skryf André Schnabel: > Hi, Hallo Goran, André, everybody.
> Am 22.06.2010 21:39, schrieb Goran Rakic: > > У уто, 22. 06 2010. у 16:10 -0300, Olivier Hallot пише: > >> Hi Rafaella& dev's > >> > >> I would like to express my deep disapointment with this situation. > > > > I will second that, but for what I know the problem here is in our PO > > toolkit, not in the process how developers work. Things can easily > > improve by creating a new tool for merging POTs created from SDF file > > with old PO files that could cope up with code moving from one module > > into another. > > > > If there are no voices against it I can work on this during July so we > > can test and improve it later and make it ready for next release cycle. > > > Hmm .. I'm not really keen of having "yet another tool". If we are > working on something, this should be done within translate toolkit. The > pretranslate tool from translate toolkit is supposed to do exactly what > we need - unfortunately it doesn't work the way we need it. The tool that Goran mentions, pomigrate2 is supposed to handle this to some extent. Goran, can you maybe help us see what is currently missing in pomigrate2 to handle this situation? We should file a bug for the Translate Toolkit to ensure that we can prioritise this and try to fix this for everyone's benefit. > At least not for xliff - did anybody try with .po? > > I also did not check, how "successfull" pretranslate works with > translation memories. Unfortunately pretranslate manpage gives no > information, what format to use as translation memory file. > > In fact - for my own workflow (using xliff files, OLTE and built in > translation memory which is based on the translations I did so far) > gives ~ 60% automatic transaltions for the "moved" strings. > My translatoin memory does not contain all the previus translations, > therefore the rather low rate. Unfortunately there is no german tmx file > at ooo.services :( > > > > So for me - before starting a new tool I'd recommend: > - to provide .tmx files based on previous translations for all languages > - try to improve translate toolkit > - teach developers about the workload some acitivities cause here, that > seem to be very simple for developers and find some way to move l10n > strings along with the original english strings I agree with all of this. Several tools, such as our own Virtaal, can use the TMX file to provide speedup to translators when working. We shouldn't underestimate the difference in value between identifier matched TM, and source text matched TM - matching perfectly on identifier and source text is the first prise, and would mean that no review of the string would be necessary (in principle). Matching on source text only (as you would with TMX files) would need review, in my opinion (at least for anything shorter). So please, let us work together to fix whatever we need on the tools side (including for teams using XLIFF :-) - We need to migrate translations well if source code moves, without translators needing to do a lot of work. I believe pomigrate2 is at least a step in the right direction, maybe with some outstanding work. - We need to ensure that up-to-date translation memories are available for people to use (regardless of whether source code moves or not). Keep well Friedel -- Recently on my blog: http://translate.org.za/blogs/friedel/en/content/emotions-and-localisation --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@l10n.openoffice.org For additional commands, e-mail: dev-h...@l10n.openoffice.org
