Op Donderdag 2008-01-03 skryf Clytie Siddall: > Friedel, thanks for your detailed reply. > > For now, I want to focus on retaining metadata and a viable update > process, so please excuse my not replying to other parts of your > message. >
Of course. As background for uninitiated readers, most of the commands I mention here are programs in the translate toolkit, and not all of these functionalities are provided by the Pootle front-end. They are of course freely available as part of the translate toolkit: http://translate.sourceforge.net/wiki/toolkit/index > On 02/01/2008, at 9:39 PM, F Wolff wrote: > > ... ... > > > > > > 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. > > How much metadata storable in XLIFF can the filter transfer to SDF? Very little, and I don't think this is where our effort should be spent. Although I consider the SDF file something I only deliver and never touch, I understand the issues you mention below. > > > > > > 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. > > The problem probably is that we use one or the other. I check my PO > files with msgfmt when editing offline, then once I convert to SDF, I > run gischeck (now I actually have gsicheck for OSX). msgfmt is nice, but very limited especially if you are checking OOo translations. It doesn't know about OOo variables or XML tags and properties. As far as I know there is a pofilter test for each of the things that gsicheck checks for (and several others, of course). > > Once our files are back on Pootle, I can give you further feedback on > pofilter. As you know, we still need to work on language-specific or > more inclusive checks (e.g. « guillemets » being used instead of > "quotation marks", spacing being acceptable before question and > exclamation marks with some languages) to reduce the number of false > positives which, for my language at least, is discouragingly high. This has been addressed with infrastructure to customise tests per language. At least the guillemets should not pose any problems, and we can discuss the other requirements. I think I solved the spacing before !? for French and there are now some customisations for several languages (including Vietnamese). > > > > > > 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) > > If I download the latest GSI file (which is more economical than > grabbing the whole POT tree), then convert it (oo2po) to POT, then > update (pomigrate) my previous PO files to the new POTs, my PO > metadata would remain. (I hope.) > Yes > However, I find it easier to make quick changes in the GSI file, > because it is only one file, which is more viable for global search- > and-replace and checking and updating specific strings. > I understand that. If you don't like the workflow offered by pogrep and pomerge, I understand that editing the SDF file directly is attractive. We'll hopefully work on search and replace in Pootle soon. for reference: http://translate.sourceforge.net/wiki/toolkit/pogrep http://translate.sourceforge.net/wiki/toolkit/pomerge Of course, searching with pogrep has other advantages, like handling accelerators and unicode normalisation. > (It probably wouldn't be more difficult technically to do that over > the entire tree, but for some reason it just seems more complex. And I > don't have much concentration left to work with.) > > So if I update the GSI file, before merging with the new POTs, I have > to convert my GSI file back into PO, because it is now my current > translation. > > And right there, I lose all my metadata. My PO directory won't have > any, because the GSI file doesn't. > > (Unless there is some way we can merge a GSI with an existing PO tree?) I think we might be able to do this with pomerge, by merging the fresh-from-GSI-POs into the older-POs (templates). This way comments and headers should be maintained, for example. I think this is worth a try. > > The only way to avoid this is not to work with the GSI file at all. > But working with a whole PO tree is a bit clumsy. > > If Pootle makes the whole conversion, update and submission process > invisible to us translators, that would be a great help. But I'm not > sure yet that the PO tree, whether online or offline, is a good > vehicle for fine-tuning and quick adjustments. oo2po can output files in different configurations, including a single big PO file, one file for each top-level directory, or the default of a tree hierarchy. For detail, see the --multifile option of oo2po: http://translate.sourceforge.net/wiki/toolkit/multifile_multifilestyle As I recall the people from Rosetta use the top-level option for oo2po when they prepare files for Rosetta. > > As an example, I'm translating a Help PO file, and the Help string > quotes an interface string (menu item, preferences etc.). So I go to > the GSI file to check the translation of the interface string, to make > sure I will use the exact same translation in the Help. > > Skipping findwise through the GSI file, it is easier to compare > similar strings. I sometimes find that identical strings, (which for > some peculiar reason occur frequently to be translated again, and yet > again in OpenOffice.org) have not been translated identically. It's > quicker to check, and fix, that sort of thing in a single file. > This is partly the reason we created poconflicts - to catch these kind of things and make it easy to review and to merge changes back. It follows a similar workflow to pogrep/pomerge, except the conflicting entries are all listed in one file per "issue". http://translate.sourceforge.net/wiki/toolkit/poconflicts > My PO editor handles similar strings, comparison, etc, but not with a > PO tree of this size. I can't import the whole tree to XLIFF, because > it is just too large. My editor has pink fits and makes sardonic > comments about memory. > > Even though my text editor is quite competent to compare and display a > lot of files simultaneously, it is time-consuming to open individually > every multiple-directory-embedded PO file in that tree. Even once > open, there are 243 files. The visual interface just doesn't work with > that many files. (On the accessibility track, dealing with that many > files is visually confusing, and switching between them is physically > difficult.) > > OTOH, a single XLIFF file would be fine. But we have the same > conversion problems. If I make my last-minute or ongoing changes to > the XLIFF file, I still have to convert back to GSI before uploading, > then run gsicheck. I don't always have that extra half an hour [1]. > > We need something quicker and easier to handle. I hope that one day we will simply be able to submit translations in translation formats, so that all format conversions can be hidden from translators (like for languages currently using the OOo Pootle server). All of this can already be automated. > > I know we have global search on Pootle, for example, but not yet > search and replace; is that right? We do need something like that, > some way of moving through the files quickly and comparing/editing > strings. A single change in vocabulary is a lot of work if you do it > one string at a time. > Yes. Agreed. > It would be great, for example, if the global search would return a > list of editable strings, especially if one could mark all, none or > some of them for the change. > > Pootle is a big help and a bit improvement: I just want to keep on > improving. ;) > Yes, I think we all want to. I believe we will continue to have interesting improvements this year. Keep well Friedel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
