If so, UserBase needs you.  What we need is not so much geek as bulldog determination.  For our wikis to be really useful in the long run they need to keep to guidelines that will enable them to be used with translation tools – both for localization and for translation to docbook.  Working with our translators we have produced a short guide to which all pages should, in time, adhere.  Since we have so many pages I propose that we tackle small groups at a time, editing them thoroughly, so that they can be marked for translation.  You will find the first four groups on the Translation Workflow page.

If you have a little time to spare while waiting for your application to build, we could really use it – we are looking for long-term benefit.

By the way –

There has been a remarkably fast take-up of the new system, as shown by this graph:

Inevitably we have met a few glitches.  The developers have already fixed a few problems for us, but some of the problems need an awareness when preparing pages for translation.  For the moment we would ask you to read http://userbase.kde.org/Translation_Workflow regularly, to see if new points have been added, and to follow the discussions of other issues on the associated Discussion page.

Soon we will distill the feedback into a Best Practices page, similar to our guidance on PageLayout.  With rapid feedback from translators and the extension developers this should be available in just a few days.

To get a translator account, please email me with your UserBase username, and mention the language(s) you will be using.

Some two years ago Uga wrote some wonderful blogs explaining techniques for quality photo editing (Uga’s Blog).  His host didn’t store the actual photos, and in an unfortunate accident the ones belonging to some of the blogs were lost.  I’d dearly like to have all of these on UserBase.  The remaining blog, 1-1: Levels adjust is referenced on UserBase. There were also

• 1-2: Curves adjust
• 1-3: White balance and
• 1-4: Brightness/Contrast/Gamma + Hue/Saturation/Lightness

We had a link to the last one on UserBase – but it appears to be an incomplete address, so I don’t know whether that was lost too.

With the number of keen photographers in KDE there is a distinct possibility that someone saved a copy of those tutorials.  If they could be located I’d ask permission to put them (in entirety, not as references) in UserBase.

Such tutorials should not be lost.  If you know other material that should also be preserved on UserBase, please let me know.

Current Statistics

It’s a while since I wrote about UserBase, but there’s been plenty of activity.  Let’s look at some statistics, first.  We now have 1,212 content pages and 1,236 uploaded images.  There have been 10,889 page edits since UserBase began – and that will already be out of date by the time you read this.  We have 1,459 registered users, of which 20 have contributed this week.  A year ago that statistic was a mere handful.  The total number of views is now 2,764,290!  Kontact is the most-viewed page – well ahead of the Welcome page – and Akonadi has passed GPU-Performance!  A sign of the times, perhaps.

Top 10 contributors this week

Once again the top three places in the Contributions table go to translators.  New contributors since last I wrote are Jzmer, writing about Kimpanel, Afiestas who has undertaken to get the Kbluetooth page sorted out, Aseigo who is writing about Plasmate and Algotruneman – a student on our recent UserBase Editing Klassroom course, who has taken on the difficult twin pages of Krdc and Krfb.

Parlez-vous anglais?

As UserBase has grown, so some of it has become unwieldy, difficult to find for those new to the site, so we have a new initiative to help navigation.  Every English page now carries a Category field at the bottom.   Clicking on that takes you to a page where you can see the list of all pages in the same category.  With a little more work that promises to be very useful.  But what if you are a user with little English, or, even worse, poor skills at reading Latin script?

Clearly we have to do the same categorisation for other languages, but they mustn’t be presented with an English category name.  At the same time, we need standardised category names, to avoid making still more complications, so, after consultation with involved translators we decided that we must make a table of names and ‘approved’ translations.  Hans Chen kindly dented for me, and many people responded quickly,so that we now have 20 out of 31 languages entirely or almost entirely translated in the Category tables.  If you command another language, please take a look at http://userbase.kde.org/Translation_Help_Needed and follow the link to your language, to see whether any more help is needed.

This is just the start of our ‘other language’ support.  We plan to offer translated page names too, which will also mean that searches in other languages will be more successful.  A new tool to make translations easier to manage will be installed shortly, and we’ll put up a page on how to use it.  On-line and off-line translations are supported.  Currently there are many pages with almost no language support, and some translated pages are over a year out of date – something we need to address.  Hopefully this tool will take some of the hassle out of it.  If all goes to plan you will see the start of this within the next few weeks.

