#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 Changed 15 years ago by
Summary: | i18n - compilemessages → Restart runserver after translation MO files change |
---|---|
Triage Stage: | Unreviewed → Someday/Maybe |
comment:2 Changed 14 years ago by
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 Changed 12 years ago by
Severity: | → Normal |
---|---|
Type: | → New feature |
comment:4 Changed 12 years ago by
Cc: | trebor74hr@… added |
---|---|
Easy pickings: | unset |
comment:6 Changed 11 years ago by
Cc: | bmihelac@… added |
---|
comment:7 Changed 11 years ago by
Cc: | charette.s@… added |
---|
comment:8 Changed 11 years ago by
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 Changed 10 years ago by
Has patch: | set |
---|
I provided a pull request fixing this issue: https://github.com/django/django/pull/1283
comment:10 Changed 10 years ago by
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 Changed 10 years ago by
Cc: | Bouke Haarsma added |
---|---|
Owner: | changed from nobody to Bouke Haarsma |
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 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:14 Changed 10 years ago by
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 Changed 10 years ago by
Version: | 1.0 → master |
---|
comment:16 Changed 10 years ago by
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.