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

2 files changed, 7 insertions, 6 deletions

diff --git a/django/utils/translation.py b/django/utils/translation.py
index a74bd06c71..ba64e76d68 100644
--- a/django/utils/translation.py
+++ b/django/utils/translation.py
@@ -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 = '??'
     
diff --git a/docs/translation.txt b/docs/translation.txt
index 5f63abdc09..e0a6531ba8 100644
--- a/docs/translation.txt
+++ b/docs/translation.txt
@@ -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.