Proposal to add translation support for non-docs pages of djangoproject.com

[jacklinke]

Proposal to add translation support for non-docs pages

While Django’s documentation is translated into several languages, the main entry-point to the framework — the djangoproject.com website itself — remains mostly untranslated. Ensuring djangoproject.com is accessible to non-English speakers is important for demonstrating Django’s inclusivity and supporting a broad user base.

• Please let me know if this proposal misses any existing discussions or considerations.
• If this should be addressed to the Internals - Internationalization forum, please let me know, but the technical portion of this proposal (adding translation templatetags) at least seemed more appropriate to post here.

This issue did not seem to be identified as a problem in the recent User research report (1496)

Discussion

It feels a bid odd to see that the docs are translated into a variety of languages, but the greater djangoproject.com site is only available to English speakers.

Django strongly promotes internationalization, with clear documentation on using trans and blocktrans tags, and even shows an example of using {% blocktrans %} and {% trans %} templatetags on the Start page, but the page itself is only available in English. (ref)

One issue that we will run into is the content of djangoproject.com is a mix of text in templates and text that comes from models. While the models-based text could be a problem for another day, there are concrete steps we could take today to work toward translation of the template-based text.

Questions

• Was it a conscious decision not to translate the (non-docs) pages of djangoproject.com? If so, does the reason behind that decision still stand?
• Would it be beneficial to start work on this?
• If we move forward with this, would we prefer using a service like Transifex for translating non-documentation pages, similar to how documentation is currently handled, or would it be more appropriate to stick to the existing .po files?

Proposed Work

See updated checklist in the comment below

Templates with at least some trans or blocktrans tags

Approximate percentage of tags present on each template in the repo compared to potential trans or blocktrans opportunities.

Template	Completion
dashboard/templates/dashboard/index.html	100%
djangoproject/templates/members/corporate_members_join_thanks.html	100%
djangoproject/templates/members/corporatemember_form.html	100%
djangoproject/templates/members/individualmember_list.html	100%
djangoproject/templates/registration/password_reset_email.html	100%
docs/templates/docs/doc.html	100%
docs/templates/docs/genindex.html	100%
docs/templates/docs/py-modindex.html	100%
docs/templates/docs/search_results.html	100%
djangoproject/templates/includes/toggle_theme.html	75%
docs/templates/base_docs.html	75%
docs/templates/docs/search_form.html	50%
dashboard/templates/base_dashboard.html	33%
djangoproject/templates/members/corporatemember_list.html	22%

Templates with no trans or blocktrans tags

Note: Only those templates with text that can be translated but have no trans or blocktrans tags are included in the list below. All remaining templates whcih only load other templates or only load text content from models have been excluded.

• dashboard/templates/dashboard/detail.html
• djangoproject/templates/400.html
• djangoproject/templates/403.html
• djangoproject/templates/404.html
• djangoproject/templates/410.html
• djangoproject/templates/500.html
• djangoproject/templates/accounts/edit_profile.html
• djangoproject/templates/accounts/user_profile.html
• djangoproject/templates/aggregator/delete-confirm.html
• djangoproject/templates/aggregator/denied.html
• djangoproject/templates/aggregator/edit-feed.html
• djangoproject/templates/aggregator/feeditem_list.html
• djangoproject/templates/aggregator/index.html
• djangoproject/templates/aggregator/local-django-community.html
• djangoproject/templates/aggregator/my-feeds.html
• djangoproject/templates/base.html
• djangoproject/templates/base_blogroll.html
• djangoproject/templates/base_code.html
• djangoproject/templates/base_community.html
• djangoproject/templates/base_foundation.html
• djangoproject/templates/base_weblog.html
• djangoproject/templates/blog/blog_pagination.html
• djangoproject/templates/blog/entry_archive.html
• djangoproject/templates/blog/entry_archive_day.html
• djangoproject/templates/blog/entry_archive_month.html
• djangoproject/templates/blog/entry_archive_year.html
• djangoproject/templates/blog/entry_detail.html
• djangoproject/templates/blog/news_summary.html
• djangoproject/templates/conduct/base.html
• djangoproject/templates/conduct/changes.html
• djangoproject/templates/conduct/enforcement.html
• djangoproject/templates/conduct/faq.html
• djangoproject/templates/conduct/index.html
• djangoproject/templates/conduct/reporting.html
• djangoproject/templates/contact/coc.html
• djangoproject/templates/contact/coc_form.html
• djangoproject/templates/contact/foundation.html
• djangoproject/templates/contact/sent.html
• djangoproject/templates/diversity/base.html
• djangoproject/templates/diversity/changes.html
• djangoproject/templates/diversity/index.html
• djangoproject/templates/donate_thanks.html
• djangoproject/templates/foundation/coreawardcohort_list.html
• djangoproject/templates/foundation/meeting_archive.html
• djangoproject/templates/foundation/meeting_archive_day.html
• djangoproject/templates/foundation/meeting_archive_month.html
• djangoproject/templates/foundation/meeting_archive_year.html
• djangoproject/templates/foundation/meeting_detail.html
• djangoproject/templates/fundraising/email/thank-you.html
• djangoproject/templates/fundraising/includes/display_django_heroes.html
• djangoproject/templates/fundraising/includes/donation_form_with_heart.html
• djangoproject/templates/fundraising/includes/donation_snippet.html
• djangoproject/templates/fundraising/index.html
• djangoproject/templates/fundraising/manage-donations.html
• djangoproject/templates/fundraising/thank-you.html
• djangoproject/templates/homepage.html
• djangoproject/templates/includes/footer.html
• djangoproject/templates/includes/header.html
• djangoproject/templates/includes/mailing_lists.html
• djangoproject/templates/members/corporate_member_badges.html
• djangoproject/templates/members/team_list.html
• djangoproject/templates/overview.html
• djangoproject/templates/registration/activate.html
• djangoproject/templates/registration/activation_complete.html
• djangoproject/templates/registration/base.html
• djangoproject/templates/registration/logged_out.html
• djangoproject/templates/registration/login.html
• djangoproject/templates/registration/registration_complete.html
• djangoproject/templates/registration/registration_form.html
• djangoproject/templates/releases/download.html
• djangoproject/templates/start.html
• djangoproject/templates/styleguide.html
• djangoproject/templates/tracdb/bouncing_tickets.html

