Fixed #7163 -- Fixed a translation-sharing problem so that you can have en-gb

and en-us at the app-level, even though Django only has an "en" translation
(for example). Analysis and patch from ognjen.maric@gmail.com.


git-svn-id: http://code.djangoproject.com/svn/django/trunk@7857 bcc190cf-cafb-0310-a4f2-bffc1f526a37

AUTHORS

@@ -280,6 +280,7 @@ answer newbie questions, and generally made Django that much better:
     Neal Norwitz <nnorwitz@google.com>
     Todd O'Bryan <toddobryan@mac.com>
     oggie rob <oz.robharvey@gmail.com>
+    oggy <ognjen.maric@gmail.com>
     Jay Parlar <parlar@gmail.com>
     Carlos Eduardo de Paula <carlosedp@gmail.com>
     pavithran s <pavithran.s@gmail.com>

django/utils/translation/trans_real.py

@@ -161,6 +161,15 @@ def translation(language):
 
         res = _translation(globalpath)
 
+        # We want to ensure that, for example,  "en-gb" and "en-us" don't share
+        # the same translation object (thus, merging en-us with a local update
+        # doesn't affect en-gb), even though they will both use the core "en"
+        # translation. So we have to subvert Python's internal gettext caching.
+        base_lang = lambda x: x.split('-', 1)[0]
+        if base_lang(lang) in [base_lang(trans) for trans in _translations]:
+            res._info = res._info.copy()
+            res._catalog = res._catalog.copy()
+
         def _merge(path):
             t = _translation(path)
             if t is not None: