Hi list I was lucky to be away over the previous while during the recent discussions. It is almost impossible to reply in the threads to everything, and I just wanted to reply to a few issues. So please forgive the reply not being in the threads. I can't imagine that I'll be up to replying to much mail, so just a few points here.
Let's start with something I think most of us agree on: I'll be the first to agree that the raw SDF data isn't pretty. XML type tags are escaped, and yes, if somebody does the work, going directly from the XML help files to translation formats, could provide some benefits. Having looked at the current help files, however, I didn't immediately see what the format rules for escaping are so that I could hide it during conversion to PO or XLIFF files. I'd be very much in favour of working on a better escaped interpretation for helpcontent2. Specifically, last time I checked, there were escaped '<' characters _and_ unescaped ones. This would need to be sorted out to be able to hide the escaping on conversion. However, I have to agree with Pavel: let's make sure we understand exactly what problem we are trying to fix and that such a change actually solves it. SDF files are a dream compared to other things I've seen :-) Yuri, I agree that context is a big issue, and I think we agree that context is mostly an independent issue from the workflow and file formats. As far as I know the SDF file can already contain meta-information by means of the x-comment information. oo2po from the translate toolkit will add those notes to the PO file (and oo2xliff will add it to note tags of XLIFF files). I think the issue is rather that these haven't been maintained. I don't personally know much about this. Perhaps somebody can add some information about SDF files with x-comment information? We also have a converter that goes directly from SDF to XLIFF. It shipped with the current version of the toolkit, although a packaging bug might hide it for some users. The packaging bug will be fixed in the next versions of the toolkit. gsicheck errors: Alessandro, if there are errors reported by gsicheck from the SDF files created by the translate toolkit and that are not reported by pofilter (in Pootle they are listed as "checks"), I would really like to know. None has been reported on our list or bugzilla as far as I can remember. I agree that we should be generating good SDF files after our translation process. Clytie wrote: > We would need an upgrade process for strings that somehow retains that > metadata on our side. I don't know how we could do that. What Javier wrote here is right: we maintain our translations in localisation formats. Then all of the information (not only comments, but also things like state, last translator, etc.) Converting to SDF can therefore be seen as being similar to compiling to binary format. We store our localisation formats in a version control system, and that is considered to be the stored translations. This way we also don't need to "retranslate with a TM" at the start of version update such as the method is with OmegaT (according to my understanding). The files are just updated with pot2po (which can optionally use a TMX file for fuzzy matching while upgrading the files) Upload to Pootle: It is possible to upload PO or XLIFF files to Pootle to merge back translations. This is most useful for entirely replacing the existing files, or to carefully merge in work contributed by several people. In the case of conflict the last method changes uploaded translations into suggestions that can be reviewed (if something has already been translated). Glossary matching in Pootle: Pootle can do glossary matching, but it needs to be configured. My understanding is that Aijin Kim from Sun will look at this soon. It is actually quite easy and people should be able to maintain their own terminology if permissions are configured in that way. TM in Pootle Pootle can do TM matching. The bulk of useful fuzzy matches can already be provided in the files when they are upgraded to the newer OOo version. Alternative suggestions can be provided during translation, although it doesn't work in the same way as offline translation tools. This also needs to be administered by the server administrator. Details here: http://translate.sourceforge.net/wiki/pootle/updatetm OLT with XLIFF files: About OLT not being able to open our XLIFF files: our XLIFF files are well formed as far as we know - please report any bugs to our mailing list or bugzilla. We have validated some of our XLIFF files according to the XLIFF DTD, so I would be surprised if they are truly malformed. Claims of mismatches between PO and TMX files: My understanding is that this error is reported by users of OmegaT. It is also my understanding that OmegaT doesn't actually interpret PO files, but only contains functionality to identify / highlight the different parts of the PO file for translation. I salute the great work of the OmegaT community, but if the tool doesn't understand the format, the PO/TMX tools can't take the blame for it. To see the PO and TMX files working well, I suggest people try using a TMX file with pot2po (either the TMX file provided by Sun, or one created with po2tmx from the translate toolkit). Our TMX files should work on both PO and XLIFF based translation. I guess the point of Translation Memory _eXchange_ is the point that it should be exchangeable regardless of what it will be used for. If tools interpret the escaping differently, that does pose a problem and that will need to be addressed. However, if the issue is that OmegaT is translating PO files as text files without regard for the PO file format, I don't think we can lay the blame on the TMX specification or something else. Kind regards Friedel (a developer for Pootle and the translate toolkit) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
