Skip to content

Add missing translated strings#4725

Draft
bmispelon wants to merge 8 commits intoHyphaApp:mainfrom
bmispelon:dhsh-translation-audit
Draft

Add missing translated strings#4725
bmispelon wants to merge 8 commits intoHyphaApp:mainfrom
bmispelon:dhsh-translation-audit

Conversation

@bmispelon
Copy link
Contributor

(This contribution was sponsored by DigitalHub.sh)

I've split this PR over several commits which are mostly independent of each other. I'm happy to open separate PRs if you think that'd be easier to review.

Explanations of the separate commits

Mark missing strings for translation

After a few unsuccessful attempts at scripting the identification of untranslated strings, I ended up reviewing all Python files manually.

The command I used to identify the relevant files was:

git ls-files -z '**.py' ':!**/migrations/*.py' ':!**/urls.py' ':!hypha/settings/*.py' ':!docs/*' ':!**/test*.py' | find -files0-from - -not -empty

(That's all Python files, but excluding stuff like migrations, settings, ... (and empty files))

This change should have no impact for a site running the English version of Hypha.

Add missing strings for translations (templates)

Similar to the previous commit, I ended up reviewing all templates manually (git ls-files '*.html'), adding {% trans %}, {% blocktrans %}, or _(...) where needed.

Again, this change should have no impact.

Add trimmed option to blocktranslate

This removes irrelevant whitespace in source strings, making it a bit nicer.

I used git grep blocktrans | grep -vw trimmed | grep -v endblocktrans to identify uses of {% blocktrans %} without the trimmed argument, excluding lines that also included {% endblocktrans %} on the same line.

This is technically a breaking change, but it only introduces whitespace changes to HTML templates, which is irrelevant.

Use {% blocktranslate trimmed %} to break down long lines

This one just makes templates a little bit more readable as it breaks very long lines into more manageable pieces.

Again, it can introduce whitespace changes to the HTML, but should not have any effect to the source strings.

Added verbose_name and verbose_name_plural to all models

Some models already has a translated verbose_name or verbose_name_plural, but it was inconsistent (and quite rare). This change adds these attributes to all models.

I used git ls-files '**/models/*.py' and git ls-files '**/models.py' to find all models, then went through the files manually to add the missing verbose_name and verbose_name_plural.

I decided to omit the plural form for model classes inheriting from BaseSiteSettings since it didn't seem to make sense.

I also opted to use lower case (like _("foo bar") for model FooBar) to match Django's own default behavior, but I used Foo Bar in a few instances where the model already had a verbose_name that used titlecase.

Next steps

I ran out of time to complete all my objectives and I've still got some translation-related tasks I wanted to get to. I'm happy to open issues for these if you think they're relevant:

  • Fix missing translations in javascript files: I found about 10 instances but fixing them would require either using the Django javascript translation functions, or moving the strings to the HTML (data attributes for example).
  • Add explicit verbose_name to all declared model fields (and maybe form fields as well). This can probably be scripted somewhat, ideally with a linter that would catch the introducing of future untranslated strings.
  • Review cases where gettext is used at the module level instead of gettext_lazy as this could indicate some possible bugs (visible in a multi-language setup where the user is not using the default language).
  • Fix translations that build up a sentence word by word, as this doesn't really work in practice. Something like {% trans "Application" %} {{ application_id }} {% trans "updated on" %} {{ date }} {% trans "by" %} {{ author.name }} should be rewritten to have the whole sentence in a single blocktrans, or when not possible small words like by should be given a context because they're likely to be translated differently for different sentences.

Copy link
Member

@frjo frjo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work, must have taken some time!

The error messages we never bothered with before, normal users should never see them hopefully. But no harm in having them translated.

"unique_together": "You have already created a determination for this submission",
"unique_together": _(
"You have already created a determination for this submission"
),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The forms in this file are old and only used on old installs, in reality only OTF I believe.

I do not think we should translate them, just adding a lot of strings to translate that are not really used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've reverted the changes for that file. The text did appear very OTF-specific when I made the change originally, but I wasn't quite sure so thanks for giving me context!

@bmispelon bmispelon force-pushed the dhsh-translation-audit branch 2 times, most recently from 013bcb9 to 6001e0c Compare February 27, 2026 15:48
@bmispelon bmispelon force-pushed the dhsh-translation-audit branch from 85bef34 to 35b1949 Compare March 3, 2026 15:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants