Merge #2892: [Scripts][GUI] Overhaul translation ingestion script and update translations from Transifex
b0d6e37c2b5a4106953c860a516afc575d72e325 [GUI] Update translations from Transifex (Fuzzbawls)
6694c35425f06db21700a675f5d5773423f67457 [Scripts] Update update-translations.py script and config (Fuzzbawls)
Pull request description:
Our `update-translations.py` was in dire need of updating since Transifex depreciated their old `tx` CLI utility in favor of their new CLI utility (of the same name). Minor changes to the `.tx/config` file format were needed to be compliant, and the translation ingestion script itself (`update-translations.py`) was updated to be more in-line with upstream's version, with some additional Flake8/PEP compliance rules being adhered to.
The first commit is really the only commit that needs actual code review. The second commit is automatically generated changes resulting from running the `update-translations.py` script, with **ONE** caveat: I changed the minimum translation threshold from 80% to 50% solely for the purpose of not loosing any already translated languages.
I felt this necessary for the `master` branch (which will never be used for final release translations) simply to showcase that translating the core wallet is an ongoing process that is never truly "finished", as strings change or new strings get introduced between wallet release versions.
It also gives users of otherwise incomplete translated languages a chance to view how their language translations appear in a compiled GUI wallet, and provide feedback if there are any clipping issues.
----
This PR does introduce two completely new wallet translations never before seen with PIVX:
- Bengali (bn) (95.68% translated)
- Persian (fa) (95.68% translated)
---
And now for the part where we need some more help prior to the final 6.0 release;
The following languages are in jeopardy of being EXCLUDED from the final 6.0 release unless they can reach a minimum of 80% translated strings. Listed in descending order based on completion percentage:
- Polish (pl) (79.59%)
- Spanish (es) (79.02%)
- Spanish (Spain) (es_ES) (79.02%)
- Dutch (nl) (77.75%)
- Italian (it) (76.19%)
- Russian (ru) (75.9%)
- Chinese (China) (zh_CN) 67.26%
- Chinese (Taiwan) (zh_TW) 67.26%
- Turkish (tr) 59.32%
- Swedish (sv) 52.16%
---
Any translator that has contributed translations via Transifex for the PIVX Core wallet is highly encouraged to check-in on the Transifex website, as no language (other than the English source) is 100% complete at the time of writing this PR.
Anyone not already part of the PIVX translation effort on Transifex that would like to join the effort, you can goto https://explore.transifex.com/pivx-project/ and request to join the `PIVX Core Wallet` project.*
*Note: the completion percentages represented on the public page are TOTAL over all resource versions available (we keep many historical resource versions for archival purposes), and NOT indicative of the specific targeted resource version percentages listed above
ACKs for top commit: b0d6e37c2b5a4106953c860a516afc575d72e325
panleone:
tACK b0d6e37c2b5a4106953c860a516afc575d72e325
Liquid369:
tACK b0d6e37c2b5a4106953c860a516afc575d72e325
37315c75e53d7b853575cc5a4dbfc4b26c4ea2ba tests: increase wait time in p2p_invalid_messages.py (Fuzzbawls)
f6666b3d0de91d67c4522a761aae2ceb67d60a34 [GA] Fix GA for macOS runners (Fuzzbawls)
Pull request description:
Homebrew no longer supports pre-built (binary) packages on macOS 11.
Some binary packages remain (for now). This means that packages are
built from source instead, which causes a runner timeout to occur when
trying to build the Qt and ZMQ packages.
A secondary issue came up with the newer Boost 1.83 version supplied by
homebrew for all macOS versions that was causing build errors.
To work around this, I've re-worked the CI and CMake workflows to
not include Qt/ZMQ on macOS 11 runners, and also set a specific Boost
version (1.76) that is still binary compatible with macOS 11.
llvm 13 ships with macos 11 runners natively, but is still not working for our
CMake builds (we previously used Homebrew's `llvm@13` package, which is
also no longer available on macos 11 runners in binary format), so I've
dropped down to llvm 12 instead.
Lastly, and as it's own commit, I was consistently running into an assertion
error with the p2p_invalid_messages.py functional test with counting the
number of `mnping` messages. An increased wait time has cleared up this
issue.
ACKs for top commit: 37315c75e53d7b853575cc5a4dbfc4b26c4ea2ba
Liquid369:
tACK 37315c75e53d7b853575cc5a4dbfc4b26c4ea2ba
panleone:
utACK 37315c75e53d7b853575cc5a4dbfc4b26c4ea2ba
Homebrew no longer supports pre-built (binary) packages on macOS 11.
Some binary packages remain (for now). This means that packages are
built from source instead, which causes a runner timeout to occur when
trying to build the Qt and ZMQ packages.
A secondary issue came up with the newer Boost 1.83 version supplied by
homebrew for all macOS versions that was causing build errors.
To work around this, I've re-worked the CI and CMake workflows to
not include Qt/ZMQ on macOS 11 runners, and also set a specific Boost
version (1.76) that is still binary compatible with macOS 11
Merge #2886: [DB] Upgrade evoDB and llmqDB to V2 serializer
d6424b87a3a6a33a0d8c60c9ed60ad827fd92844 Upgrade evoDB and llmqDB to V2 serializer (Alessandro Rezzi)
Pull request description:
This PR upgrades the `evoDB` and `llmqDB` serializer version to V2 in order to support TOR DMNs. In order to keep a potential backward compatibility all others databases (like spork, blocks...) kept the old V1 serializer.
The PR also also upgrades to V2 the way `extraPayload` in transaction is serialized and the way keys of `mnUniquePropertyMap` are serialized
ACKs for top commit: d6424b87a3a6a33a0d8c60c9ed60ad827fd92844
Fuzzbawls:
ACK d6424b87a3a6a33a0d8c60c9ed60ad827fd92844
Liquid369:
tACK d6424b87a3a6a33a0d8c60c9ed60ad827fd92844
be497204a7f32634085be0ccf39436509488f94f Functional test coverage (Alessandro Rezzi)
2379c2daa98d7ab428fe138fc4e25d0965ceaf93 Improved error coverage and added default behaviour for null merkle tree (Alessandro Rezzi)
387144f623a50fa03b8c697780579719c62f4ff3 Function to rollback, eventually disconnect a block by recreating the witness cache (Alessandro Rezzi)
Pull request description:
Invalidateblock has not been working since sapling came out. This happens because the current maximum witness cache has a depth of only 100 blocks. With this PR I want to fix this issue by manually building the witness cache if the block has a depth bigger than the cache size.
Since this operation can become pretty lengthy, the RPC will just return error if your oldest sapling note is older than 1 month (43200 blocks behind the chain tip).
Note: After using invalidateblock the user might need to do
`-> debug ->wallet repair -> recover transactions ` in order to recover the correct balance. This is not a limit of this PR and you can test that it already happens with the current implementation of invalidateblock.
Anyways "recover transactions" also cleans the wallet GUI from "conflicted" txs that you get after invalidating a block so it would be useful regardless.
Overall invalidating + eventually using recover transactions is faster than the current rescanning the blockchain from 0
Solves #2605
ACKs for top commit: be497204a7f32634085be0ccf39436509488f94f
Liquid369:
tACK be497204a7f32634085be0ccf39436509488f94f
Fuzzbawls:
ACK be497204a7f32634085be0ccf39436509488f94f
