This is a really important first impression, and easy UX win!
--
Ticket URL: <https://code.djangoproject.com/ticket/22635>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* needs_docs: => 0
* needs_tests: => 0
* stage: Unreviewed => Accepted
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22635#comment:1>
* status: new => assigned
* owner: nobody => giuliettamasina
--
Ticket URL: <https://code.djangoproject.com/ticket/22635#comment:2>
Comment (by claudep):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22635#comment:3>
Comment (by giuliettamasina):
Sure, let me know, so I don't put time into this one unnecessarily :)
--
Ticket URL: <https://code.djangoproject.com/ticket/22635#comment:4>
Comment (by hakanw):
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?
--
Ticket URL: <https://code.djangoproject.com/ticket/22635#comment:5>
Comment (by erikr):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22635#comment:6>
Comment (by claudep):
Replying to [comment:5 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22635#comment:7>
* cc: hakanw (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/22635#comment:8>
Comment (by shai):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22635#comment:9>
Comment (by ramiro):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22635#comment:10>
Comment (by giuliettamasina):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22635#comment:11>
* needs_better_patch: 0 => 1
* has_patch: 0 => 1
Comment:
I left a comment on the commit.
--
Ticket URL: <https://code.djangoproject.com/ticket/22635#comment:12>
Comment (by giuliettamasina):
Thanks, I'll make a new pull request with the relevant phrases inserted
into the HTML block instead.
--
Ticket URL: <https://code.djangoproject.com/ticket/22635#comment:13>
Comment (by giuliettamasina):
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
--
Ticket URL: <https://code.djangoproject.com/ticket/22635#comment:14>
Comment (by claudep):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22635#comment:15>
Comment (by giuliettamasina):
Removed the comments and changed `ugettext_lazy` to `ugettext`.
Here's the pull request:
https://github.com/django/django/pull/2682
--
Ticket URL: <https://code.djangoproject.com/ticket/22635#comment:16>
* needs_better_patch: 1 => 0
* type: Bug => Cleanup/optimization
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/22635#comment:17>
Comment (by Claude Paroz <claude@…>):
In [changeset:"813ded775d2491bc12b55b8dbbb4a2e591e9dd15"]:
{{{
#!CommitTicketReference repository=""
revision="813ded775d2491bc12b55b8dbbb4a2e591e9dd15"
Merge pull request #2682 from alimony/welcome_page_local_02
Fixed #22635 -- Make "It worked!" page localizable
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/22635#comment:19>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"5f24cf9705f567f081c2ec704034ef5425306eff"]:
{{{
#!CommitTicketReference repository=""
revision="5f24cf9705f567f081c2ec704034ef5425306eff"
Fixed #22635 -- Made "It worked!" page localizable.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/22635#comment:18>
Comment (by Claude Paroz <claude@…>):
In [changeset:"43372fc7aa50b52487f29fffdea3c597a0e8117f"]:
{{{
#!CommitTicketReference repository=""
revision="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.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/22635#comment:20>