(Since, I would be writing a bit more in response to the comments on my earlier post, I decided to make it into another post.)
Thanks Chris for dropping by. I hope to make it clear that I do not intend to point fingers at individuals, but rather the overall scheme of things where more often than not, the results take a backseat – much like red-tapism.
“Selection of locale specific search engine plugins, RSS feeds and services is a key part of trying to give that kind of good experience and I’ve been a big proponent of trying to make sure that we don’t just have en-US selections in the UI of the locale versions. That doesn’t serve the best interest of the user, but it does create some tough work for the localization teams. Some teams love this ability to customize the browser to their locale, and some find this extra work tiresome. Where we can find people that want to get involved with the research to find the top search engines and services we definitely want to try and add them as contributors to the localization teams to help distribute the work load. “
Regarding the above statement, I remember exchanging notes with Axel during Foss.in last year (a good 2 hours, he was kind enough to spare). Especially, about the fact that the standard productization process seems to go through lots of bends. For each language. Given the headstart a few languages had gotten, a natural assumption for l10n volunteers is that the processes would be streamlined into segmented divisions over the course of time. e.g. Pooling of alternatives for indic languages, which would probably share a few resources due to their geographical relevance (RSS feeds, start pages, searchplugins etc.). Re-inventing the wheel in this case is a (re)research overhead for all parties involved. e.g. the amount of time Mic spent chasing up rediff.com for their consent for bn-IN, would be spent again for another language. Instead, if approval for all Indian languages is gained from these Indian websites at one go, all other languages could simply walk-through the process. Same for the earlier mentioned leg-work regarding the First-Run pages. Imho, not too many language groups share such a huge geographical boundary and web-presence. But we do and perhaps merit a somewhat customized localization process. I have been waiting for the FFx2 productization process to reach its end, so that I can collate all the steps that I have completed and create a documentation (checklist with pointers), for other localization teams. Especially, the parts regarding the India-specific bits.
I do not intend to be given leeway by unexplained choices for an under-baked product. Rather I’d like to see things done with precision – from both ends – to be assured of a product cured of basic failings. I do agree in a way with Axel when he says – “The right thing is to get users a sustained on-line life with mozilla, the wrong thing is to make marks on the wall and just count languages.”
“On-life sustenance” comes from the fact that the basic foundation of the product is strong enough to withstand the expectations from users. What those expectations can be is a matter of homework in the right direction. Marks on the wall always look good, but are not always in the deepest shade.
Secondly, about the messaging. I would agree that restricting the press coverage is not an option. However, correct packaging of the message is important. That is what I intended to convey. From my personal experience of having to explain how-open-source-projects-work, to various audience levels, I can say that the analogy to be used, differs widely. Mainstream media, to most extent do not understand the concept of “volunteer-driven-open-source-projects”. Its a shade of gray, that does not belong to their black and white world. Passion-driven projects are the ones equated with NGOs or hobbyist groups (intended without a commercial motive). Hence, relative circumstances would probably play a huge part in customization of the jargon.