Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#22635 closed Cleanup/optimization (fixed)

Welcome page should be translatable

Reported by: Håkan W Owned by: Markus Amalthea Magnuson
Component: Translations Version: dev
Severity: Normal Keywords:
Cc: Håkan W Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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!

Change History (20)

comment:1 by Russell Keith-Magee, 10 years ago

Triage Stage: UnreviewedAccepted

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.

comment:2 by Markus Amalthea Magnuson, 10 years ago

Owner: changed from nobody to Markus Amalthea Magnuson
Status: newassigned

comment:3 by Claude Paroz, 10 years ago

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.

comment:4 by Markus Amalthea Magnuson, 10 years ago

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

comment:5 by Håkan W, 10 years ago

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?

comment:6 by Sasha Romijn, 10 years ago

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.

in reply to:  5 comment:7 by Claude Paroz, 10 years ago

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.

comment:8 by Håkan W, 10 years ago

Cc: Håkan W added

comment:9 by Shai Berger, 10 years ago

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.

comment:10 by Ramiro Morales, 10 years ago

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.

comment:11 by Markus Amalthea Magnuson, 10 years ago

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.

comment:12 by Claude Paroz, 10 years ago

Has patch: set
Patch needs improvement: set

I left a comment on the commit.

comment:13 by Markus Amalthea Magnuson, 10 years ago

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

comment:14 by Markus Amalthea Magnuson, 10 years ago

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

comment:15 by Claude Paroz, 10 years ago

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.

comment:16 by Markus Amalthea Magnuson, 10 years ago

Removed the comments and changed ugettext_lazy to ugettext.

Here's the pull request:

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

comment:17 by Tim Graham, 10 years ago

Patch needs improvement: unset
Triage Stage: AcceptedReady for checkin
Type: BugCleanup/optimization

comment:18 by Markus Amalthea Magnuson <markus.magnuson@…>, 10 years ago

Resolution: fixed
Status: assignedclosed

In 5f24cf9705f567f081c2ec704034ef5425306eff:

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

comment:19 by Claude Paroz <claude@…>, 10 years ago

In 813ded775d2491bc12b55b8dbbb4a2e591e9dd15:

Merge pull request #2682 from alimony/welcome_page_local_02

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

comment:20 by Claude Paroz <claude@…>, 10 years ago

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.

Note: See TracTickets for help on using tickets.
Back to Top