Imagine that you are Joe-User.  You like an application but can see a lack that
should be easy to sort out.  What do you do about it?

In this case I was looking at Tellico and wanted to create a new report template.  The obvious place to start is the Manual – yes?  Yes, indeed, there is a good deal of information about field types etc. – so I’ll print out that chapter.  No I won’t – you can’t print out from the Manual.

I’m told that PDFs exist in KDE Help Center, so I go there.  I can’t see Tellico listed, so I put it into the search box – and get the Manual.  Back to square 1.

I’m told that if I click on the package in the left pane I can request the PDF which would allow me to print the chapter – I’d never have found that.  Wait – which package? Every package has to be listed until you find the right one, and
Tellico is in the last one. Have you given up yet?

Someone goes to a good deal of trouble to make PDFs of the manuals – and we
hide them where users can’t find them.  This is simply not good enough.  If
there is no easy way to do it in KDE Help Center, there is something, infintely
more accessible, that can be done.  Every application has its Manual in the
Help menu.  Why can’t we have a link to the PDF there as well?

What are your issues with our wikis?

What drives you mad?

What would float your boat?

Whatever the issues, come and talk to me at Desktop Summit.  I’ll be on IRC, #kde-www as much as I can be, and I’ll happily join you in a face-to-face brainstorming session for solving your wiki problems.  See you in Berlin!

So in Part 1 we looked at where we are now, but what of the future?

That’s where we need your help. What can we do to improve the system to meet your needs? Comments here are welcome, but I suspect that we need a greater discussion.

In the first place I’d really like to meet some people from the docbook team and some from the i18n team, together with anyone else who is interested in progressing their own projects in this way. I would suggest that we book some BoF time and space in Berlin, and have our face-to-face meeting, and it would be possible to follow that up with an IRC session so that those who can’t be in Berlin can hear about our discussions and add their input.

So, here’s the question – Are you willing to help us get things rocking? Let me know, and we’ll look for a session time.

By the way – if you are interested in exploring UserBase’s stats further, you can find the full set in a sortable table at http://userbase.kde.org/User:Annew/LangStats

This week I was asked whether it was possible to draw statistics on the status of translations of UserBase pages.  In fact it’s very easy to see the status of languages on specific pages.  The language bar shows, beside each language name, a small box, indicating roughly the status.  Hover over it and you will see what percentage of “strings” or “messages” have been translated into that language.  This, though, was not what the speaker was looking for.  If there is any way of getting a status report for every page in every language, I haven’t found it.  When you consider how big that would be, it probably isn’t even sensible to look for it.  Meanwhile, though, I do have some interesting stats for you.  All the stats were gathered on the 28th July.

First we have the four most active languages over the past month:

Of course those four are not the only ones with a good score of contribution.  Here is the Roll of Honour:

The Roll of Honor

You’d think that the languages with the highest number of translated strings might have a large team – and you couldn’t be more wrong.  Team size has little correlation with output, as the next table shows:

Number in Translation Team

Of course, a more realistic measure of activity is to look at how recently the work was done:

Days since the last edit of a language

Worryingly, though, look at the reverse of that:

Have we lost these translators?

So – Where are we Now?

While there is always room for more, I’m happy that we are steadily increasing our translations on UserBase.  On Techbase, the system is still very new, and before it can be as useful as we would like there needs to be some concensus as to which pages can usefully be translated.  I suspect that a glance at the footer, where the “last edited” date is visible, would give some clear hints for some pages, yet there are others where what was written five years ago is still valid and needs no change.  Clearly, then, only the people who know a particular project or process can make that decision.

We have made considerable effort to get a useful system.  For instance, the markup described in our help pages has grown out of long discussions with Blueck and Yurchor, and at times other translators too.

• The system happily allows translators to work with the off-line tools that are familiar, if that is the wish.
• We have a HowTo for ensuring that your pages are capable of being created in Docbook format at http://userbase.kde.org/How_To_Convert_a_UserBase_Manual_to_Docbook
• We are close to having a customisable “Create a Book” where the user can select the pages that are helpful to his own interests and create a .pdf format booklet.

The Next Step?

Read Part 2!

A week ago Translate came to Techbase.  Since then we have been busy adding pages to help you get started, complete with a bunch of sidebar links. At the moment there are just 23 pages ready for translation.  How many more pages get translated is really up to you.

Why would you care?

TechBase gets some 65,000 unique visitors each month (UserBase gets ~100,000) – and yes, they are genuine visitors.  65,000 visitors don’t drop in just to pass the time – they come in for information, and you can safely bet that a large proportion are not native English speakers.  Yes, the TechBase content is different from that on UserBase, in that much of it is written entirely for contributors to specific projects, but I’d guess that even within projects there are people with a variety of languages – and you can’t guess which language your next volunteer contributor will speak.

