Information & Communication Technology (ICT) is one of the most powerful technologies ever developed by humankind. It has drastically changed the way we do things, the way we communicate and even the way we think.

ICT is supposed to be an amalgamation of communication and computing technologies and more often than not the abbreviation ICT4D is used in the context of using such a convergence to facilitate development. Even if we leave this strangely ambiguous statement aside, the single most important feature that the declaration lacks is the action plan to take it forward. I see a declaration as more of a mere PR exercise than an actual roadmap or, guide to implementation and sustaining the deployments.

A barrier to the adoption of Free and Open Source Software technologies in education and especially basic primary education is the mixing of the concepts of FOSS-for-Education and FOSS-in-Education. And inevitably, any discussion of FOSS and Education leads to a discussion, often misinformed, about the ways to improve the system. The root cause is often neglected – the lack of books/reading material/content that are necessary for anyone to actually adopt a methodology/pedagogy that is based around FOSS toolkits and stacks. If you pick up any book it would be obvious that there is a massive proliferation of non-FOSS technologies and terminologies in them. The change in terminology is fairly important as well – that leads to recognition of name and which in turn leads to awareness.

There is another somewhat odd aspect that I notice. FOSS concepts and discourses are being increasingly influenced by political currents. And, adoption of them are also depending massively on state-level political support. The potential downside of this is course that if political equations change, the discourses and deployments are also prone to get changed. Where would that leave us ?

 

• The profile of the attendees was different from last time. If the organizers talk about the demographics, this observation might be validated but I got the feeling that the crowd was more of professionals than students
• The event has introduced diversity and, that is a good thing to have
• There have been new speakers as opposed to the “same old faces” talking
• There were elements of avid interest in things Fedora where the speakers were enthusiastic and participated in rapid Q/A

I liked what I saw. Including Shreyank’s enthusiasm to not get off-stage till the “download link came up”

One of the things that I’d hoped would happen at the event is that the group of Fedora folks who met would sit down and discuss their goals for this year. By goals I meant the stuff they would be focussing on and, more importantly, how they would be measuring their achievements. I don’t know how much was discussed along these lines but it is a good time to start doing it. Keeping the focus on a few important things and then creating easy-to-visualize ways of looking at the achievements allow the contributors to assess themselves. Self-assessment goes a long way in removing any perceptions of anonymity that might be lingering on. And, it also creates a sense of involvement – of belonging.

The other important bit this would achieve is that it would make the developers more visible and approach-able. For too long I have seen developers have an aloof or, stand-offish approach to their projects. And, it isn’t because they are arrogant but perhaps it is their trait. Unfortunately, “they will contribute if they figure out that the project is good” isn’t a nice approach. Going upfront and talking about goals, plans and in general doing advocacy allows potential contributors the confidence to tinker with the code and, start contributing. Building up the confidence to tinker not because it is “good for the nation” but because it is “good for oneself” and, is profitable is a concept that needs to be repeated over and over again. The students aren’t rolling up their sleeves enough and, it is an urgent need to exhort them to do it. The world is moving forward at a fairly fast clip and they cannot take comfort in the “learn-by-rote-to-join-TWITCH” way of life in the various colleges across the country. In money terms as well as in time and effort an enormous quantity is invested in students, that shouldn’t go to waste.

The others have already blogged about the event, I’m waiting for Hiemanshu’s writeup.

Posted from GScribble.

This year we have been able to reach out to a number of events and groups which helped us take the message of the Four Foundations to them. That has been good. We have also noticed that a larger number of those signing up to become Ambassadors are students or, are dipping their feet into the FOSS way of doing things. So, here’s the area in which we need to work our hardest.

Earlier I wrote:

Additionally, if during the initial days, the new Ambassadors are encouraged to actively participate in any other part of the project, it should lead to greater involvement and appreciation of the Foundations. This of course has the advantage of helping them build the social connects and network across projects/amongst individuals which is an invaluable part of being an Ambassador. It also builds up the required confidence in the Ambassador to go out and evangelize about contributing back to various projects and upstream. Because, if one has already drunk the Kool-Aid, talking about it is dead simple.

