The roads I take...

KaiRo's weBlog

July 2014
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

Displaying recent entries tagged with "Firefox". Back to all recent entries

Popular tags: Mozilla, SeaMonkey, L10n, Status, Firefox

Used languages: English, German

Archives:

May 2014

April 2014

March 2014

more...

December 19th, 2013

LCARStrek and Australis

The latest version of my LCARStrek theme does not just support the latest SeaMonkey and Firefox releases. As I'm using it myself on Nightly, I'm trying to keep it working in an experimental way with that as well - and with that, a pretty huge challenge came up in the last weeks: A redesign of the Firefox interface code-named "Australis".

I blogged a month ago about how it may affect my customizations and I have dealt with those to a good degree by now, even though not yet even as drastically as I thought when writing that blog post. As always, more will follow. It took me some time until I switched over actually, as I wanted to keep using my theme, but it was naturally not compatible with such a huge redesign.

But after a lot of hours of my free time in the last few weeks, I have experimental support for Australis working in LCARStrek. The new changes living together with support for pre-Australis Firefox in the same theme require quite a few hacks to have a number of styles only apply on one side or the other. But then, I have been doing theme design for long enough (about 14 years now) that I know a few tricks and could use those - thankfully, there are a few changes in attributes set on the main toolbox, for example.

There's still a lot to be done in this area to fix some details (and I see a painting issue that is triggered in the submenus of the new main menu but is probably Linux-specific and connected to transparency used in the arrowpanel), but the main things seems to work decently now. See this screenshot:
Image No. 23159

Given that I'm using it every day, I hope starting now gives me enough experience with it that I can deliver a really decent theme when Australis finally will ship, probably with Firefox 29. :)

By KaiRo, at 23:43 | Tags: Firefox, LCARStrek, Mozilla, themes | 1 comment | TrackBack: 0

April 4th, 2013

15, 14, 13, 8, 7, 2 years ago, and the future? My Web Story

It all started on March 31, 1998. Just a few days off from 15 years ago.

Netscape open-sourced the code to its "Communicator" Internet suite, using its own long-standing internal code name as a label for that project: Mozilla.

I always liked the sub-line of a lot of the marketing material for this time - under the Mozilla star/lizard logo and a huge-font "hack", the material said "This technology could fall into the right hands". And so it did, even if that took time. You can learn a lot about that time by watching the Code Rush movie, which is available under a Creative Commons license nowadays. And our "Chief Lizard Wrangler" and project leader Mitchell Baker also summarized a lot of the following history of Mozilla in a talk that was recorded a couple of years ago.

Just about a year later, in May 1999, so 14 years ago, I filed my first bug after I had downloaded one of the early experimental builds of the Mozilla suite, building on the brand-new Gecko rendering engine. This one and most I filed back then were rendering issues with that new engine, mostly with my pretty new and primitive first personal homepage I had set up on my university account. After some experiments with CSS-based theming of the Mozilla suite, I did some playing around with exchanging strings in the UI and translating them to German, just to see how this new "XUL" stuff worked. This ended up in my first contribution contact and me providing a first completely German-language build on January 1, 2000.

A few months after that, in May, I submitted my first patch to the Mozilla project, which was a website change, actually. But only weeks later, I created a bug and patch against the actual Mozilla code - in June of 2000, 13 years ago. And it would by far not be the last one, even though my contributions the that code were small for years, a fix for a UI file here, a build fix for L10n stuff there. My main contributions stayed in doing the German localization for the suite and in general L10n-related issues. Even when Firefox came along in 2004, I helped that 1.0 release with some localization-related issues, esp. around localized snippets for its Google-based and -hosted start page - and stayed with L10n for the full suite otherwise (while Kadir would do the German Firefox L10n). I wrote a post in 2007 about how I stumbled into my Mozilla career.

As Firefox became rapidly successful and took an increasingly large standing in the project and community, I stuck with the suite as I liked a more integrated experience of email and browser - and I liked the richer feature set that the suite had to offer (Firefox did cut out a lot of functionality in the beginning to be able to found its new, leaner and more consumer-friendly UI). When in March of 2005, it became clear that the suite was going into strict maintenance mode and be abandoned by the "official" Mozilla project, I joined the team that took over maintenance and development of that suite - once again using a long-standing internal code name for that: SeaMonkey. In all that project-forming process 8 years ago, I took over a lot of the organizational roles, so that the coders in our group could focus at the actual code, and eventually was credited as "project coordinator" within the project management group we call the "SeaMonkey Council".

When I founded my own business 7 years ago, in January of 2006, I was earning money in surprising ways, and trying to lead the SeaMonkey project into the future. We were just about to release SeaMonkey 1.0 and convince the first round of naysayers that we actually could have the suite running as a community project. In the next years, we did quite some interesting and good work on that software, and a lot of people were finally realizing that "we made it" when we could release a 2.0 version that was based on the same "new" toolkit that Firefox and Thunderbird were built upon, removing a lot of old, cruft code and replacing it with newer stuff, including the now common-place add-ons system and automated updates among a ton of other things. I would end up doing a number of the major porting jobs from Firefox to SeaMonkey, including the places-based history and bookmarks systems, the download manager (including a UI that was similar to the earlier suite style), and the OpenSearch system. With the Data Manager, I even contributed a completely new and (IMHO) pretty innovative component into SeaMonkey. In those times, I think I did more coding work (in JS, mostly) than ever before, perhaps with the exception of the PHP-based CBSM community and content management platform I had done before that.

The longer I was in the SeaMonkey project, the more I realized, though, that the innovation I would like to have seen around the suite wasn't really happening - all the innovation to the suite came from porting Firefox and Thunderbird features and/or code, and that often with significant delay. Not sure if anything other than the Data Manager actually was a genuine SeaMonkey innovation, and I only came up with that when trying to finally get some innovation going, back in 2010. I was more and more unsatisfied with the lack of progress and innovation and the incredible push-back we got on the mailing list on every try to actually do something new. In October of 2010, I took a flight to Mountain View, California, to meet up with Mitchell Baker and talk about the future of SeaMonkey - and I also mentioned how I wanted to be more on the front of innovation even though I seem to not manage to get the SeaMonkey community there. Not sure if it came out of this or was in the back of her head before, in one of those conversations I had with her, she asked me if I would like to work for Mozilla and Firefox. I said that this caught me by surprise but we should definitely keep that conversation going. Just after that I met then-Mozilla-CEO John Lilly, and he asked if Mitchell had offered me a job - just to make sure. As you can imagine, that got me thinking a lot more about that, and gave me the freedom to think outside SeaMonkey for my future. I was at the liberty to think about my personal priorities in more depth, and it became clear that the winds of change were clearly blowing through my life.

After some conversations with people at Mozilla, I decided I wanted to try a job there, and Chris Hofmann proposed my working on tracking crashes and stability, so I started contracting for Mozilla on the CrashKill team in February 2011, first half-time, finally full-time. So, 2 years ago, I opened a completely new chapter in my personal web story. Tracking crash statistics for our products - Firefox desktop, Firefox from Android, and now Firefox OS - and working with our employees and community to improve stability has turned out to be a more interesting job than I expected when I started. Knowing that my work actually helps thousands or even millions of people, who have a more stable Firefox because of what I do, is a quite high award. And I'm growing into a more managerial role, which is something I really appreciate. And I'm connected to all kinds of innovation going on at Mozilla: A lot of the new features landing (like new JIT compilers for JavaScript, WebRTC, etc.) need stability testing and we're tracking the crash reports from those, Firefox for Android needed a lot of stability work to become the best mobile browser out there - and with Firefox OS, I was even involved in how the crash reporting features and user experience flow were implemented. I'm also involved in a lot of strategic meetings on what we release and when - an interesting experience by itself.

Where this all will lead me in the future? No idea. I'm interested in moving to the USA and working there at least for some time - not just because it would make my day cycle sane and having most or all my meetings within the confines of the actual work days in the region I'm living in, but also because I learned to like a lot that country has to offer, from Country Music to Football and many other things (not to mention Louisiana-style Cajun cuisine). I'm also interested in working from an office with other Mozillians for a change, and in possibly becoming even more of a manager. Of course, I'd like to help moving the Mozilla mission forward where I can, openness, innovation and opportunities on the web are something I stand behind nowadays more than ever - and Firefox OS as well as associated technologies promise to really make a huge impact on the web of the future. I'm looking forward to quite exciting times! :)

By KaiRo, at 00:13 | Tags: CrashKill, Firefox, future, history, L10n, Mozilla, SeaMonkey | 6 comments | TrackBack: 0

February 18th, 2013

LCARStrek 2.16 Brings Updated Look

Every six weeks, it's time for a new release of Firefox and SeaMonkey, and along with them, updates for my EarlyBlue and LCARStrek themes to match those Firefox and SeaMonkey releases. Of course, I personally am using them with the Nightly versions and try to keep them working with those, so they are usable with newer versions already, but only after I incorporate changes from the beta cycle, they're really fully up to date with the release versions.

That said, I kinda had my worries with the buttons of LCARStrek being not really discoverable unless you move your mouse over them, and also about the theme feeling "too orange", esp. after I reviewed some shots of LCARS screens in Star Trek series and once again saw both the shapes of buttons there, which are very discoverable, and also the amount of colors used there.

