Category: mozilla

Categories
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.

Categories
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.

Categories
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 🙂

Categories
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 http://builder.addons.mozilla.org.

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) {
    notifications.notify({
      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) {
    notifications.notify({
      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: https://l10n.mozillalabs.com/projects/p/mozilla-jetpacks/upload/. 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 https://l10n.mozillalabs.com, 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 l10n.mozillalabs.com 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. 🙂

Summary

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 irc.mozilla.org #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! 🙂

Categories
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 – https://l10n.mozillalabs.com! 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.

Categories
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 firefox.bajo.pl – miłej lektury i czekam na opinie 🙂

Categories
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. 😉

Localization 2.0 – Mozilla Summit 2010

View more presentations from zbraniecki.

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! 🙂

Categories
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.

Clients

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.

Server

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

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.

Summary

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. 🙂

Categories
main mozilla tech

Pontoon – introduction

One of the three core types of content I described in my previous blog post is what I call rich content.

This type of localizable content has certain characteristics that are very different from the common UI entities. Starting from different goal (to provide information), through different size (long sentences, paragraphs), different l10n flexibility (needs ability to reorder, extend, shrink long texts) to much richer syntax (sentences can be styled with HTML, CSS).

Almost a year ago I started playing around some type of a web tool that would allow for WYSIWYG style localization for the web, later picked up by Ozten in his blog post about potential use cases, and finally landed on Fred Wenzel’s mind as he decided to give this idea a try. He ignited the project, and created first iteration of the UI, where I joined him, and added server side.

Now, the idea itself is neither new nor shocking. Many projects were experimenting with some forms of live localization for web content but the solutions we know so far are hardly adaptable for generic purposes. Some require a lot of prerequisites, others are gettext only, and they come as black-box solution which requires you to follow all the procedures and lock your process in.

Pontoon is different in the sense that it is a toolset that allows for rich content localization with grading amount of prerequisites and varying strictness of output. It’s a very alpha mode tool, so be kind, but I think it’s ready to get the first round of feedback 🙂

Pontoon – components

Pontoon is composed of three elements:

  • client – pontoon client is an application that allows for content navigation and localization. It’s responsible for analyzing content and providing ways for the user to translate it.
  • server – pontoon server is an application that the client communicates with in order to send/update translations provided by the localizer and store them later for the website to use.
  • hook – pontoon hook is a small library that can be hooked into a target application in order to provide additional information for the client to improve its abilities.

There are various clients possible, for now we have two – HTML website as a client, and Jetpack 0.8.1 based one. They share a lot of code and they operate quite similarly.

We have one server – django based one – that can receive translations provided by the client, and uses Silme to store them into a file (currently .po), and we have one hook – for PHP – that adds special meta headers and provides simple API for modified gettext calls that gives client direct information on where the entities are located, so that the client does not have to guess.

I’ll dig into details in a separate post, there’s much more into how Pontoon can operate and what are the possible enhancements for each of the three components, but for now, I’d like to present you a short video of Pontoon used to localize two old versions of our website projects.

The video is a coffee-long, so feel free to grab one and schedule 6 minutes 🙂

urls used in the video:

notes:

  • the locale codes that are supported by the server are usually ab_CD, not ab – for example de_DE, fr_FR etc.
  • pontoon does not support multiple users at the same time, so you may observe strange results when many people will try it at the same time. Enjoy alpha mode!
  • “0.1 alpha” means – I’m looking for feedback, comments, ideas and contributions 🙂

Categories
main mozilla tech

My vision of the future of Mozilla localization environment (part1)

After two parts of my vision of local communities, I’d like to make a sudden shift to write a bit about technical aspects of localization. The reason for that is trivial. The third, and last, part of the social story is the most complex one and requires a lot of thinking to put it right.

In the meantime, I work on several aspects of our l10n environment and I’d like to share with you some of the experiences and hopes around it.

Changes, changes

What I wrote in the social vision, part 1 about how the landscape of Mozilla changes and gets more complex, stands true from localization perspective and requires us to adapt in a similar fashion as it requires local communities.

There are three major shifts that I observe, that makes our approach from the past not sufficient.

  1. User Interfaces become more sophisticated than ever
  2. Product forms are becaming more diversified and new forms of mashups appear that blend web data, UI and content
  3. Different products have different “refresh cycles” in which different amount of content/UI is being replaced

Historically, we used DTD and properties for most of our products. The biggest issue with DTD/properties is that those two formats were never meant to be used for localization. We adapted them, exploitet and extended to match some of our needs, but their limitations are pretty obvious.

In respose to those changes, we spent significant amount of time analyzing and rethinking l10n formats to address the needs of Mozilla today and we came up with three distinct forms of data that requires localization and three technologies that we want to use.

L20n

Our major products like Firefox, Thunderbird, Seamonkey or Firefox Mobile, are becoming more sophisticated. We want to show as little UI as possible, each pixel is sacred. If we decide to take that screen piece from the user, we want to use it to maximum. Small buttons, toolbars should be denser – should present and offer more power, be intuitive and allow user to keep full control over the situation.

That exposes a major challenge to localization. Each message must be precise, clear and natural to the user to minimize his confusion. Strings are becoming more complex, with more data elements influencing them. It’s becoming less common to have plain sentences that are static. It’s becoming more common that a string will show in a tooltip, will have little screen (Mobile) and will depend on the state of other elements(number of open tabs, time, gender of the user).

DTD/properties are absolutely not ready to meet those requirements and the more hacks we implement the harder it’ll be to maintain the product and its localizations. Unfortunately other technologies that we considered, like gettext, XLIFF or QT’s TS file format are sharing most of the limitations and are being actively exploited themselves for years now (like gettext’s msgctxt).

Knowing that, we started thinking about how would localization format/technology look like if we can start it today. From the scratch. Knowing what we know. With experience that we have.

We knew that we would like to solve once and for all the problem with astonishing diversity of languages, linguistic rules, forms, variables. We knew we’d like to build a powerful tool set that would allow localizers to maintain their localizations easier, and localize with more context information (like, where the string will be used) than ever. We knew that we want to simplify the cooperation between developers and localizers. And we knew we would love to make it easy to use for everyone.

Axel Hecht came up with a concept of L20n. A format that shifts several paradigms of software localization by enabling algorithmic power outside of the source code. He’s motto is “Make easy things easy, and complex things possible” and that’s exactly what L20n does.

It doesn’t make sense to try to summarize L20n here, I’ll dig deeper in a separate blog post in this series, but what’s important for the sake of this one, is that L20n is supposed to be a new beginning, different than previous generations of localization formats, differently defining the contract between localizer and developer called “an entity”.

It targets software UI elements, should work in any environment (yes, Python, PHP, Perl too) and allow for building natural sentences with full power of each language without leaking this complexity to other locales or developers themselves. I know, sounds bold, but we’re talking about Pike’s idea, right?

Common Pool

While our major products require more complexity, we’re also getting more new products that appear in Mozilla, and very often they require little UI, because they are meant to be non-interruptive. Their localization entities are plain and simple, short and usually have single definition and translation. The land of extensions is the most prominent example of such approach, but more and more of our products have such needs.

Think of an “OK” and “Cancel” button. In 98% of cases, their translations are the same, no matter where they are used. In 98% of cases, their translations are the same among all products and platforms. On top of that there are three exceptions.

First, sometimes the platform uses different translation of the word. Like MacOS may have different translation of “Cancel” than Windows. It’s very easy, systematic difference shared among all products. It does not make any sense to expose this complexity to each localization case and require preparing each separately for this exception.

Second, sometimes an application is specific enough to use a very specific translation of a given word. Maybe it is a medical application? Low level development tool or for lawyers only? In that case, once again, the difference is easy to catch and there’s a very clear layer on which we should make the switch. Exposing it lower in a stack, for each entity use, does not make sense.

Third, it is possible that a very single use of an entity may require different translation for a given language. That’s an extremely rare case, but legitimate. Once again, it doesn’t make sense to leak this complexity onto others.

Common Pool is addressing exactly this type of localizations. Simple, repetitive entities that are shared among many products. In order to address the exceptions, we’re adding a system of overlays which allow a localizer to specify separate translation on one of the given three levels (possibly more).

L20n and Common Pool are complementing each other and we’d like to make sure that they can be used together depending on the potential complexity of the entity.

Rich Content Localization

The third type is very different from the two above. Mozilla today produces a lot of content that goes way beyond product UI and localization formats are terrible when dealing with such rich content –  sentences, paragraphs, pages of text mixed with some headers and footers that fill all of our websites.

This content is also diversified, SUMO or MDC articles may be translated into a significantly different layout and their source versions are often updated with minor changes that should not invalidate the whole content. On the other hand small event oriented websites like Five Years of Firefox or Browser Choice have different update patterns than project pages like Test Pilot or Drumbeat.

In that case, trying to build this social contract between developers and localizers by wrapping some piece of text into uniquely identifiable objects called entities and using some way to sign them and match translation to source like we do with product UI doesn’t make sense. Localizers need great flexibility, some changes should be populated to localizations automatically, only some should invalidate them.

For this last case, we need very different tools, that are specific for document/web content localization and if you ever tried Verbatim or direct source HTML localization you probably noticed how far it is from an optimal solution.

Is that all?

No. I don’t think so. But those are the three that we identified and we believe we have ideas on how to address them using modern technologies. If you see flaws in this logic, make sure to share your thoughts.

Why I’m writing about this?

Well, I’m lucky enough to be part of L10n-Drivers team in Mozilla, and I happen to be involved in different ways in experiments and projects that are going to address each of those three concepts. It’s exciting to be in a position that allows me to work on that, but I know that we, l10n-drivers, will not be able to make it on our own.

We will need help from the whole Mozilla project. We will need support from people who produce content, create interfaces and who of course from those who localize, from all of you.

This will be a long process, but it gives us a chance to bring localization to the next level and for the first time ever, make computer user interfaces look natural.

In each of the following blog posts I’ll be focusing on one of the above types of localizations and will present you projects that aim at this goal.