And, it is true. An Ambassador is the face of the project to the external world. It requires people skills but more importantly, it requires an intrinsic knowledge about the project that takes time and effort to build up. Unless an Ambassador takes a keen interest in the various projects within Fedora and, contributes to at least one of them, it is an uphill climb for most. More so for a student who is just learning the ways of FOSS and, gathering experiences via Fedora.

In the coming months, the plan is to put in place a stronger coaching plan for these student contributors so as to tap into their huge talent and, the capacity to produce stunning results. We have always been surprised by the sheer amount ideas that come up when students are gradually pointed to a direction.

Stay tuned. Exciting stuff is going to happen.

Talks have transcripts and, they are whole blocks of dialogue which have a different feel when undergoing translations than the User Interface artifacts that make of the components of the software I translate. In some kind of confusion I turned to the person who does this so often that she’s real good at poking holes in any theory I propound. In reality, it was my turn to be shocked. When she does translations of documents, Runa faces problems far deeper than what I faced during the translation of transcripts. And, her current toolset is woefully inadequate because they are tuned to the software translation way of doing things rather than document/transcript/pieces of text translation.

In a nutshell, the problem relates to the breaking of text into chunks that are malleable for translation. More often than not, if the complete text is a paragraph or, at least a couple of sentences – the underlying grammar and the construction are built to project a particular line of thought – a single idea. Chunking causes that seamless thread to be broken. Additionally, when using our standard tools viz. Lokalize/KBabel, Virtaal, Lotte, Pootle, such chunks of text make coherent translation more difficult because of the need to fit things within tags.

Here’s an example from the TED talk by Alan Kay. It is not representative, but would suffice to provide an idea. If you consider it as a complete paragraph expressing a single idea, you could look at something like:

“So let's take a look now at how we might use the computer for some of this. And, so the first idea here is just to how you the kind of things that children can do. I am using the software that we're putting on the 100 dollar laptop. So, I'd like to draw a little car here. I'll just do this very quickly. And put a big tire on him. And I get a little object here, and I can look inside this object. I'll call it a car. And here's a little behavior car forward. Each time I click it, car turn. If I want to make a little script to do this over and over again, I just drag these guys out and set them going.”

Do you see what is happening ? If you read the entire text as a block, and, if you are grasping the idea, the context based translation that can present the same thing lucidly in your target language starts taking shape.

Now, check what happens if we chunk it in the way TED does it for translation.

So let's take a look now at how we might use the computer for some of this.

I just drag these guys out and set them going.

Get them out of context and, it does make threading the idea together somewhat difficult. At least, it seems difficult for me. So, what’s the deal here ? How do other languages deal with similar issues ? I am assuming you just will not be considering the entire paragraph, translating accordingly and then slicing and dicing according to the chunks. That is difficult isn’t it ?

On a side note, the TED folks could start looking at an easier interface to allow translation. I could not figure out how one could translate and save as draft, and, return again to pick up from where one left off. It looks like it mandates a single session sitdown-deliver mode of work. That isn’t how I am used to doing translations in the FOSS world that it makes it awkward. Integrating translation memories which would be helpful for languages with substantial work and, auto translation tools would be sweet too. Plus, they need to create a forum to ask questions – the email address seems to be unresponsive at best.

In fact I wanted to talk with him about how massive the momentum built up by Transifex has been. Just two years ago, in 2007, Tx was a GSoC project within The Fedora Project aimed at looking at managing translations from a developer’s perspective. Today, it is a start-up which is hiring employees, relocating to newer offices, has a foot-print across a significant portion of upstream community projects and, most importantly, has clients willing to pay for customization services and, developer services. Tx isn’t only helping translation communities by allowing them to craft their work in peace – it is keeping developer sanity with the fire-n-forget model of the architecture. I hear that PulseAudio, PackageKit developers are strong supporters of Tx. That is tremendous news. The provocative nature of Tx is also based on the charm that it has been bootstrapped. That should provide hope to developers thinking along the “product” route.

I would say that these two years have done Dimitris good. His focus on the road Tx should take has become more vivid and, he has a deeper insight into the changes he wants to bring about via Indifex. There’s nothing more exciting than keeping a close watch on his team and his company for news that would come up soon. Tx is coming up with a killer set of features in the upcoming releases. That should get the attention of a couple of clients too.