So I finally decided to something about it and added some gradual changes to LCARStrek 2.16, see e.g. the buttons, tab and scrollbars colors in those two screenshots (left is a Firefox release with 2.15, right is a Nightly with 2.16, that's why it also has an additional "Data Choices" tab):

Image No. 23116Image No. 23120

The new colors are taken directly from video screenshots of the series, so they should be pretty "true to the original". Actually, I copied the colors for buttons and default buttons directly from buttons in those screen shots. Trying to apply the same color to more button-like elements, I also converted buttons to that color and a larger border radius similar to that of the fully-rounded buttons.

While I was at it, I also took the orange off the primary toolbars and replaced it with a gray color taken from some screen that I think I saw on Voyager shots. And I always wanted to get some more of the connected horizontal and vertical borders found usually in LCARS screens, but that needs to have enough elements to construct, so it's hard to do in a theme. I found a way to get this design into the SeaMonkey sidebar though - and also used that new button color for its headers which act similarly to buttons as well. See those two screenshots from LCARStrek 2.0 (left) and now 2.16 (right) on SeaMonkey (of course, some small non-theme-reated changes in SeaMonkey UI are visible as well, as the application itself saw some development since 2.0):

Image No. 23114Image No. 23117

I hope I caught all the fine details that come along with far-reaching changes like esp. the one for the buttons, I've done a number of corrective changes along with this.
Still I had some time left and enough elements to play with to give SeaMonkey's profile switcher some real beauty in LCARS terms (you also see the different color for default buttons in there):

Image No. 23119

Unfortunately, this only applies to "Switch Profile…" from within a running SeaMonkey profile, as a theme like LCARStrek can only apply in that situation and not on the profile manager seen on application startup, where no profile and therefore no add-on or theme is loaded yet.

The new LCARStrek 2.16 version has been submitted to AMO, but is waiting for review now. Once that is granted, all users of this theme will see that updated look, and I hope they'll like it! :)

I probably will work on updating the look of more parts of this theme as time allows and I find things that should look differently.

By KaiRo, at 18:46 | Tags: Firefox, LCARStrek, Mozilla, SeaMonkey, themes | no comments | TrackBack: 0

January 17th, 2013

"Webby" browser UI on mobile? It's FirefoxOS or nothing.

I've always been a huge fan of the idea of rendering (browser) UI with the web rendering engine and write even the UI itself in a "webby" language. This idea AFAIK came up at Netscape somewhere in 1998 when the new Gecko engine for Mozilla was built. Unfortunately, HTML wasn't in a shape back then to be used for writing complex UI, and actually was quite far away from doing that 15 years ago. The basic concept looked good though, and so an intermittent technology was created to build a UI language on similar concepts, using as much of the JavaScript and CSS from HTML as possible and a markup document written in something like "HTML for UI", which ultimately became XUL ("XML UI Language").

Firefox on desktop, as well as Thunderbird, SeaMonkey, BlueGriffon and others are written using XUL for all their UI, and it's working great there. Actually, this is what even lured me into contributing to Mozilla in the first place - I saw that the UI was written in a way that I could understand back then, as someone who had played around with writing HTML, including some CSS and tiny bits of JS. I felt right at home when I saw that a button in the UI was a <button> in the markup, and that markup followed basically the same, albeit stricter (due to being XML), rules as the HTML I knew. Sure, the tag names were a bit different, but it's UI, and they were easy to understand.
Of course, another import aspect was that this UI would work on any platform you could build Gecko for, be it Windows, Mac and Linux, or even OS/2, Solaris, BeOS and others (including exotics such as AmigaOS). Of course, to fit really in with the host OSes, a number of specific tweaks were added esp. for the mainstream ones, but it works without them, just doesn't integrate as well. As soon as you can compile the Mozilla engine (which takes enough effort anyhow), you also get the full UI, which is a nice deal.
And, of course, the extension system we built over the years has largely been based upon the concepts of XUL, but I won't go into depth on this right here.

Even on mobile devices, Mozilla used that concept for a while. That was great for portability, as you had a working browser with all UI once you could get it to compile somewhere. Hell, I even ran SeaMonkey on a Nokia N810 (a 4.1" Internet tablet) - with the full UI! Of course, that UI was way too small and too overloaded for use on a touch screen, but, being XUL, it loaded and could be used if you managed to tap the correct points with the stylus.
So, for portability, including getting it to run on new devices, this XUL UI was great - and of course, some XUL UI was created that would work decently on those small touch-screen devices. I like the concepts and UI of our modern mobile Firefox browsers (both look similar, see below) better, but we had a usable, easily hackable, nicely extendable UI built with XUL. When Android became a larger deal on mobile, we could just use that and make it work on this system as well, and had something usable pretty fast.



All would have been perfect if it wasn't for one problem: If you render all your UI with the web renderer, it means that you need to load up this rendering engine in its full glory before you can paint any UI at all. And with the web becoming more powerful, what needs to be loaded for that became pretty large, and with loading from permanent storage into memory being pretty slow on those weakly powered mobile devices, it meant waiting times of multiple seconds (on some devices 15 seconds and more) - while the same "smartphone" devices were propagating more and more the concept of instantly launching apps.
Back in 1998, waiting several seconds for an application to start was common and it was OK for Netscape or Mozilla browsers to do the same, maybe display a "splash screen" while the user was waiting for that. Now, in the fast-living world of smart phones, the usage patterns as well as the expectations have changed enough that this waiting time is what instantly (no pun intended) your app is being shot down by users for that, and nobody but your strong supporters (which Mozilla fortunately has) will use it. Things needed to change. And they did.

Basically, there's two ways Mozilla had to make the browser UI start fast: Either write it in a way that it used the "native" toolkit of the hosting OS and not depend on the rendering engine to launch (so that can be loaded lazily in the background), or to have that "native" toolkit of the system be our rendering engine already!
Well, as funny as it sounds, we ended up doing both!

On Android, we did the former, write a "native" (i.e. Java) Android app, which is very fast to be displayed as all the Java/Dalvik framework is already loaded, and load Gecko in the background once the UI is up - while the user interacts with the UI to e.g. enter a site to call up, we have enough time for that so Gecko is ready to display the actual websites once it's needed.
Unfortunately, that "native" UI is not "webby" any more, Java is very different from HTML/XUL/CSS - though AFAIK we are using quite a bit of JS to driver things, so there's at least some pieces left that someone like me would still understand. Oh, and as my job nowadays is stability, Java exceptions crash the browser, while we don't have that problem with JavaScript, and the amount of crash reports rose up significantly with that UI rewrite (the team is doing a great job on fixing them, though, and we've become actually pretty good in stability there nowadays). To be fair, we also added support for the Flash plugin, which seems to be causing by far the most stability problems with this version. All that said, this new Firefox for Android is really fast, esp. on startup, and works incredibly well, it's getting cheered as the best browser for Android by many - compare that with the quite bad reputation that the XUL-based version had and you need to admit this was a good change - even if you happen to be me. ;-)

Well, and then there's this thing that I mentioned with the "native" toolkit of the system be our rendering engine, and then you can use web technologies for the mobile browser UI, right? That's what we're doing in Firefox OS!
On that system, the whole UI of everything you see on screen is rendered by Gecko. And not just that, Mozilla took the final step and didn't even do it with XUL, but used plain HTML this time, so that everything running on this system is made of pure web apps (sure, with some new WebAPIs thrown in). All that said, there's some things in UI design where HTML still needs to catch up to XUL, but those mobile apps are working really nicely already (still, mobile has less UI with less complexity and less need for cross-app consistency, so the particular weak spots I'm thinking of don't come to light that much).
What it comes down to for what I want to say here is that in Firefox OS, we indeed have a browser on mobile which has its UI completely rendered by the web rendering engine (again) - but this time, not done in XUL but in plain HTML!

And it looks pretty good, compare our "native" Android UI to our Firefox OS UI and you'll see that there are some similarities:



And, go ahead and try yourself, e.g. in the simulator, it even pretty much works the same!

Time to come to the reason I actually brought this up today: You might ask what happened with the XUL-based UI for mobile, which I said was nicely portable to different devices (and older builds of which I still have in use on my "real-Linux-powered" N900 and N9 phones)? Well, it's dead and gone. And even its source has been removed today from our mozilla-central repository. So, if you want a browser with a "webby" UI on mobile, your only chance from now on is Firefox OS. (That is, if nobody comes along and resurrects a XUL UI for alternative mobile platforms in some external project.)

All that said, I'm excited that the original idea of rendering the UI with the browser engine survives on mobile - and actually thrives and is being hugely extended to powering the whole system, in Firefox OS! :)

By KaiRo, at 17:23 | Tags: Android, Firefox, FirefoxOS, mobile, Mozilla, N810, N9, N900 | 1 comment | TrackBack: 0

May 23rd, 2012

Jetzt testen: Firefox Beta für Android-Telefone

Eines der größten Projekte, an denen Mozilla in den letzten Monaten intern gearbeitet hat, ist der völlig umgeschriebene Firefox für Android - nachdem frühere Versionen besonders auf Telefonen eher als langsam beim Start und großzügig im Speicherverbrauch auffielen, sind diese neuen Versionen jetzt extrem schnell beim Start, deutlich schlanker im Speicher, und unterstützen das Flash-Plugin.

Und jetzt sind sie als Beta zum Download verfügbar!

Wenn du Zugang zum Google Play Store hast, dann einfach von der offiziellen Beta-Download-Seite (oder direkt aus dem Store) installieren. Eine Bewertung im Store würde uns auch freuen, da viele der bisherigen Bewertungen von der alten, eher klobigen und langsamen Version kommen.

Wenn du keinen Google-Account verbunden hast oder aus anderen Gründen den Store nicht nutzt, die aktuellste Beta-Version vom FTP-Server holen, derzeit ist das 14.0b2 (aber ca. jede Woche kommt eine aktualisierte mit großteils Stabilitäts-Fixes).

Die neue Beta ist auf Telefone mit ARMv7-Prozessoren ausgerichtet, an einer Adaptierung für Tablets und an ARMv6-Unterstützung arbeiten wir noch.

Abstürze und Bugs bitte nach Möglichkeit an uns melden, mit dem eingebauten Crash-Reporter bzw. über Bugzilla.

Danke! :)

By KaiRo, at 15:57 | Tags: Android, Fennec, Firefox, Mozilla | no comments | TrackBack: 0

March 14th, 2012

de: Nützliche Ressourcen für Mozilla-Übersetzer

Auf meinen Aufruf für neue Übersetzer haben sich ein paar Leute gemeldet, auch "alte Bekannte" haben gemeint, sie würden sich dafür interessieren, an der deutschen Thunderbird-, Firefox- oder SeaMonkey-Übersetzung mitzuhelfen.

Sebastian "Archeopteryx" hat im Thunderbird-Forum einen Beitrag mit wichtigen Ressourcen gepostet, ich will hier auf dem aufbauen und einen kleinen Überblick geben (teilweise 1:1 übernommen, teilweise von mir etwas mehr ausgeführt):

Wichtigste Regel:

Es gibt einige Werkzeuge, die man erste kennen lernen muss. Keine Angst, wir haben alle Fehler gemacht, nur daraus lernt man. Wir "anderen" beißen nicht, sondern helfen gerne!

Anfangs muss man eventuell etwas Software installieren, aber davon sollte man sich nicht abschrecken lassen, man kann auch jederzeit um Hilfe fragen oder falls etwas nicht verständlich ist.
  • Bugzilla ist die Seite, wo die meisten Entwicklungsentscheidungen und Fehlerberichte verwaltet werden.
    Berichte über die deutsche Übersetzung gehören dort in das "Produkt" "Mozilla Localizations" und dessen "Komponente" "de / German".
  • Localization Quick Start Guide - Einführung in die Mozilla-Übersetzungsarbeit mit vielen Links und Erklärungen verschiedener Werkzeuge und Begriffe.
    Da auch Webseiten-Übersetzungen usw. angesprochen werden, braucht man nicht alles davon, um ein Produkt wie Firefox, Thunderbird oder SeaMonkey zu übersetzen.
  • L10n Dashboard: Zeigt den Stand der Lokalisierung der verschiedenen Produkte an.
    Zeilen mit roter Farbe haben fehlende Texte, mit gelber nur (ev.) überflüssige, mit grüner haben sie alles übersetzt. Der "C"-Link in jeder Zeile zeigt an, welche "Strings", also Textstücke, wirklich fehlen oder überflüssig sind, sowie ev. Fehler und Warnungen.
  • Localization with Mercurial: Beschreibt, wie man die Texte für die Übersetzung runterlädt.
    Hier geht es um jenen Kern, der Leuten ohne Programmiererfahrung meist mal nicht ganz geheuer ist. Man gewöhnt sich aber dran und lernt Dinge, die man an vielen anderen Stellen auch brauchen kann (die meisten Open-Source-Projekte laufen auf ähnlicher Basis dazu). Wir arbeiten in der deutschen Übersetzung meist direkt mit den Textdateien, was manchmal komisch anmutet, aber sehr gut funktioniert.
  • Die "de"-Repositories: Central, Aurora, Beta
    Hier liegen die eigentlichen Übersetzungen, die 3 verschiedenen Repositories entsprechen den Firefox-Kanälen Nightly, Aurora und Beta (es gibt ein viertes für Release, das ist für uns Übersetzer aber belanglos, denn dort werden keine Änderungen mehr angenommen) - bei Thunderbird und SeaMonkey mögen die nicht ganz diese Namen haben, gelten aber äqulivalent, alle Produkte sind im gleichen Repository. Alle 6 Wochen, am Release-Tag, wird alles aus Aurora nach Beta übernommen, und für die englische Orginialversion auch Central nach Aurora. Wir versuchen auch für de Central und Aurora immer wieder zu synchronisieren, aber das passiert meist erst etwas später, für die meisten Übersetzer ist das aber eher wenig relevant. Die Hauptarbeit zur Übersetzung sollte auf Aurora passieren, denn da bleibt der Vergleich zu den "originalen" immer 6 Wochen lang konstant - wenn wir das aber übersetzt haben, versuchen wir, auch für Central mit deutschen Übersetzungen nachzuziehen, aber da kann sich ständig etwas ändern.
  • Patching a Localization und Creating a patch: Wie man die Änderungen in einer Datei speichert
    Wenn man (wie jeder, der mal "frisch" ins Team reinkommt), die Berechtigungen nicht hat, um direkt in Mercurial Änderungen einzuspielen, muss man diese Patch-Dateien erstellen und dann an einen "Bug" in Bugzilla als Attachment hochladen sowie einen, der schon im Team ist, um "Review" fragen (siehe Getting Reviews, von zweiterem Artikel verlinkt). Der zweitere Artikel stammt aus einer Serie, die für Änderungen am Programmcode von Firefox, Thunderbird und SeaMonkey auch gilt, für Übersetzungen läuft manches ähnlich, aber oft lockerer (kompilieren und testen ist nicht unbedingt vorher notwendig, und ähnliches).
  • L10n-checks und compare-locales: Zwei Werkzeuge (Skripts), um die Übersetzung auf Fehler zu übeprüfen (z.B. zweimal den gleichen Buchstaben für den Zugriff auf verschiedene Menüeinträge)
    Braucht man nicht unbedingt verwenden, aber sich hilfreich, um Probleme zu finden. Compare-locales ist exakt jenes Skript, das auch hinter dem "C"-Link im L10n-Dashboard (siehe oben) liegt, bringt also gegenüber dem nichts neues, man kann es aber auch gleich lokal verwenden, wenn man will, um am eigenen Computer zu kontrollieren, dass man "alles erwischt" hat.

An dieser Stelle möchte ich auch auf den IRC-Chat verweisen: In Channel #mozilla.de (am Server irc.mozilla.org) sind einige deutsche Community-Mitglieder, inklusive Übersetzern wie Archeopteryx, Topal, KaiRo (ich), chewey und andere sehr oft online und helfen bei Fragen zu diesen Themen gern weiter, so weit wir können (allerdings, bitte Geduld haben, wir haben das oft neben der Arbeit offen und sehen nicht ständig rein und können nicht immer antworten).

Und jeden Mittwoch um 21 Uhr ist in #deMeeting ein Treffen der ganzen deutschen Übersetzer-Gemeinschaft, in dem wir durchbesprechen, was es in der jeweiligen Woche an Neuigkeiten gibt bzw. wo wir uns koordinieren müssen. Wir freuen uns über interessierte Teilnehmer!

Damit hoffe ich, einige interessante Hinweise geboten zu haben und hoffe, dass einige "neue" Leute uns in Zukunft bei den Übersetzungen helfen! :)

