If you would like to opt-in for the upcoming Beta 3 (for Firefox 3)
release. Please indicate your desire to do so in this thread by Monday
Feb 4 please. We will track this thread to ensure we have the final
list of those that want to opt-in to B3.
For details on the timing implications for B3 and beyond, check out
this post from mozilla.dev.planning (Firefox 3 Schedule update: Beta 3
and beyond):
http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/d948f265d2998522
Thank you :)
Mic
>
> Hello
>
> If you would like to opt-in for the upcoming Beta 3 (for Firefox 3)
> release. Please indicate your desire to do so in this thread by Monday
> Feb 4 please. We will track this thread to ensure we have the final
> list of those that want to opt-in to B3.
>
ga-IE would like in for b3.
Kevin
eu wants to opt-in for B3.
Julen.
Please add the fr locale too.
Cédric
Kind regards
Wim
pl wants to opt-in
We're currently green on tinderbox and l10n.mozilla.org/dashboard, so
it should be all-ok.
NOTE: I am moving, so unfortunately I might not have Internet access
through weekend.
If I'm not available and there are any problems that need solving on
the side of Polish localization team,
Hubert Gajewski and Staszek Malolepszy are capable of making
decisions
and check-ins and they both have my approval for any "SNAFU-fixing"
check-in
to Polish Firefox l10n.
--
Marek Stepien
aviary.pl
- tinderbox is green
- dashboard is green as well
- no non-approved changes to seachplugins, rss etc.
- nightlies tested with all platforms
--
Vlado Valastiak
Mozilla.sk
Thanks
Tim Maks
-----Oorspronkelijk bericht-----
Van: dev-l10n...@lists.mozilla.org namens Mic
Verzonden: vr 1-2-2008 14:53
Aan: dev-...@lists.mozilla.org
Onderwerp: Firefox 3 Beta 3 Opt-In
Hello
Thank you :)
Mic
_______________________________________________
dev-l10n mailing list
dev-...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-l10n
- tinderbox is green
- dashboard will be gren.
channy
* Tinderbox and dashboard are green
* updated WikiPedia search-plugin approved:
https://bugzilla.mozilla.org/show_bug.cgi?id=412327
* changes to RSS Reader approved:
https://bugzilla.mozilla.org/show_bug.cgi?id=410523
Francesco.
Please add the Arabic locale (ar).
Thank you,
-Ayman
Please add "de" to the mix, thanks.
--Abdulkadir
2008/2/1, Mic <michal...@gmail.com>:
--
Toni Hermoso Pulido
http://www.cau.cat
Please, add ka (Georgian) also
Thanks,
g.\
Why delete messages? Unlimited storage is just a click away. Go to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html
--
Hasse
sv-SE l10n team
* tinderbox is green now.
* dashboard is green as well.
--
Mozilla Taiwan / Jose Sun
Localization Manager
http://moztw.org
E-mail & GTalk: jos...@gmail.com
Skype: josesun
Wow, you had a busy few days :-)
Cool to see arabic come up.
Axel
Please fix http://l10n.mozilla.org/buildbot/compare/linux-langpack/4250
still?
You seem to miss the inclusion of netErrorApp.dtd, see
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/dom/locales/en-US/chrome/netError.dtd&rev=1.15&mark=83-87#83
Axel
Hi Ayman, I just saw that the windows tinderboxens are busted due to a
problem in mui.properties. I place my bet on
MUI_INNERTEXT_LICENSE_BOTTOM_RADIOBUTTONS, at least it's close to that.
The iconv to CP1256 fails there.
Axel
Please add the cs locale too.
Pavel
Please consider including Hebrew (he) to the list. We're [hopefully] ready.
Please consider including Hebrew (he) to the list. We're [hopefully] ready.
Just to make sure that we're on the same page, at this moment, both
buildbot and tinderbox are red.
http://l10n.mozilla.org/buildbot/compare/linux-langpack/4257 has a log.
Axel
That is because someone (not me :) used lam-alef Unicode presentation
form (a common thing because a buggy Arabic X keyboard layout). Should
be easily fixable.
I think it should be mentioned in the comment that this file will be
converted to another encoding, it is not uncommon to use some Unicode
control chars to control the directionality of the text, if this text
won't be used in Unicode, this has no sense then.
--
Khaled Hosny
Yeah, I've fixed that and the Windows builds are green now.
By the way, big thanks to Khaled for the extra effort he put on this
release. We would have never made it to beta 3 without his work.
-Ayman
--
Sincerely yours,
Alexander L. Slovesnik a.k.a. Unghost
==>Web-page: http://www.unghost.ru/
==>Jabber ID: ung...@mozilla-russia.org
==>Gmail Talk ID: ung...@gmail.com
==>ICQ: 205497659
==>IRC: irc://irc.mozilla.org/mozilla-ru
Hi Toni,
just to make sure,
http://l10n.mozilla.org/buildbot/compare/linux-langpack/4371 still
reports errors, in particular, the inclusion of netErrorApp.dtd in dom's
netError.dtd.
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/dom/locales/en-US/chrome/netError.dtd&rev=1.15&mark=83-87#83
is the en-US code.
Axel
Please take a look on the bugs we've reported about Hebrew. Most of them
would also affect your locale, and should be fixed.
Tomer.
Please include uk, we're on green.
Tim.
regards
--
AmanAlam
Punjabi OpenSource Team
Thank you for bringing the bugs to my attention. I will keep an eye on
them.
-Ayman
Please add Lithuanian (lt) locale to B3.
We're green on tinderbox and l10n.mozilla.org/dashboard.
Best regards,
Tatjana
Mic rašė:
> Hello
>
> If you would like to opt-in for the upcoming Beta 3 (for Firefox 3)
> release. Please indicate your desire to do so in this thread by Monday
> Feb 4 please. We will track this thread to ensure we have the final
> list of those that want to opt-in to B3.
>
> For details on the timing implications for B3 and beyond, check out
> this post from mozilla.dev.planning (Firefox 3 Schedule update: Beta 3
> and beyond):
pt-PT opts in :).
Mic escreveu:
| Hello
|
| If you would like to opt-in for the upcoming Beta 3 (for Firefox 3)
| release. Please indicate your desire to do so in this thread by Monday
| Feb 4 please. We will track this thread to ensure we have the final
| list of those that want to opt-in to B3.
|
| For details on the timing implications for B3 and beyond, check out
| this post from mozilla.dev.planning (Firefox 3 Schedule update: Beta 3
| and beyond):
|
http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/d948f265d2998522
|
| Thank you :)
| Mic
| _______________________________________________
| dev-l10n mailing list
| dev-...@lists.mozilla.org
| https://lists.mozilla.org/listinfo/dev-l10n
- --
Intraneia
http://www.intraneia.com/
Suporte a Software Livre
Tradução/Localização de software e sítios web
Desenvolvimento de software
Ao seu serviço...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHpdLCGFkMfesLN9wRAmfhAJ0TNrguP2maRTW94FuYV5/Vb2WCawCfbJ8h
/EcZ+hBscVTcl5x1uXlmi2U=
=ejAB
-----END PGP SIGNATURE-----
Thanks,
Andras
Hi Andras,
mind taking a look at your bookmarks.html again? The addons bookmark
link points to en-US now, and the title is not translated.
Waiting for the next windows tinderbox build, too.
Axel
Hi Axel,
I have checked in updated bookmarks.html. There are many untranslated
string everywhere, I know about them.
Andras
Citando a mensagem de Mic:
it's 8:45 UTC, there have not been check-ins for about an hour, so we'll
cut at 8am UTC, unless something funky happens.
Mic and I will go through the search review again.
Axel
Mic wrote:
> Hello
>
> If you would like to opt-in for the upcoming Beta 3 (for Firefox 3)
> release. Please indicate your desire to do so in this thread by Monday
> Feb 4 please. We will track this thread to ensure we have the final
> list of those that want to opt-in to B3.
>
just wanted to let you know that I checked in a bustage fix to
bookmarks.html for Arabic. There was some funkyness in the whitespace,
which made it hard to see that all the links went to en-US pages instead
of ar. So I fixed the links and cleaned up the markup, no translation
changes (aside copying the title to h1).
Axel
es-ES is ready for 3.0b3, but i don't know if it is too late :S
Sorry, and thanks
Thanks, must be green from now
http://l10n.mozilla.org/buildbot/builders/linux-langpack/builds/4452
g.\
es-ES is still red on buildbot,
http://l10n.mozilla.org/buildbot/compare/linux-langpack/4428.
To take more changes, it's sadly really too late now.
Axel
es-AR is still red,
http://l10n.mozilla.org/buildbot/compare/linux-langpack/4318.
That build is from Friday, and we've announced quite early what the
rules would be, buildbot and tinderbox need to be green. As that was a
build on your check-in, I doubt there's a whole lot more that we can do.
As for es-ES, we're out of time to land further changes now, but this
isn't the last beta, and I expect nightlies to be much more useful in
the following, too. So this isn't the end of the world.
Axel
Yes, thanks.
Axel
I agree that it is not a big deal if we can't make b3. As matter of
fact, however, when I visited:
http://l10n.mozilla.org/dashboard/
I just got an static table with no links in es-ES line. I played with
the boxes to the right, and got no useful details, so I thought what I
was seeing was all I could get.
Only today (admittedly, because I've had some more time to spend on
that page), and after seeing your other links, I've realized that the
title "table - builds - Fx2" (hint for es-*: you will probably see
"Tabla - Builds - Fx2") are actually links to different views, and
then I've seen that Builds view shows green and red boxes.
The red underline is fancier, but maybe a simple "blue-underlined"
(or, at least, blue) style there would be clearer. :-? I guess most of
us already ("already" as "since five minutes ago") ;-) know that, but
for newcomers it could be of help.
TIA
--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
It has been just fixed in trunk.
BTW, the reason why this happened is because a file with a
.properties-like syntax is named as an .ini file, so MozillaTranslator
treated as a plain text and I had to edit it by hand (and mistyped two
keys). Can we assume .INI files in Mozilla CVS repository are to be
handled as .Properties files from now on?
I know that I could base MT file detection on file contents instead of
file extension, but this would increase the complexity for something
that really shouldn't be needed most of the time; besides, things like
this kind of creates "moving targets" that makes harder to keep up the
functional status of the tool.
The problem is, ini files look like properties files, but properties
files don't look like ini files.
So the problem is that a properties parser would be fine with an ini
file, probably, but not the other way around, thus we opted to not call
the .properties. Properties files are a tad harder to parse correctly,
too, and neither the updater nor the crashreporter code can just reuse
the xpcom code.
Thus, real ini files, sorry. It shouldn't be too hard to add, may I say,
as I just wrote a special parser for that myself. Note,
crashreporter.ini violates the ini file format in using # as comment
char instead of ';', sadly. updater.ini uses ';', so you gotta take both.
Axel
I personally find the Builds tab a dash sexier than the table, too.
Maybe I change the default landing tab.
Or I improve the table, which I learned how to do in another exhibit the
other day.
Axel
I'm complaining about closing dates almost too close to weekends. Even
with a green dashboard, I would opt-in on Monday. Saturday and Sunday
shouldn't be counted when you say that there are four days to opt,
freeze or release.
BTW, it's mid-summer in Argentina. Almost the entire population is lying
down on a beach. I'm the only one working.
Oops, sorry. I missed the [Strings] section at the top of the file,
and thought that crashreporter.ini was really a renamed .properties files.
> Thus, real ini files, sorry. It shouldn't be too hard to add, may I say,
> as I just wrote a special parser for that myself. Note,
> crashreporter.ini violates the ini file format in using # as comment
> char instead of ';', sadly. updater.ini uses ';', so you gotta take both.
I've found a bug in MT 5.22 (fixed something,
https://bugzilla.mozilla.org/show_bug.cgi?id=383914; broke another
thing, namely regional packs in SM 1.1.x), and I'm getting tired of
flagging off image files every time I update SeaMonkey trunk, so I may
be adding INI files parsing as well. Thanks for the comment point.
Ricardo.
Hrm. I was running under the assumption that the weekend would actually
be valuable time for localizers, but that may well be just "for most of
them".
Here's my problem:
We're closing the tree around Tuesday, with baking time 'til Friday. I
won the weekend for l10n, so we're starting builds on Monday.
Now, I'm not feeling good about posting the opt-in thread before the
release drivers understand how good the tree really is. And this time
around, Tuesday was landing-crazy. So I added a bit of padding time.
Like, the opt-in is supposed to say "I translated the stuff and I took a
good look at it, it's great stuff for Beta". I really think that
starting the opt-in time too eagerly is just tempting localizers into
saying "ship whatever", which I'd rather not do. And like, how can you
say "it's cool, I checked" if nobody is actually sure that there isn't a
l10n change on Friday. Bad, but happened for B1.
Given that we still have one more Beta, with string freeze in effect, I
really think that we should get a more confident landing window for
localization for the upcoming milestones. Like, I would hope that most
locales will already be green, with localization teams running their
nightlies as dogfood, before the code freeze for Firefox for that
milestone. That should resolve the chicken-egg problem here, and that's
cool. Remember, all our Betas are done on "best effort", and we're doing
great for that.
Hth, and sheds some light on my thinking
Axel
You could do a post here on that Tuesday or maybe Wednesday that says
"As a note, the (pre-)release is planned for early next week, so try to
get your tree clean, an opt-in thread will follow as soon as release
managers have clear the code as being ready. A small number of late-l10n
checkins is still possible until then but we're trying to keep them as
few as possible."
This would tell those who don't follow nightlies to get ready and give
them more time to clear things up for the release.
Robert Kaiser
You mean like
news://news.mozilla.org:119/Kr-dndoZefbJwj3a...@mozilla.org,
"Re: Firefox 3 Schedule Update: beta 3 & beyond"?
That's from Wednesday. It says that the opt-in thread is going to come
shortly, that tinderboxens are supposed to be green, that I'll do
stricter checks on compare-locales, which got another announcement as it
landed.
Axel
Ah, right. I read it back then, but already forgot, as German is
following nightlies anyways (at least for core, which is mostly what I
care about).
Robert Kaiser
Wikipedia says that INI file format, unlike .DTD and .Properties, is
not defined in a very strict way, so variants may happen. Although
I've reviewed existent INI files in toolkit, suite, firefox, etc., do
you happen to know if there is any provission in Mozilla dev.
environment for breaking long lines? Something like:
LongWrappedLine=This is a very \
long line value.
At the moment, it looks like the only INI file with long lines is
crashreporter.ini and no line break happens, but I wonder if there is
something written about how to do it, just in case...
I'm pretty sure that the parser in crashreporter will not grok line
continuations. It's a KISS parser, mostly. It will eat dinosaurs, too. I
think it basically takes anything that has a '=' in the middle. But one
shouldn't rely on that.
Axel