Fixing Ubuntu translation problems in a CoC-adhering way

(sorry for spamming the planet earlier when I joined, I blame Blogger, and hi all)

It's not always easy to be an Ubuntu translator. Ubuntu has always gotten a good share of critic towards Launchpad, its translations handling and its lack of devotion towards KDE. Let's first list the problems briefly:

• Rosetta has struggled with translation imports, performance etc. each release, only slowly getting better. The struggle continues each release, but usually for different reasons than with the previous one.
  
• Fixing problems directly in Rosetta is impossible since Launchpad is closed source
• Initially some or many of the translation teams evolved chaotically, resulting in similarly chaotic translations in some cases, with no systematic way to fix all the problems until after Ubuntu 7.04.
• Some imports have historically been messed up, and the worst apparently were on the KDE side
  
• Ubuntu chose GNOME for the first flavor, and therefore KDE only for the second flavor.

There. Now that those are listed, let's just concentrate on making the most popular desktop distribution the best localized distribution there is with the aid of unique tools that are provided to enhance Ubuntu. The tools make it possible to translate every last bit (in main) regarding a distribution release, regardless of the multitude of release schedules or lack of with individual projects. If everything would be just mainline GNOME or KDE programs and distributions did zero customization (or integration), this would not be needed of course. As it is, Launchpad's Rosetta tool is still a bit unique. It's hard to have a devoted translator knowing each software's schedule for every language. An example is eg. F-Spot or any other individual, smallish project.

I have often felt alone pushing very visible i18n bugs in eg. installer and elsewhere, getting the source codes, trying to find the culprit, checking if all languages have the problem and trying to be as polite as possible when approaching all too busy developers, hopefully with ready made patches. I've enough free time only barely to check the most visible problems on the GNOME side in my language, since many problems are relatively complex and might be a combination of source code side problems and Rosetta's import problems.

So, the KDE4 Rosetta import problems are new, very bad but should not only result in bashing Ubuntu/Launchpad. Reportedly the main problem should also be resolved by week's end, let's hope so. After that, a lot of work remains to have top-notch KDE translations in Ubuntu. Here's hoping that if you do care about KDE translations (I would, if I simply had either free or paid time), don't just rant about the problems. Find out the package that actually has the problem, do exact bug reports, ask politely from the maintainer but only when you know what to ask, get the source code (if available ie. not Rosetta problem), do patches and PPA uploads with fixed packages. I'm not claiming such would not be done, I have just seen whenever I've booted into KDE in earlier releases that there are things that look like long-hanging fruits with that ugly English (it's ugly when you expect some other language:)) that could be fixed. On the GNOME side, like I stated, I've felt there are not too many people doing what I've done - helping in i18n of codec installation, ubufox, installer, hwtest, .desktop entries in default installation etc.

Of course the current KDE4 problems are bad, but we've had bad problems before, and there are bad problems on the GNOME side too :) Luckily there is also the possibility of post-release language packs, though I certainly hope there will be no need for those just because of the current situation. I'm also fearing how the documentation side turns out, since the deadline for documentation is 2nd of October, the delay from archive upload to Rosetta import completing is sometimes huge and the deadline for translations is 16th of October...

Regarding Rosetta-specific problems, I'd like to share a few additional observations:

• You need to do some ugly stuff to fix everything. Some import problems might not get debugged for a good time, so in addition to filing a bug report, please upload the upstream PO file as "Published upload". And I have to admit even I haven't filed bug reports of everything, currently unfiled is at least an investigation plea for why libc translation was never automatically imported in Finnish. I have filed some bugs, though, almost all fixed now.
  
• Go through everything relevant in Rosetta, yes browse through all 1400 template titles for those low-hanging fruits that can be fixed simply by making more translations. Check if anything highly visible is untranslated for one reason or other, and translate it.
• Do a basic installation of an Ubuntu flavor and use it in your own language - if you see anything not in your language, it's a bug. Try first figuring out if the problem is fixable by just translating something in Rosetta. You may also install additional language support (some big language like French or German might be good idea, since they have relatively good coverage) and check if the problem is global. Find out if the problem needs a source code patch, is a Rosetta import problem or something different.
• Sort by "Changed in Launchpad" in the template view for your language, revert whenever possible to upstream translations and commit fixes to upstream, see my instructions in a post to ubuntu-translators.
• Also see the same post and think if your language's Ubuntu translator team should be more strictly controlled.

In addition to those translation team members that are technically competent, I would hope that more non-native English speaking developers would use their native language, despite the fact that many computer hobbyists use English. The ordinary users don't use English, and even developers don't need to use English. With English, a non-native speaker might kind of lose the contact with the concepts of what the UI terms mean, since the images that words form in one's mind work the best only in one's native language. The same reason some even good translations sound funny to a English UI user, since they hadn't thought the "F-i-l-e" menu actually means a certain real-world thing adapted into non-real world's use.

If you got lost with the last chapter, concentrate on the previous ones ;)

