main mozilla tech

Hard Blockers Counter 1.0

A little bit more of coding, a few bug reports later, HBC is ready for its prime time. Version 1.0 fixes the nasty toolbar height problem, it gives a user an indication of the interval covered by his plot and is just overall better.

It can be downloaded from an listing, and the source code is available at 馃檪

A few of the lessons learned and thoughts:

  • builder is awesome, but it needs more real life users. A lot of bugs are only reproduced after you write your extension for some time, hundreds of revisions etc.
  • AddonSDK is excellent for this kind of extensions. It has everything you may want and makes the whole code extremely clean and simple to write and maintain. Just look at it – about 50 lines of core code – your cat could read that.
  • AddonSDK needs more real life users. Like with the builder, bugs show up only when you really use the extension you created.
  • AMO is an excellent developer friendly platform – it gives me a lot of satisfcators in a form of stats, and ability to manage my extension release process.
  • AMO-builder bindings need more real life users. I felt like I’m the first to try to push builder based extension to AMO – many trivial bugs that can be only revealed if you try to go through the whole thing.
  • AMO’s review/release process is excellent for the extension of the Old Days. It gives us a pool of high quality, verified extensions, that are easy to find and safe to use. It does not work with agile development. Builder and AddonSDK makes creating ad-hoc extensions super simple and quick (literally, 2 hours and you’re done with the first version, every new version is about 15 minutes of work). When you then push it to AMO it feels like Matrix slow motion then – you suddenly wait days for a preliminary review, not to mention almost two weeks you have to wait for a full review. My last revised version is super old comparing to what I claim to be the “stable” one now 馃檨

This issue requires a little bit of description. I do not try to say here, that what AMO reviewers are doing is wrong – quite the opposite, I believe the whole process is excellent and anything that is exposed to the millions of users should get some time to season and be tested and be reviewed. It’s just that AddonSDK/Builder gives you a totally different setup that fits different needs. I believe AMO will need a workflow for extensions that are created in 10 minutes, distributed in 20 minutes, updated 5 times during 4 hours and are becoming useless after one or two days.

Think of a conference where schedule is updated often and people have hard time to track it. Using AddonSDK/Builder you can create an extension for it in literally 20 minutes (xhr, panel, widget). AMO is excellent for distributing it, updating your users etc., but it requires very different approach than say, AdBlock or Firebug. Then, you add a feature (ability to mark the talk you want to attend and get a notification when its room/time changes) and upload a new version 15 minutes later. You want to switch all your users to the new one now. Then you fix a small bug affecting linux users, and update users once again.

It’s amazing that Firefox is becoming a platform where it is possible, and I can’t wait for such application for AMO 馃檪

  • AddonSDK requires a lot of users with their use cases. Myk’s approach is to iterate often which means to get version 1 ASAP and then add new features for version 2 instead of trying to build an ultimate solution without a release. I love this approach and it serves AddonSDK well, but now we need version 2 of many of the packages there – it can only be done if people start using the packages for a real life extensions and report what they miss. Like – Widget content cannot be easily themed. Or, you cannot control Panel’s scrollbar appearance. Jetpack team cannot plan for those use cases, they have to come from jetpack users. So be brave! Try things, report everything you need! 馃檪
  • There is a group of at least 500 people who deeply care about our release process. They’re ready to increase the amount of items on their screen to have a continuous updates on our progress toward Firefox 4. And it’s been just two days. It can motivate people to help, make them feel the sense of progress, help them understand the challenges better. It sucks outsiders closer to the inner circle. I believe we can do much more and the nightly users, mozilla planet readers and the audience of my extension deserve the chance to get more info which can help them start contributing! 馃檪

main mozilla tech

Hard Blockers Counter 0.8 (0.9) – with a plot!

