#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 , 10 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:3 by , 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.
follow-up: 7 comment:5 by , 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 , 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.
comment:7 by , 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 , 10 years ago
Cc: | added |
---|
comment:9 by , 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 , 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 , 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 , 10 years ago
Has patch: | set |
---|---|
Patch needs improvement: | set |
I left a comment on the commit.
comment:13 by , 10 years ago
Thanks, I'll make a new pull request with the relevant phrases inserted into the HTML block instead.
comment:14 by , 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:
- Starting a new project,
- generating a
.po
usingmakemessages
, - translating it,
- generating a new
.mo
, - changing
LANGUAGE_CODE
insettings.py
, - doing
runserver
and visiting the site
comment:15 by , 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 , 10 years ago
Removed the comments and changed ugettext_lazy
to ugettext
.
Here's the pull request:
comment:17 by , 10 years ago
Patch needs improvement: | unset |
---|---|
Triage Stage: | Accepted → Ready for checkin |
Type: | Bug → Cleanup/optimization |
comment:18 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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.