1
0
mirror of https://github.com/django/django.git synced 2025-07-04 17:59:13 +00:00

i18n: added support for the new DEFAULT_CHARSET setting in translators

git-svn-id: http://code.djangoproject.com/svn/django/branches/i18n@788 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Georg Bauer 2005-10-06 10:07:45 +00:00
parent cb09e10eb2
commit b70beda043
2 changed files with 7 additions and 6 deletions

View File

@ -32,14 +32,15 @@ _accepted = {}
class DjangoTranslation(gettext_module.GNUTranslations):
"""
This class sets up the GNUTranslations context with
regard to output charset. Django allways uses utf-8
as the output charset.
regard to output charset. Django uses a defined
DEFAULT_CHARSET as the output charset.
"""
def __init__(self, *args, **kw):
from django.conf import settings
gettext_module.GNUTranslations.__init__(self, *args, **kw)
self.__charset = self.charset()
self.set_output_charset('utf-8')
self.set_output_charset(settings.DEFAULT_CHARSET)
self.__app = '?.?.?'
self.__language = '??'

View File

@ -304,9 +304,9 @@ in the project library, but decided against this: with message files in the
application tree, they can more easily be distributed.
Another speciality is that we only use gettext and gettext_noop - that's
because django uses allways utf-8 strings internally. There isn't much use
in using ugettext or something like that, as you allways will need to produce
utf-8 anyway.
because django uses allways DEFAULT_CHARSET strings internally. There isn't
much use in using ugettext or something like that, as you allways will need to
produce utf-8 anyway.
And last we don't use xgettext alone and some makefiles but use python
wrappers around xgettext and msgfmt. That's mostly for convenience.