Discussion:
release-notes: small fixes to whats-new.dbk
(too old to reply)
Andrei POPESCU
2019-04-14 19:00:02 UTC
Permalink
Hello,

While reviewing the Romanian translation I found some typos in the
English version. There is also one small rewording included so CCing
-l10n-english.

Please find attached a patch generated with 'git diff >'.

I can also commit it directly to git or submit a merge request for it,
as you prefer.

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Andrei POPESCU
2019-04-14 19:10:01 UTC
Permalink
Post by Andrei POPESCU
Hello,
While reviewing the Romanian translation I found some typos in the
English version. There is also one small rewording included so CCing
-l10n-english.
Please find attached a patch generated with 'git diff >'.
Of course it helps if I actually attache the patch :)

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Justin B Rye
2019-04-14 20:10:01 UTC
Permalink
Post by Andrei POPESCU
Of course it helps if I actually attache the patch :)
@@ -390,7 +390,7 @@ code.
&debian; &releasename; has <literal>AppArmor</literal> enabled per
default. <literal>AppArmor</literal> is a mandatory access control
framework that allows to restrict programs' capabilities like read,
^^^^^^^^^
Post by Andrei POPESCU
- write and execute permissions on files or mount, ptrace and signal
+ write and execute permissions on files, or mount, ptrace and signal
permissions by defining per-program profiles.
You can allow actions (to occur) or allow users (to do things), but
allowing without a direct object isn't allowed. And when we're
talking about a mechanism for *forbidding* things it's best to avoid
the word anyway!

While I'm rephrasing that I'll change everything else, too - avoid
"like" (these are examples, not an analogy), avoid implying that it
changes rwx "permissions" on files as such, shift the file access
part to simplify the grammar, and finally add "Oxford commas":

framework for restricting programs' capabilities (such as mount, ptrace,
and signal permissions, or file read, write, and execute access) by
defining per-program profiles.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Andrei POPESCU
2019-04-14 20:50:01 UTC
Permalink
Post by Justin B Rye
Post by Andrei POPESCU
Of course it helps if I actually attache the patch :)
@@ -390,7 +390,7 @@ code.
&debian; &releasename; has <literal>AppArmor</literal> enabled per
default. <literal>AppArmor</literal> is a mandatory access control
framework that allows to restrict programs' capabilities like read,
^^^^^^^^^
Post by Andrei POPESCU
- write and execute permissions on files or mount, ptrace and signal
+ write and execute permissions on files, or mount, ptrace and signal
permissions by defining per-program profiles.
You can allow actions (to occur) or allow users (to do things), but
allowing without a direct object isn't allowed. And when we're
talking about a mechanism for *forbidding* things it's best to avoid
the word anyway!
While I'm rephrasing that I'll change everything else, too - avoid
"like" (these are examples, not an analogy), avoid implying that it
changes rwx "permissions" on files as such, shift the file access
framework for restricting programs' capabilities (such as mount, ptrace,
and signal permissions, or file read, write, and execute access) by
defining per-program profiles.
FWIW, this is much better and easier to understand in my opinion.

Your comments are also much appreciated by a non-native speaker as[1]
myself.

[1] corrected from "like", hopefully I got it right :)

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Paul Gevers
2019-04-14 19:10:02 UTC
Permalink
Hi Andrei,
Post by Andrei POPESCU
While reviewing the Romanian translation I found some typos in the
English version. There is also one small rewording included so CCing
-l10n-english.
Please find attached a patch generated with 'git diff >'.
You seem to have forgotten to attach the patch.
Post by Andrei POPESCU
I can also commit it directly to git or submit a merge request for it,
as you prefer.
Instead of plain messages, I prefer to either process this via a
classical bts bug report or one of your options above. Some contributors
don't follow git changes well, so if you need advice on the language I
recommend using the bts. Otherwise, just committing is fine, as well as
an MR if your slightly less sure.

Paul
Loading...