main mozilla tech

Reducing MozL10n+Gaia technical debt in Firefox OS 2.1 cycle

Firefox OS is becoming a more mature platform, and one of the components that is maturing with it is the mozL10n library.

In 2.0 cycle, which is already feature complete, we introduced the codebase based on the L20n project.

The 2.1 cycle we’re currently in is a major API cleanup effort. We’re reviewing how Gaia apps use mozL10n, migrating them to the new API and minimizing the code complexity.

Simplifying the code responsible for localizability of Firefox OS is crucial for our ability to maintain and bring new features to the platform.

There are four major areas we’re working on:

  • mozL10n.translate – with introduction of Mutation Observer, we want to phase out manual DOM translation calls.
  • mozL10n.localize – this function is extremely hard to maintain and does enough “magic” to confuse devs.
  • mozL10n.get – manual l10n gets are the biggest cause of bugs and regressions in our code. They are synchronous, not retranslatable and badly misused
  • mock_l10n – many apps still use custom MockL10n class in tests, some even use real MozL10n code in tests. This makes testing harder to maintain and develop new l10n features.

We’re working on all four areas and would love to get your help.

No matter if you are a Gaia app owner, or if you’ve never wrote a patch for Gaia. If you know JavaScript, you can help us!

All of those bugs have instructions on how to start fixing, and I will be happy to mentor you.

We have time until October 13th. Let’s get Gaia ready for the next generation features we want to introduce soon! ­čÖé

main mozilla tech

Localization framework changes in Firefox OS 2.0 and plans for 2.1

On Monday we branched Firefox OS 2.0 which is the first branch to contain a new localization library that has been developed by my team.

What landed for 2.0

Library landing and reactions

The library itself landed exactly two months ago. In order to avoid any potential regressions, we’ve put a lot of work to ensure that it matches the behavior of the old code that it replaced. I believe we can now claim a success, because with two months of baking on master we didn’t get any serious regressions that would require us to change anything in our code.

The new library comes with a lot of unit tests and is stricter than the old code, so we had to fix a couple of small bugs where code has been passing an object instead of a string to our API and one related to one test failing on old machine with too little memory. That’s been simple to catch and fix.

We also got a few requests to improve the console log output and error output that the library produces in order to simplify developers work.

New features


The major new thing that Stas completed in this cycle is the support for pseudo-locales. While this could be done with the old code, it was significantly easier with the new code thanks to some architectural decisions like separation of buildtime and runtime code.

Pseudo-locales allow developers to evaluate their UI’s localizability against an artificially generated english-like locale to catch any hardcoded strings. It also generates right-to-left locale for testing purposes. Before that, we’ve been relying on often outdated localizations that we kept with our source code. Now we can always test against fully generated pseudo localization.

mozL10n.once wrapper

Another new feature is the introduction of mozL10n.once wrapper. We identified that a lot of Gaia apps are waiting for localization to be ready before they initialize themselves. That makes sense since a lot of those apps want to work with UI and localized strings, but the challenge in asynchronous world is that you never know if your code has been fired after or before mozL10n is ready.

Because of that, simply setting an event listener and waiting for window.onlocalized event is not enough (what if it already has fired before your code was launched?). Developers were using mozL10n.ready wrapper, but the problem with that is that is has been designed to re-fire on reach retranslation which meant that your init code has been fired every time user changed language. That’s not an intended behavior, but admittedly a rare one. What’s worse is that we retained all the init code in memory.

Now, with mozL10n.once we can safely initialize code when l10n resources are available and free the memory right after that.

Uses of l10n API

On top of adding new features, we’ve been mostly busy investigating and improving how the default Firefox OS apps interact with localization API. That led to multiple design decisions including introduction of the described above mozL10n.once.

Once we got the new wrapper, we started analyzing bootstrapping code of each and every Gaia app and updating it to use the proper L10n API. Twenty two fixed bugs later, we’re done!

It’s incredible how much we were able to accomplish in just two short months. We feel much better right now about the bootstrap process and we have a clear picture on what we want to do next.

Use new navigator.languages API

Thank’s to Mounir’s work on navigator.languages API and implementation we were able to remove the only Mozilla specific API in mozL10n. That means that mozL10n should work in any modern browser now!

What we’re working on for 2.1

2.1 will be as ambitious for us as 2.0 was. The hashtag of the work is still #cleanup, but now it’s much more about modifying our API so that it’s more transparent to developers and requires less manual code in their apps.

entity.attributes become node attributes

First thing we were able to land is the transition away from assigning l10n entity attributes as node properties. We cleaned up the hacks that have been used and switched to entity attributes as node attributes.

DOM overlays

Next, we have one leftover from the previous change and that is an infamous innerHTML. We currently don’t have any clear way to inject localizable DOMFragment in Gaia. Fortunately, we have one that fits perfectly in L20n. It’s called DOM Overlays, and we’re working on getting them into mozL10n. That will allow us to further secure L10n API and remove any innerHTML calls.

Mutation Observers

Majority of localizability code in Gaia apps is related to localization of DOM nodes. With Mutation Observers we will be able to significantly reduce the amount of manual calls to mozL10n API and make majority of calls be just about settings data-l10n-id attribute with Mutation Observers doing the rest.

Not only will it reduce the use cases of mozL10n.translate and mozL10n.localize, but I expect to be able to cut by over 50% the number of manual mozL10n.get calls and manual operations that are currently used to set the result of that call into the node.

Mutation Observers will simplify Gaia code, reduce the amount of bugs related to language switching and get us closer to runtime l10n API that we want to offer for Gecko.


There are still some interesting edge cases around how code boostrapping relies on particular pieces of environment. Does your code need DOM to be interactive? Does it need l10n resources to be loaded? Or maybe you need DOM to be localized? All those events happen asynchronously and we currently do not have a clean way to guard against any combination of those that your init code may require.

We’re working on a bootstrapping wrapper that will allow app developers to simply define which pieces of environment should their initialization be blocked by.

That will further secure the app boostrapping process and limit the risk of condition races.


One part of the bootstrap puzzle is how we fire event when certain bootstrap things happen. Right now we fire window.onlocalized event that means that mozL10n resources have been loaded, but doesn’t tell us anything about if document’s DOM has been localized (and is ready to be displayed).

With the work on the new event, we’ll be able to remove the global one, and settle on triggering on event on document and one on mozL10n object. Did I tell you that we’re still cleaning up? ­čÖé

Move mozL10n to document

We originally placed mozL10n object as a property on navigator object. Because our API is transitioning to be per-document, it becomes an inconsistency and an obstacle to keep mozL10n API on navigator object. It hardly fits the world with iframes, ShadowDOM and HTML Templates. We’re going to move it to document.mozL10n.

Remove inline l10n

One of the built time optimizations that we have in Gaia is called inline l10n. We store some portion of the l10n resources within each HTML file in order to localize the UI before it is displayed. It’s not very scalable, costs us memory and performance, but historically helped us prevent flashes of untranslated content. We hope to be able to remove this optimization in this cycle which will significantly simplify our internal code and give us some small memory and performance wins.

Is this L20n yet?

While we introduce L20n concepts into mozL10n, we’re still pretty far from being able to say that we support L20n API in Gaia. There’s a lot of work to do and it’s going to be a challenging work as we port L20n concepts to Gaia, and merge lessons we learned while working on Gaia into L20n spec and implementation. What we hope to end up with is a single codebase used in Gaia and offered to web developers.

It’s an exciting journey and I’m so happy to make Firefox OS’s localizability the most modern among all OSes!

main mozilla po polsku tech

Wymy┼Ťlanie Sieci na nowo

poni┼╝szy post jest t┼éumaczeniem postu Mitchell Baker “Reinventing the Web

W zaledwie 20 lat Sie─ç sta┼éa si─Ö jedn─ů z najwa┼╝niejszych infrastruktur wsp├│┼éczesnego ┼╝ycia. Dzi┼Ť dostrzegamy szans─Ö, by Sie─ç, przez kolejny skok, sta┼éa si─Ö jeszcze bardziej u┼╝yteczna, przyjemniejsza, by otworzy┼éa nowe szanse przed biznesem i mog┼éa lepiej s┼éu┼╝y─ç celom spo┼éecznym.

Wyobra┼║ sobie bogactwo i wolno┼Ťci Sieci p┼éynnie zintegrowane w urz─ůdzeniach mobilnych. Wyobra┼║ sobie, ┼╝e to wszystko dzia┼éa i to dzia┼éa niezale┼╝nie od tego czy u┼╝ywasz aplikacji do specjalnego celu czy przegl─ůdarki by odkry─ç swoj─ů w┼éasn─ů drog─Ö.

Wyobra┼║ sobie, ┼╝e pobierasz aplikacj─Ö i ona dzia┼éa na wielu urz─ůdzeniach, niezale┼╝nie od jakich producent├│w pochodz─ů. Wyobra┼║ sobie, ┼╝e mo┼╝esz wybra─ç czy chcesz kontaktowa─ç si─Ö z dostawc─ů aplikacji bezpo┼Ťrednio czy przez Apple, Google albo Microsoft.

Wyobra┼║ sobie, ┼╝e masz wyb├│r tego kto kontroluje Twoj─ů to┼╝samo┼Ť─ç. Logujesz si─Ö na stron─Ö i wszystko co zrobi┼ée┼Ť w sieci staje si─Ö dost─Öpne dla ┼Ťwiata? A mo┼╝e logujesz si─Ö i tylko to co Ty uznasz za publiczne staje si─Ö dost─Öpne dla ┼Ťwiata?

Wyobra┼║ sobie poczucie bezpiecze┼ästwa kiedy jeste┼Ť online – kto ci─Ö ┼Ťledzi, kto sprzedaje informacje o tobie, kto ci─Ö chroni i jak mo┼╝esz ochroni─ç siebie sam.

Wyobra┼║ sobie, ┼╝e rozumiesz Sie─ç, poczucie kompetencji by robi─ç rzeczy, by zmienia─ç te kt├│re istniej─ů i tworzy─ç kolejne, kt├│re spe┼éniaj─ů twoje potrzeby. Wyobra┼║ sobie, ┼╝e uczenie si─Ö Sieci jest fajne i wykracza poza ┼Ťwiat programist├│w obejmuj─ůc zwyk┼éych ludzi.

Mozilla tworzy ten ┼Ťwiat. Mamy jego wizj─Ö, architektur─Ö, technologie i plany produkt├│w. Te produkty tworzymy w┼éa┼Ťnie teraz. Mamy zasoby finansowe, by zrealizowa─ç te cele. To ekscytuj─ůcy i bardzo produktywny okres. Sp├│jrz w nasz raport roczny, aby zobaczy─ç co zrobili┼Ťmy i co jest na horyzoncie. Do┼é─ůcz do nas, by razem budowa─ç ten ┼Ťwiat.

main mozilla tech

L20n command-line toolchain

While we do hope that most of the work around l20n installations will have visual, GUI web tools, we also recognize that it’s important to provide simple, robust command-line tools that will cover the entire workflow.

For the l20n workflow to happen, we want to have a complete command-line toolchain that will automate common tasks required to operate and maintain localizations.

Behind this toolchain we provide a powerful API that localization and release tools will use, but the first consumer of those API will be the command-line based environment for l20n.

For this toolchain, we have three personas in mind:

  • a localizer
  • release driver
  • developer


Localizer should be able to start a new localization, stay informed about the status/completeness of his localization and have easy way to learn about updates. On top of that, he should be aided in navigating through the changes like new, modified or removed entities, get help in maintaining his localization between releases and work with the build team on marking which localization version is ready to be shipped.

Initially we want to provide four elements that will enable this:

  • on demand activated shell prompt customization that will provide contextual information while the localizer navigates around the l10n project
  • bootstrap command that will help initialize a new localization sandbox for a project
  • set of diagnosis tools like validator, completness check and localization status, all of which will analyze given localization and provide detailed information or what remains for the localization to be completed
  • an automated update tool that will help localizer keep the localization structure in shape, helping adding new strings, removing obsolete and provide information on the updated ones

The latter two concepts are powerful, and we have to be very careful when we design them. Each operation may harm the system, since we can easily loose the ability to review changes made by localizers in VCS history view if we apply changes that the localizer did not work on, or we can hide from the localizer the contextual information by removing entities that became obsolete, but their value has been reused in a new entity added just next to the old one.

All this kind of stuff has to be taken into account and we want to aim for a balance between simplifying day-to-day localization work, and maintaining VCS friendliness and sense of control that a localizer must have over his localization project.

Release driver

As with a localizer, we want to provide methods to automate common tasks, like selecting locales for a release, learning about status and progress of multiple locales at once, accepting new locales from localizers and batch updating locales with changes.

In order to achieve that, we want to provide:

  • a custom shell prompt that will aid release driver while he navigates between localization projects
  • scripts that will make it easy to analyze the status of localizations and validate them
  • tools that will allow release driver to maintain the list of locales and their version, to be released with a given version of the product
  • a script that will take a small “l10n patch” like a number of new entities, or value changes, and apply it across multiple locales


For the developer, we want to make sure that it’s easy to make his code localizable and maintain it that way.

This means that we want to make it easy to add new entities manually and verify that they work with tests, that we can extract entities from code where possible (like – XML), and it’s easy to spot hardcoded strings.

For this, we plan to provide the following tools:

  • a validator that outputs unit-test readable outcome statuses, so that unit-tests can be written against localizable code
  • an extractor for simple extracting and maintenance. The extractor should be able to help developer clean l10n files by removing strings that are no longer used in the code.
  • a tool that generates dummy test locale which enables the developer to visually find hardcoded strings

We want to make the whole environment project independent by allowing each project to define how process like bootstrapping, extracting should exactly work, where the l10n resources are stored and others.

The first set of tools will be aimed to help localizers, then we’ll work on tools for release managers and developers will come after that.

We’re in the process of writing API’s and designing the syntax for those commands. You can find the document with a proposal and the current source code here.

main mozilla tech

L20n – what to add before 1.0

As I mentioned in my last blog post, we’re narrowing down the list of features that we’re willing to consider for inclusion into L20n 1.0 prior to its freeze and release.

Here’s the list:

Name Driver Target Milestone
difference between entities/macros from the resource and variables provided by the developer stas 1.0
difference between public and private attributes/entities gandalf 1.0
default values for hashes/arrays gandalf 1.0
globals namespace gandalf 1.0
import command gandalf 1.0
conditional blocks gandalf 1.0
value as ID (gettext mode) stas ?
string as ID (simple gettext mode) stas ?
key as string stas ?
relative referrals gandalf 1.0
dependency list gandalf 1.0
computer readable comments gandalf ?
multi-language resource files gandalf 1.0
Switch expression gandalf ?
attribute indexes stas 1.1
nested indexes gandalf 1.0
Expression errors gandalf 1.0
workflow gandalf 1.0
resource file syntax stas (support from: kaze, fantsai) 1.0
forbid referencing public entities stas ?
Macro attributes gandalf ?

All of those features represent some feedback item we got and we’re trying to evaluate it ASAP in order to finalize the parser/interpreter couple and work on the workflow toolchain for L20n 1.0 next.

If you want to discuss any of the items, join our localization-20 group and start a new thread for each feature.

If you want to add a new feature to be considered, start a wiki article in L20n/Features namespace.


main mozilla tech

L20n, feedback round

Last months have been extremely busy for L20n. I basically focused 100% of my time on the project, driving simultaneously multiple aspects of the project to completion.

L20n is a very complex project, not only technically, but also socially. Localization technologies have always been of minor importance for most of the software world so we never really develop technologies that could anyhow match the complexity of the human languages. The most common mindset, even among those who have to deal with localization, is that you can get “most of the stuff” done with simple key-value pair lists where English string is a key, and target localization string is a value.

It’s a bit like claiming that most of Firefox front end could be written in BASIC.

L20n is on the other side of the spectrum. It brings the localization technology to the new level, and in result breaks almost all paradigms of what people are used to do with l10n and breaks how it “usually works”.

In result, the major challenge when helping someone learn what L20n is, is to convince the person that she has to stop trying to match its components to the concepts the person knows from other l10n frameworks. It will just not do.

The reward is that once you get beyond the game of “how does L20n relate to Gettext / DTD / Properties?” people get into the “Oooh!” moment and what follows is a litany of ideas of what would be nice to have if we are about to reinvent the localization technologies. I love it ­čÖé

As many project leaders before me have observed, getting close to a target milestone always turns you from a visionary leader that sets the goals and drives them to completion into some sort of a butcher that says “no” to everything except the most crucial additions in the fear of never ending cycle of adding more and more without getting your project released.

So here we are. For the last month we’ve been working pretty close with several projects – Boot 2 Gecko, Jetpack, Firefox – and we got plenty of feedback, from minor additions to major suggestions. Now is the time to narrow down the list of changes we’re ready to incorporate for 1.0, close the list, work toward the release, and push everything else back to L20n:Next.

In the next blog post I’ll list the proposals and the status of the discussion on those.

main mozilla tech

Mozillians on Digital Freedom

Matjaz wrote a blog post on his presence in ACTA debate in Slovenia. With multiple interviews, shows and a speech at a government organized roundtable discussion, Matjaz became an ad-hoc representative of our collective in front of the audience that we rarely interfere with. That is just awesome Matjaz! Congratulations, dude!

But it’s not only Matjaz! Mozillians have been active all around Europe in the public debate on ACTA. Me and Sta┼Ť have been both helping the civic NGO side on ACTA front in Poland, Otto in Estonia, and Bogo in Sofia, just to mention a few.

Three things that strike me about this are:

1) The whole generation of Mozillians who gained their experience by shaping local Mozilla communities in Europe are now becoming respected public figures precisely because of what we are doing at Mozilla project. For years we’ve been responding to what was needed, adapting to the changing landscape on the cross of the local and global Web, growing up to roles that had to be filed. It’s amazing to see that our experience and cred gained by fighting for the Open Web is now placing us in the spotlights when the future of the Internet is being debated.

2) We all seem to intuitively build our positions on a small set of principles that we wrote just a few years ago.
I remember the time when Gerv has been driving the conversation at FOSDEM trying to isolate the limited set of statements and principles that unite us, Mozillians, and I even remember voices questioning the need for such a document arguing that we were successfully able to raise and grow our project without it.
These days, the very first thing that we do when we face something that we intuitively feel is wrong for the Internet, is that we cross check it against the Mozilla Manifesto.

We are united under this manifesto, it does work as a written summary of what we believe in and now it serves us as a point of reference when we face proposals that are not in line with the Internet that we want to see. Just take a look at Polish Mozilla Community position on ACTA, or read Matjaz’s speech.

It  grows far beyond what we originally expected and everyone who worked on this document should be proud now. I certainly am!

3) As individuals, but also as representatives of Mozilla project, we are being asked to speak, because people want to know what Mozilla thinks. It’s important. Like in all other debates that we took part in, web standards, browser wars, web video formats or privacy, Mozilla has a unique role and it’s fundamental for us to walk this thin line of subtle balance that we aim for with our hybrid nature. I’m particularly proud to read Mitchell’s words and also journalists commenting on our statement in a way like the following:

Essential statement on ACTA by Polish Mozilla Community
It’s worth pointing out, that the community’s position is very rational, calm and stripped of the emotions that are driving most of the conversation these days.
Polish PM, Donald Tusk, has said that Poland will not ratify ACTA if the there will be any doubts, and this statement by the community clearly presents those that are of vital importance for the information society.
The statement written by the Mozilla community in Poland is important for yet another reason. Its authors are not connected to any market player. Mozilla Community is not an NGO or political organization. Usually, Mozilla and its community do not comment law related topics.
Those are the people that usually avoid law related topics focusing on their great, a bit crazy vision.
Apparently what has happened, made them feel they have to speak up.

In cases like SOPA in US or ACTA in Europe, Mozilla DNA that has shaped all of us, is being injected and influences the debate in a profound way.
The same vision that has shaped Firefox, Thunderbird, Drumbeat and tons of other projects and products, and through this influenced how the Web looks like today on both, technological and social layer, has also shaped our minds and beliefs, and through this is now impacting the public debate that is being held all around the world on the future of the Interent.

Isn’t that just amazing?

