Skip to content
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

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

Open
jacklinke opened this issue Oct 6, 2024 · 5 comments

Comments

@jacklinke
Copy link

jacklinke commented Oct 6, 2024

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.

@jacklinke
Copy link
Author

jacklinke commented Oct 8, 2024

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

(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
Copy link
Contributor

marksweb commented Oct 8, 2024

@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
Copy link
Member

@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
Copy link
Member

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
Copy link
Contributor

marksweb commented Oct 23, 2024

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.

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

No branches or pull requests

4 participants