Updated translation strings

This commit is contained in:
str4d
2014-11-27 12:14:02 +00:00
parent 85151e8b64
commit 3f0ac820c9
19 changed files with 3238 additions and 7255 deletions

View File

@@ -8,7 +8,7 @@ msgid ""
msgstr ""
"Project-Id-Version: I2P website\n"
"Report-Msgid-Bugs-To: http://trac.i2p2.de\n"
"POT-Creation-Date: 2014-10-22 20:13+0000\n"
"POT-Creation-Date: 2014-11-27 12:12+0000\n"
"PO-Revision-Date: 2014-02-09 19:53+0000\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: he <LL@li.org>\n"
@@ -397,317 +397,52 @@ msgid ""
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:15
#: i2p2www/pages/site/get-involved/todo.html:53
#: i2p2www/pages/site/get-involved/todo.html:38
msgid "Core functionality"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:15
#: i2p2www/pages/site/get-involved/todo.html:27
#: i2p2www/pages/site/get-involved/todo.html:51
#: i2p2www/pages/site/get-involved/todo.html:21
#: i2p2www/pages/site/get-involved/todo.html:36
msgid "link"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:17
#: i2p2www/pages/site/get-involved/todo.html:56
msgid "NAT/Firewall bridging via 1-hop restricted routes"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:20
#: i2p2www/pages/site/get-involved/todo.html:129
msgid "High degree transport layer with UDP, NBIO, or NIO"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:23
#: i2p2www/pages/site/get-involved/todo.html:217
#: i2p2www/pages/site/get-involved/todo.html:41
msgid "NetworkDB and profile tuning and ejection policy for large nets"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:27
#: i2p2www/pages/site/get-involved/todo.html:241
#: i2p2www/pages/site/get-involved/todo.html:21
#: i2p2www/pages/site/get-involved/todo.html:65
msgid "Security / anonymity"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:29
#: i2p2www/pages/site/get-involved/todo.html:244
msgid ""
"Per-hop tunnel id &amp; new permuted TunnelVerificationStructure "
"encryption"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:32
#: i2p2www/pages/site/get-involved/todo.html:294
msgid "Strict ordering of participants within tunnels"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:35
msgid "Randomly permuted tunnel lengths"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:38
#: i2p2www/pages/site/get-involved/todo.html:356
#: i2p2www/pages/site/get-involved/todo.html:23
#: i2p2www/pages/site/get-involved/todo.html:68
msgid "Full blown n-hop restricted routes with optional trusted links"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:41
#: i2p2www/pages/site/get-involved/todo.html:375
#: i2p2www/pages/site/get-involved/todo.html:26
#: i2p2www/pages/site/get-involved/todo.html:87
msgid "Hashcash for routerIdentity, destination, and tunnel request"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:44
#: i2p2www/pages/site/get-involved/todo.html:404
#: i2p2www/pages/site/get-involved/todo.html:29
#: i2p2www/pages/site/get-involved/todo.html:116
msgid "Advanced tunnel operation (batching/mixing/throttling/padding)"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:47
#: i2p2www/pages/site/get-involved/todo.html:441
#: i2p2www/pages/site/get-involved/todo.html:32
#: i2p2www/pages/site/get-involved/todo.html:153
msgid "Stop &amp; go mix w/ garlics &amp; tunnels"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:51
#: i2p2www/pages/site/get-involved/todo.html:455
#: i2p2www/pages/site/get-involved/todo.html:36
#: i2p2www/pages/site/get-involved/todo.html:167
msgid "Performance"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:61
msgid "Implemented in I2P 0.6.0.6"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:62
msgid ""
"The functionality of allowing routers to fully participate within the "
"network \n"
"while behind firewalls and NATs that they do not control requires some "
"basic \n"
"restricted route operation (since those peers will not be able to receive"
" \n"
"inbound connections). To do this successfully, you consider peers one of"
" \n"
"two ways:"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:72
msgid ""
"<b>Peers who have reachable interfaces</b> - these peers do not need to \n"
"do anything special"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:76
msgid ""
"<b>Peers who do not have reachable interfaces</b> - these peers must "
"build \n"
"a tunnel pointing at them where the gateway is one of the peers they have"
" \n"
"established a connection with who has both a publicly reachable interface"
" \n"
"and who has agreed to serve as their 'introducer'."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:84
msgid ""
"To do this, peers who have no IP address simply connect to a few peers, \n"
"build a tunnel through them, and publish a reference to those tunnels "
"within \n"
"their RouterInfo structure in the network database."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:89
msgid ""
"When someone wants to contact any particular router, they first must get"
" \n"
"its RouterInfo from the network database, which will tell them whether "
"they \n"
"can connect directly (e.g. the peer has a publicly reachable interface) \n"
"or whether they need to contact them indirectly. Direct connections occur"
" \n"
"as normal, while indirect connections are done through one of the "
"published \n"
"tunnels."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:97
msgid ""
"When a router just wants to get a message or two to a specific hidden "
"peer, \n"
"they can just use the indirect tunnel for sending the payload. However, \n"
"if the router wants to talk to the hidden peer often (for instance, as "
"part \n"
"of a tunnel), they will send a garlic routed message through the indirect"
" \n"
"tunnel to that hidden peer which unwraps to contain a message which "
"should \n"
"be sent to the originating router. That hidden peer then establishes an \n"
"outbound connection to the originating router and from then on, those two"
" \n"
"routers can talk to each other directly over that newly established "
"direct \n"
"connection."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:108
msgid ""
"Of course, that only works if the originating peer can receive "
"connections \n"
"(they aren't also hidden). However, if the originating peer is hidden, "
"they \n"
"can simply direct the garlic routed message to come back to the "
"originating \n"
"peer's inbound tunnel."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:114
msgid ""
"This is not meant to provide a way for a peer's IP address to be "
"concealed, \n"
"merely as a way to let people behind firewalls and NATs fully operate "
"within \n"
"the network. Concealing the peer's IP address adds a little more work, as"
" \n"
"described <a href=\"#fullRestrictedRoutes\">below.</a>"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:120
msgid ""
"With this technique, any router can participate as any part of a tunnel."
" \n"
"For efficiency purposes, a hidden peer would be a bad choice for an "
"inbound \n"
"gateway, and within any given tunnel, two neighboring peers wouldn't want"
" \n"
"to be hidden. But that is not technically necessary."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:132
msgid "Both UDP and NIO have been Implemented in I2P"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:133
msgid ""
"Standard TCP communication in Java generally requires blocking socket \n"
"calls, and to keep a blocked socket from hanging the entire system, those"
" \n"
"blocking calls are done on their own threads. Our current TCP transport \n"
"is implemented in a naive fashion - for each peer we are talking to, we \n"
"have one thread reading and one thread writing. The reader thread simply"
" \n"
"loops a bunch of read() calls, building I2NP messages and adding them \n"
"to our internal inbound message queue, and the writer thread pulls "
"messages \n"
"off a per-connection outbound message queue and shoves the data through \n"
"write() calls."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:144
msgid ""
"We do this fairly efficiently, from a CPU perspective - at any time, \n"
"almost all of these threads are sitting idle, blocked waiting for "
"something \n"
"to do. However, each thread consumes real resources (on older Linux "
"kernels, \n"
"for instance, each thread would often be implemented as a fork()'ed "
"process). \n"
"As the network grows, the number of peers each router will want to talk \n"
"with will increase (remember, I2P is fully connected, meaning that any \n"
"given peer should know how to get a message to any other peer, and "
"restricted \n"
"route support will probably not significantly reduce the number of "
"connections \n"
"necessary). This means that with a 100,000 router network, each router \n"
"will have up to 199,998 threads just to deal with the TCP connections!"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:156
msgid ""
"Obviously, that just won't work. We need to use a transport layer that \n"
"can scale. In Java, we have two main camps:"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:161
#, python-format
msgid ""
"Implemented in I2P 0.6 (\"SSU\") as documented <a "
"href=\"%(ssu)s\">elsewhere</a>"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:164
msgid ""
"Sending and receiving UDP datagrams is a connectionless operation - if \n"
"we are communicating with 100,000 peers, we simply stick the UDP packets"
" \n"
"in a queue and have a single thread pulling them off the queue and "
"shoving \n"
"them out the pipe (and to receive, have a single thread pulling in any \n"
"UDP packets received and adding them to an inbound queue)."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:171
msgid ""
"However, moving to UDP means losing the benefits of TCP's ordering, "
"congestion \n"
"control, MTU discovery, etc. Implementing that code will take significant"
" \n"
"work, however I2P doesn't need it to be as strong as TCP. Specifically, \n"
"a while ago I was taking some measurements in the simulator and on the \n"
"live net, and the vast majority of messages transferred would fit easily"
" \n"
"within a single unfragmented UDP packet, and the largest of the messages"
" \n"
"would fit within 20-30 packets. As mule pointed out, TCP adds a "
"significant \n"
"overhead when dealing with so many small packets, as the ACKs are within"
" \n"
"an order of magnitude in size. With UDP, we can optimize the transport \n"
"for both efficiency and resilience by taking into account I2P's "
"particular \n"
"needs."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:184
msgid "It will be a lot of work though."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:187
msgid "NIO or NBIO"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:188
msgid "NIO Implemented in I2P 0.6.1.22 (\"NTCP\")"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:191
msgid ""
"In Java 1.4, a set of \"New I/O\" packages was introduced, allowing Java"
" \n"
"developers to take advantage of the operating system's nonblocking IO \n"
"capabilities - allowing you to maintain a large number of concurrent IO \n"
"operations without requiring a separate thread for each. There is much \n"
"promise with this approach, as we can scalable handle a large number of \n"
"concurrent connections and we don't have to write a mini-TCP stack with \n"
"UDP. However, the NIO packages have not proven themselves to be battle-"
"ready, \n"
"as the Freenet developer's found. In addition, requiring NIO support "
"would \n"
"mean we can't run on any of the open source JVMs like <a "
"href=\"http://www.kaffe.org/\">Kaffe</a>, \n"
"as <a href=\"http://www.classpath.org/\">GNU/Classpath</a> has only "
"limited \n"
"support for NIO. <i>(note: this may not be the case anymore, as there \n"
"has been some progress on Classpath's NIO, but it is an unknown "
"quantity)</i>"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:205
#, python-format
msgid ""
"Another alternative along the same lines is the <a href=\"%(link)s\">Non"
" \n"
"Blocking I/O</a> package - essentially a cleanroom NIO implementation \n"
"(written before NIO was around). It works by using some native OS code \n"
"to do the nonblocking IO, passing off events through Java. It seems to \n"
"be working with Kaffe, though there doesn't seem to be much development \n"
"activity on it lately (likely due to 1.4's NIO deployment)."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:220
#: i2p2www/pages/site/get-involved/todo.html:44
msgid ""
"Within the current network database and profile management "
"implementation, \n"
@@ -730,152 +465,14 @@ msgid ""
"code yet, since we aren't going to need it for a while."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:235
#: i2p2www/pages/site/get-involved/todo.html:59
msgid ""
"That said, as the network grows we are going to want to keep these "
"considerations \n"
"in mind. We will have some work to do, but we can put it off for later."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:247
#: i2p2www/pages/site/get-involved/todo.html:331
#, python-format
msgid ""
"Addressed in I2P 0.5 as documented <a "
"href=\"%(tunnelimpl)s\">elsewhere</a>"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:250
msgid ""
"Right now, if Alice builds a four hop inbound tunnel starting at Elvis, \n"
"going to Dave, then to Charlie, then Bob, and finally Alice "
"(A&lt;--B&lt;--C&lt;--D&lt;--E), \n"
"all five of them will know they are participating in tunnel \"123\", as \n"
"the messages are tagged as such. What we want to do is give each hop "
"their \n"
"own unique tunnel hop ID - Charlie will receive messages on tunnel 234 \n"
"and forward them to tunnel 876 on Bob. The intent is to prevent Bob or \n"
"Charlie from knowing that they are in Alice's tunnel, as if each hop in \n"
"the tunnel had the same tunnel ID, collusion attacks aren't much work."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:260
msgid ""
"Adding a unique tunnel ID per hop isn't hard, but by itself, "
"insufficient. \n"
"If Dave and Bob are under the control of the same attacker, they wouldn't"
" \n"
"be able to tell they are in the same tunnel due to the tunnel ID, but \n"
"would be able to tell by the message bodies and verification structures \n"
"by simply comparing them. To prevent that, the tunnel must use layered \n"
"encryption along the path, both on the payload of the tunneled message \n"
"and on the verification structure (used to prevent simple tagging "
"attacks). \n"
"This requires some simple modifications to the TunnelMessage, as well \n"
"as the inclusion of per-hop secret keys delivered during tunnel creation"
" \n"
"and given to the tunnel's gateway. We must fix a maximum tunnel length \n"
"(e.g. 16 hops) and instruct the gateway to encrypt the message to each \n"
"of the 16 delivered secret keys, in reverse order, and to encrypt the \n"
"signature of the hash of the (encrypted) payload at each step. The "
"gateway \n"
"then sends that 16-step encrypted message, along with a 16-step and "
"16-wide \n"
"encrypted mapping to the first hop, which then decrypts the mapping and \n"
"the payload with their secret key, looking in the 16-wide mapping for \n"
"the entry associated with their own hop (keyed by the per-hop tunnel ID)"
" \n"
"and verifying the payload by checking it against the associated signed \n"
"hash."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:281
msgid ""
"The tunnel gateway does still have more information than the other peers"
" \n"
"in the tunnel, and compromising both the gateway and a tunnel participant"
" \n"
"would allow those peers to collude, exposing the fact that they are both"
" \n"
"in the same tunnel. In addition, neighboring peers know that they are \n"
"in the same tunnel anyway, as they know who they send the message to (and"
" \n"
"with IP-based transports without restricted routes, they know who they \n"
"got it from). However, the above two techniques significantly increase \n"
"the cost of gaining meaningful samples when dealing with longer tunnels."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:297
msgid "Implemented in release 0.6.2"
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:300
#, python-format
msgid ""
"As Connelly <a href=\"%(link)s\">proposed</a> to deal with the\n"
"<a href=\"%(pdf1)s\">predecessor attack</a> <a href=\"%(pdf2)s\">(2008\n"
"update)</a>, keeping the order of peers within our tunnels consistent \n"
"(aka whenever Alice creates a tunnel with both Bob and Charlie in it, \n"
"Bob's next hop is always Charlie), we address the issue as Bob doesn't \n"
"get to substantially sample Alice's peer selection group. We may even \n"
"want to explicitly allow Bob to participate in Alice's tunnels in only \n"
"one way - receiving a message from Dave and sending it to Charlie - and \n"
"if any of those peers are not available to participate in the tunnel (due"
" \n"
"to overload, network disconnection, etc), avoid asking Bob to participate"
" \n"
"in any tunnels until they are back online."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:315
msgid ""
"More analysis is necessary for revising the tunnel creation - at the \n"
"moment, we simply select and order randomly within the peer's top tier \n"
"of peers (ones with fast + high capacity)."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:320
msgid ""
"Adding a strict ordering to peers in a tunnel also improves the anonymity"
" \n"
"of peers with 0-hop tunnels, as otherwise the fact that a peer's gateway"
" \n"
"is always the same would be particularly damning. However, peers with \n"
"0-hop tunnels may want to periodically use a 1-hop tunnel to simulate \n"
"the failure of a normally reliable gateway peer (so every MTBF*(tunnel \n"
"duration) minutes, use a 1-hop tunnel)."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:337
msgid ""
"Without tunnel length permutation, if someone were to somehow detect that"
" \n"
"a destination had a particular number of hops, it might be able to use "
"that \n"
"information to identify the router the destination is located on, per the"
" \n"
"predecessor attack. For instance, if everyone has 2-hop tunnels, if Bob \n"
"receives a tunnel message from Charlie and forwards it to Alice, Bob "
"knows \n"
"Alice is the final router in the tunnel. If Bob were to identify what "
"destination \n"
"that tunnel served (by means of colluding with the gateway and harvesting"
" \n"
"the network database for all of the LeaseSets), he would know the router"
" \n"
"on which that destination is located (and without restricted routes, that"
" \n"
"would mean what IP address the destination is on)."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:349
msgid ""
"It is to counter user behavior that tunnel lengths should be permuted, \n"
"using algorithms based on the length requested (for example, the 1/MTBF \n"
"length change for 0-hop tunnels outlined above)."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:359
#: i2p2www/pages/site/get-involved/todo.html:71
msgid ""
"The restricted route functionality described before was simply a "
"functional \n"
@@ -897,7 +494,7 @@ msgid ""
"to forward it as requested."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:378
#: i2p2www/pages/site/get-involved/todo.html:90
#, python-format
msgid ""
"Within the network, we will want some way to deter people from consuming"
@@ -911,7 +508,7 @@ msgid ""
"to make certain requests \"expensive\"."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:386
#: i2p2www/pages/site/get-involved/todo.html:98
msgid ""
"<a href=\"http://www.hashcash.org/\">Hashcash</a> is one technique that \n"
"we can use to anonymously increase the \"cost\" of doing certain "
@@ -929,7 +526,7 @@ msgid ""
"with few resources."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:397
#: i2p2www/pages/site/get-involved/todo.html:109
msgid ""
"There are a few other algorithms that we can explore for making those \n"
"requests for resources \"nonfree\", and further research on that front is"
@@ -937,7 +534,7 @@ msgid ""
"appropriate."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:407
#: i2p2www/pages/site/get-involved/todo.html:119
#, python-format
msgid ""
"To powerful passive external observers as well as large colluding "
@@ -958,7 +555,7 @@ msgid ""
"tunnel mixing strategies."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:420
#: i2p2www/pages/site/get-involved/todo.html:132
msgid ""
"In addition to the anonymity aspects of more varied tunnel operation, \n"
"there is a functional dimension as well. Each peer only has a certain \n"
@@ -976,7 +573,7 @@ msgid ""
"available."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:433
#: i2p2www/pages/site/get-involved/todo.html:145
msgid ""
"In addition, we may want to implement code to dynamically reroute tunnels"
" \n"
@@ -986,7 +583,7 @@ msgid ""
"with instructions to redefine the next-hop in the tunnel."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:444
#: i2p2www/pages/site/get-involved/todo.html:156
msgid ""
"Beyond the per-tunnel batching and mixing strategy, there are further \n"
"capabilities for protecting against powerful attackers, such as allowing"
@@ -1001,7 +598,7 @@ msgid ""
"clove exposed includes delay instructions."
msgstr ""
#: i2p2www/pages/site/get-involved/todo.html:456
#: i2p2www/pages/site/get-involved/todo.html:168
#, python-format
msgid ""
"Performance related improvements are listed on the\n"
@@ -4134,3 +3731,15 @@ msgid ""
"href=\"http://%(zzz)s/forums/14\">translation forum on %(zzz)s</a>."
msgstr ""