Throughout the afternoon we ended up talking about getting youngsters up to speed to think beyond patches as contributions and, starting tuning their thoughts to products. Dimitris opines that patches are excellent jump-off points but in order to become a valuable contributor, one must start thinking about “architecture”, “design”, “roadmap”, “milestones” and all such issues that form part of the theory classes but never see implementation in real-life scenarios. In addition, there is also the need to inculcate the “CC thinking” in everyday work of creativity – be it code or, content or even be it hardware and standards (the “CC thinking” is a fancy short-hand towards thinking about Open Standards, Open Protocols and so forth. In a somewhat twitter-ish way, we compressed it to a meta-statement we both could relate to and agree with).

Dinner and post-dinner with a couple of us was another story. Having a bunch of hard-core “Fedora” folks in the room creates a passion. Sitting back to savor the flames of discussions and, interjecting with a leading viewpoint to keep the debate flowing is the best way to get action items resolved. Nothing wasn’t touched upon – from the way to get best out of *SCos to mundane stuff like getting feature requests into Tx, OLPC and Sugar, or, talking about the general issues within the IT development community in Greece. And of course, the frequent checks on Wikipedia to validate various points in the argument. We could have done with an offline Wiki Reader yesterday

I think I finally went to sleep at something around 0200 today – which is impossibly past my standard time. There are photos aplenty, though I don’t know who will be uploading them. There was food, there was coffee, cakes, and, there were friends – in short, a nice day.

Sometime ago, I was shopping for an off-line translation tool. I was fed up with Lokalize’s issues and, the fact that it wasn’t letting me do what I wanted to do at that point in time – translate. Additionally, I wasn’t in the mood to actually install a translation content management system to do stuff. Face it, I am an individual translator and, calling in the heavy shots to get the job done was a bit silly. So, I turned to virtaal. Actually, I think I was goaded into giving it a try by Runa.

Virtaal was, at that point in time, not really a good tool And, you can figure from the blog link above that I wasn’t interested in it too much. However, since I ended up giving it a chance (you cannot simply ignore a recommendation from her) I ended up running into two issues. One was predominantly more annoying than the other and, in effect was what was putting me off the tool. However, the developers took interest to get it fixed and, in the latest release have resolved it.

The other bug was resolved in an even more interesting way – over IRC with hand-holding to obtain the appropriate debug information and, then on to editing the file to put in the fix. At the end, the fix might be trivial. But the level of interest and care taken by the team to listen to their users is what makes me happy. In this aspect, the other development crew I can mention is Transifex. I haven’t met most of them and yet they keep taking suggestions, reports via every communication channel they are on – blogs, micro-blogs, IMs, IRC and trac. That makes them visible, gets them into the shoes of the users and, I am sure it earns them invaluable karma points.

Yesterday, while helping (I just did the file editing while Walter did all the brain muscling) to close the other bug, I felt incredibly happy to be part of a system where it isn’t important who you are or, where you are from. What is important that you have a real desire to develop better software and, make useful artifacts for all.

As it goes – “Your mother was right, it is better to share” link to video.

The post is brought to you by lekhonee v0.8

• One, in their Credits to Contributors section, Mozilla (for both Firefox and Thunderbird) state that “We would like to thank our contributors, whose efforts make this software what it is. These people have helped by writing code and documentation, and by testing. They have created and maintained this product, its associated development kits, our build tools and our web sites.” (Open Firefox, go to Help -> About Mozilla Firefox -> Credits, and click on the Contributors hyperlink)
• Two, whether with design or, with inadvertent serendipity, projects using Transifex tend to end up defining their portals as “translate.<insert_project_name>.domain_name”. Translation, as an aesthetic requirement is squarely in the forefront. And, in addition to the enmeshed meaning with localization, the mere usage of the word translation provides an elevated meaning to the action and, the end result.

A quick use of the Dictionary applet in GNOME provides the following definition of the word ‘translation’:

The act of rendering into another language;  interpretation; as, the translation of idioms is  difficult. [1913 Webster]

