-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix all i18n
issues detected by new script
#9499
Fix all i18n
issues detected by new script
#9499
Conversation
That's an interesting edge case - just my two cents, if concatenating HTML strings in that manner is infrequent/something we tend to avoid, I think it would be fine to just flag it with |
@pidgezero-one I figure this will probably be the best solution, just a bit awkward for the files themselves as they each have many instances of the concatenated HTML, which will require many flags. But we'll see! |
@rebecca-shoptaw Ahh, I see... It might be a little tricky, but I wonder if it's worth it to add some logic that detects if it's part of a I guess HTML within |
"has_fulltext": _("Ebook"), | ||
"author_key": _("Author"), | ||
"subject_facet": _("Subjects"), | ||
"person_facet": _("People"), | ||
"place_facet": _("Places"), | ||
"time_facet": _("Times"), | ||
"first_publish_year": _("FirstPublished"), | ||
"publisher_facet": _("Publisher"), | ||
"language": _("Language"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll want to confirm that, in cases where we have dictionaries like this, that the values aren't being used as keys
elsewhere in the code -- otherwise, once we i18n these keys, we could unintentionally break things. I don't think that's what's happening here, just sharing a possible use case we may hit given this PR touches some 100 files
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Roger that! I'll investigate -- and I believe this is the only dict affected by the PR (the script doesn't actually detect them, I just ran across it).
e7b02c6
to
f001b48
Compare
Per @cdrini's advice, closing this to split it up into easier-to-review sub-PRs, which I will list and categorize in the original issue. 🙂 |
Closes #9486.
Fix. Manually fixes all
i18n
syntax issues picked up by the newpre-commit
script. Also escapes some non-i18n
-able and/or accidentally detected lines.Technical
$('
or$("
to avoid creatingWARN
s for Python code insertsSyntaxWarning
when the newmessages.pot
is generated; would be nice to get this fixed before merge, but everything still runs as expected$(" " if condition else None)
-->$((" " if condition else None))
-- somewhat awkward but only done in ~2-3 infrequently used files, so seems to be worth itEXCLUDE_FILES
for now --/books/edit.html
and/history/sources.html
-- as both have HTML elements concatenated with+
:openlibrary/openlibrary/templates/books/edit.html
Line 30 in 3a59fc5
I'm not sure the best course of action for handling this would be (i.e. reverting to normal HTML, leaving them in the
EXCLUDE_LIST
, using the new escape syntax, something else, etc.)Testing
pre-commit run --all-files
with the current much shorter exclude listScreenshot
Stakeholders
@cdrini @pidgezero-one