Open jacklinke opened 1 month ago
Aha! I didn't see that there were previous attempts at this!
@tobiasmcnulty proposed https://github.com/django/djangoproject.com/issues/883 to add a language switcher.
Way back in 2015, @bmispelon proposed having the fundraising page translated in https://github.com/django/djangoproject.com/issues/377, and @pauloxnet and @carltongibson seemed to think it a good idea.
And https://github.com/django/djangoproject.com/pull/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.
gettext
in user-facing strings throughout the app's files (models, forms, etc)gettext
for user-facing strings in the site's static files and submit a PRFurther, 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.
@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.
@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.
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.
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.
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.
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
Proposed Work
See updated checklist in the comment below
Templates with at least some
trans
orblocktrans
tagsApproximate percentage of tags present on each template in the repo compared to potential
trans
orblocktrans
opportunities.Templates with no
trans
orblocktrans
tagsNote: Only those templates with text that can be translated but have no
trans
orblocktrans
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.