Clutter usage increases in future Nokia devices

Just a tidbit from maemo summit I'm visiting: Clutter will be available and used in the so called "maemo 5", which is an SDK and eventually results in a device from Nokia. Clutter is a OpenGL "2.5D" library, which means in practice easy manipulation of 2D objects in 3D space, with all the OpenGL smoothness you will want. Even though I still wonder if it will ever be that Nokia devices will use 100% free software in the whole functionality, like is possible with the Openmoko devices, I definitely have to congratulate on choosing Clutter. Good usage of Clutter will show example to others, too.

Hopefully Clutter usage will also increase on the desktop side, as I think it's the enabler of more aesthetically pleasing user interfaces in all kind of devices. Just a random example of a suggestion for Ubuntu using new gdm face browser.

App stores and APIs: It's the ecosystem, stupid

If you make a web application or mobile platform, one of the trendiest things you can do is add APIs and a software marketplace to it so developers will extend your product. Google is previewing its application market for Android (link), T-Mobile USA has promised a new applications store for its phones (link), and many people I've spoken with believe Microsoft bought Danger in order to get its software store technology.

The idea of encouraging third party developers dates back at least to the early days of MS-DOS, but it was associated mostly with operating systems until Web 2.0 applications took off a few years ago. Google played a big role in that change, by exposing APIs to Google Maps that made it possible to embed maps in other web applications. That helped Google Maps quickly blow past established mapping services like Mapquest, while the installed base of Google Maps extensions made it hard for Microsoft's web mapping product to gain traction.

The drive for web APIs got another big boost when Facebook enabled developers to extend its functionality, driving an explosion of widgets for Facebook that helped it grow past MySpace to become the #1 social network in the US (at least according to Alexa).

The web app people all noticed Google's and Facebook's success and furiously started adding APIs to their products. Today it's unusual to hear about a new web app that doesn't have some sort of API story or future plan to add them.

In mobile, applications have an interesting history. Lately some new mobile players have generated huge attention for their application marketplaces. The chart below shows the one year growth in the developer base for a certain well-known mobile platform:



If you're like most people in Silicon Valley, you probably think that's an Apple iPhone developer chart. But actually it's Palm OS ten years ago, from 1998 to 1999.

Disturbing, isn't it? The idea that a platform could take off like that and then crash and burn...makes you wonder if the same thing could happen to the platforms that are popular today.

And in fact, if you look at the history of APIs on both mobiles and web apps, the failures are more numerous than the successes. If you're a developer trying to pick the right platform to create your apps on, that choice is very dangerous -- you're betting the success of your company on something that has a better than 50-50 chance of failing.

If you work at a web or mobile company creating APIs or an app store, the news is equally disturbing: The odds are that you won't succeed.

So it's very important to look at the history of those failed platforms, to figure out what goes wrong and how to avoid it. When you do that, the answer is pretty clear:


It's the ecosystem, stupid

The success of a developer program is not driven just by the beauty of the APIs or the store, but by how the overall ecosystem works to enable developers to prosper. The two parts of the ecosystem that are most important to developers are the ability to create something cool, and the ability to make money. Coolness gets developers to try your platform in the first place. Most developers, especially the innovative new ones, gravitate to a platform that lets them easily create something cool that will impress their friends. But as those developers get older and more responsible, they eventually get tired of drinking lemon drops with Mark Cuban (link). They need to pay rent, buy food, and do other things that require money. If they can't make money from a platform, they will move away to the next one. So the financials are what makes developers stick around over time.

If the ecosystem breaks down anywhere in the chain, the developer community will eventually collapse. You can see this in process driving the history of some prominent web and mobile platforms:

Facebook. Earlier I said Facebook apps were a success because they helped the company grow. That's definitely true from Facebook's short-term perspective, but if you talk to Facebook developers the story is much more mixed. Some people online say there are lots of ways to monetize Facebook apps (link), but other reports say it's difficult to actually make the revenue come in (link). The online attitude toward this when Facebook's platform launched in 2007 was pretty dismissive. One commentator wrote (link):

The problem of not making money with your app is not a Facebook problem. It's your problem!

That's the right attitude for a developer to take: Control your own destiny. But monetization becomes a Facebook problem if nobody can make money. Developers poured into the Facebook platform like the tide in the Bay of Fundy, but a lot of them couldn't make money and promptly poured back out. I can tell you from personal experience that some are pretty bitter and unlikely to do anything with Facebook again.

Mobile Java's problem was that it's not a real platform. Handset vendors and operators were allowed to break compatibility between their implementations of Java, forcing developers to tweak their java apps almost endlessly, dramatically raising their costs and making it hard to scale their companies. The selling model for Java apps was also seriously broken -- to get prominent placement on a phone, developers often had to cut special deals with carriers. Some of the most successful mobile Java game developers have survived because they're great deal-makers; they figure out how to develop for a big brand that wants to create a mobile presence, or they hook into the promotion of a movie. This business model favors a few companies with the skill and contacts to cut the deals; the current mobile Java world is not an ecosystem that can support huge numbers of developers.

Palm and Windows Mobile both succeeded at first in enabling developers to create a lot of interesting applications. Although both operating systems had technical flaws, they were reasonably open to any developer, and the "write once run anywhere" idea mostly worked. Unfortunately, the marketing and sales model for those applications started out mediocre and got worse over time. There was no software store on device, so users had to go out on the web to find apps. This cut the number of people looking for applications. Those who did look online usually landed in the mobile application stores, which over time took a larger and larger share of the developer's revenue. Eventually, the stores' cut grew to more than 50% of revenue, making development uneconomical for many companies. When sales of Palm OS and Windows Mobile devices failed to grow rapidly, the financial model for many developers fell apart, and the ecosystems faded.


What to look for in an ecosystem

If you're a developer looking to find a viable ecosystem, or a platform vendor looking to build one, here are the things to look for.

How easy is it for developers to create something cool? How powerful are the APIs? Can the platform be programmed using standard development tools? Eclipse seems to be the preferred platform among much of the web app crowd, and it's free.

Is the platform programmed in a language that's obscure or difficult to use? This has long been one of the big barriers to Symbian native app development.

How do applications get visibility? Is the store displayed at the first level of the smartphone? How easy is it for users to navigate the store? Online stores like Handango are notoriously hard to navigate; the user experience is about like walking through a flea market.

Can good apps rise to the top? In some software stores, the developer has to pay for prominent placement on the store. This is incredibly corrosive to the ecosystem. The big software companies with money to pay for placement are often the least innovative. So users see an app prominently featured, try it, are disappointed, and never try another one. If web search worked this way, there's a good chance that the web as we know it would never have developed. The practice of pay for placement is a self-defeating, regressive tax -- it penalizes most the small developers who are most likely to create compelling new apps that make a platform more successful.

Ideally, placement on the store should be based on independent user reviews, so the best new apps can rise to the top naturally.

What are the terms of business? Can a developer bill for an app through the user's phone bill? Forcing people to input their credit cards separately slows adoption of software. Can the developer choose different forms of payment? Developers should be enabled to experiment with freeware and subscription payment systems, just as they do on the web. How much of the developer's revenue does the store keep? The ideal cut is no more than 20%.

Are there restrictions on the application's functionality? This is a sore point for iPhone developers. Apple won't allow intermediate platforms that run other applications. So no Java, no Flash, and no emulators like StyleTap's Palm OS emulator (link). This also inhibits other developers who want to expose APIs within their applications.

