Language can be very difficult to capture within software localization. Each natural language in the world evolves at its own pace and in its own unique way, creating vibrant and rich means of expression. Sadly, simple static string translation is often ill-equipped to properly accommodate gender, conjugation, plural, or case changes required within the language by changing string variables and other run-time string composition issues. This is why we created L20n.

We’re super happy to announce that we’ve released an amazing tool to help localizers, engineers, and localization tool developers learn and practice L20n themselves! l20n.org contains a real-time text editor that allows you to edit L20n code and visually see how it impacts localization. The real-time editor is part of the “Learn” section of l20n.org dedicated to walk you through what L20n has to offer, feature by feature, and give you a chance to try these features out in real-time.

L20n is a localization framework (comprised of a pseudo-programming language) meant to transfer the ability to localize software using the fullness of any language from the developer to the localizer. L20n empowers localizers to be more independent of source language developers and have more control and flexibility in localizing software according to their native language’s demands.

l20n.org is live and running now! Go give it a try! Not only is it live, but its hosted on github for you to fork and contribute to. Enjoy testing out L20n!

 

In response to my post earlier this week on Tinderbox’s end-of-life, reader Carsten Mattner asked:

Reading [your post], I couldn’t figure out what replaced Tinderbox for the Mozilla builds. What feeds tbpl? Does Mozilla not use Tinderbox to build continuously?

When I left Mozilla in 2007, there was a Release Engineering project in progress to actively replace Tinderbox (Client) with buildbot. So in short, no, Mozilla does not use Tinderbox Client to drive its continuous integration builds, and hasn’t for some time.

Do they still use buildbot today?

I didn’t know the answer to that question, so I tracked down Coop on IRC, who graciously gave me a few minutes of his time to answer exactly that.

He said:

• Mozilla currently uses “95% buildbot, with 5% Jenkins for random small projects”
• There are multiple buildbot masters that drive the buildbot clients
• Unlike the out-of-the-box buildbot master setup, the masters query a job scheduling database instead of monitoring source control for changes themselves; they then report their results to a database, which tbpl (and other services) use to generate their reports/dashboards; the buildbot master waterfall pages aren’t accessible to the external world (which makes sense, because they include unsecured administrative functionality1)
• There are about 60 masters right now, but Coop said “number keeps growing though, so we need to rethink the whole solution”

So there’s your answer, Carsten!

_______________
1 A long standing criticism of mine, among others?

I’ve got a Beer & Tell to give about alembic. Alembic is a migration tool that works with SQLAlchemy. I’m using it for database migrations with PostgreSQL.

So, here’s what I want to say today:

• Written by SQLAlchemy wiz Mike Bayer
• Here’s the tutorial. Socorro is now using alembic in production with SQLAlchemy 0.6.x. I’m hoping to get us upgraded to 0.8.x soon.
• Here’s what running an upgrade in production for Socorro looks like. Awesome right?
• Here’s what a migration looks like.
• Here’s a configuration file.
• Generating a migration from the command line might look something like:
  alembic revision -m "bug XXXXXX Add a new table" --autogenerate

The most difficult thing to deal with so far are the many User Defined Functions that we use in Socorro. This isn’t something that any migration tools I tested deal well with.

Happy to answer questions! And I’ll see about making a longer talk about this transition soon.

cross-posted from the Webmaker blog

We use Bugzilla to work open and get stuff done

Webmaker, like many Mozilla projects, uses an issue tracker called Bugzilla for filing tickets and getting stuff done. These two new pages provide tips and tricks for filing bugs, and for getting the most out of Bugzilla:

1. Bugzilla for Webmaker — the best place to start. How to file a Webmaker bug, plus simple tweaks for making Bugzilla easier to use.
2. Bugzilla for Webmaker: PRO TIPS – for digging deeper. How to make it easier for users to file tickets, tagging, searching and tracking bugs, Frequently Asked Questions and more.

Anyone can create, comment or contribute to a ticket

We work open. Webmaker is an open source, non-profit project powered by a global community of friendly humans like you. Anyone can create a ticket, comment on a ticket, and contribute. Just because it’s called a “bug” doesn’t necessarily mean there’s something wrong. It could just be a to-do, or a suggestion. All your tickets are welcome — don’t worry if you’re doing it right. We’re a friendly community, and we want your ideas!

