On 4/25/12 12:54 AM, Dave Fisher wrote:
On Apr 24, 2012, at 9:30 AM, Rob Weir wrote:
On Tue, Apr 24, 2012 at 12:02 PM, Herbert Duerr<h...@apache.org> wrote:
On 24.04.2012 16:55, Risto Jääskeläinen wrote:
See: Thread: Fix for bug 116639 almost
I don't think that 116639 was the root cause. Looking at the problematic
string in the screenshot you provided at
http://www.saunalahti.fi/rjaaskel/Kuvat/Tulostaikkuna.jpg
the reason was simply a strange translation of what is named "Comments",
"Kommentare", "Comentarios", "Commenti", etc. in other languages.
In the Finnish localization as of AOO340_rc1 it reads:
"Kun tämä valinta on tehty, ohjelman lisäämät tyhjät sivut tulostetaan. Tämä
on tarpeen, kun tulostetaan kaksipuoleisesti. Esimerkiksi kirjassa
\"luku\"-kappaletyyli on määritelty alkavaksi aina parittomalta sivulta. Jos
edellinen luku päättyy parittomalle sivulle, %PRODUCTNAME lisää parillisen
tyhjän sivun. Tämä valinta ohjaa mainitun parillisen sivun tulostusta."
which is defined in the "STR_PRINTOPTUI 18" line of
https://svn.apache.org/repos/asf/incubator/ooo/trunk/extras/l10n/source/fi/localize.sdf
Getting such a long string into a poor little dialog is does of course cause
some trouble.
[...] Bug is fixed in
Pootle but correct translation is not yet in publshed package.
The other translations for the other STR_PRINTOPTUI lines in the finnish
localize.sdf were also a bit long. Have they been fixed too?
I am sorry if this is not correct way of voting
I'd like to extend that question by asking (e.g. the mentors) if it should
be possible to split the voting in such situations, so that e.g. individual
localization could vote for a different revision? Is a staggered release
process allowed?
Otherwise there would be a inherent scalability problem in the release
process of such a huge multi-platform and multi-language application
targeted at end users: if one problematic localization could reset the work
of everyone else then this would be a recipe for a lot of frustration, as
building, distributing, announcing and especially testing of a new revision
is a huge effort and a lot of people are involved.
I think we can handle this efficiently. But we would need to take
some precautions. Start with making a branch of RC1 in SVN, if RC1 is
approved. If we then want to update a single language or a single
platform, then we can make those changes in the branch.
Or RC2. A branch this big will require coordination with Infra.
we will need a branch anyway to have a code line for bugfixes etc. based
on the release and the main trunk to continue the development to the
next release.
Juergen
I think we would still require a release vote for any additional files
we publish, such as updated translations, etc. So the same 72-hour
voting process.
Makes sense to me.
But I don't think it would require that the IPMC do an in-depth review
of the entire release, and it should not be necessary for us to do a
complete regression test. I'd hope the IPMC would be satisfied to
look at the SVN logs and see that only translations had been changed,
and that would be enough to justify their approval.
Before we hope, let's get through a release with IPMC approval.
Depending on how we do, a push for graduation makes sense. In that case our PMC
votes will be enough.
Regards,
Dave
-Rob
Herbert
