Help Hackfest
2011-01-31
The documentation team will have a hackfest in Toronto from March 17 to 22. Most of the core contributors are already planning to attend. We’ll finish the desktop help for 3.0 and work on as many application help documents as we can. This could mark the first time in years that we ship a point-oh release with complete documentation.
We’re interested in colocating a developer documentation hackfest. We need to add more content and polish to the new developer demos and finish the Platform Overview for 3.0. Time permitting, we can also review and improve our reference documentation. This can only happen if we have people.
So if you have experience with our developer platform and developer documentation, and would like to spend a week making Gnome a more enticing platform to developers, please email me at shaunm at gnome dot org.
Blip Up and Running
2011-01-14
A long time ago, I started working on a universal project tracker called Pulse. (There’s even a half-broken stale-data copy of it running here, for now.) After a series of refactors and rewrites, as well as a name change owing to the ubiquity of the name Pulse, I had Blip. Over the last week, I’ve been setting up an honest-to-goodness live Blip instance on my VPS. This is the real deal. Information is currently updated hourly.
Highlights:
- All pages, with status information, in the new Mallard-based GNOME Help
- Activity graph and log of the commit-generating machine Matthias Clasen
- Translation statistics for Evolution
What does Blip do?
Blip scans stuff for information. You hand it some initial set of information (like some jhbuild modulesets) and it crawls everything it finds. It records history. It finds documents and parses them for status information. It finds translations and records their completion. It finds mailing lists and scans their history. (Mailing lists aren’t being scanned on my instance right now, because I’m working on some changes.) It associates all that information with people, and lets you see what everybody’s been up to. If you have an account, you can even watch projects and people.
What else does it do?
Blip can do anything you teach it to do. Everything it does—every piece of data it collects and every report it generates—is done with plugins. The built-in plugins handle a lot of generic cases. The blip-gnome package is a collection of plugins that make Blip play better with the sort of stuff you see in Gnome. Need another document format? A different translation setup? A different version control system? Just write some simple plugins. Or contract a Blip expert to do it for you. 
What’s next?
A few summers back, Florian Ludwig did a bunch of work on Pulse for the Summer of Code. One of the biggest things he worked on was integrating issue tracking systems like Bugzilla. Unfortunately, this stuff hasn’t yet made the transition to Blip. I’d really like to go to Yelp’s Blip page to get a glimpse of bugs not just on bugzilla.gnome.org, but on downstream trackers as well. I’d also love to track releases, along with distribution patches and packages for those releases. Features like these will make Blip a one-stop overview for developers in our crazy distributed world.
More Faceted Navigation
2010-12-16
I blogged earlier this year about doing faceted navigation with Mallard. The idea sat dormant for a while, but with the new GNOME developer demos, I had a really fun use case.
Here’s the basic idea: Topic pages declare values for facets. These are basically just categorized tags. So my Message Board tutorial has some simple markup that says it’s written in C and it’s teaching you WebKit. You then have a page that collects all the topics and provides selectors to narrow what you’re looking at.
So as I browse the demos, I can say that I’m only interested in C. And perhaps I’m looking at GTK+ and Clutter to see which one is a better fit for a project I’m starting. I can uncheck everything else. Then I’m looking at only demos in C that teach either GTK+ or Clutter. Screencast:
All of the scripting is handled by Yelp. Document authors only need to write some simple declarative markup in a Mallard extension format.
(Aside: When I try to upload an ogv file to WordPress, it tells me the file type doesn’t meet security guidelines. If I rename it to ogg, I can upload it, but WordPress inserts it as audio. I have to write the HTML for the video by hand. Could somebody please make it easier to use Ogg Theora on blogs.gnome.org?)
Developer Documentation Hackfest
2010-12-09
I attended the GNOME developer documentation hackfest in frigid Berlin last week. This was, I think, a very successful hackfest. We came out of it with a concrete plan, a new documentation effort firmly started, and a host of improvements to tools in the pipelines.
The plan: We will have an updated Platform Overview. We will have a large and continually growing set of demo tutorials. We will have conceptual overviews for all libraries and major subsets of libraries. We will have complete API references. And we will have a beautiful new developer.gnome.org that acts as a portal to all this information.
Everybody kicked in to create an initial set of demo tutorials. The initial demos focus on getting you up to speed with one of our platform libraries. Further demos will build on this knowledge and help you dive deeper into what the GNOME platform can offer. The demos are in git.gnome.org/gnome-devel-docs/demos/C. We will do our best to make all demos available in multiple programming languages.
Get involved by contacting the GNOME documentation team.
The demos are written in Mallard. This is interesting to me, because it’s pushing Mallard in places where it hasn’t been pushed before. This helps me develop useful features. (As a rule, I do not add language features without real-world use cases.)
Jonh asked for line numbering, so I’ve added that in Yelp using a simple style hint. Chris wondered about starting line numbers, continuations, and line number references. These sorts of features require more than an on/off style hint, and I want to think about them more. I think that, with dynamic pages, we can do better than callout lists. Regardless, any improvements there should be in a Mallard extension.
Everybody wanted syntax highlighting. Fortunately, Mallard allows you to provide the MIME type of the content of code blocks, so we already have a way of declaring what should be parsed and highlighted. I looked through half a dozen JS libraries to do syntax highlighting. In the end, I chose jQuery.Syntax. This is now integrated into Yelp, and syntax highlighting works with appropriate values of the mime attribute. Obligatory screenshot:
A big thanks to Openismus for hosting the hackfest, and to Kat and David for putting up Phil and me. And of course, thanks to the GNOME Foundation for their sponsorship.
Open Help Conference
2010-11-29
Mark your calendars for June 3-5, 2011. The first-ever Open Help Conference will be held in Cincinnati, OH, USA. The Open Help Conference is a gathering of people interested in open-source and community-based help. It combines traditional conference presentations with discussion forums and a new open-participation writing session. Professionals and community volunteers will come together to learn, share, work, and have fun.
Does your team hold in-person documentation sprints? We can provide space for post-conference documentation sprints near the conference venue.
Space is limited, so register today.
Mallard+TTML+ITS
2010-11-08
I just blogged about Mallard+TTML. And earlier I blogged about XML translations with ITS.
One of the nice features of ITS Tool is that it can merge ITS definitions from multiple sources. So when you embed TTML into Mallard, you don’t need to have a specific Mallard+TTML mode. Instead, the Mallard ITS definitions get applied, and the TTML ITS definitions get applied on top of them. I just added this ITS file to itstool git:
<its:rules
xmlns:its="http://www.w3.org/2005/11/its"
xmlns:tt="http://www.w3.org/ns/ttml"
its:version="1.0">
<its:withinTextRule withinText="yes" selector="//tt:p//*"/>
</its:rules>
This ensures that inline markup like tt:span doesn’t get split off with a placeholder into a separate translation unit. This one file applies the ITS definitions whether your TTML is embedded in Mallard, DocBook, XHTML, or any other format, or even if you have a standalone TTML file.
Mallard+TTML Video Captions
2010-11-08
I said, “Why not add some simple captions to Mallard?” Philip said “Why not embed an existing format, like TTML?” Philip was so right.
<media type="video" mime="application/ogg" src="figures/gnotravex-video.ogv">
<p>Simple demonstration of a game</p>
<tt:tt xmlns:tt="http://www.w3.org/ns/ttml">
<tt:body>
<tt:div begin="1s" end="7s">
<tt:p>Drag pieces from the right to the left, making sure that
adjacent edges have the same number<em><tt:span begin="1s"> and
color</tt:span></em>.</tt:p>
</tt:div>
<tt:div begin="6.5s" end="14s">
<tt:p>Press <keyseq><key>Ctrl</key>arrow keys</keyseq>
to move all the placed pieces at once.</tt:p>
</tt:div>
</tt:body>
</tt:tt>
</media>
A nice bonus feature is the tt:span element. One second after the first caption is displayed, some extra text appears inside it.
We should host a TTML profile for Mallard+TTML on projectmallard.org. Authors concerned with interchange would then be able to specify that profile using ttp:profile to prevent non-Mallard TTML processors from choking up on the inline Mallard syntax.
Mallard Video Captions
2010-11-03
The documentation team has recently started creating short videos to supplement our text help. The first video we shipped was for Tetravex, showing basic piece movement. The nice thing about this video is that it doesn’t include any UI elements with translatable text, so translators don’t have to go through the truoble of retaking it. It also has no audio, so there’s nothing to retake there.
But parts of the video could be helped by some explanations. For that reason, I started working on a media subtitling system for Mallard. The subtitles are written directly in your Mallard document, where they’ll get translated along with the rest of the document. They’re then inserted into the HTML and dynamically shown and hidden as the video plays.
Sample XML:
<media type="video" mime="application/ogg" src="figures/gnotravex-video.ogv">
<p>Simple demonstration of a game</p>
<e:captions xmlns:e="http://projectmallard.org/experimental/">
<e:caption start="1" end="7">Drag pieces from the right to the left, making
sure that adjacent edges have the same number and color.</e:caption>
<e:caption start="7" end="14">Press <keyseq><key>Ctrl</key>arrow keys</keyseq>
to move all the placed pieces at once.</e:caption>
</e:captions>
</media>
End result (very much a work in progress):
XML Translations with ITS
2010-10-27
When I first started doing GNOME documentation, our documents were translated manually, as a whole, and with no change-tracking. That is to say, they were never translated. Then Danilo came along and wrote xml2po, and I integrated it into the build utilities in gnome-doc-utils. Suddenly, all our XML documents could be translated with standard PO files. And we started seeing actual documentation translation.
Fast forward six years. We’re still using xml2po, and it’s serving us well. Various web-based translation editors and trackers have appeared that can handle XML documents. Some of them use xml2po underneath; some use the same concepts in their own implementation. Meanwhile, the W3C created ITS, a common vocabulary for specifying things that translators and translation tools might want to know about an XML format. But we’re not using it, and I don’t know anybody in the greater GNOME ecosystem who is.
Presenting itstool: an ITS-based tool for converting XML files to PO files and back again.
This is an experiment I started over the weekend. The idea is to have a general xml2po-like tool that contains no vocabulary-specific logic. All it knows is XML and ITS, and everything you need to know about a format is specified with an ITS rules files. Look at the Mallard ITS file as an example. The basics of how to handle Mallard are in 13 lines.
This has a lot of potential. For starters, you don’t need to patch a program or write a plug-in to support a new XML vocabulary. All you need to do is provide an ITS file. There’s a chance that the people who developed the vocabulary will already have ITS definitions in place.
What’s more, you can embed ITS attributes and rules directly into your XML document, extending or overriding global rules. This is huge. This is the “mark something as untranslatable” feature that translators want, provided by a W3C recommendation that other tools might actually understand as well.
For an example, take a look at the DocBook Element Reference for Mallard. If you convert this to a PO file using itstool, you’ll see a bunch of messages that look like this:
msgid "<code href=\"http://www.docbook.org/tdg/en/html/abbrev.html\">abbrev</code>"
Yawn. It’s some markup, and a URL, and the name of an XML element. Nobody needs to translate that, but there’s no way a general tool can know that. But the author knows, so the author can use the its:translate attribute to save the translators some work:
<td its:translate="no"><p> <code href="http://www.docbook.org/tdg/en/html/abbrev.html">abbrev</code> </p></td>
Problem solved. This one pesky message will no longer appear in the PO file. That’s a big step forward for us. Unfortunately, there are 417 of those on that page. That’s a lot of typing. Fortunately, ITS also provides a standard way to specify rules, and you can put those rules directly inside your document. For this page, I happen to know that the first column of every row is untranslatable. And I know there’s no row spanning that would cause the first td to be in anything other than the first column. So rather than type its:translate="no" 417 times, I can put what I know right in the XML, where itstool can find it.
<its:rules xmlns:its="http://www.w3.org/2005/11/its"> <its:translateRule translate="no" selector="//mal:tr/mal:td[1]"/> </its:rules>
We can just put this inside a Mallard info element. This is valid because Mallard allows any element from an external namespace inside the info element. And now itstool drops all 417 of those pesky messages from the PO file.
There are some bits that ITS doesn’t provide, and for those, we’ll need extension rules. Annoyingly, ITS doesn’t have a rule to specify space-preserving elements. I think the idea is that your DTD or XSD can specify this using xml:space. But I come from the RELAX NG school of thought, where validation is validation, and processing logic is something else. The two formats I care about most, DocBook and Mallard, are both RNG-based, so I had to create an extension rule for that. That’s done.
Then we have xml2po’s awesome ability to create messages for external files like images. We can’t translate the images using xml2po, of course. But xml2po can let translators know when images have changed, or when new images were added. That’s another extension rule. It’s not in yet, but I have a syntax for it, and I think it will be easy.
Finally, there’s translator credits. This one is harder, but I think it can still be specified in XML as an extension. I have a prototype of how the XML might look in the ITS files for DocBook and Mallard, but no working code yet.
Some things were easier than with xml2po’s approach, and some things were harder. On the whole, I think the ITS-based approach can take us further, and lines up more with standards that exist outside GNOME. I’m going to keep experimenting with this, and perhaps try to get in touch with other ITS folks. We’ll see where it goes.
Accessibility Hackfest
2010-10-27
Earlier this month, I attended the GNOME accessibility hackfest at the AEGIS conference. My goal was to start planning the accessibility user help for GNOME 3.0. The documentation team often doesn’t understand the needs of users of accessible technologies, and understanding user needs is the first step to writing good help.
I got Joanie Diggs started working on Orca help, and Brian Nitz on Accerciser help. I led them through the basics of planning topic-oriented help and helped them revise their plans. It’s always interesting to teach people topic-oriented help with Mallard, and to see what they grasp quickly and what needs more explanation. It helps me develop my ability to teach people to write.
I also got a much clearer sense of how we should work accessibility information into our desktop and application help. The entire team helped me understand what types of information users might be looking for. For example, Joanie mentioned keyboard shortcut reference pages as something that will often be useful to users of accessible technologies.
This led us to a feature idea for Mallard and Yelp. Joanie wondered if it would be possible to aggregate the keyboard shortcut references from across the desktop. This is basically remixing Mallard pages into a new document, which is entirely doable. But in this case, we want to do it dynamically. And for that, we need a tagging system. I once blogged about tags for faceted navigation, and I think those would work for this kind of use as well. This probably not 3.0 material (unless Phil Bull asks for it, because Phil always gets the backburner features he asks for). But it’s a potentially powerful feature that’s made possible by Mallard’s design.
I also watched demos that gave me a better appreciation of the kinds of needs some people have. Tools like screen readers and magnifiers have high visibility, but there are so many other accessible technologies aimed at people with lots of different needs. All GNOME developers should have the chance to see this stuff first-hand.
On a personal note, I left my wallet in a taxi. Brian Nitz and Mario Sanchez Prada spent two hours with me at the hotel where I picked up the taxi, hoping that the same cabbie would come back there to wait for customers. He didn’t, but Mario heroically talked to every single cabbie that stopped there. End result: my wallet was recovered the next day, minus 30€. Thanks, Mario. You’re my hero.




