-
Ajaxian » Adobe, HTML5 Standards Blocking, and the evil of the private backroom
Sometimes the W3C standards body feels like a tycoons backroom. For such a public and important standard to live in a world of secrecy is plain wrong. Now and then we get sniffs of information but can’t put together the puzzle and thus are left with rumour and speculation.
-
Frédéric Wenzel has a great series of L10n blog posts going and there has been a lot of discussion of L20n work at Mozilla. I ping’d Fred to check in and share an idea with him… What if you could directly edit the copy on the staging server of a website and have it transparently save your changes in the background without messing with PO files, SVN access, etc You’d eliminate lots of problems that localizers have… and provide a richer, fun editing environment. Like any idea worth building… I found out it’s already been invented A few months back when I pitched this idea to Stas Malolepszy, he mentioned that Gandalf already thought of the idea and built a prototype. I’m realizing that this has been sitting in my TODO list for too long and I’m better off doing a brain dump in this blog post. Here’s my take on the idea: Design Constraints: Keep po files as the backing store Work as much as possible with existing gettext tools Use direct object manipulation for the UI - pick strings directly from page, see live updates Requirements: Let localizer view a web page and pick a string to translate Display an editor widget that sit on top of or beside the page Display the msgid and msgstr. In practice this is the English String and the Localized version. As they type, redisplay the page with their updated translation Provide a revert button Provide a save button. Save persists this string back to the po file server which commits the change to SVN. PO LiveEdit at 10,000 feet
PO Enhanced HTML – In PHP or other web code, instead of making calls to gettext methods, a set of wrapper methods would be used which add metadata to the HTML output. This would basically add the msgid to a span tag that surrounds the output of the msgstr. This would extra metadata wouldn’t affect the display, but would capture the semantics of a localized string. Old PHP code <p><?= _(‘Be the Difference’); ?></p> outputs <p>Fai la differenza</p> New PHP cde: <p><?= _w(‘Be the Difference’) ?></p> outputs <p><span id=‘md5_58cbc46092296cbe517d748685f52838’>Fai la differenza</span></p> PO Edit Client - This editor would use the msgid or some other token (such as the md5 hash of the msgid) from the enhanced html, to retrieve the information for an individual string and display it for editing. The comments, English translation, and Current localization string would be displayed. The editor would be aware of the current locale which is a page. It would be a live editor where changes would be reflected in the web page as you type. PO Edit Web Service – The server manages the collection of messages.po files for a web application. It’s provides read and write access to the PO Edit Client, one string at a time. It manages commits to SVN and conflict management. Technology: So three are three components to build… PHP gettext wrapper libraries, which are pretty trivial and produce the enhanced metadata in the HTML, a Server and a Client which lives within the browser. Server Either a stand-alone python server using Stas and Zbigniew’s [https://wiki.mozilla.org/Silme Silme library], or integrated into an existing web based L10n tool like [http://en.wikipedia.org/wiki/Pootle Pootle], it would provide a REST web service for editing po files by locale and msgid. Client The client can be built as either: Pure JavaScript included from the page Addon – Firefox/Fennec Extension Pure JS has the benefit of working with any browser (Safari on iPhone, IE 6 in corporate dungeon, etc). It has the negative affect of introducing L10n only code that you wouldn’t want to push to production. It adds another integration point to every app. The Addon has the benefit of being totally isolated from the specific web application’s codebase, which makes for easier adoption. The client would have the ability to use the PO Edit WS without any same-origin policy limitations. Downsides are that it’s requires Firefox or Fennec and it is an extra step for localizers. Either way, a simple textarea will be a good start for a prototype. Localizers will be loosing any features of their current text editor (say POEdit), but they will gain rich “preview”. For a prototype, the addon route could be built out of an existing extension, such as Jetpack Slidebar or Ubiquity pageLoad command, since it’s a more rapid development env. Considerations: The devil is in the details, here are some design decisions. By default, does this introduce a new requirement for a L10n preview environment? Or is the web application in a testable state? Adding String Metadata changes the web application and invalidates it for QA, unless you ship this metadata in the production version also. The ’right’ thing to do would be to introduce a localization step into the SDLC, but this might lower adoption. Or you could focus on making the implementation of the String Metadata really light weight, so it would have minimal overhead and not need an additional phase, since it could ship to production and other applications can invent new uses for this metadata. Exposing hard to reach state: Many strings are hidden behind a hard to reach sequence… such as error messages. A common practice in web app development is to expose every part of the app through testing hooks. Many large applications grow these features through time, such as allowing testers special query string parameters for each error condition to simulate the error. Another example is web apps with emails; provide urls so that each email is a click away w/o actually running through the registration process. These kinds of hooks would make translation easier and you’d have to list them somewhere so it’s easy to find them all. These become a requirement for a live web editor, unless you make the user jump through steps to reach all the states of the UI. Out of Scope(?) but on the Radar A real-time synchronization between the client and server would be ideal, so that multiple localizers could see who was editing a string and to reduce conflicts. Mike Morgan and Fred have suggested Bespin which is a freaking awesome idea. Wrapping up If we had a web based live editor for translating sites, this could be a huge win for localizers and the people of earth. Translating a website is one of the most painful and dangerous workflows I’ve seen. You know we have an amazing community, if they are willing to put up with the draconian toolchain we have today. Throwing everything out, is simply not an option, but if we can make a small evolutionary improvement towards a live preview edit workflow which hides revision control systems and text files… There are plenty of sticky corner cases and whiz bang features one can dream up, but I think building a prototype for this is a tractable problem. I did some brainstorming with Fred this morning and he had lots of other cool ideas and good observations on how this would work in practice.
- Tags:
- programming
- mozilla
- research
- webdev
-
Nothing earth-shattering here… but I wanted to capture some ideas that the webdev team has discussed in terms of how we share our code between projects and with the community at large. Of course 100% of our code is open source, but we want to do a better job of letting others use and contribute to our libraries. Screenshot of a typical project layout A typical project Let’s talk about a theoretical new project foomo which is the code behind Foo.mozilla.org. This project may reuse a couple libraries as well as host it’s own code. Let’s assume this is a project has the layout pictured to the left: In bin we have various Python and shell scripts which are executed via cron or CLI. These scripts depend on the config directory for configuration and the lib for libraries of code. I won’t focus on the bin part of the project, but it could follow the pattern below, but using a Pythonic packaging idiom. Let’s assume that the web directory houses a Kohana PHP project. Under the web/application directory there are typical these project specific directories: config, controllers, helpers, hooks, libraries, models, andviews. In addition to application, Kohana also provides modules and system directories. Let say that foomo project reuses a Mozilla WebDev PHP library barlib library it will be located under modules. system is where Kohana stores it’s framework code that is overridden by modules and application code. But how do we manage foomo and barlib codebases? Version Control The authoritative code repositories for this website would be in atleast two places. If we keep all the code for foomo under one project, say svn.mozilla.org/project/foomo, this makes it easy to deploy and manage. The mainline of application specific code would be changed from here. The second codebase is for the library barlib. The mainline of development would happen on github.com/projects/barlib. Let’s look at the source code layout of foomo and barlib to see how they relate. foomo's module directory contains barlib barlib's project layout So foomo’s web/modules/barlib on the left is a subset of barlib’s development tree on the right. A read only copy of this dist directory, heck even just a tarball distribution of it, comes from github and lands in foomo’s web/modules/barlib. As we want to enhace barlib, we work in that codebase on the right. barlib is it’s own project, so development includes running it’s tests, etc and then creating a release version to be imported back into foomo, on the left, as needed. Keeping the official repository for reusable libraries separate introduces some disadvantages, but is worth it. Disadvantages:
More complexity and administrative overhead Requires more discipline You have to manage dependencies between libraries and apps Increases development costs
Advantages:
Encourages Reuse Removes barriers for community contribution Makes QAing and releasing components possible
All Growed Up As code in foomo solidifies or another project wants to use chunks outside of just foomo, the various pieces of code can be pulled out into a module and moved from web/application to web/modules/<library name>. We’ll have to re-QA foomo after this code extraction, but we will gain the benefit of reduced development on the second project and anyone who needs it won’t have to pick through foomo internals to copy and paste the tasty chunks. If the second project is a CakePHP project, then all it will need to do is write CakePHP wrappers analogous to the very this Kohana specific layer of barlib. Everything Cannot Be Reused Not ever line of code can be reused. A lot of web development is about crafting a very specific solution. Localization, error handling, and coding conventions introduce challenges. That said, we should spend the extra time it takes to publish and integrate dynamite WebDev libraries.
- Tags:
- programming
- mozilla
- webdev
-
I’ve posted in detail on the webdev blog about a project I’ve spent the last several weeks working on – the Mozilla Service Week website. It’ been a lot of fun with a great team and it was my first project at Mozilla that had marketing and QA. Please check it out and get involved with volunteering today. We had a brownbag lunch with Computer Technology Network today which was very timely. You can see the mozservice09 promo badge to the right and I’m also rock’n the persona on my browser.
- Tags:
- mozilla
- webdev
- mozservice09
-
Demo - Firefox 3.5: XMLHttpRequest improvements - blog.mozbox.org
A great blog post on 2 new XHR features. Progress indication and cross-domain request support. Nifty!
-
PhoneGap | Cross platform mobile framework
PhoneGap is an open source development tool for building fast, easy mobile apps with JavaScript.
If you’re a web developer who wants to build mobile applications in HTML and JavaScript while still taking advantage of the core features in the iPhone, Android and Blackberry SDKs, PhoneGap is for you.
-
A simple well executed "Share This" widget.
-
Running Rhino and Helma NG on Google App Engine
Running Rhino and Helma NG on Google App Engine
- Tags:
- webdev
- javascript
- serverjs
- appengine
-
10 Social Actions API Secrets - Social Actions
"Social Actions has created the Open Actions Format, a potential universal XML format to describe rich information about social actions. In the future, we hope many of our partners will take advantage of this format and feed this data into the Social Actions API."
-
Guideline 1.2 Time-based Media: Provide alternatives for time-based media
-
XSS (Cross Site Scripting) Prevention Cheat Sheet - OWASP
This article provides a simple positive model for preventing XSS using output escaping/encoding properly. While there are a huge number of XSS attack vectors, following a few simple rules can completely defend against this serious attack.
- Tags:
- programming
- webdev
- security
- guide
- xss
-
CSS Canvas Using CSS Canvas, web designers can position canvas elements anywhere an image can be placed using CSS. Safari is the first web browser to support CSS Canvas.
- Tags:
- webdev
- canvas
- javascript
- browser
- safari
-
Mozilla Webdev » Blog Archive » Cross-Browser Inline-Block
Cross-Browser Inline-Block. Ah, inline-block, that elusive and oh so tempting display declaration that promises so much, yet delivers so little.
-
JSLitmus is a lightweight tool for creating ad-hoc JavaScript benchmark tests. Features include ...
* Single-file install (JSLitmus.js) * Works on Firefox, Opera, Safari, IE, Google Chrome, and iPhone browsers * Adaptive test cycles - tests take ~1-2 seconds, regardless of the operation * Google Chart + TinyUrl integration * Open Source MIT-style license (see source) -
Bespin is the newest Mozilla labs project. It's aims to be a self hosted open web editor and is pretty freaking awesome.
-
When can I use... Compatibility tables for features in HTML5, CSS3, SVG and other upcoming web technologies
- Tags:
- programming
- webdev
- ui
- web
- standards
- compatibility
Copyright © 2012 Me. All Rights Reserved. Running on Sweetcron v1.08e
This site is monitored by mon.itor.us