By KaiRo, at 22:20 | Tags: de, Firefox, L10n, Mozilla, SeaMonkey, Thunderbird | 1 comment | TrackBack: 2

March 12th, 2012

de: Die nächste Generation?

Alex Ihrig, unser langzeitiger deutscher Thunderbird-Übersetzer, hat vor kurzem bekannt gegeben, dass wir einen neuen "Maintainer" für Thunderbird brauchen, also jemanden, der die Übersetzung übernimmt. Alex hat 9 Jahre lang gute Arbeit geleistet, der deutsche Thunderbird ist ein wichtiger Beitrag für Mozilla, und Alex hat auch in den gemeinsamen Bereichen einiges übersetzt, was uns alles geholfen hat. Ihm gebührt großer Dank dafür.

Trotzdem heißt die Nachricht, dass er das nicht weiter machen wird, dass wir neue Leute für die Thunderbird-Übersetzung suchen. Aber nicht nur dafür: Kadir hat für die Firefox-Übersetzung etwas wenig Zeit übrig, seit er hauptamtlich und in anderen Bereichen für Mozilla arbeitet, und auch meine Zeit für die SeaMonkey-Übersetzung ist in letzter Zeit extrem beschränkt. Wir wären beide froh, bei diesen Produkten auch Unterstützung von anderen zu bekommen, sodass wir in Zukunft die Arbeit nach Möglichkeit auch mal anderen Community-Mitgliedern übergeben können.

