The Okapi Framework: Q and A with Yves Savourel of ENLASO
As of October, 2005, ENLASO has started to port a set of localization tools to the open-source Okapi Framework. The project's developer, Yves Savourel, has been involved in the development of standard XML formats for translation, such as XLIFF and TMX. Open Source Update recently spoke with Yves, who works as a Localization Solutions Architect at ENLASO's headquarters in Boulder, Colorado.
Open Source Update:
Please tell us a bit about the tools that are included
in the Okapi framework.
It sounds a bit complicated, but it's really simple: Imagine Okapi being a box of Legos. The interface specifications are the description of how the bricks can connect together, the components are the bricks (some very simple, some more complex), and the applications are the different things you build with the bricks.
Currently all the implementations are in .NET C# and we have two applications: Tikal and Olifant. Tikal is a command-line tool that allows you to run any of the utilities, and Olifant is a TM manager tool. For the utilities we have currently: The Text Extraction utility that puts translatable text from input file into various format for translation, like RTF, XLIFF, etc. The Text Merging utility that merges back text extracted to XLIFF into its original format. The Text Rewriting utility that extract and merge translatable text in one pass and do some modification to the text as specified.
For example: you can pseudo-translate the text, or remove it all (so you can compare two files with just the codes), etc. All utilities are fed from filters. Currently there are two filters implemented: one for PO files and one for Properties files. All that is for the last release, but we have already more filters and utilities ready to go for the next one: a .NET Resource filter (for both ResX and compiled .resource files), a Encoding Conversion utility, a Byte-Order-Mark Conversion utility, and a Line-Break Conversion utility. In addition, Rainbow, a GUI application to launch utilities, will also be part of the upcoming release.
OSU: Where does the
name "Okapi" come from?
OSU: How did the
idea to open source these tools come about?
OSU: What kind of
response have you gotten to the release so far?
The nature of the tools themselves does not help: filters for example are quite low-level "boring" programs to write, and they are much less prone to generate enthusiasm than a translation editor for example. To a large extend we are still making the bricks, people will get more interested when we will be building things with those bricks.
As far as the response in usage: Because the tools themselves have been freeware for several years we are not anticipating a lot of change on how much they are used. For now the current material available is not yet at the same level as the "old" freeware. We still have to port a number of parts to Okapi.
OSU: What advice
would you offer to other for-profit companies that
are interested in open sourcing their in-house software?
OSU: What do you
hope to do with the tools now that they are available
to the public?
OSU: Who is the target
user for these tools?
OSU: What do you
think is standing between the translation/localization
industry and more widespread use of open source software?
Most open-source translation/location tools are Linux/Java oriented, while most of the potential users are Windows-based. The users exist: if we look at Wordfast--not even an open-source tool--we can see how much enthusiasm it generates. But many tools completely miss the target because they simply don't aim at it: the users are on Windows. One could answer that the Java-based tools can run on Windows. That's true, but often I've noticed such applications often don't quite "fit" into the Windows environment: a lot of little details are not working as the users would expect (shortcuts, clipboard actions, input method, etc.) and the users just give up on the tool very quickly. Maybe I'm wrong, but I don't think you can really develop a good GUI solution for one platform from another one. You often have to be yourself a user of the environment where your users will be working to understand better their needs and expectations.
Linux is great, and developing open-source for it is perfectly fine. I suspect there is a broad use of open-source translation tools by Linux users. But open-source is wider than that: Make Windows and Mac open-source tools and they will get used. I've been a little frustrated by the anti-Microsoft attitude a part of the open-source community has: Whether we like it or not freedom includes the freedom of choosing Microsoft's OS. We should not dictate to the users what system they should use or not (Isn't it one of the main reasons behind the Linux and open-source movements?). They are plenty of good reasons some users want to stick with Windows and the attitude "If you are not with us you are against us" that we see sometime is not helping anyone.
Sorry for venting a bit...But somewhere along the road the open-source community seems to have lost sight of the *Users* to become, at least partially, a stage for a platform war. And I find that profoundly sad I was expecting better from a community that uses words like "open", "choice" and "freedom" so often.
If we want a given open-source tool to be embraced by many users, it has to answer the requirements of the majority of these potential users: and today these users are running Windows. Whether we can reach them by developing Java or Python tools better fitted to work in Windows, or pure-Windows tools, is a choice for each developer to make. I think there are also two more problems with the open-source translation tools:
One of them (hopefully) stems from the first one: Most the tools are the "translation editor"-type applications, and while there are plenty of good projects, very few would be able to win a side-by-side comparison with the mainstream commercial applications. For example, many open-source projects work without problems with software strings but get very quickly difficult to use with large documentation-oriented input. I think this has a lot to do to the fact that the current open-source tools don't have a large user base and don't have to deal with the diversity and amount of feedback commercial tools have. In other words, I think it is difficult to be become competitive if you don't reach a critical mass, and today a lot of the open-source tools don't reach that threshold because of problem #1.
The last issue I can think of is fragmentation: There are many little open-source projects, and it somehow scatters the energy and good will of the users. While I do like having several choices, and I'm all for diversity, I wonder how much of that is impacting the quality of the tools. If the different developers were collaborating more maybe they would achieve more. Maybe concentrating on two or three of the main translation editor projects would help. The Open Language Tools and OmegaT seem to be the projects drawing the most users. I have no idea if grouping the effort of different developers is possible, but it feels like the projects are losing something by not having a better collaboration.
OSU: If you could
create a new open source application for the translation
industry, what would it be?
How about an open-source machine translation engine? This could provide the translators with a channel to make such software more to their liking, and more useable within their work environment. I think the old Logos system is being ported to open-source, so maybe this is already happening. There are also some interesting applications implementing Web Service interfaces that could be done.
But more importantly I would try to finish a project, or at least to reach a stage where it's not Beta anymore, before starting a new one. I see some open-source projects never going very far and these are not helping the users. Obviously all depends on your initial objectives: it's good to try and experiment, but it could be helpful to clearly state the aims of the projects to the user community.
OSU: Do you have
any new or upcoming projects that you can tell us
OSU: Yves, thanks
very much for sharing your insights and expertise
with Open Source Update.
Please see some ads as well as other content from TranslationDirectory.com: