Proof reading and related updates to Release notes?

[Martin Bagge / brother]

Did the Swedish translation of the Release notes over the last few
days. One of the great things with this is that I also read most of
the English strings during this process and I found a bunch of
oddities that I think need to be adjusted. I am not sure about the
process for updating the source text used. Mostly it's concerns with
Stretch vs stretch vs &releasename; and debian vs &debian; and other
such constructs. Can probably be handled by a script in many cases.

What files and how do I submit them for review by someone else than
me, I rather have some proofing before making all translations fuzzy =)

- --
brother
http://sis.bthstudent.se

[Justin B Rye]

Post by Martin Bagge / brother
Did the Swedish translation of the Release notes over the last few
days. One of the great things with this is that I also read most of
the English strings during this process and I found a bunch of
oddities that I think need to be adjusted. I am not sure about the
process for updating the source text used. Mostly it's concerns with
Stretch vs stretch vs &releasename; and debian vs &debian; and other
such constructs. Can probably be handled by a script in many cases.
What files and how do I submit them for review by someone else than
me, I rather have some proofing before making all translations fuzzy =)

I'm just starting my own copy-editing sweep - what I usually end up
doing is splitting it up into a large number of bug reports (cf.
"https://lists.debian.org/debian-doc/2015/04/"). There's still work
to be done just on getting the right content before we start trying to
polish it up and have it translated; much of that is an automatic
result of our insane workflow of basing the list of things that will
be new in Stretch on the list of things that were new in Jessie.

On the &releasename vs Stretch vs stretch issue: personally I'm in
favour of avoiding the use of the &expando entirely, since its main
effect is to make it harder to tell what the output will look like and
disguise the bits that are out of date - anything that's *always* true
shouldn't be mentioning a releasename anyway. But note that the
canonical form is (rather mystifyingly) lowercase: "stretch".

[Baptiste Jammet]

Hello Martin,

Post by Martin Bagge / brother
Stretch vs stretch vs &releasename;

... and vs &Releasename; !

Post by Martin Bagge / brother
On the &releasename vs Stretch vs stretch issue: personally I'm in
favour of avoiding the use of the &expando entirely,

I think that "&releasename;" should be used where nothing change from a
release to another, ie everywhere, except in "issues" & "what's new"
chapters that are cleaned up for each new release.

Post by Martin Bagge / brother

Post by Martin Bagge / brother
What files and how do I submit them for review by someone else than
me

Files are in the ddp svn
https://anonscm.debian.org/viewvc/ddp/manuals/trunk/release-notes/
http://www.debian.org/doc/cvs
and, as Justin add them in Cc, proofread english is done by
debian-l10n-english team.

Baptiste

[Justin B Rye]

Post by Baptiste Jammet

Post by Martin Bagge / brother
Stretch vs stretch vs &releasename;

... and vs &Releasename; !

Just when I thought I'd worked out whether we were standardising on
"stretch" or "Stretch"... The answer at present seems to be that
we're standardising on "stretch" no matter where you use it in a
sentence... unless you roll a 1. Almost all of the cases of
&Releasename; appear to be in issue.dbk, and inexplicable.

Personally I would be in favour of declaring that Debian 9 is
canonically "Stretch", because it's named after something called
"Stretch". But for now I'm trying to edit the files into compliance
with the current standard.

Post by Baptiste Jammet

Post by Martin Bagge / brother
On the &releasename vs Stretch vs stretch issue: personally I'm in
favour of avoiding the use of the &expando entirely,

I think that "&releasename;" should be used where nothing change from a
release to another, ie everywhere, except in "issues" & "what's new"
chapters that are cleaned up for each new release.

It's true, in some of the .dbk files it almost makes sense - but those
are the places where it's pointless to specify a releasename. The
files that people ever need to edit are the ones where things change
frome release to release, and there &releasename just causes trouble.

Similarly, I was just noticing that the &debian; entity makes sense
in about.dbk (which someone might want to recycle for a derivative)
but not in moreinfo.dbk (which has lines like "further documentation
on &debian; is available from the Debian Documentation Project").