% -> % to fix translations problems

i2p2www/pages/site/about/performance/history.html

@@ -24,7 +24,7 @@ Rather than try to tune this method, we'll call out to
 ugha and duck are working on the C/JNI glue code, and the existing java code
 is already deployed with hooks for that whenever its ready.  Preliminary results
 look fantastic - running the router with the native GMP modPow is providing over
-a 800% speedup in encryption performance, and the load was cut in half.  This
+a 800% speedup in encryption performance, and the load was cut in half.  This
 was just on one user's machine, and things are nowhere near ready for packaging
 and deployment, yet.
 {%- endtrans %}</p>
@@ -54,7 +54,7 @@ have to do the network database lookup.
 <p>{% trans -%}
 For unpublished LeaseSets such as "shared clients", this is the only way to
 get the LeaseSet to Bob. Unfortunately this bundling every time adds
-almost 100% overhead to a high-bandwidth connection, and much more to
+almost 100&#37; overhead to a high-bandwidth connection, and much more to
 a connection with smaller messages.
 {%- endtrans %}</p>
 <p>{% trans -%}

i2p2www/pages/site/docs/api/i2ptunnel.html

@@ -40,8 +40,8 @@ A HTTP proxy used for browsing I2P and the regular internet anonymously through
 Browsing internet through I2P uses a random proxy specified by the "Outproxies:" option.
 {%- endtrans %}</li>
 <li><b>Irc2P</b> - <i>localhost:6668</i> - {% trans %}An IRC tunnel to the default anonymous IRC network, Irc2P.{% endtrans %}</li>
-<li><b>mtn.i2p2.i2p</b> - <i>localhost:8998</i> - {% trans -%}
-The anonymous <a href="http://en.wikipedia.org/wiki/Monotone_%28software%29">monotone</a>
+<li><b>mtn.i2p2.i2p</b> - <i>localhost:8998</i> - {% trans monotone='http://en.wikipedia.org/wiki/Monotone_%28software%29' -%}
+The anonymous <a href="{{ monotone }}">monotone</a>
 sourcecode repository for I2P
 {%- endtrans %}</li>
 <li><b>smtp.postman.i2p</b> - <i>localhost:7659</i> - {% trans postman=i2pconv('hq.postman.i2p') -%}

i2p2www/pages/site/docs/applications/bittorrent.html

@@ -108,7 +108,7 @@ The peers key may be absent, or the peers value may be zero-length.
 
 <p>{% trans -%}
 While compact response support is optional for both clients and trackers, it is highly
-recommended as it reduces the nominal response size by over 90%.
+recommended as it reduces the nominal response size by over 90&#37;.
 {%- endtrans %}</p>
 
 

i2p2www/pages/site/docs/discussions/ntcp.html

@@ -144,10 +144,10 @@ Posted to new Syndie, 2007-03-27
 <p>
 On the whole, I'm open to experimenting with this, though remember why NTCP is 
 there in the first place - SSU failed in a congestion collapse. NTCP "just 
-works", and while 2-10% retransmission rates can be handled in normal 
-single-hop networks, that gives us a 40% retransmission rate with 2 hop 
+works", and while 2-10&#37; retransmission rates can be handled in normal 
+single-hop networks, that gives us a 40&#37; retransmission rate with 2 hop 
 tunnels. If you loop in some of the measured SSU retransmission rates we saw 
-back before NTCP was implemented (10-30+%), that gives us an 83% retransmission 
+back before NTCP was implemented (10-30+&#37;), that gives us an 83&#37; retransmission 
 rate. Perhaps those rates were caused by the low 10 second timeout, but 
 increasing that much would bite us (remember, multiply by 5 and you've got half 
 the journey).
@@ -333,7 +333,7 @@ stream timeout. TCP in practice has retransmission timeouts orders of magnitude
 less, though yes, can get to 60s on links running through exposed wires or 
 satellite transmissions ;) If we increase the streaming lib retransmission 
 timeout to e.g. 75 seconds, we could go get a beer before a web page loads 