What else? Well, the mediawiki engine is to be updated, probably to the same version as is used by Wikipedia, and, oh yes!  A whole new look, based on our new kde.org website, is planned.  Of course our wonderful web team need to draw breath first 🙂

I haven’t updated this topic since September, but I’m very excited about the progress so far.  You may remember that one develope, David Boddie, had done some work, with the result that I could build .png files to visualise my patterns within Dolphin, and that we were hoping that the other developer who had shown interest, Purple-Bobby, would join us.  That’s exactly what happened.  David and Robert Forsyth, a.k.a.Purple-Bobby, attacked the problem from different angles, which proved to be very informative, as they could feed on each other’s ideas.

I originally bemoaned the fact that my patterns, in the format .jef, could not be visualised without running Windows.  Some of you may have seen Linus Torvalds’ blog http://torvalds-family.blogspot.com/2010/01/embroidery-gaah.html on much the same subject.  David gave me .png, and Robert gave me .eps files to be used in the same way.  Neither developer can spare huge amounts of time for this project, but although much progress is incremental, sudden leaps forward happen.  It’s this latest leap forward that excites me.

First – an apology to the KTurtle team.  We have borrowed your icon.  This is, of course, temporary, but it reminded us of a X-Stitch pattern, so was the best available until we make our own.

So this is a representation of the pattern held in the .jef file.  It’s not so easy to see in a small image, but the pattern is contained on a white background, which denotes the actual extent of stitching, while the yellow border surrounding it denotes the size of the hoop to be used.  The application already can gather a great deal of information about the pattern.  One of the considerations to follow this is whether some of that information could be included alongside the actual preview.  We have to wait to see the practicalities of that.  Meanwhile, take a look at how much information we can already gather:

[anne@anne-laptop JEFPreview]$
./JEFPreview LydgateDesign/ArtNouveau/ArtNouveauPeonies348868.jef
JEF file: LydgateDesign/ArtNouveau/ArtNouveauPeonies348868.jef
Date/time:                                                                     
Thread count: 31                                                               
Stitch count: 56297 between 86 and 141 minutes                                 
Hoop: B 140.0mm x 200.0mm                                                      
Pattern: 123.2mm x 164.4mm                                                     
Threads Used:                                                                  
 1: 219 Olive Green 14.997m                                                   
 2: 213 Beige 14.748m                                                         
 3: 257 Cocoa Brown 21.986m                                                   
 4: 219 Olive Green 1.572m                                                    
 5: 214 Brown 9.322m                                                          
 6: 219 Olive Green 1.304m                                                    
 7: 215 Wine Red 3.264m                                                       
 8: 244 Cardinal Red 5.764m                                                   
 ......
 25: 215 Wine Red 0.594m
 26: 234 Coral 3.267m
 27: 244 Cardinal Red 0.254m
 28: 239 Sunflower 0.203m
 29: 270 Mustard 0.713m
 30: 234 Coral 1.319m
 31: 244 Cardinal Red 0.503m

So we know the number of thread changes, the number of stitches, and approximate time to stitch out.  This is always an under-estimation, because it can’t allow for how much time it takes to thread your needle another 30 times!  You’ll see that already there is a big spread in the estimation – the machine can work at different speeds, depending on the type of materials in use.  Then we have the hoop size and the actual pattern size – corresponding to the yellow and white rectangles in the preview.  Finally you have the thread identification number, name, and amount required for each colour change.

This is an impressive amount of information.  Most of it, if not all, can be obtained from the supplied Windows software, but not all in one place.  You have to access different modules of the software to find some of the information – most inconvenient.  As JEPreview stands it provides 98% of what I need.  I can then simply copy the .jef onto the CF card (the latest version of the machine has USB),  insert the card into the machine and stitch.  Of course, if I want to edit the file, change colours or move elements around, I am, for the moment still dependent on the Windows software.  Maybe one day that will be possible too.

New Year is traditionally the time when people re-assess their priorities, and all too often have to make decisions that may not be too comfortable.  So it is with CWG members.  Jucato (Juan Carlos de Torres) has struggled for some time to keep up with his commitments, and has finally and reluctantly decided that he must leave the CWG.  Martin Fitzpatrick (mfitzp), too, has found it progressively more difficult to reconcile the demands on his time, and has also decided that he must step down.  We thank both of them for the time they have given, and wish them both every success in their undertakings.  In their place we have two new members, Ingo Malchow and Jeff Mitchell.