What: Mozilla Open Web Open Mic
When: May 22, 6-9pm ET.
Where: Mozilla Toronto, 366 Adelaide St. W, 5th Floor

Mozilla Open Web Open Mic (OWOM) is back for May. Put on by the Mozilla Toronto community, OWOM features a science share exploration and lightening talks (5 min). April’s event had a great turnout (50-60 people) and included a variety of content from WEBVTT, to MakerFaire, to my talk Building for Mobile Web Compatibility.

The call is currently open for science share participants and speakers. Sign up at
https://mozillianstoronto.etherpad.mozilla.org/owom-may-2013

Interested in attending? Sign up now at
http://owommay2013.eventbrite.ca/#

Tagged: mozilla, mozilla community, toronto

In grad school, I remember a conversation across the campus green with an visiting psychologist from Harvard.  I don’t remember much about the conversation except that he introduced me to Isaiah Berlin’s notion of the Hedgehog and the Fox, and correctly pegged me as a Fox.  I think I was a bit offended at the simplification, but time has proven him right.  I’m certainly no hedgehog.

I got into a silly argument on twitter last night, about whether my looking to hire someone who I labeled (as job descriptions make us do) a “Coding Designer” was not just foolish (I’d seen the Unicorn references in my tweetstream already) but apparently a bad idea, because, so the ultra-simplified argument goes, you somehow can’t be both.  And so I’ll use the energy to rant a bit about what seem to be prevailing attitudes around titleism and narrow definitions of “professionalism”.

We all need to define ourselves to others. It helps us be understood, and hopefully valued.  Labels can be useful for that. We also, even more, like to label others.  It helps us simplify our approach to them.  If I can find a label for you, then I can rely on a prioris about how people with that label tend to think and behave, and I don’t need to actually get to know you too much.  The more people we interact with, the more important these shortcuts are.  Some roles are particularly subject to that (Recruiters, VCs, politicians, etc. — people who routinely talk to dozens if not hundreds of people a day).  And the best at these roles are those who use a different labeling system than their peers.  Recruiters who see the latent ambition or genius in a shy candidate; VCs who see the determination behind a stutter, or, conversely, the lack of self-confidence behind the bravado, etc.

Labels are useful and practical in the short term.  And I don’t know how one could run a large HR department without them.  But we should be careful to not take them too seriously, as in the long term, they can hurt. They hurt because people, especially interesting, worth-getting-to-know people, are much more subtle, complicated, confusing and hard to categorize creatures.  Whether you take the label too seriously when thinking about others (e.g., refuse to see the valid opinion about a design expressed by a non-Designer) or about yourself (and limit your impact on the world because “oh, that’s not something that a mere ____ like me could say/do”), you’re not getting the most out of anyone involved.

As I write this, I realize that I feel quite strongly about this topic.  Part of it is probably because I grew up in an educational system, which at least then believed way too much in labeling people and determining their fate based on that label.  Much waste ensued.  Part of it is probably because I can’t for the life of me figure out what my label should be, and if I can’t, then that must be bad. I’ve had a range of professional labels, from scientist to engineer, architect, team lead, vice president, CTO, CEO, blah blah blah.  I’ve been called a designer, strategist, entrepreneur, boss, blah blah blah. None of those words will, I hope, be in my epitaph.  And so I get cranky on twitter at night, because if there are people who strive to be both excellent at design and at coding, then by golly we should encourage them.

Titles are a poor approximation of a professional ideal, and a profession is a poor approximation of a human’s breadth, contributions, and talents.  Embrace your inner fox, and if you happen to have both design and coding skills, can see a problem, conjure up a solution, prototype it, welcome challenges to your idea from peers, data, and users, apply.

In grad school, I remember a conversation across the campus green with an visiting psychologist from Harvard.  I don’t remember much about the conversation except that he introduced me to Isaiah Berlin’s notion of the Hedgehog and the Fox, and correctly pegged me as a Fox.  I think I was a bit offended at the simplification, but time has proven him right.  I’m certainly no hedgehog.

I got into a silly argument on twitter last night, about whether my looking to hire someone who I labeled (as job descriptions make us do) a “Coding Designer” was not just foolish (I’d seen the Unicorn references in my tweetstream already) but apparently a bad idea, because, so the ultra-simplified argument goes, you somehow can’t be both.  And so I’ll use the energy to rant a bit about what seem to be prevailing attitudes around titleism and narrow definitions of “professionalism”.