With each passing day innovative software is released under the umbrella of various Free and Open Source Software (FOSS) projects. For software that is to be consumed as a desktop application, the ability to be localized into various languages makes the difference in wide adoption and usage. Localization (or, translation) projects form important and integral sub-projects of various upstream software development projects.

In somewhat trivial off-the-cuff remarks which make translation appear easier than it actually is, it is often said that translation is the act of rendering into a target language the content available in the source language. However, localization and translation are not merely replacing the appropriate word or phrases from one language (mostly English) to another language. It requires an understanding of the context, the form, the function and most importantly the idiom of the target language ie. the local language. And yet, in addition to this, there is the fine requirement of the localized interface being usable, while being able to appropriate communicate the message to users of the software – technical and non-technical alike.

There are multiple areas that were briefly touched in the above paragraph. The most important of them being the interplay of context–subtext and inter-text. Translation, by all accounts, provides a referential equivalence. This is because languages and, word forms evolve separately. And, in spite of adoption and assimilation of words from languages, the core framework of a language remains remarkably unique. Add to this mix the extent with which various themes (technology, knowledge, education, social studies, religion) organically evolve and, there is a distinct chance that idioms and meta-data of words,phrases which are so commonplace in a source language, may not be relevant or, present at all in the target language.

This brings about two different problems. The first, whether to stay true to the source language or, whether to adapt the form to the target language. And, the second, as to how far would losses in translations be acceptable. The second is somewhat unique – translations, by their very nature have the capacity to add/augment to the content, to take away/subtract from the content thereby creating a ‘loss’ or, they can adjust and hence provide an arbitrary measure of compensation. The amount of improvement or, comprehension a piece of translated term can bring forward is completely dependent on the strength of the local language and, the grasp over the idiomatic usage of the same that the translator brings to the task at hand. More importantly, it becomes a paramount necessity that the translator be very well versed in the idioms of the source language in additional to being colloquially fluent in the target language.

The first problem is somewhat more delicate – it differs when doing translations for content as opposed to when translating strings of the UI. Additionally, it can differ when doing translations for a desktop environment like, for example, Sugar. The known user model of such a desktop provides a reference, a context that can be used easily when thinking through the context of words/strings that need to be translated. A trivial example is the need to stress on terms that are more prevalent or, commonly used. A pit-fall is of course it might make the desktop “colloquial”. And yet, that would perhaps be what makes it more user-friendly. This paradox of whether to be source-centric or, target-friendly is amplified when it comes to terms which are yet to evolve their local equivalents in common usage. For example, terms like “Emulator” or, “Tooltip” or, “Iconify”being some of the trivial and quick examples.

I can pick up the recent example of “Unmove” from PDFMod to illustrate a need to appreciate the evolution of English as a language and, to point to the need for the developers to listen to the translators and localization communities. The currently available tools and, processes do not allow a proper elaboration of the context of the word. In English, within the context of an action word “move” it is fairly easy to take a guess at what “Unmove” would mean. In languages where the usage of the action word “move” in the context of an operation on a computer desktop (here’s a quirk – the desktop is a metaphor that is being adopted to be used within the context of a computation device) is evolving, Unmove itself would not lend itself well to translation. Such “absent contexts” are the ones which create a “loss in translation”.

The singularity here is that the source language strings can evolve beautifully if feedback is obtained from the translated language in terms of what does improve the software. The trick is perhaps how best to document the context of the words and phrases to enable a much richer and useful translated UI. And, work on tooling that can include and incorporate such feedback. For example, there are enormous enhancements that can be trivially (and sometimes non-trivially) made to translation memory or, machine translation software so as to enable a much sharper equivalence.

I finally managed to add it to my Safari Bookshelf (for some odd reason I had to delete a book to free up a slot inspite of not being over quota) and, I did have high expectations from it, Jono has been active and visible in various communities and, I expected his enthusiasm to reflect in the writing. The book is a good one and, definitely worth a read. Interesting chapters are: Building Buzz, Measuring Community, Handling Conflict and, Hiring a Community Manager. A couple of observations about the book:

