Opened 16 years ago
Last modified 4 years ago
#6376 assigned New feature
Allow using custom gettext domains
Reported by: | Owned by: | Rui Pereira | |
---|---|---|---|
Component: | Internationalization | Version: | dev |
Severity: | Normal | Keywords: | gettext |
Cc: | clouserw@…, fwenzel, 4glitch@…, raymond.penners@…, Krzysztof Gutkowski | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
I'm using django as a library in my non-web-based application. As such I prefer not to use the 'django' gettext domain but my own. I currently work around it with some symlinking trickery since being compatible with upstream django is more important than not having workarounds, but it would be great if django supported this. To illustrate what I mean, I've attached a simple and untested patch against current svn (rev 7020).
Attachments (1)
Change History (24)
Changed 16 years ago by
Attachment: | gettext_domain.patch added |
---|
comment:1 Changed 16 years ago by
If you change the domain you also have to rename django.mo, which I think is awkward.
You could use gettext.translation('django') for django-related strings and gettext.translation('yourapp') for other strings. This way your translations are separate and don't interfere with the django ones.
comment:2 Changed 16 years ago by
That doesn't work for my use case: template strings with {% trans %}/{% blocktrans %}. I'm using the django db/model api and templating system, nothing else. So no translated strings from django are being used, but the translation infrastructure is.
comment:3 Changed 16 years ago by
Has patch: | set |
---|---|
Patch needs improvement: | set |
Triage Stage: | Unreviewed → Design decision needed |
comment:4 Changed 16 years ago by
I don't think the proposed solution is the right approach. It is best practice that the translation domain for a library or reusable component does not change, that way it is shared between all apps that want to use it. I'd prefer to see a way to specify additional translation domains, since that will allow different apps to ship in different domains.
That might be an extra template tag or something, I'm not sure. It's better than a setting, which isn't something application authors will know about -- it's in the control of the user/installer -- so they won't be able to create appropriate translation files. Application authors must be able to create PO files in their applications and users of those applications must be able to use them, so a setting can't work.
comment:5 Changed 16 years ago by
Triage Stage: | Design decision needed → Someday/Maybe |
---|
comment:6 Changed 14 years ago by
Cc: | clouserw@… added |
---|
comment:7 Changed 13 years ago by
Severity: | → Normal |
---|---|
Type: | → New feature |
comment:8 Changed 13 years ago by
Needs tests: | set |
---|
comment:9 Changed 13 years ago by
Cc: | fwenzel added |
---|---|
Easy pickings: | unset |
comment:11 Changed 13 years ago by
Easy pickings: | unset |
---|
Yeah, you didn't unset it, it simply didn't have any value.
comment:13 Changed 10 years ago by
Triage Stage: | Someday/Maybe → Accepted |
---|
#20070 asked for the same feature and was accepted by Jacob.
comment:14 Changed 10 years ago by
Cc: | 4glitch@… added |
---|
comment:15 Changed 10 years ago by
Cc: | raymond.penners@… added |
---|
comment:16 Changed 8 years ago by
Cc: | Krzysztof Gutkowski added |
---|---|
Has patch: | unset |
Owner: | changed from nobody to Krzysztof Gutkowski |
Patch needs improvement: | unset |
Status: | new → assigned |
comment:17 Changed 8 years ago by
Has patch: | set |
---|---|
Needs tests: | unset |
Created a pull request: https://github.com/django/django/pull/5053
Added a setting LOCALE_FILENAMES, allowing to specify what filenames should be looked for by the internationalization system, tests, and documentation.
comment:18 Changed 8 years ago by
Created a django-developers thread to ask if a new setting is fine for this.
comment:19 Changed 8 years ago by
Patch needs improvement: | set |
---|
Claude proposed a way to avoid adding a new setting on the django-developers thread. Marking as "Patch needs improvement" in light of that.
comment:20 Changed 5 years ago by
Owner: | changed from Krzysztof Gutkowski to Rui Pereira |
---|---|
Patch needs improvement: | unset |
comment:21 Changed 5 years ago by
Patch needs improvement: | set |
---|---|
Summary: | Please don't force the usage of the 'django' gettext domain → Allow using custom gettext domains |
comment:22 Changed 5 years ago by
Patch needs improvement: | unset |
---|
comment:23 Changed 4 years ago by
Patch needs improvement: | set |
---|
Current patch:
- Allows finding translations from
LOCALE_PATHS
but notINSTALLED_APPS
. - Doesn't allow working with
makemessages
.
Not sure it meets the criteria outlined above:
Application authors must be able to create PO files in their applications and users of those applications must be able to use them
Maybe it would still be good enough to allow the external translations #20070 talks about, so perhaps we could take it as it is on that basis. (Discussion on PR.)
If so, documentation changes need some improvement.
SImple and untested patch