We've closed the tree for SeaMonkey 2.0 Alpha 3 a number of hours ago -
unfortunately, we still couldn't get our download manager replacement
for this milestone, so this will be another alpha we need to release
without localized builds. Once again, I'd like to offer experimental
language packs though, running language packs from comm-central-l10n
through my script to stick the en-US files for download manager in and
get some form of working language packs for testing.
We're not expecting string changes in suite/ until we will cut Alpha 3
any more and hope that the mozilla-1.9.1 will stay without string
changes in that time frame as well.
When we will tag and create the a3 builds sometime in the next few days,
I'll closely watch http://l10n.mozilla.org/dashboard/?tree=sea20x and
SeaMonkey's comm-central-l10n directory on FTP, and as I don't expect
any string changes between tagging and the next nightlies, I'll take all
langpacks for those next nightlies that get built and where dashboard is
green or orange, run those langpacks through my script and test the
results on a 2.0a3 candidate build.
If browser, mail, prefs and add-ons windows work and look localized,
I'll upload the langpacks for testing into the candidate directory.
If the respective localizers don't veto releasing them here, they'll
also end up as experimental langpacks in the release directory and on
the webpages later, just like we had it for Alpha 1 and Alpha 2.
I hope this process is acceptable once again as it was for Alpha 2 and
gets you more testing of your work, so that we can get high-quality
localizations for SeaMonkey 2. Of course, this process doesn't scale too
well, but for the betas, we should finally get automated and fully
working L10n builds and langpacks in place. Sorry we couldn't get that
yet for this milestone, we're getting near to closing the gap though.
I'll report back with which locales will make the steps in that process
and I hope we'll have a good number of langpack available for SeaMonkey
2 Alpha 3.
Robert Kaiser
We were exceptionally fast this time around and already have cut the
relbranch and tagged a first build. We might need to do a second
candidate build (we're still investigating), but the cutoff in terms of
code (and original strings for L10n) has been made.
> I'll closely watch http://l10n.mozilla.org/dashboard/?tree=sea20x and
> SeaMonkey's comm-central-l10n directory on FTP, and as I don't expect
> any string changes between tagging and the next nightlies, I'll take all
> langpacks for those next nightlies that get built and where dashboard is
> green or orange, run those langpacks through my script and test the
> results on a 2.0a3 candidate build.
We will refrain from changing L10n strings today so you have at least
some time to still catch up and make it. So far 11 languages are
green/orange and will be considered for those langpacks. If you still
want to be on 2.0a3, please make your locale go green ASAP.
Sorry for the short notice, things will become better next time with
actual L10n freezes, etc.
Robert Kaiser
Actually, not all of those green/orange ones actually produce langpacks.
Those in such a state but without langpacks are:
* ca *:
The orange due to help itself is OK, but help still breaks the build:
RuntimeError: file not found: chrome/common/help/cert_dialog_help.xhtml
gmake[1]: *** [libs] Error 1
gmake[1]: Leaving directory
`/builds/slave/comm-central-linux-l10n-full/build/obj/suite/locales'
* cs *:
ChatZilla is not reported by dashboard and not included in the
experimental langpack, but if it's broken, we don't even generate/upload
langpacks or builds:
Comparing cs to en-US
Properties in ./chrome/chatzilla.properties don't match:
In
/builds/slave/comm-central-linux-l10n-full/build/mozilla/extensions/irc/locales/en-US:
(add these to your localization)
cmd.evalsilent.params
cmd.evalsilent.help
cmd.unalias.params
cmd.unalias.help
msg.err.inputhistory.not.writable
* pt-PT *:
As with cs, ChatZilla breaks the whole build:
Comparing pt-PT to en-US
Properties in ./chrome/chatzilla.properties don't match:
In
/builds/slave/comm-central-linux-l10n-full/build/mozilla/extensions/irc/locales/en-US:
(add these to your localization)
cmd.evalsilent.params
cmd.evalsilent.help
cmd.unalias.params
cmd.unalias.help
msg.err.inputhistory.not.writable
If you manage to fix those today so that we actually spin langpacks, we
still can include your locales in 2.0a3.
Robert Kaiser
The following locales have made it so far and I will run the langpack
repackaging script for them:
ca, cs, de, es-AR, es-ES, fr, lt, nb-NO, nl, pl, pt-BR, ru, sk
Robert Kaiser
The following language packs made it through that test:
ca*, cs*, de, es-AR*, es-ES, fr*, lt, nb-NO, nl, pl, pt-BR, ru, sk
* (errors to note, should be fixed for later releases):
ca has an XML error in the mail start page
fr has an error in the main mail pref panel
es-AR has a good number of unchanged strings
cs has the main Composer pref panel unchanged
The language packs are now available on
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2.0a3-candidates/build1/langpack/
and if the locale owners don't veto it, those will be released as
experimental language packs along with SeaMonkey 2.0 Alpha 3.
Robert Kaiser
I just realized I didn't post about what we shipped, so this is the 13
experimental langpacks we ended up shipping:
ca, cs, de, es-AR, es-ES, fr, lt, nb-NO, nl, pl, pt-BR, ru, sk
See http://www.seamonkey-project.org/releases/2.0a3#l10n for downloads.
Thanks to all the localizers who helped make this happen this time!
Robert Kaiser
P.S.: A new WIP patch for the download manager switch just came up
today, we hope to get to finish this up soon so we can finally have
fully working localized builds up.