MDN 1.9

Posted by on 05 Jan 2012 Go to original comments

MDN 1.9

MDN 2.0

  • Set up 'master' and 'next' branches and corresponding stage servers on allizom.org
  • Wiki content migration & work

BrowserID

BrowserID Sign-inA few years ago I pushed hard for OpenID on SourceForge.net. OpenID was and is a noble project. But now I can tell some big advantages of BrowserID over OpenID:

  • It feels like an identity. I cognitively associate my online identity with my email, and BrowserID is a verified-email protocol. When I saw my email in the BrowserID login dialog on MDN, I already understand that I'm logging in - much more-so than an empty 'URL' input box.
  • No NASCAR effect. Because BrowserID is designed to be an open web standard, there's a single sign-in button that invokes a javascript API. It can be polyfilled with Mozilla's BrowserID service until platforms implement it, but even that will automatically be consumed by platform-native UI.
  • The site already knows you. As a site owner, we already have email addresses for our users. So when you sign in with BrowserID, we don't have to say "Now sign in with your existing account to merge your new identity with your existing" the way we did with OpenID. We know you own that email, so we log you into the account with that email address - simple.
  • Changing email is easy. Craig and I fretted for a whole hour or so over how to let users change their email address with BrowserID, but we were over-thinking it. Since BrowserID is effectively a streamlined "verify your email" dance, we simply point our "Change email" links to our sign-in page. If you're already signed in, and you sign in with a new verified email address, we simply update your email. BrowserID has already done the whole verify-your-email-address dance.
  • No lock-in. We get a verified email address from BrowserID, so we can register users in django with set_unusable_password(). But if we ever drop BrowserID (oh noes!), we have a verified email address. So we can initiate an email-based password reset flow for users. In addition, any site can run their own verification service so they don't need to call Mozilla's BrowserID at all.
  • Privacy. Finally, BrowserID is a user-centric identity system. This really hit me when I watched Ben's Deeper Look at BrowserID video. Especially when BrowserID is implemented in other platforms, Mozilla doesn't sit between you and the sites or services you use. A primary authority can issue identity certificates to your agent, and you present those certificates to other parties for authentication. "This triangle is never closed."

BrowserID Triangle

All-in-all, it was much simpler and much more intuitive to implement BrowserID on MDN than it was to implement OpenID on SourceForge. The Mozilla Identity team has built an awesome product, and Les integrated django-browserid with his trademark pace and effectiveness. BrowserID is great for the whole web - it will help us regain control of our online identities. It's worth repeating, "the people I work with are built of brains and heart" - it's another great day for Mozillians and for the web.

/me is so proud

MDN 1.8

Posted by on 21 Dec 2011 Go to original comments

MDN 1.8

MDN 1.9

BrowserID Flow

In Q1 2012 we are planning to sprint thru our wiki migration from MindTouch to django. Les has already started a migration script we will work on to import all the MindTouch wiki pages into django. That will be a big focus of 2.0. After that, the only big unknown is how to replace DekiScript with JavaScript.

Since Jay will be gone, John is re-joining us part-time to do some product management along with folks from the Developer Engagement team until we hire a dedicated PM. Until that happens, we're going to work hard on the wiki migration and we'll only add features if they are high priority - like Apps, BrowserID, mobile, etc.

MDN 1.7 Released

Posted by on 09 Dec 2011 Go to original comments

17We released MDN 1.7 today. Included in this release:

MDN

Wiki

  • Switch auth from MindTouch to django (big bug 674635)

MDN 1.8

The major themes of MDN 1.8 are:

  • Merge our separate mdn & wiki branches so we can develop and deploy both with a sane release process.
    It also lets run the new wiki on the production site, controlled by waffle, so we can get feedback from MDN users on the new wiki.
  • Clean up and polish the django auth.
  • Define UX and mockups for BrowserID.
  • Continue to support the Apps developer launch on MDN.

It's gonna be the future soon

Jay is leaving Mozilla! :( I'm going to miss him and his war stories from the good ol' days of Netscape. He brought a lot of insight and perspective to MDN and drove the efforts to make it more than "just" a documentation wiki. Until someone else takes over product management, we're going to put our heads down to work on the big components of the MindTouch-django wiki migration:

  1. Migrate MindTouch wiki data.
    It's nice that MindTouch stores HTML and our django wiki also stores HTML. Much better than having to parse and translate wiki markup.
  2. Implement an alternative to DekiScript
    MindTouch's DekiScript is a LuaScript subset for making dynamic content snippets in wiki pages. We're planning to implement an equivalent system based on JavaScript with a library to work with the django wiki.

I'll probably run product management interference for any urgent MDN features (e.g., apps) until we have a dedicated product manager.

Right now James and Les and I are in Toronto with #sumo and #sumodev talking about the future of the newly-amalgamating "Platforms" Webdev team. We want to open MDN, SUMO, Mozillians.org, and Input sites as community "platforms" over the next year. Stay tuned for more ...

MDN 1.6

Posted by on 22 Nov 2011 Go to original 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 18 Nov 2011 Go to original 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
Home / groovecoder by groovecoder is licensed under a Creative Commons Attribution-ShareAlike CC BY-SA
Home / groovecoder by is licensed under a Creative Commons Attribution-ShareAlike CC BY-SA