Closed kristian-clausal closed 3 days ago
It'd be really helpful to restore the long strings in non-en test cases so I don't have to resolve the conflicts... But it's also fine to not restore them if it's too much trouble.
This is a low-priority PR, you can merge what you want and I'll take care of merge conflicts if they come up for this PR. I'll rebase based on yours and let your conflicts override what's here.
Thanks! I'll merge the fr edition pr.
In the future, I won't bother with breaking up strings in tests/ and the ignored files. It's unfortunate that there's no way to have separate errors for string too long for line
and code being too long. If there any reason not to leave the current split lines? These seem the kind of strings that don't see much editing after their creation.
I can't properly format the HTML tags in test cases because the parsed nodes will have "preformatted" nodes break node structure. And break long strings doesn't make it easier to read. Another reason to using long string is when templates updated on wikipedia, it's easier to see the expended text changes in git diff.
I will revert many of the breaks. Should be possible with a reset to baseline and git commit -p
.
I think it's also fine to ignore mypy false errors in tests, test will fail if a wrong type is used and non-en code also use pydantic to check types. So no need to add ignore
for these lines. mypy is so weak... If most mypy errors in tests are false alarm. maybe better not run mypy checks for test files.
Could we ignore long lines in test files?