Using userbase for manuals

[Burkhard Lück]

Am Sonntag, 1. Juli 2012, 13:14:19 schrieb Kevin Ottens:
> On Sunday 1 July 2012 10:17:21 Albert Astals Cid wrote:
> > El Diumenge, 1 de juliol de 2012, a les 09:49:11, Kevin Ottens va 
escriure:
> > > More seriously, I think we shouldn't loose perspective here. Yes,
> > > you're right, it *can* happen, but Boudewijn is also right, it's
> > > becoming rare situation.
> > 
> > Sincerely I don't agree, having 100% internet connection each time I use
> > my computer is something I don't have and I do live in Europe, I can't
> > think what's like for someone in poorer regions.
> 
> Indeed, you got a point.
> 
> > > My opinion is that I would love to go for it, and if over time that
> > > turns out to be a problem, we could ship a dump of the relevant wiki
> > > content along the application. It'd be used as fallback if the wiki
> > > cannot be reached online. This way we'd still benefit from the better
> > > contribution scalability of userbase compared to our current
> > > situation.
> > 
> > And i'm going to be a pain here, but i do not agree userbase scale better
> > either.
> > Let's see Krita manual at http://userbase.kde.org/Krita it's translated
> > to 7 languages only two of them being at 100%
> > 
> > Now let's see KMail manual at
> > http://l10n.kde.org/stats/doc/stable-kde4/po/kmail.po/
> > and we have 12 at 100% and a few more over 90%
> 
> Right but that said, the number of translations is not the only metric to
> take into account regarding documentation. Overall quality of it and its
> coverage of the application features, keeping up with changes, are equally
> important IMO.
> 
> That's where I think the wiki is actually superior to the docbook stuff
> we're doing (as Boud and Eike pointed out). 

My experience translating docbooks extracted from userbase pages (which can be 
done via script in a minute) is slightly different. I have never finished a 
translation whithout fixing wrong/outdated stuff in the english documentation.

> Now the low number of
> translations? That's likely in part because our translators are not used
> to look there to translate.
> 
> Which raises the question of: If we were to consistently use the wiki how
> do we best support our documentation translators? Would they just be happy
> with being pointed to the wiki as it is a simple enough tool? 

No, lokalize is a specialized translation tool with features like shortcuts to 
copy markup, a translation memory, a glossary etc. All these features are 
missing translating in the wiki.
And in the wiki I can not change all german translations of "foo" from "bar" 
to "baz" using tools with an editor highligting "foo", "bar" and "baz" in 
different colors like:
$ python checkwordtranslation.py 

Usage:    python checkwordtranslation.py [OPTION] /path/to/pofiledir/ arg1 
[arg2 [arg3]]
          arg1 regexpression of english word in msgid
          arg2 list of regexpr with default translations of arg1, separated by 
","
          arg3 list of regexpr with wrong translations of arg1, separated by 
","
          quote args to use spaces (" ") in regexpressions
Options: -h, --help           : usage
         -s, --summary        : print only summary
         -a, --all            : print list of all messages, default print only 
list of messages with different translation
         -k, --konsole        : only output to konsole, no edit dialog
         -m, --msglen int     : check only msgids with len<msglen characters, 
default no limit
         -w, --words  int     : check only msgids less the int words, default 
no limit
         -t, --translated     : check only translated messages, default all 
messages. If word-lang!="", always true
Output : print messages with arg1 msgid [and arg2 in msgstr] for msgids <80 
characters or <10 words
         if arg2 (regexpr of default translations) !="", a dialog appears to 
edit all messages with different translation of arg1
         use the script only with arg1 to pick up the different translations of 
arg1 from the konsole output
         then use it with arg1 / arg2 / arg3 to find all messages with different 
translation and edit them

> Or would
> they need the wiki content extracted as po files so that they use their
> current toolchain for translation (aka the wiki is a too simple tool)?
> 
Yes

> Both possibilities are fine IMO. Means in the second case we need to write
> an equivalent to our current docbook extractor but for the wiki somehow.
> 

-- 
Burkhard Lück