Bug#786448: [RFR] templates://neurodebian/{neurodebian.templates}
Dear i18n team et al!
First of all thank you again for all your work/contributions! I thought
to jump on addressing them all right away but other RL duties
overwhelmed me. I hope to actually take care about this in 2 weeks when
I get back and schedule normalizes. Meanwhile my few comments are
inlined below with hope to boil down the optimal patch. BTW -- if
easier, neurodebian package is available also from github
(https://github.com/neurodebian/neurodebian/) so if you are working
within git -- feel more than welcome to send a PR with the changes to
be merged.
On Thu, 04 Jun 2015, Justin B Rye wrote:
Christian PERRIER wrote:
It's indeed hard to detail each and every proposed changes : there are
many because the original files had to be both reviewed for English
usageand also using the standardized writing style we usually
recommend.
The same stands for debian/control.
--- neurodebian.old/debian/neurodebian.templates2015-05-21
21:14:37.627014717 +0200
+++ neurodebian/debian/neurodebian.templates2015-06-04
10:07:49.400262065 +0200
@@ -5,26 +5,30 @@
Template: neurodebian/enable
Type: boolean
Default: false
-_Description: Should NeuroDebian repository be enabled?
+_Description: Enable the NeuroDebian packages repository?
Make that package repository.
wouldn't it collide with NeuroDebian package as if it is only about
that package (or packages for that sake)?
- NeuroDebian project provides a separate APT repository with backport
- builds of most recent releases of maintained software, datasets and
- some software not in Debian proper yet. Enabling this additional
- repository will make those packages available on your base system.
+ The NeuroDebian project provides a separate APT repository with
+ the most recent releases of maintained software and datasets as
+ well as software that is not yet provided in Debian.
Are we avoiding the phrase backport builds on the basis that it's
developer jargon? The trouble is, backports aren't necessarily the
same thing as the most recent releases. And does maintained
software mean some software (which we're maintaining) or only the
software that's maintained? And doesn't the category software that
is not yet provided in Debian also cover both the backports and
datasets?
first to clarify: some software packages we are not directly
maintaining ourselves (thus we're maintaining would be misleading) --
some are maintained by upstream authors, some we simply re-build
to provide backports from current testing.
To address your comment about the most recent, I would be ok
rephrasing the most recent releases into recent releases.
I am ok to avoid backports (since we also have standalone and
sloppy builds ;) )
Maybe we should just say:
The NeuroDebian project provides a separate APT repository with
software that is not available in Debian, including datasets and
backported new releases.
This phrasing imho misleads a bit since majority of the software we
provide from NeuroDebian IS available in Debian (we aim to upload to sid
and NeuroDebian at the same time), just possibly of previous
releases.
I should hope by the time they're reading this users would already
know what NeuroDebian is anyway.
+ .
+ If you choose this option, those packages will be available
+ for upgrades and installation.
Minor tweaks:
.
If you choose this option, these packages will be available for
installation and upgrades.
- .
- Note: although NeuroDebian team aims to assure robust and correct
- operation of provided packages, enabling this additional archive
- might compromise the integrity of your base system.
+ .
+ Even though these packages are closely maintained
+ by the NeuroDebian team, enabling this additional archive
+ may compromise the integrity of the system.
OK.
Template: neurodebian/release
Type: select
-Choices: auto, ${releases}
+__Choices: automatic, ${releases}
+Choices-C: auto, ${releases}
Oh, one of these.
any preference? ;)
Default: auto
_Description: Release name of the base system:
- Specify for which Debian or Ubuntu release (e.g. wheezy or trusty).
+ Please specify the relevant Debian or Ubuntu release name
+ (for instance wheezy or trusty).
It's not immediately obvious what the name would be relevant
to; how about
Please specify the appropriate Debian or Ubuntu release codename
(for instance stretch or trusty).
(Updating the Debian codename just for futureproofing.)
yeah -- sounds good
.
- If 'auto', Debian or Ubuntu release name will be '${release}' as
- deduced from the output of apt-cache policy. If the release of your
- system is not '${release}' -- please choose specific one which
+ If this is set to automatic', the release name is chosen
+ after the output of apt-cache policy. If the release name
+ for this system is not ${release}, you should choose specific
Bug#786448: [RFR] templates://neurodebian/{neurodebian.templates}
Thanks for taking the time to double-check my efforts!
Yaroslav Halchenko wrote:
[...]
BTW -- if easier, neurodebian package is available also from github
(https://github.com/neurodebian/neurodebian/) so if you are working
within git -- feel more than welcome to send a PR with the changes to
be merged.
Sorry, no, I don't really understand Git.
On Thu, 04 Jun 2015, Justin B Rye wrote:
-_Description: Should NeuroDebian repository be enabled?
+_Description: Enable the NeuroDebian packages repository?
Make that package repository.
wouldn't it collide with NeuroDebian package as if it is only about
that package (or packages for that sake)?
A NeuroDebian package repository might mean a repository for the
NeuroDebian package *if* there was some reason to expect that single
package to have a repository of its own, but if that was what it
meant, it would be a mistake to capitalise it as NeuroDebian - the
individual package is called neurodebian.
There's a tricky point of English syntax here. In a stack of nouns
like window manager bug tracker, we don't normally say windows or
managers or bugs even though there are presumably lots of them.
However, there are also plentiful exceptions.
Putting all that to one side, we could in fact get by with just
_Description: Enable the NeuroDebian repository?
since no other sort of repository is relevant.
- NeuroDebian project provides a separate APT repository with backport
- builds of most recent releases of maintained software, datasets and
- some software not in Debian proper yet. Enabling this additional
- repository will make those packages available on your base system.
+ The NeuroDebian project provides a separate APT repository with
+ the most recent releases of maintained software and datasets as
+ well as software that is not yet provided in Debian.
Are we avoiding the phrase backport builds on the basis that it's
developer jargon? The trouble is, backports aren't necessarily the
same thing as the most recent releases. And does maintained
software mean some software (which we're maintaining) or only the
software that's maintained? And doesn't the category software that
is not yet provided in Debian also cover both the backports and
datasets?
first to clarify: some software packages we are not directly
maintaining ourselves (thus we're maintaining would be misleading) --
some are maintained by upstream authors, some we simply re-build
to provide backports from current testing.
I'm afraid that hasn't helped. Why do you specify that the project
provides backport builds of [the] most recent releases of
*maintained* software if it also provides software that you're only
backporting, and if that *doesn't* count as maintaining it?
Oh well - the word maintained doesn't occur in my draft, so maybe we
can just ignore this question.
To address your comment about the most recent, I would be ok
rephrasing the most recent releases into recent releases.
It's okay, I wasn't quibbling about that; I was saying that specifying
that they're backports provides extra information. In ten years time
the .deb in question won't be a recent release, but it will still be
a backport.
I am ok to avoid backports (since we also have standalone and
sloppy builds ;) )
Well, standalone builds are a different thing, but sloppy builds
(at least in the old volatile-sloppy sense) *are* backports, aren't
they? The only thing different about them was that they're backports
to release N of a package version newer than the one in release N+1.
Maybe we should just say:
The NeuroDebian project provides a separate APT repository with
software that is not available in Debian, including datasets and
backported new releases.
This phrasing imho misleads a bit since majority of the software we
provide from NeuroDebian IS available in Debian (we aim to upload to sid
and NeuroDebian at the same time), just possibly of previous
releases.
I'm not sure what you mean by just possibly of previous releases.
Why would you bother keeping software in the NeuroDebian repos if the
exact same piece of software (with the same version number) is always
going to be present in Debian? Surely the point of the repository is
the software it contains that *isn't* available from elsewhere?
Maybe we're just interpreting software slightly differently?
Besides, a repository with package version 3.1 isn't necessarily a
repository *without* version 1.0.
And anyway:
I should hope by the time they're reading this users would already
know what NeuroDebian is anyway.
[...]
Template: neurodebian/release
Type: select
-Choices: auto, ${releases}
+__Choices: automatic, ${releases}
+Choices-C: auto, ${releases}
Oh, one of these.
any preference? ;)
I just mean oh, this is one of those templates with a Choices-C
field. Though if I get the option, I'll pick automatic, thanks!
--
JBR with qualifications in linguistics, experience as
Bug#786448: [RFR] templates://neurodebian/{neurodebian.templates}
Christian PERRIER wrote:
It's indeed hard to detail each and every proposed changes : there are
many because the original files had to be both reviewed for English
usageand also using the standardized writing style we usually
recommend.
The same stands for debian/control.
--- neurodebian.old/debian/neurodebian.templates 2015-05-21
21:14:37.627014717 +0200
+++ neurodebian/debian/neurodebian.templates 2015-06-04 10:07:49.400262065
+0200
@@ -5,26 +5,30 @@
Template: neurodebian/enable
Type: boolean
Default: false
-_Description: Should NeuroDebian repository be enabled?
+_Description: Enable the NeuroDebian packages repository?
Make that package repository.
- NeuroDebian project provides a separate APT repository with backport
- builds of most recent releases of maintained software, datasets and
- some software not in Debian proper yet. Enabling this additional
- repository will make those packages available on your base system.
+ The NeuroDebian project provides a separate APT repository with
+ the most recent releases of maintained software and datasets as
+ well as software that is not yet provided in Debian.
Are we avoiding the phrase backport builds on the basis that it's
developer jargon? The trouble is, backports aren't necessarily the
same thing as the most recent releases. And does maintained
software mean some software (which we're maintaining) or only the
software that's maintained? And doesn't the category software that
is not yet provided in Debian also cover both the backports and
datasets?
Maybe we should just say:
The NeuroDebian project provides a separate APT repository with
software that is not available in Debian, including datasets and
backported new releases.
I should hope by the time they're reading this users would already
know what NeuroDebian is anyway.
+ .
+ If you choose this option, those packages will be available
+ for upgrades and installation.
Minor tweaks:
.
If you choose this option, these packages will be available for
installation and upgrades.
- .
- Note: although NeuroDebian team aims to assure robust and correct
- operation of provided packages, enabling this additional archive
- might compromise the integrity of your base system.
+ .
+ Even though these packages are closely maintained
+ by the NeuroDebian team, enabling this additional archive
+ may compromise the integrity of the system.
OK.
Template: neurodebian/release
Type: select
-Choices: auto, ${releases}
+__Choices: automatic, ${releases}
+Choices-C: auto, ${releases}
Oh, one of these.
Default: auto
_Description: Release name of the base system:
- Specify for which Debian or Ubuntu release (e.g. wheezy or trusty).
+ Please specify the relevant Debian or Ubuntu release name
+ (for instance wheezy or trusty).
It's not immediately obvious what the name would be relevant
to; how about
Please specify the appropriate Debian or Ubuntu release codename
(for instance stretch or trusty).
(Updating the Debian codename just for futureproofing.)
.
- If 'auto', Debian or Ubuntu release name will be '${release}' as
- deduced from the output of apt-cache policy. If the release of your
- system is not '${release}' -- please choose specific one which
+ If this is set to automatic', the release name is chosen
+ after the output of apt-cache policy. If the release name
+ for this system is not ${release}, you should choose specific one which
matches best.
s/after/according to/
s/choose specific one/choose the specific one/
Template: neurodebian/mirror
Type: select
Choices: origin, best, custom, ${mirrors}
Default: best
_Description: NeuroDebian mirror to use:
- NeuroDebian project has a number of community-maintainer mirrors
+ NeuroDebian project has a number of community-maintained mirrors
around the globe.
^The^ NeuroDebian project.
.
If you do not know which mirror URL to choose, select among
s/select among/select one of:/
- origin: original NeuroDebian repository
* origin: the original NeuroDebian repository
(Does it mean the one that was set up first, or the primary
copy that the others are mirroring? Presumably those are both
the same server at present.)
- best: will try to use netselect to select closest mirror.
Depending on the configuration of the firewall, and actual mirror
-setup, might fail to select actually closest one. If netselect
-is not available, default mirror (possibly 'origin') will be used.
+setup, this might fail to select the really closest one. If netselect
+is not available, the default mirror will be used.
I suspect that's a false-friend actual(ly). There's still one
missing article, and reshuffling slightly lets me reduce the
repetition:
* best: will try to use netselect to select the closest mirror.
This may fail depending on the current mirror setup and the
configuration of
Bug#786448: [RFR] templates://neurodebian/{neurodebian.templates}
Please find, for review, the debconf templates and packages descriptions for
the neurodebian source package.
This review will last from Thursday, June 04, 2015 to Sunday, June 14, 2015.
Please send reviews as unified diffs (diff -u) against the original
files. Comments about your proposed changes will be appreciated.
Your review should be sent as an answer to this mail.
When appropriate, I will send intermediate requests for review, with
[RFRn] (n=2) as a subject tag.
When we will reach a consensus, I send a Last Chance For
Comments mail with [LCFC] as a subject tag.
Finally, a summary will be sent to the review bug report,
and a mail will be sent to this list with [BTS] as a subject tag.
It's indeed hard to detail each and every proposed changes : there are
many because the original files had to be both reviewed for English
usageand also using the standardized writing style we usually
recommend.
The same stands for debian/control.
Template: neurodebian/title
Type: title
_Description: NeuroDebian APT repository installer
Template: neurodebian/enable
Type: boolean
Default: false
_Description: Enable the NeuroDebian packages repository?
The NeuroDebian project provides a separate APT repository with
the most recent releases of maintained software and datasets as
well as software that is not yet provided in Debian.
.
If you choose this option, those packages will be available
for upgrades and installation.
.
Even though these packages are closely maintained
by the NeuroDebian team, enabling this additional archive
may compromise the integrity of the system.
Template: neurodebian/release
Type: select
__Choices: automatic, ${releases}
Choices-C: auto, ${releases}
Default: auto
_Description: Release name of the base system:
Please specify the relevant Debian or Ubuntu release name
(for instance wheezy or trusty).
.
If this is set to automatic', the release name is chosen
after the output of apt-cache policy. If the release name
for this system is not ${release}, you should choose specific one which
matches best.
Template: neurodebian/mirror
Type: select
Choices: origin, best, custom, ${mirrors}
Default: best
_Description: NeuroDebian mirror to use:
NeuroDebian project has a number of community-maintained mirrors
around the globe.
.
If you do not know which mirror URL to choose, select among
.
- origin: original NeuroDebian repository
- best: will try to use netselect to select closest mirror.
Depending on the configuration of the firewall, and actual mirror
setup, this might fail to select the really closest one. If netselect
is not available, the default mirror will be used.
Template: neurodebian/flavor
Type: select
Choices: auto, libre, full
Default: auto
_Description: NeuroDebian flavor to use:
The NeuroDebian project adheres to Debian Free Software Guidelines and
offers three packages areas, depending on software licenses, for all
suites/releases:
.
libre
DFSG-compliant material only
full
all three areas (main, contrib, non-free)
auto
picked from the output of apt-cache policy
(for this machine: ${flavor}).
Template: neurodebian/components
Type: multiselect
Choices: software, data, devel
Default: software, data
_Description: NeuroDebian repository components to enable:
NeuroDebian repository provides different sets of packages:
.
software
Packages containing software packages, often backports of stable
software releases for previous Debian/Ubuntu releases
devel
Additional bleeding edge software packages, more risky to be
enabled by default. It is similar to Debian experimental.
data
Packages containing data (e.g. atlases, sample datasets), often
required by software packages. It should most often be enabled.
Template: neurodebian/overwrite
Type: boolean
Default: true
_Description: Override the existing NeuroDebian APT file entries?
If an APT sources.list file already exists for NeuroDebian, choosing
this option will lead to a failure in the configuration of this package.
Template: neurodebian/suffix
Type: string
Default:
_Description: Additional suffix for the NeuroDebian APT file name:
For instance if you would like to enable additional repository
(e.g. NeuroDebian devel) or release, without interfering with the
main/default configuration file. Generally should be left empty.
Template: neurodebian/run-update-note
Type: note
_Description: Needed update for the packages list
The installion or removal of the NeuroDebian APT configuration file
requires running the apt-get update command. This needs to be
done manually after the installation of the neurodebian package.
Template: neurodebian/netselect-not-found
Type: error
_Description: Missing netselect tool
The netselect utility was not found. You probably need to
install the netselect package.
.
Alternatively, you can manually select the mirror to use.
Template: neurodebian/netselect-cannot-be-used
Type: error
_Description:
