Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Calendar localization update

0 views
Skip to first unread message

Simon Paquet

unread,
Sep 29, 2006, 7:24:28 PM9/29/06
to
Hi folks,

as you probably have noticed, we have an RC1 for Sunbird 0.3 now. So now
it's time to go out and test it.

If you find anything that you to correct, please be advised, that we have
created the SUNBIRD_0_3_BRANCH, from which we'll release Sunbird 0.3
from, so all l10n-related checkins have to go into that branch.

Please also commit the same changes to the trunk, so that it stays in
sync.

A last note to all localizers:
We'll also release Lightning 0.3 together with Sunbird 0.3. Other than
Sunbird, Lightning 0.3 will be released from the MOZILLA_1_8_BRANCH that
is also used for the FF2 and TB2 releases. So if you haven't already done
so, please also commit your changes in l10n/$language$/calendar to this
branch.

Thanks in advance
Simon

--
Sunbird/Lightning/Calendar Website Maintainer:
http://www.mozilla.org/projects/calendar
Sunbird/Calendar blog: http://weblogs.mozillazine.org/calendar

sskroeder

unread,
Sep 30, 2006, 6:23:10 AM9/30/06
to

Simon Paquet skrev:

> If you find anything that you to correct, please be advised, that we have
> created the SUNBIRD_0_3_BRANCH, from which we'll release Sunbird 0.3
> from, so all l10n-related checkins have to go into that branch.

Simon, perhaps i've misread your previous statements, but didn't you
say that you would wait 'till Oct. 2nd to tag (and branch) ?

Have you made a copy off all the /calendar localizations on that branch
-or are we to do the whole cvs add routine all over again ?

>
> Please also commit the same changes to the trunk, so that it stays in
> sync.

Ok -- I'll keep that in mind...


>
> A last note to all localizers:
> We'll also release Lightning 0.3 together with Sunbird 0.3. Other than
> Sunbird, Lightning 0.3 will be released from the MOZILLA_1_8_BRANCH that
> is also used for the FF2 and TB2 releases. So if you haven't already done
> so, please also commit your changes in l10n/$language$/calendar to this
> branch.

Please be advised that Pike have discouraged ANY checkins (including
/mail and /calendar) to the mozilla_1_8_branch pending completion of
Firefox 2 RC 2, so theres a conflict of guidelines here ....

Please confer with Pike and advise....

/Søren Munk Skrøder
Localizer, Danish Firefox team - Temp checkin-guy for calendar too...

Simon Paquet

unread,
Sep 30, 2006, 6:45:09 AM9/30/06
to
And on the seventh day Simon Paquet spoke:

>Hi folks,
>
>as you probably have noticed, we have an RC1 for Sunbird 0.3 now. So now
>it's time to go out and test it.
>
>If you find anything that you to correct, please be advised, that we have
>created the SUNBIRD_0_3_BRANCH, from which we'll release Sunbird 0.3
>from, so all l10n-related checkins have to go into that branch.
>
>Please also commit the same changes to the trunk, so that it stays in
>sync.

Please forget what I've said above. It is totally wrong. As lilmatt
posted earlier, we'll tag the /l10n repository on October 0.3 at the
earliest.

Sorry for the confusion!

Simon Paquet

unread,
Sep 30, 2006, 6:43:36 AM9/30/06
to
And on the seventh day sskroeder spoke:

>
>Simon Paquet skrev:
>> If you find anything that you to correct, please be advised, that we have
>> created the SUNBIRD_0_3_BRANCH, from which we'll release Sunbird 0.3
>> from, so all l10n-related checkins have to go into that branch.
>
>Simon, perhaps i've misread your previous statements, but didn't you
>say that you would wait 'till Oct. 2nd to tag (and branch) ?

Yes, scrap my comment from above.

>Have you made a copy off all the /calendar localizations on that branch
> -or are we to do the whole cvs add routine all over again ?

When we'll tag the /l10n repository, you won't have to add your
localizations all over again.

>> Please also commit the same changes to the trunk, so that it stays in
>> sync.
>
>Ok -- I'll keep that in mind...

Scrap what i said there, also.

>> A last note to all localizers:
>> We'll also release Lightning 0.3 together with Sunbird 0.3. Other than
>> Sunbird, Lightning 0.3 will be released from the MOZILLA_1_8_BRANCH that
>> is also used for the FF2 and TB2 releases. So if you haven't already done
>> so, please also commit your changes in l10n/$language$/calendar to this
>> branch.
>
>Please be advised that Pike have discouraged ANY checkins (including
>/mail and /calendar) to the mozilla_1_8_branch pending completion of
>Firefox 2 RC 2, so theres a conflict of guidelines here ....
>
>Please confer with Pike and advise....

Yeah, I noticed that only after I posted this. I_'m not so happy about
that discouragement, but we'll sort it out with Pike.

Stefan Sitter

unread,
Sep 30, 2006, 9:24:27 AM9/30/06
to
Hello,

I noticed a problem yesterday.