Wir haben diesen Arbeitsbereich viel Erfahrung gesammelt, es ist an der Zeit, die an andere weiter zu geben und selbst neue Projekte zu suchen, die wir aufarbeiten können. Man sollte nicht zu lange in einer Routine stecken, andere können sicher wieder weniger abgestumpft daran arbeiten und daher die Qualität hoffentlich auch weiter verbessern.

Also, wenn ihr das lest und Interesse daran, habt, die deutschsprachigen Mozilla-Produkte vorwärts zu bringen, wir freuen uns über Hilfe!
Die nötigen Qualifikationen sind nicht allzu schwierig - gute Deutschkenntnisse, keine Scheu, auch mal über Wortwahl zu diskutieren und Rechtschreibregeln nachzusehen, und nach Möglichkeit etwas Erfahrung mit Reintexteditoren (aber die kann man sich auch direkt am Beispiel aneignen). Und keine Angst, wir sind ja da, um euch zu helfen und in die Materie einzuführen.

Übersetzungsarbeit ist eine gute Chance, um im Mozilla-Projekt mitzuhelfen, auch wenn man vielleicht keine Ahnung vom Programmieren hat, und in diese großartige Gemeinschaft "hineinzuwachsen" - mach mit!

By KaiRo, at 02:01 | Tags: de, Firefox, L10n, Mozilla, SeaMonkey, Thunderbird | 3 comments | TrackBack: 1