We all need to define ourselves to others. It helps us be understood, and hopefully valued.  Labels can be useful for that. We also, even more, like to label others.  It helps us simplify our approach to them.  If I can find a label for you, then I can rely on a prioris about how people with that label tend to think and behave, and I don’t need to actually get to know you too much.  The more people we interact with, the more important these shortcuts are.  Some roles are particularly subject to that (Recruiters, VCs, politicians, etc. — people who routinely talk to dozens if not hundreds of people a day).  And the best at these roles are those who use a different labeling system than their peers.  Recruiters who see the latent ambition or genius in a shy candidate; VCs who see the determination behind a stutter, or, conversely, the lack of self-confidence behind the bravado, etc.

Labels are useful and practical in the short term.  And I don’t know how one could run a large HR department without them.  But we should be careful to not take them too seriously, as in the long term, they can hurt. They hurt because people, especially interesting, worth-getting-to-know people, are much more subtle, complicated, confusing and hard to categorize creatures.  Whether you take the label too seriously when thinking about others (e.g., refuse to see the valid opinion about a design expressed by a non-Designer) or about yourself (and limit your impact on the world because “oh, that’s not something that a mere ____ like me could say/do”), you’re not getting the most out of anyone involved.

As I write this, I realize that I feel quite strongly about this topic.  Part of it is probably because I grew up in an educational system, which at least then believed way too much in labeling people and determining their fate based on that label.  Much waste ensued.  Part of it is probably because I can’t for the life of me figure out what my label should be, and if I can’t, then that must be bad. I’ve had a range of professional labels, from scientist to engineer, architect, team lead, vice president, CTO, CEO, blah blah blah.  I’ve been called a designer, strategist, entrepreneur, boss, blah blah blah. None of those words will, I hope, be in my epitaph.  And so I get cranky on twitter at night, because if there are people who strive to be both excellent at design and at coding, then by golly we should encourage them.

Titles are a poor approximation of a professional ideal, and a profession is a poor approximation of a human’s breadth, contributions, and talents.  Embrace your inner fox, and if you happen to have both design and coding skills, can see a problem, conjure up a solution, prototype it, welcome challenges to your idea from peers, data, and users, apply.

In grad school, I remember a conversation across the campus green with an visiting psychologist from Harvard.  I don’t remember much about the conversation except that he introduced me to Isaiah Berlin’s notion of the Hedgehog and the Fox, and correctly pegged me as a Fox.  I think I was a bit offended at the simplification, but time has proven him right.  I’m certainly no hedgehog.

I got into a silly argument on twitter last night, about whether my looking to hire someone who I labeled (as job descriptions make us do) a “Coding Designer” was not just foolish (I’d seen the Unicorn references in my tweetstream already) but apparently a bad idea, because, so the ultra-simplified argument goes, you somehow can’t be both.  And so I’ll use the energy to rant a bit about what seem to be prevailing attitudes around titleism and narrow definitions of “professionalism”.

We all need to define ourselves to others. It helps us be understood, and hopefully valued.  Labels can be useful for that. We also, even more, like to label others.  It helps us simplify our approach to them.  If I can find a label for you, then I can rely on a prioris about how people with that label tend to think and behave, and I don’t need to actually get to know you too much.  The more people we interact with, the more important these shortcuts are.  Some roles are particularly subject to that (Recruiters, VCs, politicians, etc. — people who routinely talk to dozens if not hundreds of people a day).  And the best at these roles are those who use a different labeling system than their peers.  Recruiters who see the latent ambition or genius in a shy candidate; VCs who see the determination behind a stutter, or, conversely, the lack of self-confidence behind the bravado, etc.

Labels are useful and practical in the short term.  And I don’t know how one could run a large HR department without them.  But we should be careful to not take them too seriously, as in the long term, they can hurt. They hurt because people, especially interesting, worth-getting-to-know people, are much more subtle, complicated, confusing and hard to categorize creatures.  Whether you take the label too seriously when thinking about others (e.g., refuse to see the valid opinion about a design expressed by a non-Designer) or about yourself (and limit your impact on the world because “oh, that’s not something that a mere ____ like me could say/do”), you’re not getting the most out of anyone involved.

As I write this, I realize that I feel quite strongly about this topic.  Part of it is probably because I grew up in an educational system, which at least then believed way too much in labeling people and determining their fate based on that label.  Much waste ensued.  Part of it is probably because I can’t for the life of me figure out what my label should be, and if I can’t, then that must be bad. I’ve had a range of professional labels, from scientist to engineer, architect, team lead, vice president, CTO, CEO, blah blah blah.  I’ve been called a designer, strategist, entrepreneur, boss, blah blah blah. None of those words will, I hope, be in my epitaph.  And so I get cranky on twitter at night, because if there are people who strive to be both excellent at design and at coding, then by golly we should encourage them.

Titles are a poor approximation of a professional ideal, and a profession is a poor approximation of a human’s breadth, contributions, and talents.  Embrace your inner fox, and if you happen to have both design and coding skills, can see a problem, conjure up a solution, prototype it, welcome challenges to your idea from peers, data, and users, apply.

Mozilla Has Decided Not To Block Cookies In Firefox Just Yet
WebProNews
Online advertisers have been nervous the past few weeks as Mozilla moved forward with its plans to block third-party cookies by default in its Firefox browser. Some advertiser groups have even claimed that Mozilla's policy will “undermine American ...

Back in March, we kicked off the first in hopefully a series of train-the-trainer (TTT) events for webmaking.

The idea is to run events that train people who go on to train others how to teach the web. We focused on practicing an open and participatory ethos, adapting lesson plans, and facilitating events.

This is a post to share what we did and encourage people in designing their own train-the-trainer events.

How to run a Webmaker Train the Trainer

Our prototype, the Reps Training Days, ran for four days in Athens, Greece with 40 Reps from around the world. The agenda was based on Laura Hilliger’s research and insights on successful TTT program and on Allen Gunn’s participatory event methodology. It was made possible by the amazing Mozilla Greek community.

Our participants were Mozilla Reps, a fantastic ambassador program with some of the most active and thoughtful Mozillians. Reps have been early adopters and innovators with Webmaker. They organized nearly 50 events during last year’s Summer Code Party and are leading the way in developing tools, tutorials, and localization for Webmaker. It seemed like a natural fit to run our first TTT with them.

1. Participate in a Webmaker event

The first day of Training Days was spent observing and participating in a Hive Pop-Up, organized by Hive Athens. This was an opportunity for the participants to experience a webmaker event firsthand, to see the tools and activities in action, to learn about the logistics, and to understand the vibe.

We then circled up to discuss what we saw. Participants shared their reflections on what worked well at the pop-up and what they would change if they did their own.

2. Build the training agenda

Then we opened up the training days properly. While we had topics in mind we wanted to hack on together, it was more important that everyone in the room thought about what they want to learn or discuss. So we had an agenda brainstorm.

To do this: we split into groups for 3 people. On post-it notes, we wrote down topics. 1 topic per post-it and the encouragement to write it as concretely as possible.

Then everyone pasted the notes on the wall. We read them all and then clustered them by themes. This collaborative board formed both critical event documentation as well as agenda fodder for the coming days.

3. Teach someone something

To warm up to the idea of teaching, we then got into pairs. The task: teach someone something in 5 minutes.

One person would go and then switch. Even if you knew what was being taught, you were encouraged to play a good learner, asking good questions and prompting the teacher.

After this exercise, we circled up and discussed what we observed from this experience. For many, it was a great way to think about how to explain something clearly, using metaphors and knowledge building blocks. It helped bring people into a teaching mindset.

4. Make a learner profile

Now that we’ve been thinking about teachers and learners, we made small groups and hacked together a learner’s profile.

This goal of this activity was to think about who our learners are. We used Webmaker tools to make these profiles, which was also a fun, maker-y way to be introduced to these tools. Participants were encouraged to think about real people they want to teach.

5. Hack an event invitation

After we’ve made our learner profiles, we thought about the kind of event we wanted to run. Most of the participants have already organized Webmaker events in the past, so there was already some familiarity with the format.

Nevertheless, it was helpful to hack together an event invitation. The idea was to think about your target learner and to make an invitation that would speak to them. Again, we used Webmaker tools to quickly pull these invitations together on the web.

