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

Re: [RFR] templates://xfonts-traditional/{xfonts-traditional.templates}



Quoting Ian Jackson (ijackson@chiark.greenend.org.uk):

> 
> Earlier, I received a bug report without a review.  I closed that bug
> report because it didn't seem to be suggesting any changes in the
> package.
> 
> Now, you send me a review but not as a bug report.  Surely these kind
> of reviews should be filed as bug reports in the BTS ?  Probably with
> some low severity unless you discover serious problems.

They will be.

Here, the first proposal I sent i sent to you (actually to the package
maitnainer) and to debian-l10n-english.

The point is getting comments and suggestions from both by fellow
"English translators" and from the package maintainer (after all, this
is the person who has the most important opinion).

The process you're witnessing is the first version of our workflow,
where the bug report was sent *at the end* of the review process, once
the proposed changes are stabilized.

This process was, as I explained, criticized by some maintainers
because it wasn't using the BTS. So we switched to a second version
where a bug report is opened at the beginning of the process....which
is what I started a few days ago. As, apparently, that process wasn't
fitting your expectations (I admit that the very original bug report
*without* any proposal *yet* may sound strange but, as in 99% of
packages, we always have something to propose, I think it's not that bad).


> > Finally, the reviewed templates will be sent to the package maintainer
> > as a bug report, and a mail will be sent to this list with "[BTS]" as
> > a subject tag.
> 
> I'm not sure who these comments are directed to.  They don't seem to
> be directed to me as maintainer, surely ?  But why are they then in
> this message ?

They are actually directed to both the maintainer (who might not be
aware of our process) and the potential reviewers (most are familiar
with the process....but we can't exclude that new contributors pop up
who want to learn about the process).

> 
> Given all this attention to the exact phrasing in package
> descriptions, it might be good to think about phrasing of the messages
> which carry those suggestions.

Sure. It's quite some time since I didn't review them because they're
apparently OK with most package maitnainers. But I know you're picky,
Ian, so I agree there's room for improvement..:-)

> 
> On to the substantive comments:
> 
> > Here, I tried to avoid the leading lowercase implied by using the
> > package name as first sentence word.
> 
> IMO this is a perfectly correct usage.
> 
> > I'm not entirely happy with the result as it involves passive
> > form....but I prefer this over a version where it seems that
> > packages do things or can "have an idea" about things, while this is
> > indeed the maintainer scripts...or the maintainer himself..:-)
> 
> I think it is perfectly fine to talk about packages doing or having
> an idea about things.  Perhaps it would be better to talk about
> xfonts-traditional having "knowledge of" glyphs but actually its ideas
> about glyphs are vaguer than that.

Let's see what comes out fro mJustin Rye's review. He most of the time
comes up with very interesting proposals....and very often corrects my
bad use of English for more idiomatic use of the language.


> >   To revert the change, simply change the key "*VT100.utf8Fonts.font"
> >   back from "-trad-..."  to "-misc-...", or rename the old file back
> 
> > Other changes are trying to avoid a very lengthy parenthesis and first
> > person use.
> 
> "conffile" and "configuration file" are not quite the same.  

Technically speaking, I agree. However, conffile is too much of
"Debian jargon" for the potential audience of package descriptions :
the average users (my opinion, of course).

> 
> There is nothing wrong with a computer speaking to the user in the
> first person.  Indeed, for the computer to do so often makes matters
> clearest.  It avoids circumlocutions and produces clear and plain
> language.

But, sorry to say so, it looks "amateurish". This is indeed a debate I
already had with Manoj who always bring the example of HAL9000 in such
discussions.

I have never seen any use of first person in commercial software
documentation. This is also something that is highly prohibited in
scientific publications and papers. So, well, this is why I tend to
avoid it (and actually, there are even Lintian warnings for this..:-)


> > - Removing xfonts-traditional would break your X server by removing "fixed".
> > + Removing xfonts-traditional would break the X server by removing "fixed".
> >   .
> >   You should not remove xfonts-traditional while "fixed" refers to one
> > - of its fonts.  You probably want to check the differences between the
> > + of its fonts. You first need to check the differences between the
> 
> Double space after "." is correct.

Very common debate with native speakers, I'm afraid. Depending on the
en_US or en_UK culture of people, the use of double spacing is
used....or not. Typography indeed requests a 1.5em space. The most
commonly accepted behaviour now is leaving this up to rendering
software to convert a "space after full stop" to a larger space,
rather than using the trick of a double space.

But, for many, it comes so naturally that we usually don't "fight
about that. The point we usually bring is consistency over
packages. Most non-native speakers do not use double spaces because
English is one of the few languages where this practice is actually
used and sometimes teached...so the vast majority of wording in Debian
does not use double spaces after full stops, hence the research of consistency.

> 
> >   various /etc/X11/fonts/misc/xfonts-base.alias*, reconcile any changes,
> > - and then run "update-fonts-alias misc".  After that you can retry the
> > - removal.
> > + and then run "update-fonts-alias misc".
> ...
> > Dropping the last sentence that sems useless to me.
> 
> I don't think it's obvious, so I'll leave it in.
> 
> > -Description: Traditional fixed-width fonts for X
> > +Description: traditional fixed-width fonts for X
> > 
> > uncapitalization
> 
> Why ?  This seems entirely wrong to me.

There is a recommendation to avoid leading capitals in package
description synopsis and it is widely adopted. See Developer's
Reference for th full rationale.

> 
> > - Provides "traditional" versions of fixed-width fonts.
> > + This package provides "traditional" versions of fixed-width fonts.
> >   .
> >   These are a set of 6x13 fonts (including "fixed"), with foundry name
> >   "trad" instead of "misc", with several glyphs replaced with earlier
> > 
> > Use a "This package <blabla>" style.
> 
> Why ?  That's just unnecessary verbiage.

Because the full description is meant to use complete sentences, not
telegraphic style.
> >   These changes make the fonts compatible with the US-ASCII character
> > - set.  (UTF-8 is not compatible with ASCII in its usage of the
> > - backquote and some other characters.)  With these fonts, pre-2000
> > + set, as UTF-8 is not compatible with ASCII in its usage of the
> > + backquote and some other characters.  With these fonts, pre-2000
> >   documents (including ASCII art and GNU manuals) will render
> >   correctly.
> 
> What's wrong with parentheses ?  You seem to dislike them.

I think a full sentence in parentheses, separated from the former
sentence, is incorrect. The point of a parenthese is to complete the
remaining of the sentence, not being an autonomous sentence.

At least, in French, this is entirely wrong and I suspect English to
not be different in that matter. But, of course, I will appreciate
being corrected if I'm wrong..:)


Attachment: signature.asc
Description: Digital signature


Reply to: