The roads I take...
KaiRo's weBlog
| Zeige Beiträge veröffentlicht im Juni 2007 und mit "L10n" gekennzeichnet an. Zurück zu allen aktuellen Beiträgen |
25. Juni 2007
Weekly Status Report, W25/2007
I spent lots of time this weekend at the Donauinselfest, one of the biggest yearly open air festivals with reportedly 2.6 million visitors spread over three days this year (my pics from the event are already online).
Leading up to that, I managed to do a share of SeaMonkey work as well in week 25/2007 (June 18 - 24):
Items where nothing happend but which I hope to to get some traction on again:
The list of things I've done might look rather short (and I wonder myself about this), but it shows again what amount of time some single tasks like a mere sync of two existing "code bases" (or actually "string bases" in this case) can suck up. And I think the improved quality we'll be able to provide all German users (and probably users of all languages through the en-US bugs spun off this) is really worth that time.
Leading up to that, I managed to do a share of SeaMonkey work as well in week 25/2007 (June 18 - 24):
- Bugzilla reorganization:
Lots of discussion in m.d.planning about the future product/components structure of bmo. Looking better with every revision Gerv makes - places history:
Updated patch for switching the backend, got CVS copy for nsIBrowserHistory.idl in toolkit and updated patch for building toolkit mork history for non-places non-SeaMonkey apps only, which got review. - German L10n sync:
I spent most of my time with that this week. Filed bugs and patches for syncing up dom/, netwerk/, and editor/ui between CVS and my long-lived MozillaTranslator glossary (in addition to the security/manager one I had filed earlier), which sparked a lot of discussions, some of which are still going on, most of which have been settled now though. I also discovered a bunch of cases where my colleagues fixed problems in general strings silently in the de locale, though it would improve quality for everyone to have this fixed in en-US first instead. I filed bugs for those cases we discovered, and also did a few patches for the easy cases. This should be done more often, it helps everyone. - Various discussions:
Form controls regression, user agent rant and proposal/idea, suiterunner regressions, info bars, debug UI, Firefox 3 UI, and others
Items where nothing happend but which I hope to to get some traction on again:
- xpfe cleanup:
Not much happened this week on that front, need to look into that again soon. - Killing wallet:
Neil provided new patches to sync up autocomplete for getting this to work. He reported he got an auocomplete popup on his local build, so it looks like we're getting somewhere. Neil is away (yes, really, not only in his nick) this week though.
The list of things I've done might look rather short (and I wonder myself about this), but it shows again what amount of time some single tasks like a mere sync of two existing "code bases" (or actually "string bases" in this case) can suck up. And I think the improved quality we'll be able to provide all German users (and probably users of all languages through the en-US bugs spun off this) is really worth that time.
Von KaiRo, um 16:26 | Tags: L10n, Mozilla, SeaMonkey, Status | 2 Kommentare | TrackBack: 0
22. Juni 2007
Better quality for everyone
Since Firefox landed on the L10n CVS, German localizations for Mozilla core strings have been done separately in two places: On one hand, there was my private MozillaTranslator repository holding the suite localization and maintained by myself only, seeing fixes through occasional bug reports. On the other hand, there was the L10n CVS version used for Firefox and later Thunderbird, which originally based on my work, but diverted as Firefox localizer Abdulkadir Topal maintained it, adding his own sets of changes, probably coordinated in different cases with Alex Ihrig, who is the Thunderbird maintainer and German core L10n peer.
Now that we are working on finally getting suite L10n into CVS as well, I could just concentrate on SeaMonkey-specific strings and just adopt what is in CVS for the rest - but there are two problems with that approach:
First, due to changes on trunk and Abdulkadir having little time, we lack some translations for core in German CVS, and I'm happy to help out there a bit (some people might remember my fight with nsserrors.properties a while back, which was an instance of that).
Second, it's a good idea to review where translations diverged between my version and the one in CVS, as either version could have better solutions for some hard cases and some systematic differences may be worth a discussion that makes us consistently improve our work across core and the different applications.
Because of that, I filed a set of bugs about syncing up our different versions, and both MozillaTranslator's "Search Translation Inconsistency" and my PHP script to rewrite output of that tool with the structure of the original files did once again show their usefulness.
Sure, the result was a few huge patches (and I haven't even touched toolkit/ yet), which take my colleagues some time to review, but I'm convinced the result will be a better quality localization for all German users, and that's surely worth the time we all are putting into that.
And we even came across a few things which are bugs in the original strings and which German localizers have solved silently in the translation only, but they really should be filed as common bugs, so we can improve the product for all our users. This includes the security libraries of Thunderbird and Sunbird not talking to the user as if those applications were browsers, Firefox telling the user it stores email passwords or just resolving our mixed use of "website" and "site" across the core strings. We'll sort those out, file bugs where necessary and care that the situation gets better for all of us.
I also want to ask localizers of other languages to do the same: If strings in the en-US original are strange, wrong or inconsistent, please don't hesitate to file bugs against the original code.
Better quality for everyone is surely worth investing some of our time, we all should our share to ensure it's possible.
Edit (June 22, 6:30pm CEST):
Some bugs we spotted in the original strings are filed now - and we may find even more
Now that we are working on finally getting suite L10n into CVS as well, I could just concentrate on SeaMonkey-specific strings and just adopt what is in CVS for the rest - but there are two problems with that approach:
First, due to changes on trunk and Abdulkadir having little time, we lack some translations for core in German CVS, and I'm happy to help out there a bit (some people might remember my fight with nsserrors.properties a while back, which was an instance of that).
Second, it's a good idea to review where translations diverged between my version and the one in CVS, as either version could have better solutions for some hard cases and some systematic differences may be worth a discussion that makes us consistently improve our work across core and the different applications.
Because of that, I filed a set of bugs about syncing up our different versions, and both MozillaTranslator's "Search Translation Inconsistency" and my PHP script to rewrite output of that tool with the structure of the original files did once again show their usefulness.
Sure, the result was a few huge patches (and I haven't even touched toolkit/ yet), which take my colleagues some time to review, but I'm convinced the result will be a better quality localization for all German users, and that's surely worth the time we all are putting into that.
And we even came across a few things which are bugs in the original strings and which German localizers have solved silently in the translation only, but they really should be filed as common bugs, so we can improve the product for all our users. This includes the security libraries of Thunderbird and Sunbird not talking to the user as if those applications were browsers, Firefox telling the user it stores email passwords or just resolving our mixed use of "website" and "site" across the core strings. We'll sort those out, file bugs where necessary and care that the situation gets better for all of us.
I also want to ask localizers of other languages to do the same: If strings in the en-US original are strange, wrong or inconsistent, please don't hesitate to file bugs against the original code.
Better quality for everyone is surely worth investing some of our time, we all should our share to ensure it's possible.
Edit (June 22, 6:30pm CEST):
Some bugs we spotted in the original strings are filed now - and we may find even more
Von KaiRo, um 03:46 | Tags: L10n, Mozilla, quality, SeaMonkey | keine Kommentare | TrackBack: 0
18. Juni 2007
Weekly Status Report, W24/2007
After a week that has been a bit lighter than the last, here's a summary of SeaMonkey work I did in week 24/2007 (June 11 - 17):
And, just as it was in discussion a lot this week when ISS lost attitude control due to a computer failure for a few days, I hope I've got my attitude pretty well under control. Thank god I don't need to go through pre-breathe protocols, depressurization, pure oxygen breathing or complicated suits just to go outside this living environment - though sometimes it seems I may be leaving this well-known place not too much more often than those astronauts are stepping outside theirs
- Bugzilla reorganization:
Tripping over this once again, I opened a thread about organization of Bugzilla components in m.d.planning, telling my problems and some possible solutions.
This ended up with Gerv starting on a bmo reorg plan with looking for input from more developers on the newsgroup and posting a first reorganization plan. I hope we'll come to a good plan there and will get it really done as well afterwards. - SeaMonkey releases:
Uploaded a few more contributed localized builds for 1.1.2/1.0.9 - xpfe cleanup:
This is progressing, I cleaned up
xpfe/bootstrap as much as currently possible this week, more is to be done in other directories, but a few are apparently suffering from forkitis (the abandoned xpfe versions probably contain fixes that never made it into toolkit but still should). We should try to fix that as well. - Killing wallet:
Some talk with Neil about that, he's getting near to solving the remaining problems, I'll post an updated patch for the switch itself soon. - places history:
Removing toolkit mork history won't happen before Gecko 1.9a6, but the CVS copy I requested should make fixing that easier as well as our var-based build time switch solution for places history. Still need someone to look at the UI then. - Mac nightlies:
Investigated missing copies of Mac nightlies is latest-trunk/ a bit more and saw it fixed by a mostly unrelated fix. - Even more cleanup:
Filed a bug for removing suite autoscroll now that our solution has been ported to toolkit, proposed removing moz_pis_startstop_scripts from unix startup scripts after I killed that now unused feature from xpfe/bootstrap. - Various discussions:
Suiterunner theme regressions, untrusted X connections, autocomplete theming, Mercurial repository, Apple download pages, Mozilla Credits, profile location, Firefox 3 UI, P3P UI removal, and others
And, just as it was in discussion a lot this week when ISS lost attitude control due to a computer failure for a few days, I hope I've got my attitude pretty well under control. Thank god I don't need to go through pre-breathe protocols, depressurization, pure oxygen breathing or complicated suits just to go outside this living environment - though sometimes it seems I may be leaving this well-known place not too much more often than those astronauts are stepping outside theirs
Von KaiRo, um 02:43 | Tags: L10n, Mozilla, SeaMonkey, Status | keine Kommentare | TrackBack: 1
11. Juni 2007
Weekly Status Report, W23/2007
This week I've been piling up about 80 hours of work time, mostly related to SeaMonkey and Mozilla - I think that probably is not what I should be re-doing any time soon, even though interesting things like watching a space shuttle launch can be done right next to the work thanks to internet streaming.
Here's a summary of my SeaMonkey work in week 23/2007 (June 4 - 10):
I once again realized that it's a good thing to do those weekly wrapups to remember yourself what it all was that you spent you time on that week - with such a list, it happens that you forget what it even was that took up some of those hours...
Here's a summary of my SeaMonkey work in week 23/2007 (June 4 - 10):
- SeaMonkey releases:
Uploaded a few more localized and other contributed builds for 1.1.2/1.0.9 - xpfe cleanup:
As we're on toolkit now, I started to work on cleaning up xpfe/, which in turn needed a hack to get Camino away from building xpfe/bootstrap, but this is shaping up nicely. I'll look into even more cleanup in the next few days now that the tree is open and I could check in the patches I had review for.
Both in the xpfe/components and xpfe/bootstrap dirs, we can be cvs remove even more files than in the current patches, and we should kill off all the old cruft, as anyone who needs to refer to them can always go back in cvs history.
We also might need to file a few bugs though for fixes that went into xpfe but not corresponding toolkit code and improve toolkit along the way. - Killing wallet:
I posted an updated patch for the wallet -> satchel change so Neil can work on fixing up autocomplete to work with that. - places history:
The UI work seems to be getting too much for me, so I reworked the patch to user places history so that we can turn this on in any build be setting MOZ_PLACES=1 in confvars.sh but build old xpfe mork history by default, so someone else can easily look into the UI parts.
The harder part of that is sorting out a way so SeaMonkey (and Camino) get the nsIBrowserHistory interface built in toolkit (lives in history/public there) when places is turned on, but never get all of toolkit history built. I ended up proposing to remove toolkit mork history as it's not built any more by any app in the Mozilla tree. Mano didn't agree with the patch itself (the interface should probably just be move to places), but with the general idea, but wants to get an OK for removing support for mork history toolkit builds. Watch out for this happening soon in some form. - Crash reporting:
Worked with Chris Cooper from MoCo to get Talkback re-enabled on SeaMonkey trunk as far as currently possible, (and with Frank to get it correctly packaged on Windows). Also worked with Ted (luser) on figuring out how to get breakpad working for SeaMonkey. It turns out from our talking and my testing that we are on a good way for that once the breakpad people have stabilized their infrastructure enough to make other apps than Firefox (which already tests it) use this. - Startup profiling:
I created jprof-enabled build from just before the suiterunner switch to investigate the suiterunner Ts regression but the data didn't help as much as I had hoped. Boris, who knows a lot about profiling and has a slow machine, could unfortunately not run my builds due to them being linked against libpangocairo which he doesn't have on FC4. We're (again) a bit stuck on that, it seems. - Themes:
I should have finished porting over my EarlyBlue theme to suiterunner, mozapps is done (I hope my Add-Ons Manager design is fine) and I updated the suite parts for changes in Classic over the last months. I probably will still go to consolidate some icons into bigger PNG files and use -moz-image-region on them to match Classic a bit more, but after that, syncing LCARStrek will be the next task, which should prove interesting as well, esp. as all the usage of -moz-border-radius should probably look better with cairo-based UI. - Local (bug)mail housekeeping:
I'm keeping one bugmail for every bug I find interesting enough to track (or find fast when talking about them) in folders below my main inbox, and those have grown to too long lists over time, so I went through all of them, cleaned out all resolved bugs, cleaned out bugs that could be resolved but weren't marked as such, and asking for status on unclear cases. This should not only have resulted in me finding the really interesting bugs easier but also in some selected bug triage in Bugzilla, leading to a few bugs disappearing from the open lists - Widget sync bugs:
After a bugmail from the resync xpfe bindings with toolkit widgets bug reminded me of this issue, I went through all dependent bugs and asked if we still need to port something from xpfe too toolkit there - the other way round doesn't make sense any more and if bugs were kept open only for that, we should just close them. - Various discussions:
Optional extension L10n (inspector, etc.), mailnews crashes, "turbo" mode removal, static builds, profile migration, SeaMonkey default icon set, untrusted X connections, VC8 build changes, ongoing FF3 UI discussions, etc.
I once again realized that it's a good thing to do those weekly wrapups to remember yourself what it all was that you spent you time on that week - with such a list, it happens that you forget what it even was that took up some of those hours...
Von KaiRo, um 00:39 | Tags: L10n, Mozilla, SeaMonkey, Status | keine Kommentare | TrackBack: 0
4. Juni 2007
Weekly Status Report, W22/2007
After a quite busy week (both work- and non-work-related) here's the report on my SeaMonkey work in week 22/2007 (May 28 - June 3):
As we have entered the brave new world of the new toolkit now, there's a real lot to do to improve how well SeaMonkey works on it, clean up what we left behind, switch over to the parts of it we're not using yet - and add features that will make SeaMonkey 2 an even better Internet suite. We'd be happy about anyone who can help us in any of those areas.
Oh, and if you can't, test nightlies and report bugs - that's the first step to being a contributor and improving your favorite software!
- SeaMonkey releases:
Those went online on May 30, once more in sync with Firefox/Gecko releases - and I'm proud we could push out new localized packages in 7 languages additional to US English right at the same time as the official release. For our old process with L10n teams creating and contributing the packages themselves, this is quite a nice number. Along with the still usable language packs from 1.1(.1), we now have SeaMonkey 1.1.2 in 15 languages total - for the first time also in Brazilian Portugese. - suiterunner switch:
It is done!
I checked in the patch for the real switch on Tuesday, after Frank had added the NSIS installer on Monday. Also fixed tinderbox configs to build the nightlies correctly. Mark and Frank have fixed a number of problems in migration and installer since, and are still working on newly reported ones.
If you run into problem with the new "2.0a1pre" builds, look for filed bugs and report new ones if your problem isn't know there.
Now Camino is the only xpfe-based app left, I hope we get them off that toolkit soon as well so we can clean up the source and finally kill that old code. - Killing wallet:
Did look again into the wallet -> satchel change, but I'm now at an interesting point where my (opt) build crashes when I focus any form field, which is not too helpful for working on that. - places history:
Last Sunday evening, I was contacted by Mano in IRC about what history implementation we're using in suiterunner, and I had to confess we're still using the xpfe one after looking into the code. He told me it would probably be easy to skip the toolkit version of it and go directly to places history. I
filed bug 382187 for that and with help from him and biesi, I got the backend to build and work within 3-4 hours (where most of the time was spent tweaking build vars and recompiling). It even automatically imports data from the old mork file into places.sqlite, so visited sites still stay displayed as visited after switching.
Unfortunately, getting the UI to work with this is harder, as our UI for history stuff is mostly RDF-based and mozstorage data doesn't get presented as RDF. And, which is probably worse, I have much too little coding experience in those areas.
I did manage to get a Firefox places history panel mostly working in my experimental build, but though the search and sort is nice there, I think I like our old one better functionality-wise (or even better a crossover of them). Unfortunately, it needs a ridiculously big number of files from browser/ to work properly, and one bug caused my error console to fill with one repeated line over and over. - Themes:
I again put some work into porting over my EarlyBlue theme to suiterunner, adding support for the (new) help viewer. When I realized this might be a good place to start using PNG files and -moz-image-region, I asked on IRC what the coordinates there exactly meant and ended up writing a layout reftest and improving its documentation for that instead of doing actual theme work for a while. Even though such things are distracting, more people than just me end up profiting from that, I hope. - Mozpad:
Took part in the second IRC meeting - I think this project is heading into a good direction, even if some hopes of participants might be set a bit too high for now. Cooperating for a better platform and more docs is a quite important mission though, and everyone should profit from that. - Various discussions:
A huge list of suiterunner post-landing discussions around regressions, cleanups and further improvements; continued Firefox3 UI discussions, SeaMonkey icon set and others.
As we have entered the brave new world of the new toolkit now, there's a real lot to do to improve how well SeaMonkey works on it, clean up what we left behind, switch over to the parts of it we're not using yet - and add features that will make SeaMonkey 2 an even better Internet suite. We'd be happy about anyone who can help us in any of those areas.
Oh, and if you can't, test nightlies and report bugs - that's the first step to being a contributor and improving your favorite software!
Von KaiRo, um 00:22 | Tags: L10n, Mozilla, SeaMonkey, Status | keine Kommentare | TrackBack: 0
1. Juni 2007
talking moon
In a discussion about automatic translation we just had in #seamonkey, I got reminded once again of the good old "talking moon" story, which is always good for a laugh.
We all know that automatic translation services don't work perfectly, but e.g. translate.google.com does a good job in many cases and you can figure out what the original text was talking about, even if you don't understand the language it was written in.
Back in 2002, mozillaZine had a story about a German magazine polling their readers about their favorite browser. Of course, the magazine wrote its original story in their language, which was German, so mozillaZine linked to the rough translation of that Google service.
The mostly English-speaking Mozilla community was quite glad about this, and people could easily figure out through this translation what the results of that poll were. But, reading one sentence there made some people wonder what it means: "The Browser from talking moon is further unquestioned on place one, ...". Now how is a talking moon related to browsers? Looking into the original article revealed what had happended: "Zwar liegt der Browser aus Redmond weiterhin unangefochten auf Platz eins, ..." - "Redmond" had been translated to "talking moon"! Well, "red-" as a prefix derived from the verb "reden" - "to talk", can surely be translated to "talking", and "Mond" is the "moon", that's also correct. Just the algorithm detecting "Redmond" as a German word was probably a bit wrong, I guess
Who would have thought that there's a talking moon right in the vicinity of Seattle?
We all know that automatic translation services don't work perfectly, but e.g. translate.google.com does a good job in many cases and you can figure out what the original text was talking about, even if you don't understand the language it was written in.
Back in 2002, mozillaZine had a story about a German magazine polling their readers about their favorite browser. Of course, the magazine wrote its original story in their language, which was German, so mozillaZine linked to the rough translation of that Google service.
The mostly English-speaking Mozilla community was quite glad about this, and people could easily figure out through this translation what the results of that poll were. But, reading one sentence there made some people wonder what it means: "The Browser from talking moon is further unquestioned on place one, ...". Now how is a talking moon related to browsers? Looking into the original article revealed what had happended: "Zwar liegt der Browser aus Redmond weiterhin unangefochten auf Platz eins, ..." - "Redmond" had been translated to "talking moon"! Well, "red-" as a prefix derived from the verb "reden" - "to talk", can surely be translated to "talking", and "Mond" is the "moon", that's also correct. Just the algorithm detecting "Redmond" as a German word was probably a bit wrong, I guess
Who would have thought that there's a talking moon right in the vicinity of Seattle?
Von KaiRo, um 14:16 | Tags: L10n, Mozilla | 2 Kommentare | TrackBack: 0