Re: [RFR] templates://glide/{libglide2.templates,libglide3.templates}
On Mon, 2009-04-13 at 09:16:51 +0200, Christian Perrier wrote:
> Quoting Justin B Rye (jbr@edlug.org.uk):
>
> > > Mostly because of the rewording, but I think that both have the same
> > > weight. "Please report" or "you should report" have, IMHO, the same
> > > level of urgency.
> >
> > I like the "should" version. You introduced a "please" to mark the
> > action that the user is being asked to make a decision about, which
> > is a common convention in templates. Having another "please" in the
> > same template might distract from that; saying "you should" turns it
> > into part of the factual background information (it's their duty as
> > well-behaved members of the community!) instead.
>
> So, I kept "our" version...
(Just a note, I didn't initially write those templates nor the package
descriptions.)
Well, I still find the should a bit strong, and don't think the users
should feel obliged to do anyting. But I agree two "please" do not
sound nice. So I guess I don't mind that much.
> > > This is something we discussed in former reviews. The standard for
> > > en_US is definitely double quotes for quoting and our reviews are
> > > standardized on en_US spelling and typography....even if the main
> > > reviewers are British (except /me of course)..:-)
> >
> > I'm happy to standardise things in either direction. I've never
> > seen any particular evidence that modern en_GB users as a whole
> > prefer singlequotes, especially when typing on keyboards with
> > perfectly good <"> keysyms that would otherwise go unused.
> >
> > A harder question is whether we'd "correct" UTF-8 curlyquotes.
>
> ...which is not the case here..:-)
>
> So, Guillem, based on that rationale, I'd prefer keeping the double quotes.
I tend to use different styles of quotes even when crippled by not being
able to use proper UTF-8 ones. Single quotes for commands, programming
syntax, and similar and double quotes for just normal text. But I guess
this might be rather unorthodox?
> > >> Please use '*'. I've always got the impression that was the most used
> > >> itemization style in Debian, the recent numbers posted on debian-devel
> > >> confirms that, and I'm guessing the Smith project in a way might have
> > >> slightly turned the balance on those numbers.
> > >
> > > I followed that discussion and I understand the argument.
> > >
> > > I would prefer an argument from a typographical reference here.
> > >
> > > I think that the best reference for this would be the Chicago Manual
> > > of Style. I suspect we might end up with asterisks, though.
> >
> > In printed publications of course the standard is to use genuine
> > U+2022 bullet points, not asterisks. If we're sticking to things
> > we've got on our keyboards, asterisks make sense since after all
> > they're the most "bulletlike" character we've got and aren't useful
> > for much else. But minuses and pluses work too.
>
> The point here is that Guillem is somewhat right about asterisks being
> more used (see -devel) but we "slowly" enforced minuses so reverting
> this might be kinda inconsistent.
>
> I'm balanced here: no solution is really good... I may have a very
> small peference for using asterisks as of now on the basis of current
> practice...and too bad for the already reviewed descriptions and
> templates..:-|
I've just posted more numbers. :) And I don't see the problem in
reverting the recommendation, keeping it just seems to make it worse.
> > >>> We generally recommend dropping "NOTE:" stuff.
> > >>
> > >> Why? I don't have a strong feeling about it, but it seems to make it
> > >> easier to visually mark this kind of out-of-band dependency information.
> > >
> > > In general, the reasoning is that separating in a paragraph is enough
> > > for the notice to be visible and we do our best to discourage the use
> > > of all-capitals letters (yelling, etc.). That also goes with a general
> > > stance where texts should be as neutral as possible and avoid carrying
> > > "emotional" charge...
> >
> > What makes the kernel requirements "out-of-band" and the hardware
> > requirements "in-band"(?), anyway?
It's dependency information that cannot be properly expressed in the
Depends field because the module is not provided pre-built.
The hardware informatin is something that the packaging system cannot
reliably check against, as it might change between reboots.
> > The real problem is that everything you say in a package description
> > _could_ be preceded by a "NOTE" prefix. This one was already a
> > prime example of note proliferation, since there's three successive
> > paragraphs start with "Note", "Also note", "NOTE:"!
Oh, no, the all-uppercase is just wrong, I had not changed it yet
because of the freeze, was planning to do so, when reworking the
templates (which will not be needed anymore now). I was only referring
to the "Note:" part. Anyway I was just wondering about the rationale,
and as I've said I don't have a strong feeling about it. So ok.
thanks,
guillem
Reply to: