Package: openswan
Version: 1/2.2.0-10
Severity: wishlist
Tags: l10n, patch
While translating the file openswan, I encountered the following
typos, which I thought you might like to eliminate in a future release.
_________________
1.
.po:5
auto: ⑤ Type: select
auto: ⑤ Description
reference: ⑤ ../openswan.templates.master:5
Original: ⌘0
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 is the best to start
Openswan 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).
"then it's best to start Openswan"
double space between "care" and "about"
2.
.po:6
auto: ⑤ Type: select
auto: ⑤ Description
reference: ⑤ ../openswan.templates.master:5
Original: ⌘0
If you have your /usr tree mounted via NFS and don't use a PCMCIA
network
card, then you will need to start Openswan 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.
double space between "can" and "not"
3.
po:7
auto: ⑤ Type: select
auto: ⑤ Description
reference: ⑤ ../openswan.templates.master:5
Original: ⌘0
If you use a PCMCIA network card for your IPSec connections, then you
only
have to choice 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.
"to choose to start it"
4.
po:11
auto: ⑤ Type: boolean
auto: ⑤ Description
reference: ⑤ ../openswan.templates.master:42
Original: ⌘0
This installer can automatically create a RSA public/private keypair for
this host. This keypair 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 shared secrets
(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 administrate and more secure.
"easier to administer"
5.
po:14
auto: ⑤ Type: select
auto: ⑤ Description
reference: ⑤ ../openswan.templates.master:55
Original: ⌘0
It is possible to create a plain RSA public/private keypair for the
use with
Openswan or to create a X509 certificate file which contains the RSA
public
key and additionally store the corresponding private key.
"for use with openswan"
"and additionally stores the corresponding private key"
6.
po:50
auto: ⑤ Type: boolean
auto: ⑤ Description
reference: ⑤ ../openswan.templates.master:193
Original: ⌘0
Openswan comes with support for opportunistic encryption (OE), which
stores
IPSec authentication information (i.e. RSA public keys) in (preferrably
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, Openswan upstream comes with OE enabled by default and is thus
likely
to break you existing connection to the Internet (i.e. your default
route)
as soon as pluto (the Openswan keying daemon) is started.
"preferably" (because the stress is on the first syllable)
"your existing connection"
_________________
I hope this is useful. :)
submitted by:
Clytie Siddall (vi-VN, Vietnamese free-software translation team /
nhóm Việt hóa phần mềm tự do)
