Re: Evolution and support for rtl languages



It's true that I am a little bit umm "aggressive" ;)
Well I ccd the mail to the lists yesterday ... hmm Well at least I'll
write a new polite and detailed bug report (well I'll try to write one).

yours
Arafat

Am Fr, den 23.04.2004 um 23:54 Uhr +0200 schrieb Christian Rose:
> fre 2004-04-23 klockan 21.15 skrev Arafat Medini:
> > > > Hopefully it will get fixed, but here comes the second point (or more
> > > > the POINT...) if I ask for it to get fixed and I get the answer that it
> > > > will not, at least not in the coming 4 to 5 years (maybe I understood
> > > > something wrong as they didn't directly say : "we will fix it after 5
> > > > years...") But if you feel something like that you simply panic. Well at
> > > > least I panic.
> > > 
> > > Really important things do get fixed because anyone can fix them. Nobody
> > > has the power to force anybody to work on anything unless they are
> > > paying them. You might find that inconvenient but it's still true.
> >
> > I was never against what you are saying or what others think. Still this
> > will not help me or that big portion of ppl outa there...
> > It's not about forcing, you can't force OSS work it's about getting it
> > in ppls mind, and making them "feel" the importance of work on that
> > topic.
> 
> Exactly, that's why I suggested to bring it up on more suitable lists
> for this purpose. You're essentially just preaching to those already
> convinced here. ;-)
> 
> What I would do in your case, would be to bring this up on
> desktop-devel-list and evolution-hackers, and carefully explain in a
> detailed and non-blaming way¹ what the problems are and also why it is
> important to get such bugs fixed. I'd also explain in a polite manner¹
> that currently Evolution doesn't meet the high standards in this area
> that the rest of GNOME fulfill, and so that it would probably be good if
> this could be fixed in Evo before or shortly after Evo becomes part of
> GNOME.
> As Murray pointed out, Evo probably won't be left out of GNOME just
> because of this issue, since a lot of people want it in and have worked
> hard in other areas of Evo to make it live up to other GNOME standards
> and integrate well, and Evo was initially already proposed for GNOME
> 2.6, so a lot of people are desperately waiting for it to get in. But
> that doesn't mean that you couldn't point out that this needs fixing
> soon, and will look weird and below the usual quality of GNOME. I can't
> say these things for you though, I know close to nothing about RTL
> issues in general and what issues there currently are in Evo, so you do
> need to say this yourself on those lists.
> 
> Also everything what Murray says about not being able to force anyone to
> work on something is of course true, but that doesn't mean that one
> cannot be successful by helping developers to you. I think you could be
> successful that way in this case. To me, not being an expert on RTL
> issues, the above bug report in Bugzilla looks very short on details. It
> basically says "a lot of things are broken in the Evo UI with regards to
> RTL" but is short on details on exactly what those things are. I didn't
> get much wiser myself by reading that report. Also, an attached
> screenshot can be helpful but only if it's clear what specific problem
> it is supposed to be showing.
> 
> Something developers like very much is seperate issues being reported
> seperately in Bugzilla. That way they can resolve the issues one by one
> and mark the individual reports solved one by one, instead of looking at
> one gigantic and confusing report that tries to cover all problems, and
> try to figure out what problems are already fixed and which still need
> fixing from that  report. Developers and other contributors are often
> also looking for easy bugs to fix; by doing multiple detailed and
> specific bug reports about seperate and specific problems, many people
> can solve the problems in parallell, and often they won't be that
> difficult to solve if they're specific enough and only describe one
> smaller problem.
> 
> So what I would do in your case would to be split up the initial report
> above into smaller ones, by first doing some new reports (and perhaps
> later adding a comment  to the initial report saying something like
> "This report was split up. For the problem about XYZ see bug 12345, for
> the problem about ABC see bug 12346" and so on).
> In the new reports, try to only focus on one specific problem in every
> report, for example a specific toolbar being rendered wrongly. Try to
> explain the problem in detail in the bug report text, explaining what is
> currently wrong with the toolbar and what it should be like instead.
> Perhaps attach a small screenshot showing only the toolbar in this case,
> or draw some arrows on the screenshot that points out the problematic
> area before attaching the screenshot. That way, it will be easy to see
> from the screenshot what is being rendered wrongly and what the bug
> report text describes.
> 
> If there are other issues, such as tree views, other widgets or other
> areas in the interface that are being rendered wrongly with regards to
> RTL, put those in other, seperate bug reports.
> 
> This may sound like a lot of work when reporting, and sure it is some
> more work. But the difference is that when things are reported in
> specific, detailed reports this way they are *so* much more likely to
> get fixed. Often the process of getting a problem fixed is by meeting
> halfways: for the bug reporter to describe the problems specific and
> detailed enough so that the developer knows what to fix.
> 
> I can't do this for you though -- you or someone else that knows about
> and can describe the current RTL problems in Evo needs to do this.
> 
> More details about good bug reporting practice can be read at
> http://bugzilla.gnome.org/good-bugs.html.
> 
> 
> Christian
> 
> 
> 
> ¹ Obviously I myself often fail in this area, but hopefully others can
> do much better.
> 
> 




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]