Opened 17 years ago

Last modified 4 months ago

#6376 assigned New feature

Allow using custom gettext domains

Reported by: dennis@… 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)

gettext_domain.patch (1.7 KB ) - added by dennis@… 17 years ago.
SImple and untested patch

Download all attachments as: .zip

Change History (25)

by dennis@…, 17 years ago

Attachment: gettext_domain.patch added

SImple and untested patch

comment:1 by Bastian Kleineidam <calvin@…>, 17 years ago

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 by anonymous, 17 years ago

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 by Simon Greenhill <dev@…>, 17 years ago

Has patch: set
Patch needs improvement: set
Triage Stage: UnreviewedDesign decision needed

comment:4 by Malcolm Tredinnick, 17 years ago

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 by Malcolm Tredinnick, 17 years ago

Triage Stage: Design decision neededSomeday/Maybe

comment:6 by Wil Clouser, 15 years ago

Cc: clouserw@… added

comment:7 by Julien Phalip, 14 years ago

Severity: Normal
Type: New feature

comment:8 by Julien Phalip, 14 years ago

Needs tests: set

comment:9 by fwenzel, 14 years ago

Cc: fwenzel added
Easy pickings: unset

comment:10 by fwenzel, 14 years ago

Easy pickings: set

sorry, didn't mean to unset "easy pickings".

comment:11 by Jannis Leidel, 14 years ago

Easy pickings: unset

Yeah, you didn't unset it, it simply didn't have any value.

comment:12 by Aymeric Augustin, 13 years ago

UI/UX: unset

Change UI/UX from NULL to False.

comment:13 by Ramiro Morales, 11 years ago

Triage Stage: Someday/MaybeAccepted

#20070 asked for the same feature and was accepted by Jacob.

comment:14 by 4glitch@…, 11 years ago

Cc: 4glitch@… added

comment:15 by Raymond Penners, 11 years ago

Cc: raymond.penners@… added

comment:16 by Krzysztof Gutkowski, 9 years ago

Cc: Krzysztof Gutkowski added
Has patch: unset
Owner: changed from nobody to Krzysztof Gutkowski
Patch needs improvement: unset
Status: newassigned

comment:17 by Krzysztof Gutkowski, 9 years ago

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.

Last edited 9 years ago by Krzysztof Gutkowski (previous) (diff)

comment:18 by Tim Graham, 9 years ago

Created a django-developers thread to ask if a new setting is fine for this.

comment:19 by Tim Graham, 9 years ago

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 by Rui Pereira, 6 years ago

Owner: changed from Krzysztof Gutkowski to Rui Pereira
Patch needs improvement: unset

comment:21 by Tim Graham, 6 years ago

Patch needs improvement: set
Summary: Please don't force the usage of the 'django' gettext domainAllow using custom gettext domains

comment:22 by Rui Pereira, 5 years ago

Patch needs improvement: unset

comment:23 by Carlton Gibson, 5 years ago

Patch needs improvement: set

Current patch:

  • Allows finding translations from LOCALE_PATHS but not INSTALLED_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.

comment:24 by Timid Robot Zehta, 4 months ago

The Creative Common (CC) legal tools (636 licenses and 3 public domain tools) require multiple distinct translation domains so that we can have different workflows for legal text (high friction/gatekeeping) and non legal text (low friction/gatekeeping):

We have a functional workaround (i18n/utils.py#L67-L138) but it manipulates the private _active variable, which seems fragile to me. Proper support for being able to specify a translation domain would very helpful.

Related repositories:

Note: See TracTickets for help on using tickets.
Back to Top