p.s. We’re igniting a newsgroup devoted to the topic of digital freedom. Join us there!

main mozilla po polsku tech

Stanowisko Polskiej spo┼éeczno┼Ťci Mozilli w sprawie ACTA

Polska spo┼éeczno┼Ť─ç Mozilli opublikowa┼éa stanowisko w sprawie decyzji Rady Ministr├│w w sprawie podpisania umowy ACTA.

Zach─Öcamy do zapoznania si─Ö z naszymi wnioskami.

main mozilla po polsku tech

Mozilla Europe i Mozilla w Europie

Projekt Mozilla odnosi niesamowite sukcesy w Europie. Cele jakie postawili┼Ťmy sobie, spisane w ramach Manifestu Mozilli, s─ů bardzo dobrze odbierane w ┼Ťrodowisku Internaut├│w w Europie.

Dzi─Öki temu Mozilla ma ┼Ťwietne wyniki udzia┼éu na rynku Europejskim, ogromn─ů rzesz─Ö os├│b uczestnicz─ůcych w projekcie, ┼Ťwietne kontakty z innymi spo┼éeczno┼Ťciami internetowymi, silne spo┼éeczno┼Ťci lokalne i w efekcie mamy miejsce przy stole w trakcie wa┼╝nych debat dotycz─ůcych przysz┼éo┼Ťci Internetu.

