#9523 closed New feature (fixed)
Restart runserver after translation MO files change
Reported by: | Owned by: | Bouke Haarsma | |
---|---|---|---|
Component: | Internationalization | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | trebor74hr@…, bmihelac@…, charette.s@…, Bouke Haarsma | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Hello friendly people,
I have a feature-request concerning i18n.
After running: "django-admin.py compilemessages" I'd like the testing server to restart automatically.
Now it doesn't.
Thanks for looking at this feature request!
Change History (18)
comment:1 by , 16 years ago
Summary: | i18n - compilemessages → Restart runserver after translation MO files change |
---|---|
Triage Stage: | Unreviewed → Someday/Maybe |
comment:2 by , 15 years ago
Solution suggestion
Whenever new translation is to be submitted django-admin compilemessages management command has to be called (http://docs.djangoproject.com/en/1.1/topics/i18n/localization/).
If command http://code.djangoproject.com/browser/django/trunk/django/core/management/commands/compilemessages.py issues at least one successful compiling (new version of mo is created) - it could
"touch" some django python file - what should trigger django-dev server restart. The only issue is which file to touch, while it shouldn't be any file that user is editing in the meantime.
btw. #4032 is closed ticket with the same issue.
comment:3 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → New feature |
comment:4 by , 14 years ago
Cc: | added |
---|---|
Easy pickings: | unset |
comment:6 by , 12 years ago
Cc: | added |
---|
comment:7 by , 12 years ago
Cc: | added |
---|
comment:8 by , 12 years ago
Triage Stage: | Someday/Maybe → Accepted |
---|
I think this ticket should be "accepted".
Malcolm's had two objections: it's low priority, and it isn't obvious to implement. But if someone writes a good patch, we'll certainly consider it.
comment:9 by , 12 years ago
Has patch: | set |
---|
I provided a pull request fixing this issue: https://github.com/django/django/pull/1283
comment:10 by , 11 years ago
Needs tests: | set |
---|
I've left some comments on the rebased PR. I'd like to see this tested in some way -- based on the coverage report, none of django/utils/autoreload.py is tested.
comment:11 by , 11 years ago
Cc: | added |
---|---|
Owner: | changed from | to
Status: | new → assigned |
I've updated the PR and I included a few tests for the gen_filenames
helper. The autoreloader is in the omit
section of .coveragerc
, so that's why there's no coverage at all.
comment:12 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:14 by , 11 years ago
Needs tests: | unset |
---|---|
Resolution: | fixed |
Status: | closed → new |
Translations in INSTALLED_APPS, which Django might use, are not being watched. By inspecting INSTALLED_APPS, this can be fixed.
comment:15 by , 11 years ago
Version: | 1.0 → master |
---|
comment:16 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
(Changed title to describe the problem.)
This sounds like a fair bit of work for not a huge amount of gain. The filenames for the loaded translations aren't stored anywhere (and it would be complicating things to add them just for this request). So we end up having to check every single translation file to see if there's a change.
Maybe somebody will come along and write a patch that doesn't chew up a lot of resources (file stats aren't too expensive if the dirents are already in buffer cache) and add that to the reload checker without introducing too much tight coupling, but it isn't going to be really high priority, I expect.