Sophie escribió:
Hi Santiago,
Santiago Bosio wrote:
Martin Hollmichel escribió:
Hi Santiago,
I think it's an good plan to verify localization (and terminology)
as a early as possible.Are there any technical hurdles to import
incremental localization updates from pootle and do frequent builds.
Can this also easily be done for more languages than Spanish ? What
would be your preferred platform for doing this ?
Martin
Hi Martin:
Perhaps somebody from the l10n project can give better technical
background about the workflow on translation and why the process
doesn't admit changes after the localisation CWS has been integrated.
This is something we are aiming to change. See all my posts in the
past requesting feedback and support for a better and easier workflow.
We have been working with Pootle, open language tools, and gsicheck
and, personally, I consider that string translation changes are of
the safest changes that can be introduced (provided that they are
checked and sanitized) without breaking builds or causing problems.
And even when we considered some translation errors as show-stoppers,
their corrections weren't accepted in RC stage, and were delayed to
next bugfix release.
That was after the RC3, so it's very late in the release process. May
be a warning during the RC1 would have left more time.
I understand that point, but then, after RC5 (i.e. 3.2.0 final) some
problems where detected on translation that affected Calc on his
functional part. It was a show-stopper also and the release team
accepted to make an additional build (effort that we appreciate), but
only changed the Calc problematic strings, and not the other proposed
changes, for which a patch already existed.
As I said, we have been doing our own builds, patching the
translations with the latest snapshot from Pootle, converted to OOo
SDF format using po2oo, and gsichecking the resulting file. All of it
can be done automatically, but I see two problems to solve for the
"as early as possible" scenario:
1. Pootle updates are done only after UI and string freeze. Then
these new or modified strings are available for a few weeks to be
translated, before localisation CWS integration, and after that,
usually a two week period to introduce changes before first RC.
Ideally, new or modified strings should be inmediately available on
Pootle to alleviate the translation burden when too many strings were
introduced/modified. Also, I think translation updates must be
accepted in-between RC's when NL project leaders ask to do so, and
next RC built with the last snapshot from Pootle.
This is an ideal world we would be pleased to reach I imagine, but see
the archive of this list, this is not currently possible.
I know it could be hard to do, but if you see an answer sent by Ivo,
they are willing to change this and make more frequent updates to Pootle.
2. Weekly devel builds should be done with the complete set of
language packs, and not only a few of them as it is done currently (I
think they are FR, DE, IT, JA, pt-BR, etc.) as it will give us the
opportunity to check our advance (provided that we have early the
strings to translate on Pootle as I said before).
As Andre explained, this is not for localization purpose, this gives
no advantages over the localization process but may raise i18n issues
earlier if they happen, for the QA process in general.
See my answer to André, I know it is not the purpose of the devel
builds, but if Pootle were updated frequently, and devel builds language
packs were generated using latests snapshots from Pootle, these builds
can be used also for l10n purposes, and will give more time to find
mistakes.
Regardless of that, on our community we have a specific problem with
our translation: it has a poor overall quality, and this review
process I described on my previous e-mail must be carried out outside
the current translations on Pootle, because if we did otherwise, we
can get as a result a more confusing translation on the next upcoming
releases. So, we still need a local box to do our own builds to test
the revision process until it gets to an acceptable degree of quality
to merge the changes back to Pootle.
Why didn't you react when we had the build including localization to
test in November and before the RC3? An alert here could have help to
review the workflow or dedicate a specific effort to your language.
Regretfully, I wasn't collaborating with OOoES at that moment, due to a
lack of time. When I returned to collaboration, 3.2.0 was on RC's stage.
I don't think that funding one community will help to enhance our
process.
That's not what we're talking about, and we never say so.
We ask funding to help our specific community regarding our plan to make
a full revision of the spanish translation. Then, some people took this
thread to see if our scenario was the same for other NL communities, and
if it will not be better to provide a global solution for all
communities, and not only spanish.
I think each NL project had hard time to follow the process because of
a lot of strings, a shorter period to translate them, errors in the
files and a module that was integrated and should not be translated.
I agree with you in that.
Of course we should be able to build our own cws when we feel that we
need to check the work done. But this may be coordinated also to save
resources and let the rest of the group be aware of the progress. We
need to work as a team here with the developer team and the release team.
That's what we want to do. We don't want to do our own translation and
our own builds, please don't misunderstand us. But what we need is
working (for this full revision) outside the current translation to not
introduce on the upcoming releases terminology changes that render an
even more confusing translation. And we wish to have a build box to test
the advance of the revised translation, where we can make builds on demand.
We thought that acquiring a local box for building was the simplest
solution of all, and so, we kindly ask for a funding help from the
development team budget. But we are open to hear other solutions as well.
Best regards,
Santiago
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
