[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Too technical terms in PO's
From:       Lubos Lunak <l.lunak () sh ! cvut ! cz>
Date:       2001-12-04 22:37:33
[Download RAW message or body]

On Tue 4. December 2001 22:34, Thomas Zander wrote:
> On Tue, Dec 04, 2001 at 11:16:36PM +0200, Claudiu Costin wrote:
> > On Tuesday 04 December 2001 22:40, Rob Kaper wrote:
> > > On Tue, Dec 04, 2001 at 06:33:20PM +0200, Claudiu Costin wrote:
> > > >   There are many places where such strings occur. E.g.
> > > > "KBlabla::init()  died in foobar!". There exist KDebug
> > > > to report errors, especially fatal ones. I think a number
> > > > should be assigned. E.g.
> > > >    "KSuperApp Error code: 12345"
> > > >    "Please report it to author!"
> > >
> > > That's helpful how? It doesn't provide more accurate information for
> > > the author (after all, I supposed the author knows the meaning of
> > > current messages) and it certainly won't make things less cryptic for
> > > users.
> > >
> > > I remember getting a lot of error 12345's with RealPlayer. When I went
> > > to the site for more info, it listed it as "Unknown error". At least I
> > > could've searched Google for cryptic messages.
> >
> >   If numbers are so hated, how can you explain for average user
> > difference between image & pixmap. How about things more complicated. Joe
> > user send this number to author if it feel to be cooperative. But Joe
> > will not bother to send long long error message happned in
> > KSuperApp::mangabanga() virtual method... :)

 No pain, no gain. If Joe User doesn't bother reporting one message, the bug 
is probably not that important.

> >
> > > Some phrases might need to be changed for users (especially the what's
> > > this ones, I guess), but error numbers are horrible and should be
> > > avoided at all costs. (imho)
>
> Agreed; a text on screen is there for the user, not the developer.
> The principle is simple; the user does not have to know much to be able
> to use a computer as long as all the knowledge needed for using this is
> 'in the world' (in contrairy to 'in the head')  Which basically boils down
> to the fact that texts have to be understood without referring to
> documentation.
>
> In both cases this fails; both text are basically wrong and should be
> fixed.
>
> From kcmbackground.pot:
> > "Checking this box lets KDE to use shared memory for image to pixmap
> > conversions."
>
> People don't care about the technical talk; just state what it is that
> actually affects the user when changing the setting..

 Actually, this text is from the _Advanced_ tab. It was me who added it, and 
it's supposed to be removed before 3.0 , so you don't need to worry about 
this specific one. I added some optimizations to background paiting, and I 
expected people to complain about bad results, so I temporarily added the 
options.

> Never mind that the english is broken to begin with ;)
>
> Someone know why it is 'nice' to use shared mem for this? Is it faster?
> Does it mean the memory load is less? What?

 It is faster. Now only if KPixmapIO could do such unimportant things like 
dithering or alpha channel. I'll most probably remove the MIT-SHM part 
together with the option.

-- 
 Lubos Lunak
 llunak@suse.cz ; l.lunak@kde.org
 http://dforce.sh.cvut.cz/~seli

[prev in list] [next in list] [prev in thread] [next in thread]