[jacklinke]

Aha! I didn't see that there were previous attempts at this!

• @tobiasmcnulty proposed Support switching languages on non-docs sites #883 to add a language switcher.

• Way back in 2015, @bmispelon proposed having the fundraising page translated in Localize the fundraising app #377, and @pauloxnet and @carltongibson seemed to think it a good idea.

• And Introducing i18n URL patterns (#883) #1251 was an ambitious effort by @marksweb to get the non-docs portion of the site moved forward for translation. It seems like it was too much to try to incorporate at once, but I really appreciate the work he did and the effort he put in.

(The comment from that issue here really helped frame some of my thoughts, too. The flatpages are their own beast, and can be a future effort if desired.)

Even if we do not translate every piece of the site quickly, here is a lot of low-hanging fruit when it comes to at least getting the site to be more friendly to django folks who don't speak English or for whom it is not their first language. Djangoproject.com is the world's front door to Django! (or it should be)

To avoid the same fate as #1251, and based on the recommendations in that PR, I propose the following to move this idea forward. Each step would have a separate PR if needed. In this way, no single PR would be especially challenging or time-consuming to review and approve, and because none of them are truly dependent upon the others they can be accomplished in any order without causing degradation.

• Identify which templates already have translation tags and which do not.
• Working app-by-app, perform the following and submit a PR:
  • Add translation tags to the remainder of templates
  • Implement use of gettext in user-facing strings throughout the app's files (models, forms, etc)
• Implement gettext for user-facing strings in the site's static files and submit a PR
• Add a view, url, and template to allow visitors to change the displayed language and submit a PR
• Begin working with the translations team to identify translators for the real work

Further, while working through each of these, I would recommend pulling in the tagging/gettext work @marksweb has already done if the template/file hasn't changed in the meantime.

---

• Does this breakdown seem like a reasonable way to approach the problem while avoiding the struggle of previous attempts?
• When it comes to organizing the work, would it be beneficial to create a set of issues (one for each of the checklist items above), and track their overall progress under another issue? Something like @thibaudcolas has done in djangoproject.com - User research report by 20tab #1496?

[marksweb]

@jacklinke yeah I think I basically did it all but in doing so it was overwhelming for anyone looking at it.

Last I looked there were plenty of conflicts in what I had done so not easy to pick up, but I'd suggest some discussion about what's going to need reviewing. That way there's some expectation from reviewers before they get to it.

[pauloxnet]

@jacklinke yeah I think I basically did it all but in doing so it was overwhelming for anyone looking at it.

Great job Marco with the PRs.

I thought that since the texts used in the website are the result of different contributions and stratifications over time, I would suggest taking advantage of these PRs to unify some translatable texts in their various occurrences in the code (eg: e-mail, email, Email, E-mail, ...).

This process, in addition to making the text consistent in the different sections of the website, would greatly help those who will have to deal with the translation of the strings, avoiding unnecessary additional work and misalignments.

[bmispelon]

I thought that since the texts used in the website are the result of different contributions and stratifications over time, I would suggest taking advantage of these PRs to unify some translatable texts in their various occurrences in the code (eg: e-mail, email, Email, E-mail, ...).

This process, in addition to making the text consistent in the different sections of the website, would greatly help those who will have to deal with the translation of the strings, avoiding unnecessary additional work and misalignments.

It would be nice to make the texts more consistent but honestly the review of those PRs is hard enough as it is now. I'm almost done with the reviews, and my plan is to merge them once they've all been approved. Once that's done, we still have to figure out a technical process and a human process for how to get things translated by the community and integrated back into the site's codebase. The harmonization efforts can happen while we figure out those processes.

[marksweb]

I'm almost done with the reviews, and my plan is to merge them once they've all been approved.

I'm not done with the apps yet 😬

I've got a local branch for fundraising, then there's members, releases, tracdb. Though I think they're getting easier to do and review as some of these don't contain much.

There's no harm in releasing these changes as they are though. They wont' change anything as they are.

It's the other change I've got coming that changes the language settings and adds the frontend language selector which will then have a visible change and a change to the URL structure.

In terms of the process of translations - does django have a transifex account for the docs? I've seen mention of the service in the code.