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.
On 02/01/2008, at 9:39 PM, F Wolff wrote:
...
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?
That would certainly be interesting.
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?
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).
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.
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.)
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.
(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?)
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.
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.
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 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.
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. ;)
from Clytie
Vietnamese Free Software Translation Team
http://vnoss.net/dokuwiki/doku.php?id=projects:l10n
[1] It would take me much longer, but I'm estimating how long it would
take someone not disabled.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