What is the overhead for security? Some platforms require applications to pay for a new security certificate every time the app is revised. The cost is typically a few hundred dollars, which doesn't sound like much to a big operator or OS company, but is a huge burden to a small company with several apps. They're basically punished every time they fix a bug, which is very unwise -- you want developers to fix bugs instantly, because that increases user satisfaction and reduces support calls. Basic security certificates can and should be issued automatically by the software store, at no charge.

How big is the user base? This will be a more and more important issue over time. For a developer, the ideal platform would let them sell to the whole base of mobile phone users, not just one brand or model.


Room for improvement

Based on those tests, no mobile platform offers an ideal ecosystem today. Apple probably comes closest at the moment. Here's how I'd grade it:

--Power: A-. The iPhone APIs give developers a huge amount of power, and there was a lot of delighted commentary on the web when the APIs were first revealed. But there is a learning curve for iPhone development; Apple has its own tools and its own variant version of C. And support for some typical OS features (such as cut and paste) is missing.

--Store: A-. The store is built into the device prominently, so apps are easier to discover. And there is a user-driven rating system. Developers can bill through Apple's iTunes system; not as convenient as billing through the carrier, but not bad. Apple takes 30% of revenue, which is not ideal, but is better than the 50% or more cut that burdens mobile app developers elsewhere.

--Terms: C+. There are significant, ambiguous restrictions on what a developer can do on the iPhone. The most onerous terms restrict the ability of developers to add functionality to applications and create software that run other applications. The terms cause a lot of confusion among developers; I'm on a mailing list for iPhone developers where they have been trying to figure out whether they can download content to an iPhone app. The answer: it's unclear as to whether content is a form of functionality, and you should ask Apple's lawyers. That is an incredibly intimidating message to app developers. It feels far too much like doing business with the operators.

--User base: Incomplete. It's relatively straightforward to make money from iPhone apps today because the number of developers is still relatively low. But over time, I think it's unlikely that Apple will be able to grow its user base at the same rate as the developer base is growing. If that happens, life will get much less pleasant for iPhone developers.

The ideal mobile app ecosystem would have the API power of the iPhone and the discovery experience of the iPhone store, coupled with business terms that allow add-on APIs like Flash, Java and Google Gears, all working across a much larger base of devices.


What it all means

If you're a software developer and some platform vendor or web company comes around evangelizing their software store or their APIs, you should evaluate the overall ecosystem they're providing, not just the store or APIs alone. If they haven't thought through issues like billing and discovery, it's a big warning sign.

If you work for a platform or web app company that wants to create a developer community, you need to plan the whole ecosystem and make sure it'll all work. This is especially important for a mobile company that wants to compete with the iPhone store. The way to fight iPhone for developers is to create a superior ecosystem. Apple's weak point is the business and technical restrictions on its developers, and the limited reach of the iPhone APIs. If another vendor -- say, Nokia or Google or Microsoft -- can pair a great store and powerful development with more openness and broader reach, they might be able to give Apple some serious competition. Elia Freedman had some good suggestions on ways to start (link).

____________

PS: Thanks to MobHappy for including my post on smartphone share in the Carnival of the Mobilists (link).

Conference time

I'll be doing the Grande Tour des Conferences in the San Francisco area next week. Let me know if you'll be in town and want to meet. My contact info is here.

On Monday, I'm speaking at Mobile Web Megatrends in Berkeley. My topics are:

Mobile data: Convergence or divergence?
The press is predicting a clash of the titans as Apple, Google, Nokia, and a host of other players all try to dominate the smartphone market. How is the battle likely to turn out? Will one company dominate the market? And where should a mobile app developer invest?

and

Apps for mobile devices - What happens next?
Apple's iPhone app store is getting a lot of publicity, and some industry players, such as TMobile USA, are rumored to be working on something similar. What's the future of mobile applications? Will the market grow explosively? What are the barriers to growth? Can a competitor beat the iPhone app store, or is everyone just going to play catch-up?

The speaker lineup is interesting, and I'm looking forward to it.

On Tuesday and Wednesday I'll be at the Tech Crunch conference in San Francisco (not speaking there, just taking notes). On Thursday it's CTIA, and then on Friday I'm an un-panelist at the Mobile Jam Session at CTIA. The folks at WIP have set up some very interesting discussion sessions.

I'll be posting some notes on what I hear, both here and at Rubicon's website.