Welcome page should be translatable

[Håkan W]

The Welcome page for a new project ("It worked!") should be translatable, and then translated to all languages, just like the django admin and other parts of django.

This is a really important first impression, and easy UX win!

[Russell Keith-Magee]

Sounds like a good idea to me. There's two parts here -- firstly marking all the strings as translatable, and then actually doing the translations. This ticket will only be a placeholder for marking the strings as translatable; the rest will be handled through Transifex.

[Claude Paroz]

First of all, I'm all for more localization (being the documentation or the management command output, see also #17379).

Now currently, all developer-facing strings are untranslated in Django. I think that it would be inconsistent to only translate part of those strings, and that we should aim for an all-or-nothing strategy in this domain. Why for example would we want to translate the Welcome page and not the 500 debug view? In the same vein I pushed for the documentation translation, I'm in favor of that, but I'd like to be sure this is shared among core developers, at least that noone is totally opposed.

[Markus Amalthea Magnuson]

Sure, let me know, so I don't put time into this one unnecessarily :)

[Håkan W]

I agree that also stack traces / error pages should be translated as well, I was gonna file tickets for those too, but it would be great to have it all at once since it's in the same place technically.

How do we check for core develop consensus?

[Sasha Romijn]

Conceptually, I agree with Claude, but I am wondering where this will end. We throw many exceptions that use English strings as well, should those be translated too? I'm concerned there would be much extra to translate, which not everyone will find as valuable as end user facing strings. If only parts are translated, that may lead to an inconsistent experience for users.

So, whereas I can see how a translated welcome page is friendlier and I do value consistency, I am a little concerned about the consequences of going all or nothing. With that in mind, perhaps we should allow the inconsistency here: the welcome page translated, because it is really the first experience new developers have, but other items not translated, to keep the translation burden manageable. I don't feel strongly though.

[Claude Paroz]

Replying to hakanw:

How do we check for core develop consensus?

The canonical answer would be: post on the django-developers mailing list. However, I know beforehand the result, that is basically two camps, those who think you should understand English well to program, and those thinking it shouldn't be an absolute requirement. That's why I would say to simply wait for interested people to post opinions on the ticket, as active core developers generally read the ticket logs.

[Shai Berger]

Besides what erikr said, note that languages are not necessarily the first thing tweaked in the settings; many developers will not see the translated welcome screen even if it is available. On the other hand, if we add it, translators still need to work on it. Thus, -0 from me on the whole issue.

[Ramiro Morales]

Developer-targeted error/stack traces aren't translatable because of a technical reason, IIRC: If a report of an internal app/Django error is going to be shown we don't want to have many moving parts (e.g. the i18n machinery) that could potentially introduce further error conditions. They could make it harder to find information about the original cause of the issue in the 500 status page.

IMHO they should stay like that.

I'm +0 to getting the 'It worked' page localized.

[Markus Amalthea Magnuson]

I have a branch with this change, let me know if I should open a pull request:

​https://github.com/alimony/django/commit/6b4946c4f502b536ccc7fec75ce3cfb51fd20b5f

I've tested it by generating new .po files, translating the page to Swedish, make a .mo file from that, and start a new project.

[Claude Paroz]

I left a comment on the commit.

[Markus Amalthea Magnuson]

Thanks, I'll make a new pull request with the relevant phrases inserted into the HTML block instead.

[Markus Amalthea Magnuson]

Here's the improved implementation of this:

​https://github.com/alimony/django/commit/f493d27579d94420b1b07a9bac6220fd1c7ba072

First, I tried just using DEFAULT_URLCONF_TEMPLATE as a format string, with named placeholders and a dict at the end, which is how many other localized strings are done.

But this caused a strange circular dependency and import errors. A fix for this is putting it inside a function. But instead of adding a new function, I figured easiest would be to just pass the translated strings to the template context, and having regular template variables in the HTML.

Let me know if this is a good approach.

All tests are passing, and I've tested the change itself by:

1. Starting a new project,
2. generating a .po using makemessages,
3. translating it,
4. generating a new .mo,
5. changing LANGUAGE_CODE in settings.py,
6. doing runserver and visiting the site

[Claude Paroz]

Thanks, it's a lot better now. Two comments:

• I don't think that the comments for translators are really useful in this case. The messages are pretty straightforward to understand without them. Tell me if and why you disagree.
• You don't need ugettext_lazy, as translations will happen at runtime, not at import time.

Please make it a pull request.

[Markus Amalthea Magnuson]

Removed the comments and changed ugettext_lazy to ugettext.

Here's the pull request:

​https://github.com/django/django/pull/2682

[Markus Amalthea Magnuson <markus.magnuson@…>]

In 5f24cf9705f567f081c2ec704034ef5425306eff:

Fixed #22635 -- Made "It worked!" page localizable.

[Claude Paroz <claude@…>]

In 813ded775d2491bc12b55b8dbbb4a2e591e9dd15:

Merge pull request #2682 from alimony/welcome_page_local_02

Fixed #22635 -- Make "It worked!" page localizable

[Claude Paroz <claude@…>]

In 43372fc7aa50b52487f29fffdea3c597a0e8117f:

Prevented markup escape in 'Welcome to Django' page

Fixes a regression introduced in 5f24cf9705. Refs #22635.
Thanks A.J. May for spotting the regression.