Recently there were some non-calendar locales changes on Trunk, e.g.
by Bug 354410 in mozilla/netwerk/locales/en-US. Some locales have
already updated their sources.

Currently Sunbird is build from SUNBIRD_0_3_BRANCH to have a stable
base to work on. That means that any checkins to Trunk don't affect
Sunbird.

Unfortunately this also affects locales. L10n files are not yet
branched or tagged, see previous post from lilmatt.

That means that the updated locales from Trunk don't work with
Sunbird from SUNBIRD_0_3_BRANCH. The Sunbird build e.g. expects the
locales in the old location from before Bug 354410 was fixed ...

I hope we can find a solution for this issue.

Stefan

lilmatt

unread,
Sep 30, 2006, 2:26:58 PM9/30/06
to
Stefan Sitter wrote:
> I noticed a problem yesterday.
>
> Recently there were some non-calendar locales changes on Trunk, e.g.
> by Bug 354410 in mozilla/netwerk/locales/en-US. Some locales have
> already updated their sources.

Due to this, I have retroactively cut a branch of l10n for Sunbird
(SUNBIRD_0_3_BRANCH) at 2006-09-28 20:00 UTC, which is about 10 minutes
before bug 354410 landed. Please ensure to commit localization changes
that should ship with Sunbird 0.3 to this branch. You should also
continue to commit changes that are compatible with the trunk, to the
trunk. However, changes like those in bug 354410 should _NOT_ make it
onto SUNBIRD_0_3_BRANCH.

This also means that if you have committed calendar l10n changes AFTER
2006-09-28 20:00, you'll need to commit those again on to
SUNBIRD_0_3_BRANCH. I'm very sorry for this inconvenience.

We still plan to create the SUNBIRD_0_3_RELEASE tag as mentioned in my
other post, although if we run into conflicts with the Fx2 l10n tree
closing, we may need to re-evaluate.

-lilmatt

sskroeder

unread,
Sep 30, 2006, 3:33:27 PM9/30/06
to

lilmatt skrev:

> Due to this, I have retroactively cut a branch of l10n for Sunbird
> (SUNBIRD_0_3_BRANCH) at 2006-09-28 20:00 UTC, which is about 10 minutes
> before bug 354410 landed. Please ensure to commit localization changes
> that should ship with Sunbird 0.3 to this branch. You should also
> continue to commit changes that are compatible with the trunk, to the
> trunk. However, changes like those in bug 354410 should _NOT_ make it
> onto SUNBIRD_0_3_BRANCH.
>
> This also means that if you have committed calendar l10n changes AFTER
> 2006-09-28 20:00, you'll need to commit those again on to
> SUNBIRD_0_3_BRANCH. I'm very sorry for this inconvenience.

I do wonder why is has been necessary to branch the localizations right
now - why this couldn't wait till Oct. 2nd...

We are less than 2½ days away from the deadline for completing the
localization -- at least our locale is struggling with getting ours
done, and now this added complexity (maintainment of 3 different
cvs-trees) is tossed into the equation

Couldn't this either have waited (so we just branched when tagging for
release) or have branched sooner

Right now i find this l10n process somewhat rushed - the shortness of
the window from string freeze to l10n was barely bareable, but now i
have to wonder about new branches too ...

And i hope that the l10n-process for Sunbird will mature to something
alike Firefox's -- where
1) localizers have a decent window finish their localization and do all
the polish that often is required afterwards
2) that all technicalities about what branch to release from and commit
to are in order (and in effect) at least a good while before one
reaches the "last call" phase, so we don't have to worry about cvs
branching just days before deadline of a locale, when all we really
want to worry about at this point is to provide the best localization
possible....

And i implore you - the Sunbird maintainers - to take these two points
into account --- The Firefox l10n process haven't always been painless
(esspecially not when late-l10n strings changes occur) - but at least
i've experienced that with Firefox, the issues in (#2) have been
considered...

lilmatt

unread,
Sep 30, 2006, 7:12:42 PM9/30/06
to

sskroeder wrote:
> I do wonder why is has been necessary to branch the localizations right
> now - why this couldn't wait till Oct. 2nd...
A number of locales have already committed the changes for bug 354410
to trunk. Those changes are incompatible with Sunbird 0.3. If we
didn't branch PRIOR to those changes, those locales would be broken on
Sunbird 0.3.

> Couldn't this either have waited (so we just branched when tagging for
> release) or have branched sooner

Branching sooner (at the same time as we branched the code) is what we
should have done. Since I cut the branches, I'll take responsibility
for that pain.

> Right now i find this l10n process somewhat rushed - the shortness of
> the window from string freeze to l10n was barely bareable, but now i
> have to wonder about new branches too ...

Suggestions as to an appropriate length window are welcome. Please
remember that this is the first time we (the Sunbird devs) are doing a
true string freeze, and the first time that we are trying to have a
simultaneous release of both products, and all available locales. We
_all_ are learning a great deal from this experience.