January 4th, 2012

The Winds Of Change

Quote:
The winds of change continue blowing
And they just carry me away. -- Albert Hammond

Like many others, I've been thinking quite a bit these days about what went on last year and what will or might come up in 2012. (And I figure I should bring in a bit more from my overall personality into my future blog posts and mention or quote songs I have in my mind on a particular topic, so I'll start with that here).

One topic that has been with me throughout the year and will probably also continue to be with me is change. A lot of it started with my visit to Mozilla headquarters in Mountain View, CA, in October 2010, actually - I posted about my changing personal priorities back then. And I still remember driving my rental car up to Lake Tahoe, thinking about all those things and listening to the then-just-released Zac Brown Band album "You Get What You Give" and in particular the song "Let It Go", whose lyrics gave me the right mindset for what was I was going through and what 2011 would bring: "Save your strength for things that you can change, forget the ones you can't, you gotta let it go."

Following that, I started 2011 by transferring the vast majority of my responsibilities in SeaMonkey over to other people (we have built up a great team there over the last years, including awesome people like Callek, InvisibleSmiley, etc. - kudos to them to be able to take all that over in their free time) and get the ball rolling on making the project even more sustainable in the future (I hope we'll have news for you on that soon).

Instead, I followed another piece of advice from this song - "When the pony he comes ridin' by, you better sit your sweet ass on it" - and started contracting for Mozilla on the CrashKill team in February, first half-time, finally full-time. With that, my focus changed from SeaMonkey to Firefox and from project management to crash analysis.

For one thing, I ended up growing into that role better than I imagined at first, finding crash analysis more interesting than expected, for the other, this change ended up having more influence on my life than I had imagined. With the need to communicate a lot with different people in this job, from the CrashKill team via the Socorro team that works on the crash-stats server and which I'm coordinating with to various devs, engineering managers or release managers as the need arises in crash analysis.
Unfortunately with me being a "remotie" all communication needs to be online (or via phone) and is stripped down to the essentials needed for the job. Being a very social person, I'm missing the additional nuances that face-to-face communication would bring to the table, and more need for communication as part of the job makes that more obvious to me.
Then, the whole CrashKill team is based in Mountain View, the vast majority of the Socorro team spread across the US, and most engineering or release managers also based in Northern America, so most of that communication as well as all my meetings is happening during US working hours, which from my point of view in Europe is in the evening to night hours, which requires my work time to be mostly at the end of the day. I have been doing work at late hours in the years before, but there was not as much requirement of that before, while now I have to make at least the meetings, and should be available for more conversation on IRC at those times. Making evening appointments becomes quite difficult in that light.
And speaking of requirements, while I could basically completely make my own schedule before, I now should bring in 8 hours of work per day, and with doing that at the end of every day, I need to make all shopping and other private stuff in the afternoon, leaving me all day with "I still have a full work day to deliver today" in mind - until I achieve that and fall into bed. This causes its own share of subconscious stress.
And I'm doing all the work from my own private apartment, not getting out unless I go shopping or take my usual Monday and Tuesday evening off for some Karaoke.
So, I learned that working from home and remotely has its downsides, esp. for the kind of job I'm in there. This is one area I need to work on a lot in 2012 and find solutions that will be connected with another share of change I'm sure.

But not only my role and work life have changed - Mozilla went in a direction I had often spoken for and has changed to a rapid release cycle and started planning for that shortly after I started contracting. I commented in the planning phase and tried to help shape this process and always was convinced it was a good idea, even though we hit more road bumps than expected. I was heavily involved in coordinating to get crash-stats support rapid releases usefully and also laid out publicly how the new process can improve stability.
Mozilla also has revamped its mobile efforts completely - both with a completely new "native UI" version of Firefox for Android, which is in Aurora testing now and with a completely open mobile stack in the form of Boot To Gecko (B2G), a complete "operating system" based on the browser and open web standards (requiring new WebAPIs), which is also coming together piece by piece now.
And next to those changes, we're also working on changing how identity and logins work on the web and changing the current "silo"ed app store model by bringing open concepts for web apps and markets into the fold that easily allow decentralization and users really "owning" their apps.
In the middle of all that, Mozilla has restructured a bit, brought some previously split-off groups back into the common Mozilla fold, hired a lot of new people, lost (as employees but not as community members) a few high-profile ones who were looking for new challenges, worked on the MPL 2.0, founded exciting new initiatives like WebFWD and went stronger on marketing that we are a non-profit - clearly a lot of change happening everywhere, with the mission and the Manifesto standing unchanged and as clear as ever over all of it, though.

All this makes it clear that a lot of change has come in 2011, both to me and Mozilla, and that it's still only the seed for what's to come in the year(s) ahead. The winds of change are still blowing, and I'm excited for what they propel and which interesting experiences they drag in for all of us.

Quote:
The future's in the air
I can feel it everywhere
Blowing with the wind
Of change. -- Klaus Meine / The Scorpions

By KaiRo, at 21:26 | Tags: CrashKill, Firefox, future, history, Mozilla, SeaMonkey | 1 comment | TrackBack: 0

November 26th, 2011

Firefox 7.0.1 updates to 8.0.1, but 8.0 doesn't?

I found the following question being raised on German newsgroups, but I guess there's more people interested in this:
Quote:
I found out that on one of my computers Firefox 7.0.1 has been updated to 8.0.1, but on another one there's no update for 8.0, not even when I manually trigger it via "About Firefox". On the Mozilla website, 8.0.1 is also being offered as a download. What's going on there?

Short version:
If you're not using a Mac, switching from 8.0 to 8.0.1 doesn't really help, so we only offer that update for Macs, on all other, 8.0 is just as good, as long as it runs.

Long version:
8.0.1 fixes exactly two things over 8.0:
1) A crash with the newest version of Apple's Java plugin for Mac (the bug is in that new Java version from Apple, but we can work around it with a small patch on our side).
2) On Windows, we're blocking old versions of Roboform that cause 8.0 to crash on startup, we only allow newer versions that don't cause that crash. In case 8.0 is already running, i.e not crashing when starting Firefox, this update doesn't really help anything, and we're avoiding to send people an update when they have no benefit of it, so we don't disturb them. If 8.0 is installed but crashing on startup (because of old Roboform), we don't even get to where an update would be installed. The only thing that helps those people is to manually download 8.0.1 and install it freshly - and actually download a new Roboform version that works with it.
Because of that, 8.0.1 is being offered to all versions (starting with 4.0, incl: 8.0) on Mac OS, but on Windows or Linux only for 4.0-7.0.1, because it doesn't offer any benefit to all the others.