What is most needed?

It’s difficult for me to say, but I’d suggest that some areas that should be considered early are

• How to build packages to use within your distro
• How to build a development environment

After that, projects could check their own project pages, updating where necessary.  Bear in mind, all the time, that those pages could be an invitation to new developers.  Are they accurate?  Are they attractive?  Many of you are happy writing Mediawiki code.  If you are not, ask for markup help, but get the bones of the matter down in any readable form.  When you are happy that your pages are ready for translation, let us know, either on kde-www@kde.org or on #kde-www.

At the moment TechBase falls short of the quality we would want newcomers to see.  Let’s do something about it.  Let’s make it a goal to get a body of registered translators before Desktop Summit.  If a BoF at DS would help, say so and we’ll do it.

Which pages would be your priority?

KDE prides itself as being a community.  Is that justified?  I have seen good, hard-working people driven away from projects because they were receiving behaviour from other members of our community that they would not accept from general users.  The Code of Conduct, it seems, is for others, not for ourselves.  We have a number of people in our community that regularly use aggressive behaviour, attacking the work of others without even bothering to ask why their particular dislike was implemented.  What’s worse, they are often very respected members of the community, for the work they do – but why are they allowed to behave like this?  The CWG (and I include myself here, as I was part of it for quite a long time) have done nothing about it – because generally they don’t interfere unless there are complaints from the victim.  ”We can’t offend such a valuable contributor!”  So we allow things to continue.  When a victim simply disappears from the scene, so does the problem – until next time.

It’s time for some serious questions.  What should we be doing when one respected member of the community attacks others?  I’m not talking about words spoken in the heat of the moment, then retracted, but of repeated attacks, apparently designed to make the victims feel worthless.  Often the perpetrator has treated several people in the same way.  We are, or can be, better than this.

Why do we have a Development category on UserBase, when we said quite clearly, many times, that UserBase is for users, not for developers?  The answer is quite simple – developers were once users, and some, a few, users will become developers.  We don’t aim to have any how-to-develop information on UserBase, but it seems to me that it is only sensible to have brief information about the tools that are available and where to find information and support for them.  Unfortunately, I don’t use those tools, and I’m finding it very hard to get up-to-date information about the status of some of the tools.

The Development page has several gaps:

• KBugbuster
• KFileReplace
• Kommander
• KImageMapEditor
• KLinkStatus
• KXSLDbg

How can you help?  In a number of ways.  If you use one or more of these you could

• Write a page about it – ideally in Mediawiki markup, but plain text together with screenshots would be a great help.  We have a new scratchpad area,
• Use the app’s Talk page to give me links to decent material, both for the use of the app
• and for any related Techbase pages
• We have a new scratchpad area called Draft where you can start any outline for such information.

A few minutes of your time could help new developers get started, and who knows?  You may find yourself welcoming one of those into your project.

Less than three weeks ago, at the WebWorld2011 sprint, we decided that we should open editing to all, no longer requiring registration.  During that time there has been an increase of spam, but we had a few genuine edits from people who were not logged in, and on that basis we decided that we would simply deal with the spam and keep editing open.  Yuri Chornoivan has taken the brunt of it, because much of it arrives during the night in my time-zone.  Last night, though, the situation took a turn for the worse.

Previous to that, we were getting registrations that posted pages with external links.  They were a nuisance, but easily spotted, and in numbers we could handle.  The last 24 hours has brought a threefold increase, and of a very different kind.  These are all from unregistered users, and consist of content of existing pages being deleted and inanities inserted.  This moves into an entirely different league, and is intolerable.  I have therefore requested that the sysadmins close editing again.

To those of you who used unregistered editing to add useful information, I thank you, and hope you will continue to add your wisdom.  Registering is still a fairly open process.  You do not have to wait for a confirmation email, or even to give an email address, though we do recommend that you do, as there are advantages such as allowing us to re-set your password if needed.  (Your email address is not visible to other users, at any point.)

I’m sad that we have to take this step, but if any of you read Mediawiki mailing lists you will be aware that many wikis are suffering similarly.  I would like to think that we could open editing again at some future time.

You start to write about your application -

OK, you will need a front page and a couple of sub-pages – that doesn’t sound so bad, does it?  Many people have done just this on UserBase.  Some write directly onto new pages, some are happier to draft their work first, so use sub-pages of their User-space pages, and that works fine.  With our without the help of the UserBase Admins, the content can then be pasted into the correct tree structure and the draft removed – and everyone’s happy.  But what if you want to write a whole manual?