> And i hope that the l10n-process for Sunbird will mature to something
> alike Firefox's -- where
> 1) localizers have a decent window finish their localization and do all
> the polish that often is required afterwards
> 2) that all technicalities about what branch to release from and commit
> to are in order (and in effect) at least a good while before one
> reaches the "last call" phase, so we don't have to worry about cvs
> branching just days before deadline of a locale, when all we really
> want to worry about at this point is to provide the best localization
> possible....

Regarding point 1), as I wrote above, suggestions as to an appropriate
length window are welcome.
Regarding 2), in the future, we will cut the code branch and l10n
branch simultaneously, and perhaps both earlier than we did this time.
The changes from bug 354410 are what forced us to change our plans at
this late date, but it's not that bug's fault that we didn't branch
sooner. Your concerns are noted.

-lilmatt

Stanislaw Malolepszy

unread,
Oct 1, 2006, 10:27:21 AM10/1/06
to

Simon Paquet wrote:

> Please forget what I've said above. It is totally wrong. As lilmatt
> posted earlier, we'll tag the /l10n repository on October 0.3 at the
> earliest.

I need some guidance here, please.

October 3rd is the test day and the localized builed will be ready by
then, so that they can be tested as well, right? But at the same time,
the localizers are given time till Oct. 3rd 0700hrs to commit their
changes to the repository before it is tagged.

Is the above right, or am I missing here something (something big)?

Regards,
Stanislaw Malolepszy

Ricardo Palomares Martinez

unread,
Oct 1, 2006, 2:16:09 PM10/1/06
to
lilmatt escribió:

>> And i hope that the l10n-process for Sunbird will mature to something
>> alike Firefox's -- where
>> 1) localizers have a decent window finish their localization and do all
>> the polish that often is required afterwards
>> 2) that all technicalities about what branch to release from and commit
>> to are in order (and in effect) at least a good while before one
>> reaches the "last call" phase, so we don't have to worry about cvs
>> branching just days before deadline of a locale, when all we really
>> want to worry about at this point is to provide the best localization
>> possible....
> Regarding point 1), as I wrote above, suggestions as to an appropriate
> length window are welcome.
> Regarding 2), in the future, we will cut the code branch and l10n
> branch simultaneously, and perhaps both earlier than we did this time.
> The changes from bug 354410 are what forced us to change our plans at
> this late date, but it's not that bug's fault that we didn't branch
> sooner. Your concerns are noted.


Take the following as suggestions:

As a localizer, I find complex have to deal with so many branches for
the same base product. For a start, I think that both Sunbird 0.3 and
Ligthining 0.3 should have been built from the same branch; I know
that there is work in progress to get it for future releases.
Moreover, I really think that trunk should not be the origin of a
release, even more when toolkit development isn't likely to have you
in their concern list while you are totally dependent on them.

IMHO, you should struggle to be as much in sync as possible with
Firefox (or Gecko, for that matter) strategy. That means trying to
reuse branchs created for Fx/Tb, much in the same way as SeaMonkey
team is doing. Changes in branches done to toolkit are less risky and
surely more publicited, giving you enough time to make sure than
Calendar is not affected by (or, at least, that it's able to deal
with) them.

In other words:

- Release from branches, not from trunk.
- Try to reuse branches made for Mozilla's mainstream products. While
I'm a bit ignorant in this field, I think this could be important when
XULRunner finally gets released: you won't want a shared component
build that doesn't match any official release: NVU did this and, as a
result, Daniel Glazman is thinking of dumping it and starting again
with the composer code inside Mozilla repository, to get and keep it
in sync with toolkit.
- If the previous one is possible, then you should be able to adopt
Firefox/Thunderbird freeze times for yourselves. Please note:
Thunderbird is usually a bit later than Firefox here, and anyway, as
soon as Firefox is close to be wrapped up, no changes to toolkit will
happen, so you can delay Sunbird/Lightning if you need it to, having
the confidence of no last hour changes to toolkit.

As for localizers, we would get:

- less branches to deal with, and in a more standard schedule.
- we wouldn't have the need to have trunk updated, something which by
nature is more prone to require us work that will end in the trash.

Hopefully some of these suggestions will have a point (others will
surely be no more than the result of my ignorance about Mozilla
development cycle) and you will be able to adopt it.

Ricardo.

--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?

Simon Paquet

unread,
Oct 1, 2006, 4:29:33 PM10/1/06
to
And on the seventh day Ricardo Palomares Martinez spoke:

>Take the following as suggestions:
>
>As a localizer, I find complex have to deal with so many branches for
>the same base product. For a start, I think that both Sunbird 0.3 and
>Ligthining 0.3 should have been built from the same branch; I know
>that there is work in progress to get it for future releases.
>Moreover, I really think that trunk should not be the origin of a
>release, even more when toolkit development isn't likely to have you
>in their concern list while you are totally dependent on them.

You can be assured, that we won't repeat a release from two different
trees (branch and trunk). It causes and has caused the developers at
least as much pain as it cost localizers.

For you sake and our sake, this won't be repeated. The next time we'll
either reuse an existing branch or we'll cut our own branch a few weeks
earlier.

0 new messages