Ma┼éo kto jednak wie, ┼╝e ten sukces uda┼éo nam si─Ö osi─ůgn─ů─ç korzystaj─ůc z bardzo skomplikowanej struktury organizacyjnej – w rzeczywisto┼Ťci istniej─ů trzy organizacje kt├│re powstawa┼éy w r├│┼╝nych momentach w odpowiedzi na konkretne problemy jakie nasz projekt napotyka┼é (, i

Peterv ustawia pierwszy hosting dla Mozilli Europe w 2003

W ci─ůgu ostatnich lat spo┼éeczno┼Ť─ç Mozilli w Europie pracowa┼éa wymiennie z jedn─ů z tych trzech organizacji co niepotrzebnie komplikowa┼éo sytuacj─Ö i utrudnia┼éo synchronizacj─Ö.

Jedn─ů z nich, stricte europejsk─ů jest stowarzyszenie Mozilla Europe za┼éo┼╝one w 2004 roku przez grup─Ö aktywist├│w Mozilli w czasach gdy Mozilla Foundation nie by┼éa w stanie operowa─ç efektywnie na terenie Europy i szukali┼Ťmy w┼éasnych rozwi─ůza┼ä pozwalaj─ůcych nam organizowa─ç nasz projekt.

Przez ostatnie 7 lat Mozilla Europe opiekowa┼éa si─Ö wi─Ökszo┼Ťci─ů aktywno┼Ťci projektu, organizowa┼éa spotkania, wspiera┼éa konferencje, uczestniczy┼éa w rozwi─ůzywaniu konflikt├│w w spo┼éeczno┼Ťciach, chroni┼éa marki, wsp├│┼épracowa┼é─ů z pras─ů i anga┼╝owa┼éa si─Ö we wspieranie rozwoju projektu w r├│┼╝nych regionach Europy.

Od lipca 2005 mia┼éem zaszczyt uczestniczy─ç w pracach stowarzyszenia jako cz┼éonek zarz─ůdu. By┼é to niesamowity czas i ogromna odpowiedzialno┼Ť─ç, poniewa┼╝ Mozilla Europe koordynowa┼éa tworzenie si─Ö struktur i spo┼éeczno┼Ťci w Europie, ale te┼╝ szansa na wykorzystanie mojego do┼Ťwiadczenia i wiedzy z Polski w skali ca┼éego kontynentu.

Mozilla jes niezwyk┼éym projektem, poniewa┼╝ od wielu lat ju┼╝ stanowimy tak unikalny byt, ┼╝e nie mamy od kogo si─Ö uczy─ç. Wszystkie decyzje, struktury, modele pracy i rozwi─ůzania jakie maj─ů s┼éu┼╝y─ç realizacji naszej misji musimy albo wymy┼Ťla─ç ca┼ékowicie od nowa, albo adaptowa─ç do swoich potrzeb te zaczerpni─Öte od innych projekt├│w Internetowych, kreatywnych firm, fundacji non-profit, albo projekt├│w Open Source.

Dotychczasowe decyzje i kierunki dzia┼éa┼ä pozwoli┼éy nam rosn─ů─ç i adaptowa─ç si─Ö do zmian na rynku Internetowym na tyle skutecznie, ┼╝e dzi┼Ť Mozilla ma wi─Öksze mo┼╝liwo┼Ťci realizowania swoich cel├│w statutowych ni┼╝ kiedykolwiek w przesz┼éo┼Ťci!

To za┼Ť pozwala nam skupia─ç si─Ö na adaptowaniu i rozwijaniu samej struktury projektu, tak aby przenosi─ç udane rozwi─ůzania lokalne na poziom globalny. W efekcie powsta┼é projekt “One Mozilla”, kt├│rego celem jest unifikacja projektu w ramach jednej organizacji globalnej – Mozilla Foundation.

W efekcie powoli i sukcesywnie starali┼Ťmy si─Ö identyfikowa─ç dzia┼éania jakie podejmuje stowarzyszenie Mozilla Europe i wdra┼╝a─ç je na skal─Ö globaln─ů w ramach ca┼éego projektu. Wiele inicjatyw kt├│re przez lata dzia┼éy si─Ö tylko w Europie pod auspicjami Mozilli Europe staje si─Ö globalne jak funkcje reprezentant├│w Mozilli, wolontariuszy pe┼éni─ůcych funkcje rzecznik├│w prasowych, uczestnictwo w konferencjach, organizacja w┼éasnych spota┼ä w ramach inicjatyw MozCamp, wsp├│┼épraca z agendami rz─ůdowymi zajmuj─ůcymi si─Ö Internetem i tak dalej.

Taki model organizacji pozwala nam lepiej skalowa─ç nasze dzia┼éania na ca┼éy ┼Ťwiat i pomaga─ç innym regionom korzysta─ç z tego co powsta┼éo w Europie, a tak┼╝e u┼éatwia synchronizacj─Ö i efektywno┼Ť─ç relacji mi─Ödzy projektem a fundacj─ů.

Efektem ubocznym by┼éa te┼╝ powolna redukcja roli stowarzyszenia Mozilla Europe na rzecz globalnej Mozilla Foundation i ostatecznie zarz─ůd Mozilli Europe przy wsp├│┼épracy z Mozilla Foundation podj─ů┼é decyzj─Ö o rozwi─ůzaniu tej pierwszej i przekazaniu wszystkich inicjatyw pod auspicja globalnej Mozilli Foundation.

Ten ruch jest czysto operacyjny, nie wp┼éywa w ┼╝aden spos├│b na nasze cele, dzia┼éania i prace. Mozilla Europe nie zatrudnia┼éa pracownik├│w i zarz─ůd jest przekonany, ┼╝e ta decyzja nie powinna mie─ç ┼╝adnego wp┼éywu na prac─Ö projektu i naszych spo┼éeczno┼Ťci.

Prezes stowarzyszenia, Tristan Nitot, oraz cz┼éonkowie zarz─ůdu z ni┼╝ej podpisanym, b─Öd─ů nadal opiekowa─ç si─Ö dzia┼éaniami Mozilli w Europie i traktujemy ten ruch jako czyst─ů redukcj─Ö biurokracji a tak┼╝e okazj─Ö do przedyskutowania modelu organizacji naszego projektu w Europie.

Chcemy zaktywizowa─ç wi─Öksz─ů grup─Ö lokalnych spo┼éeczno┼Ťci do pracy na poziomie ca┼éej Europy i uruchamiamy nowe inicjatywy pozwalaj─ůce wi─Ökszej liczbie os├│b wp┼éywa─ç na losy Mozilli na poziomie ca┼éego kontynentu. Mamy nadziej─Ö tak┼╝e na silniejsz─ů reprezentacj─Ö naszych dzia┼éa┼ä w ramach projektu Drumbeat oraz licznych inicjatyw znanych z Mozilla Labs w Europie a tak┼╝e planujemy otworzy─ç kilka otwartych przestrzeni dla os├│b zainteresowanych prac─ů nad rozwojem Internetu w ramach projektu MozSpaces. Pierwsze powstan─ů w Londynie i Berlinie w 2012.

By┼éem ogromnym zwolennikiem tego rozwi─ůzania poniewa┼╝ widz─Ö w nim szans─Ö na lepsz─ů adaptacj─Ö naszych dzia┼éa┼ä w Europie do dynamicznego rynku Interentowego oraz na zwi─Ökszenie aktywno┼Ťci samej Mozilla Foundation na poziomie globalnym w Europie, Azji, Afryce czy Ameryce Po┼éudniowej.

Europa jest przyk┼éadem i inspiracj─ů dla spo┼éeczno┼Ťci Mozilli na ca┼éym ┼Ťwiecie i wierzymy, ┼╝e nasze globalne struktury s─ů dzi┼Ť wystarczaj─ůco silne, aby m├│c bezpo┼Ťrednio anga┼╝owa─ç si─Ö i reagowa─ç na potrzeby lokalne. Sieciowa struktura naszego projektu dojrza┼éa przez ostatnie lata i sprawia, ┼╝e mo┼╝emy dzi┼Ť wi─Öcej ni┼╝ kiedykolwiek przy mniejszym poziomie biurokracji.

Cz┼éonkowie zarz─ůdu Mozilli Europe wraz z liderami spo┼éeczno┼Ťci lokalnych stworz─ů nast─Öpny rozdzia┼é historii Mozilli w Europie i wsp├│┼épracuj─ůc z Mozilla Foundation b─Ödziemy rozwija─ç projekt Mozilla reaguj─ůc na potrzeby i wyzwania kolejnych lat.

main mozilla po polsku tech

Tyler o ocenie błędów

uwaga: ten post jest moj─ů prywatn─ů opini─ů, nie jest stanowiskiem ┼╝adnego z projekt├│w w kt├│rych pracuj─Ö.

uwaga 2: ten post nie jest opini─ů o wszystkich portalach i vortalach informatycznych. S─ů wci─ů┼╝ serwisy kt├│re dbaj─ů o jako┼Ť─ç informacji, kt├│re weryfikuj─ů dane, kt├│re szukaj─ů u ┼║r├│de┼é, kt├│rych dziennikarze interesuj─ů si─Ö tematem na kt├│ry pisz─ů, a i w tych kt├│re wywo┼éam tutaj do tablicy nie zawsze jest tak ┼║le. Ale jest ┼║le wystarczaj─ůco cz─Östo bym pozwoli┼é sobie na uog├│lnienia.

Przepraszam, ┼╝e niezbyt cz─Östo tu pisz─Ö ostatnio, ale mam mn├│stwo pracy z L20n, Pontoonem i innymi fantastycznymi projektami nad ktorymi pracujemy i coraz mniej motywacji do prostowania tego co panowie copy&pasterzy napichc─ů.

Tym razem jednak zbieram si─Ö w sobie i prostuj─Ö ponownie. Ot├│┼╝ webhosting, dziennik internaut├│w i dobre programy zn├│w ┼éykn─Ö┼éy plotk─Ö i bujde ze slashdota jak rybka haczyk i ucieszone donie┼Ť─ç raczy┼éy, ┼╝e “by┼éy szef spo┼éeczno┼Ťci”, ┼╝e “zrezygnowa┼é”, ┼╝e zanim to zrobi┼é doni├│s┼é o “nowy cykl wydawniczy (…) bardzo ┼║le wp┼éywa na jako┼Ť─ç Firefoksa” i tak dalej i tak dalej.

Pewnie, mo┼╝na ola─ç, wszak to, ┼╝e panowie wykonuj─ůct te copy&paste t┼éumaczenia (czasem nawet z autorskim komentarzem, zazwyczaj sarkastycznym i definitiwnie wieszcz─ůcym k┼éopoty Mozilli, ewentualnie deklaruj─ůcym eksperck─ů wiedz─Ö jakoby innym przegl─ůdarkom wiod┼éo si─Ö lepiej) zrobi─ů to nast─Öpnym razem niezale┼╝nie co tu napisz─Ö.

Wiemy to bo nieca┼ée p├│┼étora tygodnia temu te same portale donosi┼éy o nieuchronnym usuni─Öciu numerk├│w wersji z okna “O Programie” Firefoksa dok┼éadnie w ten sam spos├│b klonuj─ůc sensacyjne doniesienia slashdot├│w z tak samo poprzekr─Öcanymi faktami, plotkami i przek┼éamaniami. A 4 dni temu donosi┼éy, ┼╝e Mozilla planuje walczy─ç z Chromem przez WebAPI… i tak dalej…

Wiemy te┼╝, ┼╝e tak jak zawsze nie skorzystaj─ů ze starej dziennikarskiej zasady pytania u ┼║r├│de┼é, albo chocia┼╝ dania szansy wypowiedzenia sie drugiej stronie do kt├│rej kontakt dostaj─ů regularnie od Lukasza Kluja, ode mnie, googlaj─ůc/binguj─ůc Mozill─Ö w Polsce lub na ┼Ťlepo wpisuj─ůc Nic to nie da.

I tym razem wpadka, pomy┼éka, nie przyniesie wstydu, w odr├│┼╝nieniu od slashdota nie zaktualizuj─ů swoich wpis├│w, nie zawstydz─ů si─Ö a czytelnicy rado┼Ťnie w komentarzach skorzystaj─ů z okazji do kolejnego flamewara na temat tego kt├│ra przegl─ůdarka jest lepsza i jakim epitetem obrzuci─ç wsp├│┼ékomentatora kt├│ry ┼Ťmie wole─ç inn─ů.

No to dla sprostowania:

  • Mozilla nie jest firm─ů w tradycyjnym tego s┼éowa znaczeniu. Jest projektem, spo┼éeczno┼Ťci─ů. Wszyscy kt├│rzy si─Ö wypowiadaj─ů i pracuj─ů w nim to kontrybutorzy, cz┼éonkowie spo┼éeczno┼Ťci. Tyler jest cz┼éonkiem projektu Mozilla. Cz─Ö┼Ť─ç os├│b jest zatrudniona w Mozilla Foundation w r├│┼╝nych formach do r├│┼╝nych zada┼ä. Tyler nie jest.
  • Tyler nie zrezygnowa┼é z uczestnictwa w projekcie tylko z pracy w grupie zajmuj─ůcej si─Ö ocen─ů nowych zg┼éosze┼ä
  • Tyler nie napisa┼é nic na temat wzrostu liczby b┼é─Öd├│w w Firefoksie w wyniku nowego modelu wyda┼ä
  • W projektach open source poj─Öcie “bug” odnosi si─Ö do ka┼╝dego zg┼éoszenia – czy to jest b┼é─ůd, czy propozycja zmiany, czy pomys┼é. Zdecydowana wi─Ökszo┼Ť─ç z tych zg┼éosze┼ä jest nieprawid┼éowa lub duplikuje zg┼éoszenie ju┼╝ istniej─ůce. Pisanie wi─Öc o “6000 b┼é─Öd├│w w Firefoksie” jest wi─Öc po prostu myleniem czytelnik├│w.
  • Ocena zg┼éosze┼ä to praca kt├│ra od zawsze w Mozilli jest ┼Ťcie┼╝k─ů przez kt├│r─ů przechodzi wielu nowych wolontariuszy, ja zaczyna┼éem od pracy nad tym, Gavin, i inni te┼╝. Od takiej funkcji sortowania i kategoryzowania b┼é─Öd├│w do realnej oceny wp┼éywu szybkiego cyklu na stabilno┼Ť─ç przegl─ůdarki i liczb─Ö b┼é─Öd├│w w niej jest bardzo daleko.
  • Je┼Ťli kt├│ry┼Ť z dziennikarzy interesuje si─Ö naprawde tematem stabilno┼Ťci przegl─ůdarki to mo┼╝e zechce przet┼éumaczy─ç wpis Jessiego Rudmana na temat statystyk b┼é─Öd├│w krytycznych Firefoksa w kolejnych wersjach (i artyku┼éu Kairo na ten temat?)
  • Bugzilla Mozilli w og├│le nie jest narz─Ödziem “jako┼Ťciowym” tylko “ilo┼Ťciowym”, zbieramy setki zg┼éosze┼ä dziennie, wi─Ökszo┼Ť─ç nigdy nie zostanie rozwi─ůzana, bo albo nie ma sensu, albo nie jest wa┼╝na (w stylu: “Hinduska wersja Firefoksa na system Solaris sprzed trzech lat ustawiony z czcionk─ů cyrylicy nie wy┼Ťwietla poprawnie strony CNN w wersji z 2008 roku”), albo nie jest do odtworzenia, albo nie jest w og├│le problemem tylko propozycj─ů kt├│r─ů nikt si─Ö nie zaj─ů┼é i czeka na kogo┼Ť kto si─Ö danym tematem zainteresuje. Rozmowa o liczbach w takim kontek┼Ťcie i emanowanie nimi jest wynikiem g┼é─Öbokiego niezrozumienia tematu o kt├│rym si─Ö pisze.
  • Tyler napisa┼é dwa sprostowania. Niestety sprostowania s─ů mniej skandaliczne, a wi─Öc mniej atrakcyjne, ni┼╝ oryginalna plotka. Szkoda, prawda?

Du┼╝o si─Ö dyskutuje ostatnio na temat przysz┼éo┼Ťci prasy i medi├│w w dobie Internetu. Niestety z przera┼╝eniem obserwuje dewaluacj─Ö jako┼Ťci dziennikarstwa dotycz─ůcego temat├│w komputerowych, kt├│re idzie r├│wnolegle ze wzrostem liczby os├│b u┼╝ywaj─ůcych Internetu i zwi─Ökszaj─ůc─ů si─Ö dynamik─ů tego co si─Ö w Webie dzieje.

W tym samym czasie kiedy wsz─Ödzie wok├│┼é mnie w Polsce kie┼ékuj─ů spo┼éeczno┼Ťci eksperckie, sceny front-endowe, back-endowe, webappowe, HTML5, webgamingowe itp. dziennikarski front s┼éabnie w oczach, redukuje siebie sam do formy i skupia si─Ö na straszeniu u┼╝ytkownik├│w.

Czasem zastanawiam si─Ö jak to jest pracowa─ç jako dziennikarz IT,┬ápodpisywa─ç si─Ö nazwiskiem pod tekstami i do tego stopnia nie interesowa─ç si─Ö tym co si─Ö dzieje z Sieci─ů. Nie rozumie─ç czym jest Mozilla, czym Webkit, jak tworzone s─ů standardy, jak wygl─ůda wsp├│┼épraca tw├│rc├│w przegl─ůdarek, czym jest W3C, Ecma albo jak dzia┼éaj─ů projekty open source.

To smutne, ale drodzy panowie redaktorzy – obserwowany przez Was spadek czytelnictwa nie wynika z “kryzysu” medi├│w ani tego, ┼╝e kto┼Ť Wam “kradnie” czytelnik├│w. Obni┼╝acie jako┼Ť─ç, skupiacie si─Ö na plotkach, w┼éa┼Ťciwie wi─Ökszo┼Ť─ç tego co piszecie o wydarzeniach wok├│┼é przegl─ůdarek jest pe┼éna przeinacze┼ä, b┼é─Öd├│w i dowod├│w, ┼╝e tak naprawde tym tematem niezbyt sie interesujecie i nie staracie si─Ö go pozna─ç. Dziwi Was zatem odwr├│t czytelnik├│w? Moim zdaniem g┼éosuj─ů nogami.

A panowie rednacze – newsy o przegl─ůdarkach ciesz─ů sie popularno┼Ťci─ů? To mo┼╝e zatrudnijcie do pisania ich osoby kt├│re interesuj─ů si─Ö przegl─ůdarkami? Na eventach takich jak Front Trends, Falsy-Values, czy zbli┼╝aj─ůcy si─Ö onGameStart w┼éa┼Ťciwie ka┼╝da, losowo wybrana osoba b─Ödzie si─Ö nadawa─ç. Zyjemy w czasach pasjonatow, warto z tego korzystac do budowania wartosciowych srodowisk ­čÖé