• it draws on the shared experiences and, “stories” from various personalities and, projects making it somewhat of a “comfortable” book to read. You get to see that there are patterns to the problems across various communities and, tribes and, such patterns can be addressed
• it isn’t “preachy” or, prescriptive or, even full of homilies. That’s a saving grace really. However, the deliberately chatty nature of the book sometimes becomes a bit too full. However, not mandating prescriptions to “fix” communities is a good thing to have in a book
• It does have the usual attempts to define what a community manager does (including the by now cliche of “herding cats”). The end definition is somewhat more easy-on-the-ear (read the book for that :))
• it doesn’t delve too much into the measurement aspects of the vitality of a community and, somewhat implies that the entire effort to build up and, sustain a community is somewhat of a “soft” skill issue. That, I’d say goes against the grain of the intent of the book – to demonstrate the easy of formation of communities and, the significant efforts to keep them sustained. And, although the anecdote about the 5-A-Day is insightful, on the whole, it doesn’t break new ground in statistical assessment or, deriving sense out of the number crunching
• I’d have liked to read about examples from upstream projects like GNOME, KDE and, Mozilla. Because of the size and, nimbleness of their releases, the community experiences would have far more anecdotes about processes, tools and workflows. The book does justice in talking about the importance of having open and transparent processes, however, it doesn’t delve too deeply into the catastrophic failures that can happen if the vital emotions of Belief, Respect, Accountability and Trust are thrown to the winds. There have been ample cases in the world of Open Source where one or, all of the foundations have crumbled and, havoc ensued. Dispassionate discussion about them helps bring out the case for the need to have a vigilant community.
• I recently read Cultivating Communities of Practice by Etienne Wenger, Richard McDermott, William M. Snyder (linky) and, expected The Art of Community to demonstrate the validity of legitimate peripheral participation in the Ubuntu community. There aren’t too many examples of those.

In short, although the books falls a bit short of my expectations, it is a good read and, a book to have on the shelf. It does not lend itself towards creating neat little check-boxes like, say, a Producing Open Source Software: How to Run a Successful Free Software Project by Karl Fogel (linky). Or, it isn’t aimed for companies who want to build a community around their products/services as is documented by Dave Neary in his blog.

On a related side note, the other books which I read and, would recommend are: 97 Things Every Project Manager Should Know, 1st Edition by Barbee Davis (linky) and, 97 Things Every Software Architect Should Know, 1st Edition by Richard Monson-Haefel (linky). Both are extremely nice read especially because they have a diverse range of inputs which make it topical. There’s a need for a 97 Things Every Community Manager Should Know as well

Lastly, it would be delicious if the Safari folks allowed the bookshelf to be treated like an actual library bookshelf – check-in and, check-out books at will as opposed to waiting for a specific number of days to be able to remove the books. Oh well ! you can’t have it all I guess.

KBabel

I used it only infrequently when it was around in Fedora (it is still available in Red Hat Enterprise Linux 5) but once I did get over the somewhat klunky interface, it was a joy to work with. Seriously rugged and, well formed into the ways of doing translations, KBabel was the tool of choice. However, it was replaced by Lokalize (more on that later) and so, I moved on to Lokalize.

Lokalize

This has so much promise and yet, there is so much left to be desired in terms of stability. For example, a recent quirk that I noticed is that in some cases, translating the files using Lokalize and, then viewing it using a text editor shows the translated strings. However, loading them in KBabel or, another tool shows the lines as empty. The Kbabel -> Lokalize transformation within KDE could have perhaps done with a bit of structured requirements definition and, testing (I am unaware as to whether such things were actually done and, would be glad to read up any existing content on that). Then there’s this quirk for the files in the recent GNOME release – copying across the content when it is in the form Address leaves the copied form as empty space. The alternative is to input the tags again. Which is a cumbersome process. There are a number of issues reported against the Lokalize releases which actually gives me enough hope, because more issues mean more consumers and hence a need to have a stable and functional application.

Virtaal

I have used it very infrequently. The one reason for that is that it takes some time to get used to the application/tool itself. I guess sometimes too much sparseness in UI is a factor in shying away from the tool. The singular good point which merits a mention is the “Help” or, documentation in Virtaal – it is very well done and, actually demonstrates how best to use the application for day to day usage in translation. This looks to be a promising tool and, with the other parts like translation memory, terminology creator etc tagged on, it will have the makings of a strong toolchain

Pootle

I had been initially reluctant to use a web-based tool to do translations. This however might have been a factor of the early days of Pootle. With the recent Pootle releases, having a web-based translation tool is a good plus. However, it isn’t without its queer flaws – for example, it doesn’t allow one to browse to a specific phrase to translate (or, in other words, in a 290 line file, if you last left it at 175, the choices are either to traverse from the start in bunches of 10 or, 7 or, traverse from the end till one reaches the 176th line), the instances of Pootle that I have used don’t use any translation memory or, terminology add-ons to provide suggestions.

I have this evolving feeling that having a robust web-based tool would provide a better way of handling translations and, help manage content. That is perhaps one of the reasons I have high expectations from the upcoming Pootle releases and, of course, Lotte.

Irrespective of the tools, some specific things that I’d see being handled include the following. I hope that someone who develops tools to help get translations done takes some time out to talk with the folks doing it daily to understand the areas which can do with significant improvements.

• the ability to provide a base glossary of words (for a specific language) and, the system allowing it to be consumed during translation so as to provide a semblance of consistency
• the ability to take as input a set of base glossaries across languages (for example, a couple of Indic languages do check how other Indic languages have handled the translation) and, the system allowing the translator/reviewer to exercise the option of choosing any of the glossaries to consult
• provide robust translation suggestions facilitating re-use and, increasing consistency
• a higher level of handling terminology than what is present now
• a stronger set of spell checking plumbing
• store and display the translation history of a file
• the ability to browse to a specific string/line which helps a lot when doing review sprints or, just doing translation sprints

Update: Updated the first line to ensure that it isn’t implied that these are the only tools anyone interested in translation can use. These are tools I have used or, use daily.

Update: Updated the “wish-list” to reflect the needs across tools as opposed to the implied part about they being requested only in Pootle

Some of the common aspects of the texts I have stumbled across include attempts to have a model defined, description of a rudimentary framework of tasks, an analysis of infrastructure that facilitates collaboration and, a broad overview of the character of a community. Either way, I am a bit tired about “community” as a word and, I feel that it is beginning to suffer from over-use and under-statement. A primary driver for that feeling is the tendency to look at “communities” as if they were thriving specimens on a petri-dish, isolated and unperturbed in their own imaginative evolutionary cycle. That is simply untenable as a hypothesis and, impossible in real life. Communities are constituted by groups of people and, people react to the push-pull of daily life around them – the political issues, the personal issues and, the social intricacies. As much as communities try, other than a basic tenet that binds them together, there isn’t much difference between the growth of a community and, the evolution of family. The same basic principles of Belief, Responsibility, Accountability and Trust ensure that the forward momentum is not stalled.

The paradox is that having stated the above, I ended up attempting to box-in the “community” into some nice tangible parameters so as to enable explanation. Fun !

The decline of a community or, even a sub-aspect of a community can also be traced to a larger sense of hubris and, a lack of plan in terms of moving forward to embrace change. The hubris part is perhaps derived from moving away from a central core idea that was the genesis of the community and, attaining a false sense of being indestructible to external forces. Statistics are important – but statistics are external representations of symptoms – for example, wiki edits; commits to version control; activity on mailing lists; number of contributors; mass of consumers all these indicate how the community (or, tribe) is moving forward. They do not capture whether the general direction is based on the central core theme and, is moving across a wider spectrum without getting too diluted.

Why can’t “communities” be replaced by “tribes” ? Makes for a better understanding of the complexity of interaction that ensures a sustaining environment for a group of people who perceive a need to exist. And, would be able to come together to arrive at decisions that ensure sustenance. Most communities/tribes are specialized formations of people who find a common space to talk about and extend their areas of interest. As such, the need to “fabricate” a community is somewhat redundant while the need to work on providing a “commons” is important.

ps :The post is rambling in essence, at some point I’d like to re-visit this and, collate the other thoughts.

The post is brought to you by lekhonee v0.4.1