6. Deep dive into lesson plans

With a learner profile, an event invitation and some familiarity with Webmaker tools, we then introduced the hackable kits. These are remixable lesson plans that help mentors, trainers, etc. to teach the web. The idea is that they are adaptable to different contexts and that people can share new ways of teaching in a shared format.

Participants poked around in the kits and asked questions. We also did some fun icebreakers so they could see the activities in action and get some energy going.

7. Playtest lesson plans

Now came the fun part. We had to plan for a real live event the next day. So participants got into groups of five with one group facilitator.

They had to design a four-hour agenda for local youth. Using three recommended activities from the kits, they adapted the lesson plans. Then they walked through a script for the next day, including having people role-play as learners. It was a lot of fun to see and a great way to prepare for the big day.

8. Put training to practice at a live event

So with some nervousness, we got ready for the live event. About a hundred youth were coming. We split into different rooms, each group of five trainers getting about 20 learners.

While there were the inevitable challenges (the internet is down! one kid won’t listen!), the Reps did a terrific job. They rolled with their scripts, adapting them as they saw what was working. They also taught well in smaller pairs with their learners, sometimes adding new challenges or tools to fit their needs.

It was a beautiful and fun thing to see. All the training the days before paid off: the youth had a lot of fun and so did we.

9. Reflect on event, lessons learned and where from here

We ended the event with a closing circle. We talked about what we saw that day, what worked well, what didn’t. We each shared one thing we appreciated about the experience, and what we’re excited about doing next.

With that, we headed out into the city to enjoy the day and the rest of our time together.

10. Go forth and teach!

Each participant left the Training Days with a local plan. It was a short list of possible collaborators in their hometown, a date for a small team huddle to bring those people together, and then a date for a larger Webmaker event to organize with their new collaborators.

We also started interest groups in topics like localization and offline tools. And now, a few months later, the participants from Training Days are now “Webmaker Super Mentors”, mentoring people in an online course to learn how to teach the web.

In the coming months, we hope to keep remixing and improving these agendas, as well as work with people who are interested in TTT in their own cities or communities.

Let us know if you’d like to get involved! #teachtheweb

Firebug 1.12 alpha 6 introduces one new feature called simply: Use in Command Line

This feature allows referring various page objects (HTML elements, JS objects, network requests, cookies, etc.) from within Firebug Command Line.
The user can also use object's properties in JS expressions.

See issue 6422 for more details.

This post explains the feature in detail and also asks for feedback.

How it works

As depicted on the previous screenshot the feature is represented by a new context menu item called Use in Command Line. This item is available for various objects (in various panels).

The action is simple: an expression $p is inserted into the Command Line if you execute the command. It's a variable that refers to the clicked object. You can also use the variable to access any property of the object.

What happens on the screenshot:

