Closed slightlyskepticalpotat closed 3 months ago
Let's do it for next release; there's 1h30m left on the translation deadline.
With the currently merged translation files:
Checking all translations...
No errors detected.
When I manually remove a numerusform element:
Checking all translations...
Numerus message without numerusform translations, needs fix.
When I manually add extra text to a numerusform element:
Checking all translations...
Numerus message contains extra text
正在处理数据块..., needs fix.
When I manually add an extra child element to non-numerus elements:
Checking all translations...
Non-numerus message contains child node in translation, needs fix.
When I add an extra child element under a numerus element:
Checking all translations...
Numerus message contains extra child node, needs fix.
Would it be possible to add double tags to this check too?
As in , <<
or >>
would throw an error.
I was thinking that we should also check a couple more things while we're at it - the stricter the linter is, the better we protect the build (and testers):
<translation>
elements must have:
<numerusform>
when there is numerus="yes"
numerus!="yes"
Would it be possible to add double tags to this check too?
As in ,
<<
or>>
would throw an error.
I believe the XML parser already does that, when I add an extra bracket it goes
Traceback (most recent call last):
File "/home/anthony/Programming/GitHub/dogecoin/contrib/devtools/check-translations.py", line 164, in <module>
errors_detected = check_all_translations()
File "/home/anthony/Programming/GitHub/dogecoin/contrib/devtools/check-translations.py", line 121, in check_all_translations
tree = ET.parse(io.BytesIO(data), parser=parser)
File "/usr/lib/python3.10/xml/etree/ElementTree.py", line 1222, in parse
tree.parse(source, parser)
File "/usr/lib/python3.10/xml/etree/ElementTree.py", line 586, in parse
parser.feed(data)
xml.etree.ElementTree.ParseError: not well-formed (invalid token): line 477, column 9
When I was submitting my translations the other day (#3441), I noticed that the linter would pass right away (yay!), and then some other check failed a ">>" some five minutes later. I didn't look into it too far, but just thought it was a bit time consuming to wait 5 minutes to find out that my translation work was actually faulty.
In that PR, the initial commit, and the "small fix" commit passed the linter, but failed later on. The double brackets were fixed in the following commit "small fix 2".
The double brackets were fixed in the final commit "small fix 2".
Analyzed the issue, I think I know how to fix it. Will propose on the new branch.
@patricklodder I implemented the suggestions, is there anything else you can think of (besides the fix for mismatched brackets)?
Fixed and tested with Patrick's input
Checking all translations...
Numerus message without numerusform translations, needs fix. Only text in numerus
Numerus message contains extra text Thisfails, needs fix.
Numerus message contains extra child node, needs fix. Numerusform with extra child element
Non-numerus message contains child node in translation, needs fix. Numerusform without numerus attr
Non-numerus message contains child node in translation, needs fix. Random additional element
Works for me now. Could use a rebase & squash.
Squashed, thanks!
I know we're two hours out from the 1.14.7 PR deadline but I made a quick PR for https://github.com/dogecoin/dogecoin/issues/3445. If this is merged now, we can have better translation linting for 1.15.
Alternatively, feel free to push this back to the next release.