- Updated translations.

- Import NMU patches.

1 files changed, 82 insertions, 108 deletions

diff --git a/debian/strongswan-starter.templates b/debian/strongswan-starter.templates
index 781773ac5..8d239c271 100644
--- a/debian/strongswan-starter.templates
+++ b/debian/strongswan-starter.templates
@@ -1,68 +1,62 @@
+# These templates have been reviewed by the debian-l10n-english
+# team
+#
+# If modifications/additions/rewording are needed, please ask
+# debian-l10n-english@lists.debian.org for advice.
+#
+# Even minor modifications require translation updates and such
+# changes should be coordinated with translators and reviewers.
+
 Template: strongswan/start_level
 Type: select
-_Choices: earliest, "after NFS", "after PCMCIA"
+__Choices: earliest, after NFS, after PCMCIA
 Default: earliest
 _Description: When to start strongSwan:
- There are three possibilities when strongSwan can start: before or
- after the NFS services and after the PCMCIA services. The correct answer
- depends on your specific setup.
- .
- If you do not have your /usr tree mounted via NFS (either you only mount
- other, less vital trees via NFS or don't use NFS mounted trees at all) and
- don't use a PCMCIA network card, then it's best to start strongSwan at
- the earliest possible time, thus allowing the NFS mounts to be secured by
- IPSec. In this case (or if you don't understand or care about this
- issue), answer "earliest" to this question (the default).
- .
- If you have your /usr tree mounted via NFS and don't use a PCMCIA network
- card, then you will need to start strongSwan after NFS so that all
- necessary files are available. In this case, answer "after NFS" to this
- question. Please note that the NFS mount of /usr can not be secured by
- IPSec in this case.
+ StrongSwan starts during system startup so that it can protect filesystems
+ that are automatically mounted.
  .
- If you use a PCMCIA network card for your IPSec connections, then you only
- have to choose to start it after the PCMCIA services. Answer "after
- PCMCIA" in this case. This is also the correct answer if you want to fetch
- keys from a locally running DNS server with DNSSec support.
+  * earliest: if /usr is not mounted through NFS and you don't use a
+    PCMCIA network card, it is best to start strongSwan as soon as
+    possible, so that NFS mounts can be secured by IPSec;
+  * after NFS: recommended when /usr is mounted through NFS and no
+    PCMCIA network card is used;
+  * after PCMCIA: recommended if the IPSec connection uses a PCMCIA
+    network card or if it needs keys to be fetched from a locally running DNS
+    server with DNSSec support.
 
 Template: strongswan/restart
 Type: boolean
 Default: true
-_Description: Do you wish to restart strongSwan?
- Restarting strongSwan is a good idea, since if there is a security fix, it
- will not be fixed until the daemon restarts. Most people expect the daemon
- to restart, so this is generally a good idea. However this might take down
+_Description: Restart strongSwan now?
+ Restarting strongSwan is recommended, because if there is a security fix, it
+ will not be applied until the daemon restarts. However, this might close
  existing connections and then bring them back up.
+ .
+ If you don't restart strongSwan now, you should do so manually at the first
+ opportunity.
 
 Template: strongswan/ikev1
 Type: boolean
 Default: true
-_Description: Do you wish to support IKEv1?
- strongSwan supports both versions of the Internet Key Exchange protocol,
- IKEv1 and IKEv2. Do you want to start the "pluto" daemon for IKEv1 support
- when strongSwan is started?
+_Description: Start strongSwan's IKEv1 daemon?
+ The pluto daemon must be running to support version 1 of the Internet Key
+ Exchange protocol.
 
 Template: strongswan/ikev2
 Type: boolean
 Default: true
-_Description: Do you wish to support IKEv2?
- strongSwan supports both versions of the Internet Key Exchange protocol,
- IKEv1 and IKEv2. Do you want to start the "charon" daemon for IKEv2 support
- when strongSwan is started?
+_Description: Start strongSwan's IKEv2 daemon?
+ The charon daemon must be running to support version 2 of the Internet Key
+ Exchange protocol.
 
 Template: strongswan/create_rsa_key
 Type: boolean
 Default: true
-_Description: Do you want to create a RSA public/private keypair for this host?
- This installer can automatically create a RSA public/private keypair
- with an X.509 certificate for this host. This can be used to authenticate 
- IPSec connections to other hosts and is the preferred way for building up 
- secure IPSec connections. The other possibility would be to use pre-shared 
- secrets (PSKs, passwords that are the same on both sides of the tunnel) for
- authenticating an connection, but for a larger number of connections RSA
- authentication is easier to administer and more secure. Note that
- having a keypair allows to use both X.509 and PSK authentication for IPsec 
- tunnels.
+_Description: Create an RSA public/private keypair for this host?
+ StrongSwan can use a Pre-Shared Key (PSK) or an RSA keypair to authenticate
+ IPSec connections to other hosts. RSA authentication is generally considered
+ more secure and is easier to administer. You can use PSK and RSA authentication
+ simultaneously.
  .
  If you do not want to create a new public/private keypair, you can choose to
  use an existing one in the next step.
@@ -70,12 +64,13 @@ _Description: Do you want to create a RSA public/private keypair for this host?
 Template: strongswan/existing_x509_certificate
 Type: boolean
 Default: false
-_Description: Do you have an existing X.509 certificate file for strongSwan?
- This installer can automatically extract the needed information from an
+_Description: Use an existing X.509 certificate for strongSwan?
+ The required information can automatically be extracted from an
  existing X.509 certificate with a matching RSA private key. Both parts can
- be in one file, if it is in PEM format. If you have such an existing
+ be in one file, if it is in PEM format.
+ You should choose this option if you have such an existing
  certificate and key file and want to use it for authenticating IPSec
- connections, then please answer yes.
+ connections.
 
 Template: strongswan/existing_x509_certificate_filename
 Type: string
@@ -85,118 +80,97 @@ _Description: File name of your X.509 certificate in PEM format:
 
 Template: strongswan/existing_x509_key_filename
 Type: string
-_Description: File name of your X.509 private key in PEM format:
+_Description: File name of your existing X.509 private key in PEM format:
  Please enter the full location of the file containing the private RSA key
  matching your X.509 certificate in PEM format. This can be the same file
- that contains the X.509 certificate.
+ as the X.509 certificate.
 
 Template: strongswan/rsa_key_length
 Type: string
 Default: 2048
-_Description: The length of the created RSA key (in bits):
- Please enter the length of the created RSA key. It should not be less than
- 1024 bits because this should be considered unsecure and you will probably
- not need anything more than 2048 bits because it only slows the
- authentication process down and is not needed at the moment.
+_Description: RSA key length:
+ Please enter the length of RSA key you wish to generate. A value of less than
+ 1024 bits is not considered secure. A value of more than 2048 bits will
+ probably affect performance.
 
 Template: strongswan/x509_self_signed
 Type: boolean
 Default: true
-_Description: Do you want to create a self-signed X.509 certificate?
- This installer can only create self-signed X.509 certificates
+_Description: Create a self-signed X.509 certificate?
+ Only self-signed X.509 certificates can be created
  automatically, because otherwise a certificate authority is needed to sign
- the certificate request. If you want to create a self-signed certificate,
- you can use it immediately to connect to other IPSec hosts that support
- X.509 certificate for authentication of IPSec connections. However, if you
- want to use the new PKI features of strongSwan >= 1.91, you will need to
- have all X.509 certificates signed by a single certificate authority to
- create a trust path.
+ the certificate request.
  .
- If you do not want to create a self-signed certificate, then this
- installer will only create the RSA private key and the certificate request
- and you will have to get the certificate request signed by your certificate
+ If you accept this option, the certificate created can be used
+ immediately to connect to other IPSec hosts that support authentication via
+ an X.509 certificate. However, using strongSwan's PKI features requires a
+ trust path to be created by having all X.509 certificates signed by a single
  authority.
+ .
+ If you do not accept this option, only the RSA private key will be created,
+ along with a certificate request which you will need to have signed by a
+ certificate authority.
 
 Template: strongswan/x509_country_code
 Type: string
 Default: AT
 _Description: Country code for the X.509 certificate request:
- Please enter the 2 letter country code for your country. This code will be
- placed in the certificate request. 
- .
- You really need to enter a valid country code here, because openssl will
- refuse to generate certificates without one. An empty field is allowed for
- any other field of the X.509 certificate, but not for this one.
+ Please enter the two-letter ISO3166 country code that should be
+ used in the certificate request.
  .
- Example: AT
+ This field is mandatory; otherwise a certificate cannot be generated.
 
 Template: strongswan/x509_state_name
 Type: string
 Default:
 _Description: State or province name for the X.509 certificate request:
- Please enter the full name of the state or province you live in. This name
- will be placed in the certificate request.
- .
- Example: Upper Austria
+ Please enter the full name of the state or province to include in
+ the certificate request.
 
 Template: strongswan/x509_locality_name
 Type: string
 Default: 
 _Description: Locality name for the X.509 certificate request:
- Please enter the locality (e.g. city) where you live. This name will be
- placed in the certificate request.
- .
- Example: Vienna
+ Please enter the locality name (often a city)
+ that should be used in the certificate request.
 
 Template: strongswan/x509_organization_name
 Type: string
 Default: 
 _Description: Organization name for the X.509 certificate request:
- Please enter the organization (e.g. company) that the X.509 certificate
- should be created for. This name will be placed in the certificate
- request.
- .
- Example: Debian
+ Please enter the organization name (often a company)
+ that should be used in the certificate request.
 
 Template: strongswan/x509_organizational_unit
 Type: string
 Default: 
 _Description: Organizational unit for the X.509 certificate request:
- Please enter the organizational unit (e.g. section) that the X.509
- certificate should be created for. This name will be placed in the
- certificate request.
- .
- Example: security group
+ Please enter the organizational unit name (often a department)
+ that should be used in the certificate request.
 
 Template: strongswan/x509_common_name
 Type: string
 Default: 
 _Description: Common name for the X.509 certificate request:
- Please enter the common name (e.g. the host name of this machine) for
- which the X.509 certificate should be created for. This name will be placed
- in the certificate request.
- .
- Example: gateway.debian.org
+ Please enter the common name (such as the host name of this machine)
+ that should be used in the certificate request.
 
 Template: strongswan/x509_email_address
 Type: string
 Default: 
 _Description: Email address for the X.509 certificate request:
- Please enter the email address of the person or organization who is
- responsible for the X.509 certificate. This address will be placed in the
- certificate request.
+ Please enter the email address (for the individual or organization responsible)
+ that should be used in the certificate request.
 
 Template: strongswan/enable-oe
 Type: boolean
 Default: false
-_Description: Do you wish to enable opportunistic encryption in strongSwan?
- strongSwan comes with support for opportunistic encryption (OE), which stores
- IPSec authentication information (i.e. RSA public keys) in (preferably
- secure) DNS records. Until this is widely deployed, activating it will
- cause a significant slow-down for every new, outgoing connection. Since
- version 2.0, strongSwan upstream comes with OE enabled by default and is thus
- likely to break your existing connection to the Internet (i.e. your default
- route) as soon as pluto (the strongSwan keying daemon) is started.
+_Description: Enable opportunistic encryption?
+ This version of strongSwan supports opportunistic encryption (OE), which stores
+ IPSec authentication information in
+ DNS records. Until this is widely deployed, activating it will
+ cause a significant delay for every new outgoing connection.
  .
- Please choose whether you want to enable support for OE. If unsure, do not
- enable it.
+ You should only enable opportunistic encryption if you are sure you want it.
+ It may break the Internet connection (default route) as the pluto daemon
+ starts.