As the Amarok team have discovered, it’s a whole new ball-game.  You start with a Contents page, listing all the pages you think you’ll need, and you start to build.  Before you finish I’ll guarantee that you’ve thought of something that would have been better on a page of its own.  As it happens, that’s not a big problem – you can edit the contents page and create a new page that way.  But wait – what seemed good organisation to start with is less convincing now, and maybe it would be better to move things around, re-organise a little.  Hmm – not so bad!  There’s a little icon for Move – ah yes, it moves the page to the structure you want and even leaves a re-direct behind, in case someone uses the old link.

Sounds pretty good, doesn’t it?  Unfortunately this is where it starts to come unstuck.  Once you’ve finished, the Translators move in – and where should their links point?  If they translate from the original they probably will use the original link, which is now a re-direct.  That’s not good.  We have to clean up re-directs, in that case, and that’s when we find that moved pages have been moved yet again, causing double-redirects – an even bigger job for cleaning up.  You see, we can’t just delete them – there could be a number of pages that link to the old page, so we have to track all links, and in the case of the double-redirect we have to do that for both levels of old pages.  It can be quite difficult to follow, but it’s a necessary part.  Happily we have almost finished the double-redirects – heaven preserve us from triple-redirects!

“So you said I could make it easy for myself?”

We think so.  It’s experimental, yes, but it should help anyone starting new documentation.  Most of what you see on UserBase is in the “Main” namespace, but today we have opened up a new namespace called “Draft”.  You can start your documentation there without worrying about the issues I’ve just talked about.  Move things around as much as you like – just remember that in the end any page links will need sorting!

The idea is that when the pages are ready we can simply move the whole structure into the Main namespace if any redirects have been dealt with, but if it has proved more complex and things have been moved around a lot we can use Copy/Paste to create the Main pages from the Draft ones, fixing links as we go and losing all the redirects on the way.

One last thing – you have to be the main writer for your documentation, and you are used to an entirely different kind of mark-up, finding that attempting Mediawiki mark-up gets you utterly confused.  We can handle that too – and again the Draft namespace is the best place to do it.  Put your plain text there.  Add any markup that will be obvious to us, for instance <bullets>,  and we will help you get it looking the way you want.

Using Draft  should remove a good deal of anxiety and hassle, but we need you to try it out.  Take a look at Draft and let us know what you need to make it even better for you to draft your documentaion.  See you there!

There is a strange sort of time-warp.  We can’t remember which day it is, yet the week is disappearing fast.  Most of the time I’ve been working with a group on UserBase issues.  Matthias (Pipesmoker) Meßmer has been on-call to fix many theming or display issues that we identified, while Niklas (Nikerabbit) Laxström, our wonderful Translate extension author, has added new features for our delight.

In the past, we used “Special:myLanguage” markup to help “other-language-speakers” to get the correct language page, but when you were working on a page, adding a link with that markup did not show the essential red-link that warns you that the page is not yet created.  Now it does show a red-link, which makes life so much easier for all contributors.

Another “big deal” for us was that there were times when it was decided that a page had been poorly named, or wrongly inserted into the page structure.  Because some of our translators are so diligent, we acquired translations of the page almost immediately, and before the problem was realised.   Once a page had translations added it was not possible to move it.  Now, thanks to yet another of Niklas’ efforts, a page together with all its translations can be moved to a new location.

You may remember that Claus Christensen is our Danish translator for UserBase.  He and I have worked mainly on improving accessibility.  Over the lifetime of UserBase we have added a great deal of help for users and contributors, yet people have found it difficult to find the exact function they needed.  We decided that extra sidebar links were necessary.  Again, Matthias and Niklas had to help the more arcane needs, but finding your way around should be very much easier.

Previously we have thought that it is not necessary to translate help pages, on the grounds that in order to translate you have to have a good grasp of English.  Recently, though, Zhao Han pointed out to me that for people who use other-script languages it can be helpful to see translations of help pages, so we worked on that too.

Lots of small changes have happened too, mostly the sort that you don’t notice when they are right, but you would have seen when they were not so good.

Finally, Hans (Mogger) Chen decided that UserBase needed its own strong logo.  He designed a possible logo, then took it to Eugene (it-s) Trounev, who assessed the practicalities and started on “the real design”.  So – watch out for that before the end of the week.

Oddly enough, even through all the long days of activity, we still have managed to have fun.  Eugene’s prowess in the kitchen is now known, and I’m sure he’ll be in much demand in the future too.  I’ve never tried handling food on a swinging barbecue before – and probably won’t again!  You need more hands than an octopus to hold everything steady.  We’ve had wonderful warm, sunny weather, so whenever the head needed clearing we’ve sat outside and discussed things, but we’ve been careful, because the first day some of us were sunburned before we realised what was happening.

I’m so impressed with the amount of work we’ve managed in the time, and will be pushing for a repeat sprint to bring the next set of improvements.