Although the ODF 1.0 standard was approved several years ago (by OASIS in 2005 and by ISO/IEC in 2006), work on the standard does not cease. Of course, we have work on technical revisions of ODF, in the form of ODF 1.1 and the current work on ODF 1.2. New releases make the news and are talked about at conferences. etc. But also important, though not talked about as much, is the ongoing work on the text of ODF 1.0., in the form of translation and error correction. Even after ODF 1.1 and ODF 1.2 are created, ODF 1.0 continues to be maintained.
Why is translation important? Aside from increasing the number of developers who can read the standard in their native language, translation is a prerequisite in several countries in order to make ODF into a national standard. So translation increases the number of places where ODF support can be an official requirement. So far the ODF 1.0 standard has been translated into Russian, Chinese, Spanish and Portuguese. (There may be others — Let me know if I’ve missed any.)
(Interesting to note the size advantage of ODF compared to OOXML. I’ve heard from one reliable source that to translate OOXML would cost $500,000. This will certainly hamper its ability to be adopted in some parts of the world. ODF, by reusing existing standards, is only 1/10 the size.)
Also in progress is a translation of ODF 1.0 into Japanese. From what I understand, a JISC committee has completed an initial pass of the translation and then passed the translation off to a second committee. This second committee is reviewing the translation and raising any issues where the text is unclear. In some cases this may be caused by a faulty translation. But in other cases errors may be found which were present in the original English text.
That’s the second ongoing activity related to ODF 1.0 — error correction. Although we received most of our comments during the mandated 60-day public review prior to approval as an OASIS Standard, we do continue to get a trickle of comments months and years after publication. Each OASIS TC has their own mailing list for receiving comments. For the ODF TC, the mailing list archives are here. Anyone can subscribe to the comment list and post using the instructions here. The additional complexity in the sign-up procedure compared to your average mailing list is to ensure that all feedback submitted by the public to the list is in accordance with OASIS IPR rules. This helps ensure that ODF remains an open standard, unencumbered by patents.
Although we are only obligated to address comments received during the pre-approval public review period, around a year ago the ODF TC decided to formally record and process all comments received, regardless of when they arrived. So far, from May 2005 to the present, we’ve received around 250 comments. We note each comment in a spreadsheet, along with what ODF versions it pertains to (ODF 1.0, ODF 1.1 or ODF 1.2 draft), what section number the comment concerns, and whether the comment is reporting an editorial error, a technical error, or proposing a new feature. My estimate is that 50% of the comments are feature proposals, 40% are reporting editorial errors, and 10% reporting technical errors.
The preeminent source of comments on ODF 1.0 has been Murata Mokoto, of the Japanese SC34 mirror committee. Murata-san relays to us the defects found during the Japanese translation of ODF. The vast majority of these are editorial errors, mainly typographical or grammatical. But there are a handful of more significant issues found, and we are especially pleased to receive reports of these.
You may recall the old saying, “Every new class of users finds a new set of defects”. Translation of a standard is a laborious process, especially when combined with the additional review step that JISC is engaging in. This has subjected the text of ODF 1.0 to more scrutiny, at a more detailed level, than any typical technical review could provide. So I am appreciative of the detailed comments from JISC, and of the effort made in this translation by them.
My personal aim is to ensure that all of the reported editorial errors are fixed in the ODF 1.2 text, and that any technical flaws are addressed via errata. An errata document (That’s what we call it in OASIS. Others, e.g., ISO, call it “corrigenda”) allows us to make small changes to the ODF 1.0 text to address defects.
But this goal certainly debatable. Why not aim to fix every reported error in ODF 1.0 via published errata? Why knowingly leave even the smallest typographical error in the text? What relative priority should be placed on fixing typographical errors (and others) in ODF 1.0 versus work completing ODF 1.2?
This is entirely at the will of the ODF TC. The combined priorities of the vendors and other interests represented on the committee determine the direction we take. My perception of the expressed interests is that we should address the JISC comments via an errata document, but that the overall priority is on completing the work on ODF 1.2, and not attempting to fix every last instance of subject/verb disagreement or misuse of “A” for “An” in ODF 1.0.
And so our work on the ODF TC follows that priority. I’d estimate that we spend 80% of our time on ODF 1.2 topics and 20% on processing public comments on ODF 1.0/1.1, including those from JISC. We are nearing completion of an official Errata document for ODF 1.0, consisting of fixes to defects reported by JISC. Expect to see a call for public review soon. After that, the TC will continue to review and process public comments from the comment mailing list. If warranted, we are able to issue an updated errata document in the future, to address additional issues as they are reported.
Anyone wanting to tackle the task of translating ODF into the future should probably watch, or join and help, our efforts to create an ODF to XLIFF/Gettext PO converter.
The converter is part of the Translate Toolkit which provides tools to localisers for the manipulation, management and QA of various file formats.
Adding ODF is useful for us and others as we want to make it easy to translate documents without having to run a word processor and thus lose all the features and power of our localisation tools. We’re converting to XLIFF as this is an emerging localisation standard and one that many localisation tools can understand. And PO of course because much OSS localisation is still managed in the PO format.
Hats off to the current translators, your efforts are making the standard even better for everyone.
“Interesting to note the size advantage of ODF compared to OOXML. I’ve heard from one reliable source that to translate OOXML would cost $500,000. This will certainly limit its ability to be adopted in some parts of the world. ODF, by reusing existing standards, is only 1/10 the size.”
By comparison to the money Microsoft spent on lobbying for OOXML, a very small sum to pay. If I were Microsoft it is worthwhile paying for the translation.
The bigger problem for Microsoft is that we the public still does not have the final ISO document for OOXML. Without it, how can one start translating?
Sinleeh, The estimate I saw was that Microsoft spent $125 million to get OOXML approved. So, as you say, translation costs are relatively minor, compared to the overall cost.
DWayne, Thanks for that link. I heard a talk about XLIFF earlier in the year. It sounds promising.
To put it in context, $125M is about half a day’s revenue for Microsoft.
Whether it’s a useful way of spending the money, or whether it would be better to hand it back to stockholders so they could buy larger yachts, work harder on eradicating Malaria, or whatever personal projects they have in mind, is open for debate.
I can’t raise $125M. They can. What would you do, if you had that sort of cash ?
Rob,
can you give us an idea of when ODF 1.2 will be finished by the TC and passed upwards to become an OASIS standard?
Hi Chris,
The interesting comparison is not to Microsoft’s overall numbers, but to their expenses for the development of their core Office applications (Word/Excel/PowerPoint). How does $125 million compare to their core Office development expenses for a year? What would it indicate if their single largest Office expense brought no new feature or benefit to end users, but was merely a wasteful escapade in selling a standard that Office itself does not implement? Certainly, they can afford it. But what does it say about priorities?
Felix,
ODF 1.0 took 2.5 years to create, approved by OASIS in May 2005. ODF 1.1, a minor release, was approved 1.5 years later, in February 2007. It is now 1.5 years later, and we are working on ODF 1.2. ODF 1.2 is a substantial update, with many new features. My prediction is that it will be closer to a 2.0 year total effort, meaning approval in Q1 2009. But that’s just my personal prediction.
“We are nearing completion of an official Errata document for ODF 1.0, consisting of fixes to defects reported by JISC. Expect to see a call for public review soon.”
rob , reviewing jtc1 sc34 public documents, i see that MM has issued another ODF defect report
do you plan to add this to the official Errata ? or you plan to fix them in a 2nd batch?
thanks in advance, go (truly) open standards !
orlando
[0] http://www.itscj.ipsj.or.jp/sc34/open/1078.htm
That defect report has been submitted to SC34, not to OASIS. By the time it is processed there and then submitted to the ODF TC, we will likely be done with the Errata document we are already working on.
In fact, I told Murata-san some time ago that submitting defect reports to SC34 rather than submitting to OASIS directly would only lead to needless process delays. Oh well…