Hi Sophie,
thank you for this email with great feedback and thoughts. Please see my
comments below:
On 02/28/09 13:29, sophie wrote:
Hi Rafaella, Ivo, all
I would like to know how the integration of our changes on Pootle will
be done. Just to understand and try to figure if we could have a better
process.
The integration of translated files is the same no matter if
translations are carried out in Pootle or in SDF files directly. As you
know we deliver the translations to release engineerings accoring to the
release map and translation schedule (taking into account possible
changes to the schedule which are discussed in the release meetings).
Last time for the 3.0 changes I've done in time in the cws for the UI
were not integrated, see this issues for example:
http://www.openoffice.org/issues/show_bug.cgi?id=91864
http://www.openoffice.org/issues/show_bug.cgi?id=91863
http://www.openoffice.org/issues/show_bug.cgi?id=91847
As far as I can see in the above issues, the changes have been carries
out in Pootle, but has Ivo or Vladimir got the strings with the changes?
As far as I can see they did not get notified.
That means that after the translation delivery deadline has passed and
you want to provide some additional fixes, the changes have to be be
integrated in the CWS. How:
submit an issue (as you did) and assign it to Aijin, and cc: fma, vg and
ihi asking to have the fixes integrated.
And I've to wait since August 08 to see the correction in March or April
09...
So what would be the best for the l10n teams to make sure the
corrections are integrated and for the integration team to have less
hurdle and missing risks, considering the short time and the emergency
of our fixes:
- work only on a clean .sdf file (the complete one we have on the issue
is not clean as some corrections have been integrated after gsicheck)
and provide the corrections via a .sdf containing the corrections only
- work only on Pootle (but as seen above some corrections are left
apart) so there is may be an integration issue to solve here
- work on .po files provided through an issue (we did that at the very
begining if I remember well
- ?
Currently the process I use is to correct first the .po files, then
upload them in Pootle, then correct the .sdf file, then create a new
.sdf file, not to mention that I've not yet filled issues to track the
changes and see if they are fixed in the master. It's a lot of
duplicated work and I'm sure that we can enhance that way of work for
all teams implied in the process.
Yes, sure. The current process is far from perfect and I'm thankful for
any idea that can help us simplifying it :-)
Just 3 ideas that come into my mind are:
1) the sdf file that needs to be corrected is the sdf file which results
out of the gsi check. In order not to have to fix those errors both in
pootle and in the sdf, I would encourage all teams to use the
verification checks in Pootle. And I am sure that we can ask to
customize these checks...
Advantage: by using sdf verification checks in Pootle, translators would
avoid to fix gsi check errors in sdf files.
2) from now on we will be delivering to release engineering diffs files
only via web interface. That means that the verification of translation
integration both in case of major handoffs or later l10n fixes could be
done by using these diffs without the need of submitting lots of l10n
issues.
Advantage: sdf diff files can be used to check if latest translations or
corrections have been delivered and integrated on CWS correctly.
3) l10n fixes will be delivered by the l10n fixes deadline without prior
request to release engineering
Advantage: no additional request/issue need to be submitted to deliver
l10n fixes. However, please not that anything after the last l10n fixes
delivery will not be included and that for anything that needs our
attention an issue still needs to be submitted.
Would the 3 above points help reducing duplication?
Thanks,
Rafaella
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
