2011/1/7 Javier Sola <li...@khmeros.info> > André, > > Yes, it was a problem of the toolkit, and they just fixed it. We will apply > the patch in WordForge, as we are still using the same code. > > This does not really solve the problem, which is to get a working filter > for ODF-XLIFF, but so far it can be done with Omega-T > > The main issue with the toolkit is that it does not keep the structure of > XLIFF files internally, but it creates its own internal representation. If > something is not specifically represented internally, then it is not stored, > and therefore not saved back in the file. This is why WordForge ia moving > away from the toolkit, because not being native to XLIFF it is very hard to > work on implementation of XLIFF features. > > Lokalize does not have this problem because it keeps all the data of an > XLIFF file, independently of understanding it or not. >
So, OmegaT and Lokalize can handle this conversion and WordForge might handle it in future if necessary code updates are added (after using patches for the toolkit)? Seems ok. How could then the workflow for localizing ODT files look like? Could ODF-XLIFF transformation be offered by the translation system (Pootle?) so that the user does not bother with that? Localizers would localize XLIFF files (how does that relate to localization of pictures and other objects in the ODF?). Lp, m. -- Unsubscribe instructions: E-mail to l10n+h...@libreoffice.org List archive: http://listarchives.libreoffice.org/www/l10n/ *** All posts to this list are publicly archived for eternity ***
