The presentation was centered on features of Adofex, telling people about the new features and UI that will make their lives easier both as translators and as addon maintainers. Wladimir Palant, the author of Adblock Plus, was eager to try and also to hack the new system. That is really inspiring!

Also, the community raised a very valid point about team ownership. As one of important features of the new system over the old one, I wanted to see unified translation teams. One-language-one-team. Yes, per-project teams are also totally possible, just are not the default.

With that setup, all members of language team would

• get some place to be listed (look as a team)
• help each other on totally any addon (work as a team)
• have to be approved only by global language maintainers, who are expected to be much responsive and responsible then per-project team-mainteners – who are often unreachable or have quite a view on translation standards. (able to act like a team).

Yeah.

With all that said, I have a confession to make. I am actually looking at this from the boss side of the table. I am a maintainer of Ukrainian localization, have been localizing Firefox itself and few key addons for ages, and I get frustrated when I am not able to fix typos/mistranslations/missing strings in addons owned by other people. And filing “join team” requests, then waiting for them never to get a response was not an encouraging thing.

So, I created my own system, with blackjack and whistles, the one that fits the workstyle of a WikiGnome perfectly: once you are in a team, you are free to improve whatever you want.

Thing is, not everybody is a Gnome. Most people are Maintainers, and some are even Trolls. Maintainers are the ones who care about their favorite addon, they are added to the list of localizers in credits section and they do not want any outsiders to mess around. Trolls are the who guys care more about language purity and ‘proper’ term usage than doing hard work of translating kilobytes of text. One Troll autoreplacing “center” with, say, “centre” with no ability to roll that change back can easily alienate many Maintainers.

And, actually, in an environment (Launchpad) where I do not have the master switch in my hand, and where any of my pet translations can be (and are) edited by some guys whom I have never asked to – I do not like it myself.