So, in the end, if you're installing a fresh version, 8.0.1 is the right choice, but you don't need to install an update where it's not being offered automatically.

By KaiRo, at 17:10 | Tags: CrashKill, Firefox, Mozilla, release | 5 comments | TrackBack: 0

Firefox 7.0.1 aktualisiert auf 8.0.1, aber 8.0 nicht?

Ich habe folgende Frage in den Newsgroups gefunden, ich denke, es gibt mehr Leute, die das interessiert:
Quote:
Mir ist aufgefallen, dass auf einem meiner Rechner Firefox 7.0.1 auf 8.0.1 aktualisiert wurde, aber auf einem anderen wird für 8.0 kein Update angeboten, auch nicht auf manualles Anstoßen in "Über Firefox". Auf der Mozilla-Website steht auch 8.0.1 zum Download. Was ist da los?

Kurzfassung:
Wenn du keinen Mac verwendest, bringt die Umstellung von 8.0 auf 8.0.1 nicht wirklich etwas, daher liefern wir das Update nur für Mac aus, auf anderen Systemen ist 8.0 genauso gut, wenn er läuft.

Lange Fassung:
8.0.1 behebt gegenüber 8.0 genau zwei Dinge:
1) Einen Crash mit der neuesten Version von Apple's Java-Plugin für Mac. (Der Bug liegt in dieser Java-Version von Apple, aber wird können ihn durch einen kleinen Patch auf unserer Seite umgehen.)
2) Auf Windows werden alte Versionen von Roboform blockiert, die 8.0 zum beim Start Absturz bringen, nur neue Versionen ohne diesem Absturz werden zugelassen. Wenn 8.0 schon läuft, also nicht beim Start abstürzt, dann bringt dieses Update nicht wirklich etwas, und Leute ein Update zu schicken, das nichts bringt, ist eher kontraproduktiv, wir sollten sie damit nicht belästigen. Wenn 8.0 drauf ist und beim Start abstürzt, kommt er nicht mal bis zur Installation eines Updates.
Daher wird 8.0.1 zwar für alle Versionen (ab 4.0, inkl. 8.0) am Mac angeboten, aber auf Windows oder Linux nur für 4.0-7.0.1, weil es allen anderen gegenüber 8.0 keinen Vorteil gibt.

Kurzum: Wenn man jetzt eine Version neu installiert, ist 8.0.1 die richtige Wahl, aber ein Update braucht man nicht zu installieren, wenn es nicht von selbst angeboten wird.

By KaiRo, at 16:54 | Tags: CrashKill, Firefox, Mozilla, release | no comments | TrackBack: 1

Feeds: RSS/Atom