Tremendous success of the Hard Blockers Counter extension (it got over 300 daily users and 4 positive reviews – yet they were lost in the transition :() motivated me to spend another too-early-morning on adding a history plot for the counter.

It was a real pleasure and a good lesson to go through – simpleStorage, timer, panel, and contentScript communication stuff. I reported some bugs in the toolkit, in the builder and in the builder->amo release process. It’s all been fixed 馃榾
The only real unresolved issues is that the widget affects the height of the toolbar. Reported as bug 626728.

So, 0.8 is ready and waiting, enjoy and fight that bug number down! 馃檪

Source code as always available.

[update] Actually, Builder provided me an old version of my jetpack and I submitted it to AMO as 0.8. So now I added 0.9, but it has to wait to get a review – so if you want colorful plot, download it directly from here.

main mozilla tech

Firefox 4 hard blockers counter

Last night was a usual “15 hours on a plane brings your sleep cycle into the fifth dimension” one for me.

I was pondering through the planet mozilla and realized that despite great effort from our UX Team, Firefox 4 nightly does not show up the single, most important information piece about the state of my browser, it does not answer the question that our whole project is living now:

How many blockers do we have until we reach Release Candidate

Well, you probably can imagine everything from there – now, I present you the missing piece – Fx4 Hard Blockers Counter extension in its full glory.

Source code available.

main mozilla po polsku tech

Video w sieci rok p贸藕niej

Rok temu pope艂ni艂em wpis, w kt贸rym opisa艂em jak wygl膮da sytuacja z kodekami wideo, stanowisko jakie Mozilla Foundation przyj臋艂a w tej kwestii oraz widoki na przysz艂o艣膰.

W komentarzach napotka艂em du偶y op贸r, wi臋kszo艣膰 komentuj膮cych mia艂a zdanie skrajnie odmienne ode mnie, pisz膮c o nieuchronnym upadku Mozilli, rych艂ym spadku popularno艣ci Firefoksa, bezsensowno艣ci stawania na przek贸r tak pot臋偶nym firmom jak Google, Apple czy Microsoft…

Wystarczy, nie lubi臋 wy偶ywa膰 si臋, a poza tym tamta dyskusja by艂a nie fair – ja pisz膮c to wiedzia艂em, 偶e Google uwolni VP8, moi rozm贸wcy mogli odczyta膰 moje s艂owa jako pobo偶ne 偶yczenia – wszak nic wtedy jeszcze na to nie wskazywa艂o.

Summa summarum, dzi艣 sytuacja jest odmienna. Wydaje mi si臋, 偶e nasza postawa mia艂a niebagatelny wp艂yw na decyzje Google o porzuceniu h.264, cho膰 s膮dz臋, 偶e nasz wp艂yw by艂 raczej po艣redni – zatrzymali艣my adopcj臋 h.264, utrzymali艣my pole otwartym, tak, 偶e Google op艂aca艂o si臋 postawi膰 na WebM. Jestem dumny z tego jak Mozilla korzysta ze swojej pozycji do realizacji cel贸w statutowych.

Nie wygrali艣my tego jeszcze – wci膮偶 do przekonania s膮 Apple i Microsoft i podejrzewam, 偶e ta druga firma b臋dzie 艂atwiejszym partnerem, ale krajobraz po roku czasu jest znacz膮co odmienny.

Co przyniesie nast臋pny rok? S膮dz臋, 偶e dystans jaki dzieli WebM i h.264 w zakresie wsparcia sprz臋towego zniknie, Adobe Flash zacznie wspiera膰 VP8 (a mo偶e i WebM?), Microsoft do艂膮czy wsparcie dla WebM, a Apple stanie przed trudnym wyborem… a jak b臋dzie naprawde? Czas poka偶e 馃檪

main mozilla tech

Using Common Pool – Tutorial

In this post I’m going to show you how to make your extension localizable via Common Pool and how it can be localized.

early adopter warning: It’s the first attempt, it’s a new concept, things may brake, things may be a little rough, stay calm. It’s not a replacement for a well known solutions yet, but it may be one day. Play with it, hack the service and the library, suggest improvements, report the issues, but stay calm whatever happens – there may be dragons.

Using the library

Since Common Pool is currently implemented in Addon SDK, I assume you’re using it for writing your extension. First thing is to add my localization module to your extension. It’s available at

Once you have it in your dependencies, you can just include it into your code.

Let’s take an example Hello World code:

var notifications = require("notifications");

var menuItem = contextMenu.Item({
  label: "Hello World",
  contentScript: 'on("click", function (node, data) {' +
    '聽 postMessage(node.src);' +
  onMessage: function (imgSrc) {
      title: "Hello World",
      text: "Welcome to the new, wonderful world!",

Now, in order to make it localizable, all we need to do is to add one require, and change the string initialization:

var notifications = require("notifications");
var _ = require("localization").get;

var menuItem = contextMenu.Item({
  label: _("Hello World"),
  contentScript: 'on("click", function (node, data) {' +
    '聽 postMessage(node.src);' +
  onMessage: function (imgSrc) {
      title: _("Hello World"),
      text: _("Welcome to the new, wonderful world!"),

Done! That’s what I meant when I wrote that Common Pool is asking as little attention from the developer as possible. If it reminds you of common patterns used by GetText, you’re right on spot. We like this notation, we reuse it.

With such code, you’re ready to go 馃檪 As a developer, you can move along, do your work, deploy your extension on AMO and never ever bother about this again, while we will make sure that the localizers can localize, and users will receive the localized version dynamically. 馃檪

Early adopter warning: For the time of the field testing of this library, we do not actually have any integration with AMO, so when you want your addon to be localized, you need to “cfx xpi” it, or if you’re using the builder just click on “Download” and upload the result xpi here: This is a temporary step

Using the web service

Once a developer uploaded his addon and his job is done, the camera shifts onto another hero – a localizer. This brave soul, can just go to, log in and start localizing. As a localizer, you can just select your locale and start localizing. You can filter by an extension and you can view how other locales localized it.

You can also select overrides and add one for a given jetpack or occurrence. When you finish localizing your jetpack, you’re done. We will spread your translation to all users of the jetpack who use your locale. If you later update your translation, all users will receive an update on the next day. Isn’t that awesome? 馃檪

Early adopter warning: Until we fix bug 10, we refer to jetpacks by their unique ID, instead of the human readable name. It should be fixed soon 馃檪

The beauty of early adopting

Well, that being said, you know you would not be happy to receive a complete, ready to use, bug free solution. That’s not what hackers life is about. In fact, we decided to blow quite a big hole through the middle of the road that’s called “First Run Experience“.

As we were working on the library, and the webservice, and how nicely they’re tied, and we enjoyed the experience of a user staying up to date with localization of his extensions, and being able to download an extension in en-US and then see it localized on the day when a localizer finishes localizing it… we actually did not solve a pretty important case. Here’s the issue:

When a user installs an extension it contains no translation resources bundled with it. On the first run, we asynchronously ask the localization web service for the entities used by the extension. So far so good.

The server asynchronously sends the user all the entities and they’re cached. From that moment every request for a string will work by providing a translation of the string. But what happens before we cache?

Well, for now, nothing. Bummer 馃檨 Basically, until we cache the strings, all we have is an empty cache and the localization library will just return the english strings which is the default fall back.

The bug for that is reported, bug 619807, and we’re working on a solution for that. We may decide to bundle entities that we have available for the extension together with it at the time of download, but that will be just a workaround. An ideal solution would be to pull the localizations together with the addon (as a part of addon installation experience) and then check if there are any localization updates on a normal daily routine.

If you have any ideas, suggestions or code snippets that solves it – feel free to jump in and help! 馃檪

Real Life Example

Take a look at this example extension, Translate Selection with l10n. Now, go to to see its localization and localize it live.

Next time you run this extension you should be able to see it working with localization (assuming your browser is using your locale and minus the First Run Experience bug).

That’s all. 馃檪


Common Pool is a simple, yet very powerful solution. It solves a lot of issues that we’ve been struggling with since the beginning of times. It makes internationalization easier than ever, localization easier than ever and synchronization easier than ever. Bare in mind, it’s intended as a solution for simple strings, for developers who don’t have much time to think through their UI’s and plan it for localization, and for massive localization of tons of thousands of extensions.

We believe it nails it perfectly (with the few early adopters hiccups that we’re working on right now, and an unlimited number of issues that are awaiting to be discovered by you!), and we want to improve it until we feel it to be the right one.

At the same time, please, remember that for a more complex and sophisticated UI’s, the ones where a developer has to think about entities, and the localizer wants to fine tune each and every sentence – we’re going to work on a complementary, L20n based solution.

Now, it’s your turn to play with it, hack on it, give us feedback and help us evaluate the solution. We’re available at #l10n and #jetpack channels, and we use mozilla-labs-jetpack group that you can use. For bugs in the l10n web service, please, use its bitbucket issue reporting system. Thanks! 馃檪

main mozilla tech

Jetpack Localization – Common Pool approach

Jetpack project is taking an aim at rewriting the extension system, learning from the past, responding to the feedback and thinking outside of the box. So when the Jetpack team approached L10n-Drivers and asked for support with building localization infrastructure for new addons, we decided to go the same way. 馃檪

Common Pool

The first approach we’re presenting you is called Common Pool (yup, that’s not a very creative name) – it’s basic assumption is that most jetpacks are small applications with a minimal UI. And there are going to be tons of them. We already have tens of thousands of extensions, and Jetpack with its nice API and builder are going to make it much, much easier to write a good extension.

We also made some observations – There are common phrases, like “Cancel“, “Ignore“, “Log in” that are replicated over and over in almost every extension. It’s becoming hard to localize it, hard to keep it consistent and maintain the localization. On the other hand, extension authors are struggling to work with localizers as they need to iterate fast and聽 string freeze phases are adding a lot of cost to the release process.

For that reasons we decided to build on a basic concept of entities shared across extensions, stored on a server, and pulled by the jetpack itself.

Shared entities are powerful. For a localizer it means that we can show you the list of mostly used entities and if you localize 20 of them, you localized 50, 100 or maybe 500 extensions. You can update a translation and have it translated the same way across all extensions. You can localize only one extension and your work will probably benefit other extensions as well. You can localize today, and tomorrow all users will get updated localizations. How cool is that? 馃檪

For a add-on developer it also means more good. You can pick entities that are already localized into many languages and have you extension Just Work. You don’t have to worry about releases and localization because if you only make thing localizable, users will be able to pull localizations as they appear. It means less to think about.

Now, there are of course some trade offs. One of them is that not all translations of a word should be equal. For that reason we propose a concept of an exception. Actually, two of them.

First one is a per-addon exception which allows localizers to localize a given string differently for this particular addon. It’s important when the addon uses some specific vocabulary.

Second one is a per-case exception which allows localizers to divert from the common translation for a specific use case. Say, the use case in jetpack X, file main.js line 43 should be translated differently.

Library and the Web Service

So, that’s the concept, and it has been implemented as a library. Yahoo! Now, for such a solution to work, we knew we need a partner in crime. We need a web service that will support Common Pool and allow for addon localization. We knew we will want to merge it with AMO and the Builder, so django was a preferred technology, and one other requirement was to be able to support a localization storage model that is substantially different from the industry standard.

Fortunately, at the time when we conceptualized Common Pool, our friends from Transifex were reworking their storage model away from gettext-specific to much more generic database driven one. Well then – good time to see how generic it can be, right?

Together with Transifex team, mainly Dimitris Glezos and Seraphim Mellos we’ve been working on the Common Pool web service that can back up the library and become a localization web tool. Today, the first iteration of the tool is alive at –! The source code is GPL and available at transifex-commonpool bitbucket repository and that’s where we’re collecting bugs as well.

What’s next?

Now we have to prove that the concept in the field. We’re challenging the status quo, so it’s on us to validate it. We’re going to reach out to extension authors and localizers alike to get support and testing coverage and if we that it works, we’ll include common pool library into Addon SDK 1.0. It’s up to you to help us evaluate it!

Then, it’ll be time to complement Common Pool with another architecture, that does not solve the simple cases that easily, and require much more active work from the developer, but will provide better level of details for both parties. The solution we want to offer is L20n.

Bundle pack ahead

Together, Common Pool and L20n should provide everything that localizers and developers may need pushing the limits and stretching what’s possible with the localization. We think of a Common Pool as a great generic, easy solution for most common strings, while L20n complements it with more sophisticated, more powerful approach for the developers whose extension reached the level when they want it to be localized with more attention and where the UI requirements are higher.

Let me know what you think – I know it’s early, I gave many talks about those technologies to our Mozilla communities, but I realize that it’s hard to evaluate without actual code in hand, so now is the time for feedback, feedback, and even more feedback 馃檪

In the next blog post I’ll explain the steps to create your first common-pool driven extension.

main mozilla po polsku tech

Wywiad O Fx4 i nie tylko

A偶 trudno uwierzy膰, 偶e nie pisa艂em tu od 2 miesi臋cy… Zagrzeba艂em si臋 w projekt L20n tak g艂臋boko, 偶e nie znajdywa艂em w sobie motywacji do blogowania. :/ Obieca艂em sobie w tym roku to zmienia膰, bo wierz臋, 偶e komunikowanie tego co si臋 robi pomaga ca艂ej spo艂eczno艣ci – zatem spodziewajcie si臋 wi臋cej i krzycie jak b臋d臋 lagowa艂 馃槈

Na pocz膮tek roku podrzucam wywiad kt贸ry ukaza艂 si臋 na – mi艂ej lektury i czekam na opinie 馃檪

main po polsku tech


Uwielbiam czyta膰 analizy bezpiecze艅stwa komputer贸w tworzone przez firmy sprzedaj膮ce systemy antywirusowe. Okazuje si臋 w nich, 偶e Linux, Unix i MacOS s膮 wybitnie nara偶one na wirusy i ataki, a Firefox, Chrome i Opera kompletnie nie chroni膮 systemu lepiej ni偶 IE.

To troche jakby koncern medialny publikowa艂 wyniki zam贸wionych przez siebie analiz z kt贸rych wynika, 偶e ludzie uwielbiaj膮 p艂aci膰 za filmy, ogl膮da膰 niesko艅czon膮 ilo艣膰 utrudniaczy i reklam, oraz 偶e filmy pobrane z Internetu psuj膮 karty graficzne i powoduj膮 epilepsje.

Na szcz臋艣cie panowie z firm typu Symantec, Sophos regularnie zaspokajaj膮 moj膮 potrzeb臋 i tak na przyk艂ad dzi艣 pojawi艂a si臋 publikacja na temat raportu z maja firmy Sophos.

Raport jak raport, jak zwykle musimy wiedzie膰, 偶e 偶yjemy w zagro偶eniu i nie ma od niego ucieczki, chyba, 偶e kupimy produkty tych firm. S膮dz臋, 偶e g艂贸wnym targetem s膮 osoby kt贸re rozwa偶aj膮 przesiadk臋, bo kto艣 kto od kilku lat u偶ywa Linuksa, jak moja Mama, u艣miechnie si臋 tylko jak por贸wna swoje bezproblemowe kilka lat z tymi wcze艣niejszymi, na Windows.

Natomiast uderzy艂a mnie, g艂贸wnie z powodu braku logiki, jedna teza:

“Z jednej strony najwi臋cej b艂臋d贸w znajdowanych jest w programie Mozilli, ale z drugiej Firefox jest 艂atany stosunkowo szybko, a inni producenci, np. Microsoft czy Apple nie informuj膮 o wszystkich wykrytych b艂臋dach.

Wniosek z tego taki, 偶e wszystkie przegl膮darki s膮 w r贸wnym stopniu nara偶one na niebezpiecze艅stwa, poniewa偶 wszystkie zasadniczo s膮 艣rodowiskiem dla uruchamiania kodu JavaScript.”

Po pierwsze, odwo艂am si臋 ponownie do artyku艂u Johnathana “Mierzmy to co si臋 liczy – pakiet SEC” – m贸wienie o liczbie publicznie opisanych b艂臋d贸w w przypadku por贸wnania zamkni臋tej firmy, kt贸ra tych b艂臋d贸w cz臋sto nie ujawnia a poprawki w艂膮cza bez informowania o tym u偶ytkownika do pakiet贸w aktualizacyjnych jest nieporozumieniem. M贸wienie o tej liczbie bez zainteresowania si臋 tym jak powa偶ne s膮 to b艂臋dy i jak膮 grup臋 u偶ytkownik贸w nara偶aj膮 jest nie tylko bez sensu, ale te偶 szkodliwe – uczy firmy z艂ych nawyk贸w i premiuje ukrywanie b艂臋d贸w.

Po drugie, por贸wnywanie jab艂ek do gruszek – Mozilla 艂ata szybko, a Microsoft nie informuje o wykrytych lukach jest r贸wnie bez sensu.

Po trzecie, ca艂a wypowied藕 jest zabiegiem erystycznym zwanym implikatur膮. Oto w Firefoksie znajduje si臋 najwi臋cej b艂臋d贸w (co samo w sobie jest dyskutowaln膮 tez膮, wg. Secunii Firefox 3.6 ma 9 b艂臋d贸w z czego 1 nieza艂atany, IE8 ma 15 z czego 5 nieza艂atanych, IE7 ma 47 z czego 11 nieza艂atanych, IE6 ma 148 z czego 24 nieza艂atane), ale, uwaga, z jednej strony szybko je 艂atamy, a z drugiej Microsoft i Apple ukrywaj膮 swoje b艂臋dy. Czy偶by 2:0? Nieee… nast臋pnie narzucony zostaje wniosek, 偶e jest 1:1 i nie ma bezpieczeniejszych i mniej bezpiecznych przegl膮darek… :/

Wiem, powiecie 偶e si臋 czepiam, bo dotyczy to Firefoksa. Ale to co mnie uderza to nie sprawa Fx, tylko budowa zda艅, kt贸ra jest sprzeczna z tym jak rozumiemy bezpiecze艅stwo i jego cechy, oraz nielogiczno艣c konkluzji w stosunku do informacji zawarych wcze艣niej.

“Z jednej strony otwarte standardy pozwalaj膮 tworzy膰 lepsze strony, ale z drugiej wtyczki, typu Flash zu偶ywaj膮 wi臋cej procesora.

Wniosek z tego taki, 偶e wszystkie technologie s膮 r贸wnie z艂e, bo istniej膮 w sieci”

Czy to ma jakikolwiek sens? No wi臋c nie ma. Zdanie kt贸re tutaj komentuje jest parafraz膮 dokonan膮 przez dziennikarza, ale w samym raporcie te偶 mamy 艂adne kwiatki w stylu tezy, 偶e Firefox by艂 w 2008 (!!!) najmniej bezpieczn膮 przegl膮dark膮, bo znaleziono w niej najwi臋cej b艂臋d贸w (a ile za艂atano? czy u偶ytkownicy byli nara偶eni na ryzyko przez cho膰 jeden dzie艅? To ju偶 nie wa偶ne…). Ehh.. ko艅cze ju偶, ale polecam lektur臋 raportu. Punkt na temat przegl膮darek jest b艂臋dny w praktycznie ka偶dym zdaniu. Nie mam nawet si艂y sprawdza膰 pozosta艂ych punkt贸w, poza tym mniej si臋 znam na bezpiecze艅stwie system贸w poza przegl膮darkami. Ca艂o艣c to jednak w mojej ocenie wstyd 馃檨

main mozilla tech

Mozilla Summit 2010 – Localization 2.0 talk

Here come slides I used for Summit 2010 Localization 2.0 talk.

It was a very tough talk to give. Hard to grasp, hard to explain. I originally wanted to devote it exclusively to L20n, and make it as a form of tech talk, but eventually figured out it will not work and there’s much broader vision I need to explain. Thus a few hours before the talk I started rewriting it and end up with what you can find here.

Of course slides alone will tell you just a small part of the story, but it’s better than nothing. 馃槈

Thanks to all who participated in this! I know it eats a lot of brain cycles to process and it was already 4pm, but I hope you enjoyed it! 馃檪

main mozilla tech

Pontoon – more details and 0.2 plans

Catching up from the blog post that introduced Pontoon, I’d like to present the project in a little more detail and the vision for a near future.


As stated previously, Pontoon 0.1 introduces two types of clients – web client and jetpack client. Both share majority of code base (Pontoon, jQuery, jQueryDomec and heavily modified editableText plugin), but because of the limitations of jetpack prototype I had to merge them into one JS file.

user experience

For user interface of Pontoon 0.2 I’d like to focus on a few key aspects that may make Pontoon a tool ready to use in work environment:

  • Introduce identification system that will sign contributions made by a given user. We may use Verbatim accounts for now.
  • Figure out a way to recognize the state of localization and allow for continuing localization.
  • Add ability to view/edit entity in a source view. (much like wordpress’s HTML view)
  • Fix some common cases like entity with a single anchor should treat the anchor as an entity, not its parent
  • Improve UI to look nicer and inform user on the outcome of his actions.

With those six improvements (including two top ones which are major), Pontoon will become, in my opinion, ready for real life use and we may offer it for one of the upcoming small websites for those brave souls who would like to test it.

code base

On the code base front, I will definitely want to clean up the sources, which will be easier when jetpack client get updated to new jetpack architecture. editableText plugin will require a cleanup and will be extended to allow source view, so it may make sense to fork it as a separate project, while other classes should be refactored and site-dependent code should be moved away from libraries. Also, CSS inclusions should be merged into libraries.

One thing I’d like to see soon is a third type of a client – one that may be embedded into any website so that the website author can turn on and off the “localization” mode.


Pontoon server will require adaptation to the client side changes, like ability to identify/authenticate users, and then two new things should be possible with the data received from a client. First, server should be able to add translations as suggestions in Verbatim. This way users will be able to suggest translations, leaving up to the registered localizers what to do with it. This workflow is an intended one for Pontoon.

Second thing, is that we should be able to generate a pure, localized HTML file out of a source one and translation list. This way we will be able to localize things like SUMO documents or plain HTML sites that do not use Gettext or even PHP.


Hooks will go through a major rewrite, because I want to test the concept of providing an external meta file with information like lists of entities for the client to read. Such meta information is the most natural way to also add ability to pick up localization from a midpoint. The issue here is that of course this will not help the client with localization of websites that do not use pontoon hooks.

It would be also great to add Django hooks, since so many websites this days are migrating to django, and it would also allow us to test how cross-linguistic the hook system is.


This is my plan for a short term, and I’ll try to get as many of the features described above into Pontoon 0.2 as possible. I prepared a wiki article describing the plan, and I’m open to feedback, ideas, and of course, contribution. 馃檪