• The DOM panel shows an object person implemented on the page.
• The user clicks on the person's value (the green right hand part) and executes Use in Command Line.
• Command Line popup is opened within the DOM panel (so, the user doesn't have to leave the DOM panel).
• $p expression is inserted into the Command Line (and the command line automatically gets focus).
• The user presses the Enter key to evaluate the expression.

Note that the person object implemented on the page looks as follows:

var person = {
    name: "Bob",
    age: 38
}

If you want to access properties of an object just use dot notation. You can do following in our example.

$p.name

See, even the auto-completion works as expected!

Supported Objects

The feature is implemented for various objects across all Firebug panels. Here is a list of those objects.

• Any JS object (even functions etc.)
• HTML elements
• CSS rules and properties
• Cookies
• Network requests

Call for Feedback

All objects accessible through the $p variable are coming from the page content except of network requests and cookies.

We are actually logging nsIHttpChannel for network requests and nsICookie for cookies. So, the object comes from chrome (privileged scope) and isn't accessible in the page content. This way, the user has more info, but it could be confusing since the user could expect that the data are actually accessible from the page content (and Firebug is for page content debugging).

Possible options:

• Do not implement the feature for network requests and cookies
• Implement the feature only for XHRs (and show the real XMLHttpRequest instance) and cookie (coming from document.cookie)
• Keep it as it is
• Anything else?

What do you think?

Also, would you like to refer more objects at the same time? Something like having more variables (a history) available: $p0, $p1, $p2, ...

How would you expect it to be working?

Thanks for any feedback!

Firefox 22 Won't Block Third-Party Tracking Cookies: Why Mozilla Delayed ...
iDesignTimes.com
After all the fuss we've heard about Mozilla Firefox update 22 including a controversial third-party cookie tracking blocker, it seems that it might have been a little too good to be true as Mozilla announced this week it will delay blocking third ...

Mozilla Firefox delays patch to block third-party cookies
Washington Post
Mozilla, the non-profit group that makes the Firefox browser, says that it will delay its plans for rolling out a version of its browser that would increase restrictions on cookies — pieces of code that allow companies to monitor how people use the Web.

en meer »

Mozilla postpones default blocking of third-party cookies in Firefox
PCWorld
Mozilla has postponed blocking third-party cookies by default in Firefox 22, "to collect and analyze data on the effect of blocking some third-party cookies." The nonprofit organization is, however, not softening its stand on protecting privacy and ...

Mozilla breekt belofte cookie-blokkade in Firefox 22
Webwereld
Nieuws - Het gaat Mozilla niet lukken om Firefox 22 zoals beloofd te voorzien van een standaard third party cookies-blokkade. De browsermaker heeft meer tijd nodig. Firefox 22 gaat niet standaard third party cookies van bijvoorbeeld ...

Mozilla postpones default blocking of third-party cookies in Firefox
InfoWorld
Mozilla has postponed blocking third-party cookies by default in Firefox 22, in order "to collect and analyze data on the effect of blocking some third-party cookies." The nonprofit organization is, however, not softening its stand on protecting ...

Mozilla brings power of the web into ordinary people's hands. Every day I spend countless hours working with volunteer communities around the world to translate Firefox web browser. Reading Sudheesh Singanamalla's blog post about his encounter with a farmer in rural India was such a touching experience.

A Localization journey - A Farmer's tale - A Delightful Experience

It was on my way back in a cramped out bus, travelling researching about language changes and variations within the state of Andhra Pradesh, that I sat next to a man, quite old.

Me : What do you use in the internet? How do you talk to your son?
Old man: I go to Rajat's Net Cafe nearby by house and then talk from there on Google (meant Google+)
Me : Do you know how to read English and understand which button to click and so on?
Old man : Oh, i don't know English, but i use it in Telugu. The shop guy Rajat has seen me since he was small, so after my son went to Delhi, he separately bought a Telugu keyboard so that i can be using the keyboard.
Me: Okay, but then how do you read the information on the computer screen? Isn't that in English?
Old man : (Laughs) Don't you know, there is this software something called Firefox, it is in Telugu.
Me : Really? Can you tell me how the software looks?
Old man : You should know more, you're an engineering student but if you ask i'll tell you, its a small thing like this earth picture but a small cat , orange in colour is holding it.
Me: (smiling crazily) You know how to use it in Telugu?
Old man : Yeah, its not hard, I know how to read Telugu and also know how to use mouse, so clicking gets me the job done.
 

Mozilla's plans to block third-party cookies by default in Firefox postponed ...
Tech2
Mozilla wants to ship a patch with the setting being turned on by default, but it still needs some refinement. According to Mozilla, "Our next engineering task is to add privacy-preserving code to measure how the patch affects real websites. We will ...

Yesterday, Google organized an invite-only summit for mobile web and tools developers. As an engineer working on Firefox Developer Tools, I was invited to be on a panel about mobile testing and tooling. This is my attempt to write down my answers in hope they’ll be useful for someone out there. I suggest reading them as separate, individual mini essays.

Read it on Medium

As engineers, I believe the way we approach a problem is as important as the code we write. This is especially relevant in the context of UI engineering where design is such a vital element.

Unfortunately, it seems quite hard to find good content about everything that happens around us and inside our heads when we are building user interfaces. This is what The Layout is about.

My intent is to create a space for high quality content discussing the principles, mindset, and practices that I believe shape the craft of UI engineering. It is meant to be a shared space with many voices—so, expect some awesome guest authors.

I’ve just posted the very first article, Mind the Gap. My plan is to publish a new article every other week-ish. For now, subscribe to the RSS feed or simply follow The Layout on Twitter or Google+ to get future updates.

I really hope you enjoy it!