-(especially assuming less than a 98% reliable transport). That's one reason we 
+(especially assuming less than a 98&#37; reliable transport). That's one reason we 
 prefer NTCP.
 </p>
 
@@ -399,7 +399,7 @@ more often on NTCP, but maybe that's a hint on why NTCP performs worse.
 Posted to new Syndie, 2007-03-31
 <p>
 measured SSU retransmission rates we saw back before NTCP was implemented 
-(10-30+%)
+(10-30+&#37;)
 </p><p>
 
 Can the router itself measure this? If so, could a transport be selected based 
@@ -463,7 +463,7 @@ while still somewhat bothering to carry TCP streams.
 On that background, a small diversity of transports (as many as needed, but not 
 more) appears sensible in either case. Which should be the main transport, 
 depends on their performance-wise. I've seen nasty stuff on my line when I 
-tried to use its full capacity with UDP. Packet losses on the level of 35%.
+tried to use its full capacity with UDP. Packet losses on the level of 35&#37;.
 </p><p>
 
 We could definitely try playing with UDP versus TCP priorities, but I'd urge 
@@ -502,7 +502,7 @@ build messages).
 On that background, a small diversity of transports (as many as needed, but 
 not more) appears sensible in either case. Which should be the main transport, 
 depends on their performance-wise. I've seen nasty stuff on my line when I 
-tried to use its full capacity with UDP. Packet losses on the level of 35%.
+tried to use its full capacity with UDP. Packet losses on the level of 35&#37;.
 
 </i>
 </p><p>

i2p2www/pages/site/docs/how/network-database.html

@@ -279,7 +279,7 @@ automatically enabled.
 {%- endtrans %}</p>
 
 <p>{% trans -%}
-With the current rules for automatic opt-in, approximately 6% of
+With the current rules for automatic opt-in, approximately 6&#37; of
 the routers in the network are floodfill routers.
 {%- endtrans %}</p>
 
@@ -810,7 +810,7 @@ more correlative. Of course, a larger network makes a Sybil attack that much har
 <p>{% trans threatmodel=site_url('docs/how/threat-model') -%}
 However, the general issue of DHT information leakage in I2P needs further investigation.
 The floodfill routers are in a position to observe queries and gather information.
-Certainly, at a level of <i>f</i> = 0.2 (20% malicious nodes, as specifed in the paper)
+Certainly, at a level of <i>f</i> = 0.2 (20&#37; malicious nodes, as specifed in the paper)
 we expect that many of the Sybil threats we describe
 (<a href="{{ threatmodel }}#sybil">here</a>,
 <a href="#sybil">here</a> and

i2p2www/pages/site/docs/how/peer-selection.html

@@ -237,7 +237,7 @@ To prevent some simple attacks, and for performance, there are the following res
 Two peers from the same /16 IP space may not be in the same tunnel.
 {%- endtrans %}</li>
 <li>{% trans -%}
-A peer may participate in a maximum of 33% of all tunnels created by the router.
+A peer may participate in a maximum of 33&#37; of all tunnels created by the router.
 {%- endtrans %}</li>
 <li>{% trans -%}
 Peers with extremely low bandwidth are not used.

i2p2www/pages/site/docs/how/threat-model.html

@@ -312,7 +312,7 @@ willing to contribute. The defense against this is:
 Set defaults so that most users provide resources to the network.
 In I2P, users route traffic by default. In sharp distinction to
 <a href="{{ comparisons }}">other networks</a>,
-over 95% of I2P users relay traffic for others.
+over 95&#37; of I2P users relay traffic for others.
 {%- endtrans %}</li>
   <li>{% trans -%}
 Provide easy configuration options so that users may increase their
@@ -585,7 +585,7 @@ Reference: <a href="{{ pdf }}">Breaking and Improving Protocol Obfuscation</a>
 Sybil describes a category of attacks where the adversary creates arbitrarily
 large numbers of colluding nodes and uses the increased numbers to help 
 mounting other attacks.  For instance, if an attacker is in a network where peers
-are selected randomly and they want an 80% chance to be one of those peers, they
+are selected randomly and they want an 80&#37; chance to be one of those peers, they
 simply create five times the number of nodes that are in the network and roll 
 the dice.  When identity is free, Sybil can be a very potent technique for a 
 powerful adversary.  The primary technique to address this is simply to make 
@@ -640,7 +640,7 @@ This is somewhat mitigated by our
 <a href="{{ peerselection }}">peer profiling</a> methods used to monitor the performance
 of peers.
 However, this is a powerful attack as the number of routers approaches
-<i>f</i> = 0.2, or 20% malicious nodes, as specifed in the paper.
+<i>f</i> = 0.2, or 20&#37; malicious nodes, as specifed in the paper.
 The malicous routers could also maintain connections to the target router and provide
 excellent forwarding bandwidth for traffic over those connections, in an attempt
 to manipulate the profiles managed by the target and appear attractive.

i2p2www/pages/site/docs/spec/blockfile.html

@@ -169,8 +169,8 @@ The maximum number of entries per span is 16.
 {%- endtrans %}</p>
 
 <h4>{% trans %}Properties Skiplist{% endtrans %}</h4>
-<p>{% trans -%}
-"%%__INFO__%%" is the master database skiplist with String/Properties key/value entries containing only one entry:
+<p>{% trans INFO='"%%__INFO__%%"' -%}
+{{ INFO }} is the master database skiplist with String/Properties key/value entries containing only one entry:
 {%- endtrans %}</p>
 <pre>
     "info": a Properties (UTF-8 String/String Map), serialized as a <a href="{{ site_url('docs/spec/common-structures') }}#type_Mapping">Mapping</a>:
@@ -182,8 +182,8 @@ The maximum number of entries per span is 16.
 </pre>
 
 <h4>{% trans %}Reverse Lookup Skiplist{% endtrans %}</h4>
-<p>{% trans -%}
-"%%__REVERSE__%%" is the reverse lookup skiplist with Integer/Properties key/value entries
+<p>{% trans REVERSE='"%%__REVERSE__%%"' -%}
+{{ REVERSE }} is the reverse lookup skiplist with Integer/Properties key/value entries
     (as of database version 2):
 {%- endtrans %}</p>
 <pre>

i2p2www/pages/site/docs/spec/plugin.html

@@ -321,7 +321,7 @@ Other plugin guidelines
 <li>
 See i2p.scripts branch or any of the sample plugins on zzz's page for a xpi2p file generator to make it easy.
 <li>
-Pack200 of jars and wars is strongly recommended for plugins, it generally shrinks plugins by 60-65%.
+Pack200 of jars and wars is strongly recommended for plugins, it generally shrinks plugins by 60-65&#37;.
 See any of the sample plugins on zzz's page for an example.
 Pack200 unpacking is supported on routers 0.7.11-5 or higher, which is essentially all routers that
 support plugins at all.

i2p2www/pages/site/docs/spec/updates.html

@@ -99,7 +99,7 @@ As of release 0.7.12, the router supports Pack200 decompression.
 Files inside the zip archive with a .jar.pack or .war.pack suffix
 are transparently decompressed to a .jar or .war file.
 Update files containing .pack files are traditionally named with a '.su2' suffix.
-Pack200 shrinks the update files by about 60%.
+Pack200 shrinks the update files by about 60%.
 {%- endtrans %}</p>
 
 <p>{% trans -%}

i2p2www/pages/site/docs/transport/ssu.html

@@ -81,7 +81,7 @@ The MTU value is adjusted based on the percentage of packets that are retransmit
 {%- endtrans %}</p>
 
 <p>{% trans -%}
-For both MTU values, it is desirable that (MTU % 16) == 12, so that
+For both MTU values, it is desirable that (MTU &#37; 16) == 12, so that
 the payload portion after the 28-byte IP/UDP header is a multiple of
 16 bytes, for encryption purposes.
 {%- endtrans %}</p>
@@ -118,7 +118,7 @@ honor that when a connection is established.
 
 <p>{% trans -%}
 For IPv6, the minimum MTU is 1280. The IPv6 IP/UDP header is 48 bytes,
-so we use an MTU where (MTN % 16 == 0), which is true for 1280.
+so we use an MTU where (MTN &#37; 16 == 0), which is true for 1280.
 {%- endtrans %}</p>
 
 <h3><a name="max">{% trans %}Message Size Limits{% endtrans %}</a></h3>

i2p2www/pages/site/faq.html

@@ -159,7 +159,7 @@ garbage collection. Increase the setting <code>wrapper.java.maxmemory</code> in
 </li>
 <li>
 {% trans -%}
-Is the CPU usage simply higher than you would like, or is it pegged at 100% for a long time?
+Is the CPU usage simply higher than you would like, or is it pegged at 100&#37; for a long time?
 If it's pegged, this could be a bug. Look in the logs for clues.
 {%- endtrans %}
 </li>
@@ -203,7 +203,7 @@ All traffic you route is internal to the I2P network, you are not an <a href="#e
 Your only alternative is to refuse to route
 <i>any</i> traffic, by setting your share bandwidth or maximum participating tunnels to 0 (see above).
 It would be nice if you didn't do this, you should help the network by routing traffic for others.
-Over 95% of users route traffic for others.
+Over 95&#37; of users route traffic for others.
 {%- endtrans %}
 </li>
 <li>

i2p2www/pages/site/get-involved/bounties/unit-tests.html

@@ -93,7 +93,7 @@ To collect this bounty, the automated unit tests of the router
 
 <p>{% trans -%}
 To collect this bounty, a new set of unit tests must meet a 
-measured code coverage of 90% of the streaming lib 
+measured code coverage of 90&#37; of the streaming lib 
 (i2p/apps/ministreaming/ and i2p/apps/streaming/).
 {%- endtrans %}</p>
 <br />
@@ -104,7 +104,7 @@ measured code coverage of 90% of the streaming lib
 {%- endtrans %}</b><br />
 
 <p>{% trans -%}
-To collect this bounty, all above unit tests must meet the 100%
+To collect this bounty, all above unit tests must meet the 100&#37;
 coverage marker (except for log statements).
 {%- endtrans %}</p>
 <br />

i2p2www/pages/site/misc/benchmarks.html

@@ -248,7 +248,7 @@ speeds because time is needed to transfer data to and from memory.
 For the ciphers that specify big endian byte order, the timing data 
 listed include time needed to convert to and from little endian
 order.  For some ciphers (WAKE and SHA) this is a large fraction (up
-to 25%) of the total time.
+to 25%) of the total time.
 <LI>
 The RSA, RW, DH, MQV, and elliptic curve schemes come from the IEEE P1363
 standard. For more info see <A HREF="http://grouper.ieee.org/groups/1363/index.html">

i2p2www/pages/site/misc/jbigi.html

@@ -123,7 +123,7 @@ info, it will be something like this:
 {%- endtrans %}<pre>
 native run time:  5842ms ( 57ms each)
 java run time:   41072ms (406ms each)
-native = 14.223802103622907% of pure java time
+native = 14.223802103622907&#37; of pure java time
 </pre>
 {% trans %}If the native is indeed 5-7x faster (or more) then it looks all good. If not, please report.{% endtrans %}</li>
 <li>{% trans %}Copy <code>libjbigi.so</code> to your i2p directory{% endtrans %}</li>