Ingo is best known for his involvement in forum.kde.org, but is now heavily involved in all matters kde-www. The up-coming new websites have been taking much of his time recently, and he is also committed to helping advance significant improvements to userbase.kde.org.  Jeff, on the other hand, has most recently been visible in organizing Camp-KDE, where many of you will meet him in a few days’ time.  He is also deeply involved in many aspects of Amarok development and promotion.  Ingo and Jeff are both known to be good, sensitive, discrete listeners – an attribute that we consider to be absolutely essential.  Lydia, Richard and I, the remaining CWG members, are confident that they will be valuable members of the team.

I’ll end by reminding you of our contact details.  Emails can be sent to community-wg@kde.org, and messages to individual members of the CWG are acceptable.  If you use IRC, it could be useful to include your nick in the message, so that we can catch you on-line if necessary.

The Charter of the CWG is at http://ev.kde.org/workinggroups/cwg.php and the Code of Conduct can be found at http://www.kde.org/code-of-conduct

A wiki is supposed to be an easy place for all to contribute to documentation, but when we held an IRC meeting about UserBase, back in October, it was clear that not everyone found the wikis welcoming or comfortable.  We’ve started several initiatives to solve, or at least alleviate, some of the problems.

Getting Started

First, we have made sure that ‘Help’ in the navigation panel  points to http://userbase.kde.org/Help:Contents – where general guidance is found.  Then, right at the bottom of the page is a Category link.  Clicking on that takes you to a page that lists other pages that you might find helpful – some to help you quickly find what you need, and others to help you get started contributing.  At the moment the English pages are, I believe, fully represented.  Currently you will see some translated pages listed there, but work is in hand to improve this, giving languages their own Category links.  Watch this space!

Getting Help

So – you’ve found your way around a bit, and know roughly what you want to say, but you’re still finding the whole thing a bit daunting.  Well, the first thing is to remember that you are not working in a vacuum.  Sign on to #kde-www on irc.freenode.org and there will always be someone around to help.  Even better – starting next weekend we have a Klassroom course on contributing to UserBase.  Sign on at http://forum.kde.org/viewtopic.php?f=4&t=84864.

Tell me about the course?

The aim is quite simple – to make you familiar and comfortable with the tools of mediawiki editing and the layout of a typical UserBase page.  This course is for you if

• You are a user without development skills and want to make your contribution by helping others to enjoy KDE software
• An application that you use frequently has little, or outdated, documentation on userbase, and you know you could help people get more out of it.
• You are a developer, and your application is under-represented, or not represented on UserBase.
• You are a developer and have documentation elsewhere but want an easier place to work with it.

You will work on a UserBase page, asking questions on a dedicated forum thread.  You will see questions asked and answers received by other students.  You will do the work at times when it suits you.  Help pages have been prepared to give you all the tools you are likely to need.  In fact, the aim is to make it as un-threatening as possible.

Sign up

This week is sign-up time.  We look forward to seeing you on http://forum.kde.org/viewtopic.php?f=4&t=84864 or come along to #kde-www to ask questions.

A quick note to tell of a small but important change.  We have occasionally met some administrative difficulties on our wikis.  Nothing out of the way, if only we had been able to contact the contributors.  However, the problems arose because the contributor was not logged in.  We have no way of talking to him/her.  In view of this the deicision has been taken to require login before any edit can be done.  On UserBase alone we now have 1074 registered users, so clearly registering is an acceptable process, and it will certainly make life much easier for our various maintainers.  The change will affect each of our wikis, starting over the next few days.

I’ve quite a bit to report on progress and planned changes, so more about that in a day or two.

subtitle: Is UserBase selling you short?

If you follow my blogs you’ll know that one of my preoccupations in UserBase is with navigation.  More than once I’ve seen a mailing list message that UserBase contains no information about a particular problem, whereon I’ve had to reply with a link to the information.  The search facility built in to the wiki is not good, and we have plans to do something about that, but that alone isn’t enough.

