Monthly Archives: November 2011

MDN 1.6

Posted by on November 22, 2011 4 comments

MDN 1.6

We released MDN 1.6 today.

MDN

Kuma

Up next

For MDN 1.7 we will:

  • Complete the switch from MindTouch authentication & users to django authentication & users.
  • Add some spiffy HTML5 features to MDN.
  • (Start to) Merge the separate kuma (master) and mdn (mdn) branches into a single branch so we can optimize our git workflow and run the new wiki side-by-side with MindTouch for testing and comparison.
  • Promote MDN developer profiles.
  • Include various content changes and bug fixes.

In other news(?), as you can see from my Google search box there, Angry Birds Web now works in Firefox, and Safari and IE9. (Why does Rovio give Opera a big fat screen to download Google Chrome? How much is Google paying these developers to bundle or promote Chrome with everything?) Someone needs to tell Rovio it's not just for the Chrome Web Store anymore. And someone needs to tell Google that "Chrome Web" is as senseless as "Firefox Web", "Explorer Web", "Opera Web", "Safari Web", "Xbox Web", "iPhone Web", or anything else into which companies are trying to confine the web these days.

Angry Birds Chrome-only?

pseudo-translation to test i18n

Posted by on November 18, 2011 4 comments

MDN Unicode BannerI really like that Mozilla has a strong L10n team made up of both employees and community volunteers. Months ago we made some cool localization changes to MDN, and I learned a lot about django localization, gettext, pootle, and translate toolkit.

Back then Leszek, a localization volunteer and add-on developer, filed a bug about a bunch of un-localized MDN strings, and then found a bunch more un-localized strings again recently. I remembered I had read about using pseudo-translations for localizability testing, and thought I'd try it for MDN.

MDN, like (almost?) all Mozilla webdev projects, uses gettext message files (svn), so we can use translate toolkit. (woo! SourceForge project!) We also use a product_details repository (svn) to closely track the same language and country codes used by other Mozilla products. I needed to add the new test locale, but Pike pointed out we have to use a single-character subtag (x-testing) to indicate a privately-defined language code (per ietf bcp47), while Stas pointed out that pootle requires a two-character subtag. So, we added 'x-testing' language to the product_details (bug), then I added  xx_testing in locale/ for pootle, along with a x_testing -> xx_testing symlink so django uses the xx_testing files for the x-testing locale.

I installed toolkit and ran podebug on our message.pot file:

cd locale/
mkdir -p xx_testing/LC_MESSAGES
podebug --rewrite=bracket templates/LC_MESSAGES/messages.pot 
    xx_testing/LC_MESSAGES/messages.po
./compile-mo.sh .

Which gave me a pseudo-translated messages.po file and a compiled .mo file.

Testing Messages PO file

I changed MDN to use the environment-specific language-loading snippet (found in playdoh funfactory) to keep the test locale from showing up in production. (We have to add the 'x-testing' locale to linux on our staging servers so gettext can use it there, which proves to be quite a chore.)

Voilà - a new pseudo-translated locale for MDN development. It shows which strings we forgot to mark for localization:

MDN strings missing 18n

