So we don't need to re-translate the whole description string everytime a default value is changed.
Example:
" -keypool=<n> " + _("Set key pool size to <n> (default: 100)") + "\n" +
" -keypool=<n> " + _("Set key pool size to <n> (default:") + "100)\n" +
Some defaults need to be translated, and some languages might not place them at the end. To work with this, such a change should use a %1 placeholder for the default, and make the default independently translatable when it is not a simple integer. The hard part will be doing this in a way that remains compatible with bitcoind, where _ is currently a no-op.
Default is always the literal value that will be used as default. For that reason it does not need to be translated, integer or otherwise.
Using substitutions is an okay idea although I personally don't see the problem with putting the default at the end in every language. And thus not introducing complexity for something that should be so simple.
Any languages where this'd be different? Right-to-left languages render from right to left so putting the default at the end is still sane.
Counter-examples:
-tor=<ip:port> Use proxy to reach tor hidden services (default: same as -proxy)
-port=<port> Listen for connections on <port> (default: 8333 or testnet: 18333)
-discover Discover own IP address (default: 1 when listening and no -externalip)
-listen Accept connections from outside (default: 1 if no -proxy or -connect)
-dnsseed Find peers using DNS lookup (default: 1 unless -connect)
-upnp Use UPnP to map the listening port (default: 1 when listening)
-shrinkdebugfile Shrink debug.log file on client startup (default: 1 when no -debug)
-checkblocks=<n> How many blocks to check at startup (default: 2500, 0 = all)
Ok, you're right. It does not describe only default values but also conditional default behavior. Better to close this issue, it was a bad idea.
Well, I think it's a good idea - just a lot of work >_<
Seems like the idea is not consistently convertible (with little effort) and it makes no sense to special case such a thing -> closing this one.
Yeah exactly, it could have been a good idea if we had structured options help more consistently from the beginning, but retrofitting it is just not worth the work.