When I first saw Dolphin I fell in love with Breadcrumb Navigation, and I have wanted something like that for UserBase ever since.  I began manually adding breadcrumbs, but stopped when it was pointed out that scalability was a big problem.  We now have over 1000 pages.  It just isn’t a solution on that scale.  Now we are looking at possible mediawiki extensions to deal with the problem.  There are several, and at the moment we have not made the decision as to which best suits our purpose.  However, most of them do rely on pages being allocated to Categories, so for the last week I have concentrated on getting those categories working.  I’m mopping up the last few English pages now, and when I’ve discussed with our active translators I’ll help them get the translated pages categorized as well.  That’s the good news part.

While I’ve been doing this, I’ve had an enormous shock.  I found pages that I had forgotten existed.  Worse, everyone else seems to have forgotten them too.   Once we get our navigation improved all those are going to be so much more visible – and you will not be happy with the result.  I really need your help.  I need you to look for the page for your application, then also use the Category link at the bottom of the page to check for related pages.  I need you to check for these things –

• Are the screenshots horribly out of date?
• Is a revision, either of the application or required SC version, mentioned and is it up to date?
• Are there links to related UserBase pages that are no longer relevant?
• If there are links to external project pages, are those links still correct?

Then there are at least two applications that have compile instructions on UserBase.  From the start we agreed that those are not for the average user.  After consulting the developer mailing list it was agreed that the UserBase page should carry a link to a page under http://techbase.kde.org/Projects, and the compile instructions moved there.

We have so many plans to improve UserBase over the coming months.  It would be a pity if that improvement caused embarrassment by exposing such problems, so please take a good look at your pages.  You are always welcome to contact me by email, or to catch me on #kde-www.

The third and final part of my wanderings today concerns the development of our wikis.  I told you last time that the forum team have set up a sandbox wiki for us, and a good deal of work has come out of that during that past two weeks. A special thanks is due to neverendingo, who has done so much work for us.

When we started this I had not realised that the reason our wikis are consistent in looks is because they share the same skin.  Even when I first heard that, I didn’t entirely realise the consequences of this.  Basically, apart from content itself, anything that is done to one of the wikis will also affect the others.  The downside of this is that we really should have agreement among all the wiki maintainers before things get changed, and that really means that we need to be exchanging views far more often.  #kde-www is the easiest place for this to happen.  The upside,though, is huge.  As long as we can get those communication channels working, it means that any and every issue we can identify and fix on our sandbox can be used to the benefit of all our wikis, giving noticeable improvements to them all for minimal effort.

One issue that we have looked at concerns the Recent Changes RSS feed, which has been broken since our Mediawiki installation was upgraded to 1.14.0.  I had hoped that upgrading to 1.15 would fix it – but it doesn’t.  We have 1.16alpha installed on our sandbox – the version that is due to be release in the next few weeks (and it is remarkably stable, as far as our limited use can tell) – but that doesn’t fix it either.  From reading posts in the archives of the Mediawiki mailing list it seems that the decision-makes at Mediawiki don’t think it’s worth putting time and effort into fixing RSS when Atom feeds are totally reliable, and, they say, more powerful.  I have been watching voth RSS and Atom feeds for both UserBase and Userbase-testing for a while now, and I have to say that the Atom feeds are great.  That begs the question, though, of whether RSS feeds should be offered on our wiki pages.  Because they are so well known, not to offer them might seem very strange.  However, offering something that is known to be really badly broken is embarrassing.

The other issue that has been taking our time is that of developing systems to help with translations.  We are getting a great deal of help from the two developers of the translation extension, which naturally feeds back to improve the extension for everyone else.

As we have talked to translators it has become clear that we are not going to get a one-size-fits-all solution, so we are looking at a two-pronged attack.  The main, and intended, usage of the extension is to do it on-line.  The source is marked up as translatable, and from then on changes are tracked so that the translators can see what needs updating.  It’s a new way of working, so there is a small learning curve, and there are still a few wrinkles to iron out, but it’s looking very promising indeed.

For those who prefer to work with familiar tools, the extension does allow export and import of .po files.  Again, there are wrinkles, but the main system is actually working now.  This system is also one that would be useful for creating docbook files.  There is a downside, though, to using this method for translations.  What if we have more than one translator for a language, and one starts to work on it on-line but the other has downloaded it for off-line translating?

Apart from the RSS issue, I don’t think we’ve found anything so far that can’t be fixed, one way or another.  If you have any involvement with our wiki sites, please do join us on #kde-www whenever you can, to be part of the development.  I have high hopes that we can make a huge contribution to the wikis.