Couple of items I'd like help with:

  • Find out how to exclude jinja template variable names so that 
    {{ _('Welcome back, {username}]) }}

    doesn't create

    #: templates/includes/login.html:3
msgid "Welcome back, {username}"
msgstr "Ẇḗŀƈǿḿḗ ƀȧƈķ, {ŭşḗřƞȧḿḗ}"
  • Put all this into tower

MDN Agile and status

Posted by on November 9, 2011 No comments

tl;dr: We're settling into an Agile process for MDN with daily standups and weekly planning. In the last few months we've added and enhanced developer profiles, events, demos dev derby, and other MDN features. We've also restored, added, and enhanced drafts, review flags, search, article properties, section editing, and authentication in the new wiki. I'll try to write status posts more frequently - each time we make a release, if possible.

AgileAgile

Since my last MDN & Kuma progress post, we've settled into a regular, yet customized, Agile methodology in the MDN team with our agile Bugzilla JS tool. We've pushed MDN 0.9.8, 0.9.9, 1.0, 1.1, 1.2, 1.3, 1.4, and 1.5 thru it relatively smoothly. We've learned and adapted a few techniques in our Agile process worth noting:

Daily standups on IRC

  1. What have you done since we last met?
  2. What do you plan to do until we meet next?
  3. Are you blocked by anything?

By far the 3rd question here is the most important. The first questions are mostly intended to lead into the 3rd. Our scrum-master (now me) is tasked with removing any and all blockers as much as possible - usually chasing down people in other groups from whom we need something (IT, DevEngage, Legal, Security, etc.)

(Bi-)Weekly Retro & Planning Poker

We push code on Tuesdays, so we alternate between post-/pre- and mid-sprint planning meetings. Mid-sprint planning meetings are shorter and faster, little more than a standup. We use an etherpad template for a running minutes of our weekly Wednesday meetings. The basic format is:

  1. Retro - what's go[(ing)|(ne)] good or bad in the sprint?
  2. Discuss - general items to discuss, usually flowing from Retro
  3. Planning (post/pre-sprint only) - re-assess bugs carried over from previous sprint, use planningpoker.com to estimate the current sprint backlog in bugzilla

Test Chamber ProgressStatus

We're developing major features for both MDN and the upcoming wiki.

MDN

  • Developer profiles
    My MDN profile is missing demos because I haven't made any yet. :( We want to hook this up with Mozillians.org in the (near) future.
  • Events
    We've tried to make the MDN events page a comprehensive resource to find the events Mozillians attend. Inspired originally by Christian's site for Mozilla events.
  • Demos & Dev Derby
    We've done significant work on the Dev Derby feature - streamlining the process and clearing out bugs. This is one of my favorite MDN features. When I need to show anyone cool web technology I can open the MDN demo studio and inevitably find something way cool with canvas, video, audio, and webgl.
  • Miscellaneous
    We're also finding and squashing bugs as often as we can. We finally restored production server error emails, so we should be much better about squashing bugs that real users are are hitting. And we're trying to add smaller optimizations and fun features as often as we can.

I enjoy enhancing MDN in addition to building the new wiki system. The wiki is important and should help us take more control over our docs, but it's still behind-the-scenes; I like shipping code to a production site that helps people, especially developers, immediately.

Wiki

We hope to soon (by the end of the year) run the new wiki side-by-side with MindTouch so we can work from a single line of code and allow testers to compare MindTouch with the new wiki on the same server. But so far we've developed the following features on the separate kuma wiki staging server:

  • Drafts
    We use localStorage to periodically save the editing session so a writer doesn't lose precious work if their client crashes.
  • Review Flags
    We added review flags for both technical and editorial review.
  • Search
    We restored the Sphinx-powered search backend we inherited from SUMO/kitsune (just in time for them to move on to ElasticSearch). We still need to restore all of the search frontend and ancillary features.
  • Page Properties
    We restored and refactored document properties we inherited from SUMO/kitsune.
  • Section Editing
    We added section editing to the wiki - our first major modification to the wiki functionality we inherited from SUMO/kitsune.
  • Authentication
    We're in the middle of switching MDN user authentication from MindTouch to django. We will run both authentication backends together, first django then falling back to MindTouch and auto-registering and migrating users to django authentication as they log in.

The wiki work is going pretty well, but we still have a couple of major hurdles to clear: data migration & user scripting. We are already investigating data migration a bit, and once we start migrating data over it should help direct our work on user scripts. In my opinion, we can see light at the end of the tunnel but we're still watching out to avoid potential train-wrecks.

The rest

Outside of MDN, I helped pull together an HTML5 track for Tulsa Tech Fest, helped organize a Tulsa Hackathon with Tulsa Web Devs, and I participated in Startup Weekend Tulsa. At SWT we started a quick web app on top of the TRIF project from Hackathon called OttoZen to send an SMS alert to someone when there's a traffic incident on their commute. It's making us consider building a broader Data/App site for Oklahoma. We'll see.

From now on I'll try to make a status post every time we make an MDN release.