To give people sense of satisfaction and well-earned fame – they should be able control the results of their work. Outsourced projects still is a useful feature to have, because Adblock Plus and Adblock Hiding Helper should really have the same teams working on them. But whether to outsource every new project to global team – that is a question. At least until someone implements translation history (#705) for Transifex – which would at least explain who changed what.

A feedback here would be greatly appreciated.

PS: for those who haven’s seen that great show, the source of team joke is IT Crowd.

You can try it on Adofex having registered/logged in and created a new test project. ID for Adblock is 4592, for Stylish — 4983. Kudos to Bz devs for making their data available.

Not so good news: The project-creation wizard (import from github/bitbucket), dashboard etc – “stuff that makes transifex.net interesting” – are closed source addons. Also, navigation issues and general unfriendliness to a localizer are all mine – no one else is currently working on them.

Thus, to make that cutie the next and better Babelzilla – a little more than the format support is needed. Dashboard, streamlined navigation, XPI-based newproject wizard (every addon author have an xpi, even if he does not have a source repo, so xpi-reading seems to be more important), just to name some. Working on.

Through to brew the code in my fork to the state when it can yield the patch ready to be filed, two things need to be done:

• Upgrade Silme to July’s version (currently rev 629 is used), which was just this day reworked by Zbigniew and now works on top of new shiny library for handling mozilla things, currently formats. BTW, last time I checked, my pet l10nmerge.py also required fixes to work with recented pyast-powered silme, and a little more complex than the one needed for r629.

• Solve the conflict with JavaProperties handler. That is trickier, as this handler uses the same file extension as Mozilla one, yet it differs in two important matters:

  • it supports many more features of the format than Mozilla’s one do, namely multiline strings, using : for specifying pairs besides of = etc.
  • it reads and outputs Latin-1.

JavaPropertiesHandler’s format tolerance is not a problem, and neither is its habit of expecting Latin-1. I can try two of them in turn, Java and Moz, one after another, checking for ability to decode incoming file. Java will accept Latin, Moz will accept UTF8, everybody happy.

But who will be in charge of outputting the content? It will not be possible to judge target platform by file-to-be-localized extension, and neither by its encoding : usually those are in English, and only in some cases they carry fancy characters like Unicode ellipsis.

Speaking of the screenshot above, it shows a picture unusually rarely seen in Transifex, yet so common on Babelzilla and so natural for a localizer to see. Tx experience is organized as Project-Resource-Language-edit, and the “Localizer’s view” where you see all the files in your language and their status — the thing that obviously interests you the most — is hidden in Teams tab (when teams are enabled!), and is not the one you go back after editing a resource. Haven’t found a bug on that, gonna file one.

Also hacked a prototype for addon-repacker, the python script which will be adding localized resources (dtd/properties) to given xpi files for ease of testing. As its purpose is testing and testing only, final shipping is author’s business anyway, it uses very straghtforward approach: adds files into someaddon.xpi/tx_locale/code/ and fiddles with chrome.manifest to expose new locale for the same content package other locales are. Might fail for complex files with multiple content packages being localized, but that seems quite uncommon.

Among the other format readers there is Java .properties reader, which unfortunately works only with ISO 8859-1 encoding (other characters have to be represented as Unicode escapes). I plan to replace its reading code with Silme calls, along with writing DTD reader. The one thing to check is whether Silmefied .properties reader would supersede original one totally, or I would have to check which one to call. I would like to avoid that, as currently Tx picks file reader only by extension and magic number, which is obviously the same for Java and Mozilla .properties file.

Rounded up a few things besides of GSoC during during start of June, like the studies, and Thunderbird/Calendar localized release and can devote more time to the project now.

Next talk with mentor is scheduled to June 21^th, and I hope to have working prototype by then.

I had talks with Zbigniew, who will be my mentor for this project and Dimitris, leader of Transifex project. I am looking forward for working with both of them more deeply, but so far I am just diving into Transifex sources and rounding up my studies. The first and obvious thing to do it solving Transifex’s ticket #89, as other things go after that.

On a side note, I am amazed by how noisy GSoC mailing list is. Thank you, dear Google, for the Mute button! Update: Finally got my City card, tried to register it online, and lots of so-called “noise” on the list instantly started making sence. The main URL does not even open for non-US IPs, for starters.

Scheduled my next meeting with Zbigniew to June 7th, and we will probably have at least bi-weekly talks through the summer.

I loved books since I was a child. They allow you to travel to the places distant in time and space, to see the worlds that disappeared long ago or did not even exist. They tell stories that fascinate people all over the world and shape our common knowledge like Bible did thousands years ago. And of all modern ways to fill your mind with a fascinating reading the most prominent one is e-books.

History note

There was a time when monks used to rewrite them by hand, and by the mistakes they made in the process we can now get hints on what language did they actually speak besides canonical one. Later, mr. Gutenberg created his famous invention, pretty much killing that little monastery business.

I wonder if there were lawsuits then.

Six centuries later, hand rewriting and retyping made an interesting comeback, when in our country the ability to print was blocked not by technical shortcomings, but by political circumstances. It is known as Samizdat books, funny name coined by resemblance of official publishing houses names, but meaning “My own Publishing House”.

Authors and Publishers

Interestingly, but we are approaching the same destination just having taken other route. These days anyone can be his own publishing house and easly print his own book, or reprint someone else’s.

Of course, that gives traditional publishing houses a hard run for their money and may even eventually kill them. Who cares? In the brave new world we will have the ability to buy books directly from the Author, saving the cost on printing and saving the space on our bookshelves. Everybody wins, and, btw, publishers will have their niche anyway: print-on-demand, illustrated books, atlases, etc.

But the books that are “just text” will soon be arranged only inbetween the Author and the Reader. May be with a little help of some web-service, but soon to sell a book will be as easy as to sell a photo, font, drawing or some other work of art.

And even more. There are several books that I and many other people want written, and I see no reason why the community can not prepay their writing. We prepay opensource software, right? There were lots of cases, when people collected needed sum to pay the developer, funding his work for a promise to release the result into the world. This model will surely work for book developers too.

The modern reading

Ok, now you surely know how wonderful e-books are and how bright our future will be, . Time for some gory details.

Whatever you use to read your library (I very very much recommend some eInk based device, your eyes will thank you a thousand times), standards matter.

And looks like the standard for e-books is finally settled, it is called ePub, and is based on open technologies. With Google promizing to release a million ePub books into the wild, and Sony commiting to that format there is no question on who the winner is.

I feel a little sad for other open XML-based e-book format, called FictionBook, because it was much stricter on ruling out the presentation details, caring only about the structure of the book, and leaving the style to the reader.

But, as it was for early HTML, presentational details won. Not as bad as it was for HTML3, through. ePub just lets creator to specify the look in CSS, and does not require the book text to have special DTD, allowing plain XTHML. Still there is special DTD, called DTBook, it is just not required for book chapters, only for TOC.

Not to mention that Fb2 format was our local, Eastern Europe only invention, and was not backed by any big worldwide player.

But hey, ePub is standartized and open: so when one would want to read it the way he wants, it is all up to the extending the reading application. Just like the approach we take to the Open Web.

The task

And here comes the task I chose myself for Mozilla technology course: to add ePub and Fb2 support as an extension to Firefox. That would make interaction with ePub books easier and provide readers with more viewing options.

The problems I have to solve to make the extension work like it should are:

1. registering the extensions .epub and .fb2, handling their rendering
2. unzipping the content (both are container formats)
3. actual presentation
4. TOC navigation
5. book metainformation display
6. some library features

The good news for me that there was an ePub extension once, that did handle points 1-3, called Openberg Lector. Unfortunately, it died two years ago, having never made it to Firefox 3.

Still, it provided me with lots of hints, and reviving it in some form is one of the goals of this project. I am sure it will be useful as people are still eagerly waiting for an update on its AMO page.

And for FB2 format (which is not going away soon in near future in our part of the world) there has not been an extension yet, despite it was asked for on forums several times.

Update Dec 2010:

FB2 reader app is done, available on its own page.

EPUB reader is done by other guys, see Lucifox.