Depends on #1422
Decide between "app" and "program"?
Possibly tackle these two strings:
Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed this number of bytes. (The default is 1450)
There are some variation of this message depending on the exact situation. They all have in common that server and client could not agree on a common cipher. The main reasons are: <ul><li> You are still relying on the fact that OpenVPN 2.4 and older allowed BF-CBC in the default configuration (if no --cipher was set). OpenVPN 2.5 does not allow it per default anymore since it is a <a href="https://community.openvpn.net/openvpn/wiki/SWEET32">broken/outdated cipher</a>.</li><li>The server runs OpenVPN 2.3 (or even older) with --enable-small (at least 4-5 year old OpenVPN)</li><li></ul>Broken configuration (e.g., mismatching data-ciphers on client and server)</li> <p> The <a href="https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/cipher-negotiation.rst">OpenVPN manual section on cipher negotiation</a> explains the different scenarios of cipher negotiation very well and what to do in these situation.<p>TP-Link devices use a at least 5 year old OpenVPN 2.3.x version (possibly older) on their devices, even in the 2019/2020 models.<p>Last but not least, there is a popular VPN provider that has a broken server that always says it is using 'BF-CBC' because its developer thought it would be a good idea to create a proprietary cipher negotiation patch that is incompatible with standard OpenVPN.<p>In summary: all sane configurations should not get these errors. But (apart from the broken VPN provider's server) the client can be persuaded to still connect (fixing the sympton and not the real problem). When connecting to older servers the comaptiblity mode option in the basic settings of a VPN should be able to address most of the common compatiblity problems.
I started reviewing this but I found that I don't agree on many changes here. Since neither of us is a native speaker I find many of these changes questionable and just because they sound better to another non-native speaker is not something that I think is good enough to change them. Overall I find the changes too "intrusive". I will have to go through them and pick the ones that are fixing actual mistakes but this is not something I can just accept.
@schwabe Be that as it may, it gives some amount of preference to people that aren't.
If we can (hopefully) get through it together, then that leaves some amount of home for the next translator, and in turn
less generational loss for translations based off other translations.
I tried translating it all myself, and also looked at available translations in so doing.
A lot of this is aimed at avoiding uncertainty and likely errors in translation based on experience.
To arrive at a good translation, it is important to start off with less entropy.
One can only keep a finite amount of strings in working memory at once, for the available time available each time.
There is a reason for every change, even if subtle.
schwabe
