#26337: Translations - No fallback used if requesting english variant
-------------------------------------+-------------------------------------
     Reporter:  cristianocca         |      Owner:  nobody
         Type:  Bug                  |     Status:  new
    Component:                       |    Version:  1.9
  Internationalization               |   Keywords:  i18n translations
     Severity:  Normal               |  english
 Triage Stage:  Unreviewed           |  Has patch:  0
Easy pickings:  0                    |      UI/UX:  0
-------------------------------------+-------------------------------------
 This a new ticket raised by an issue noticed while reporting #26328.

 The issue is exactly at this line
 
https://github.com/django/django/blob/master/django/utils/translation/trans_real.py#L190

 And it is currently done this way because django translations does not
 define values for english variants (see issue
 https://code.djangoproject.com/ticket/24413 ) because message ids are
 enough, and such, if fallback language was to be used, all english
 translations from django would fail when the default language is not
 english resulting in incorrect translations all over the place.

 Now the ticket above fixed the issue for django english translations, but
 actually creates a new issue (the one reported in this ticket).

 The issue is then that if you are using an non english default language
 and expect it to be used when an english translation is requested (ie you
 don't have any english translation at all at your app or parts of it are
 missing), all your translated text will then fallback to the message id
 rather than the actual default language translation (which may be
 different than the message id).

 How to fix this? Well, no idea! The best bet would be to make sure all
 translations values are always added rather than relying on message ids as
 defaults and remove the english check, but that would mean going through
 all translations for english variants implemented by django and django
 apps, plus there might be people relying on the same special english
 treatment.

 Another fix that involves no code changes is to at least have it
 documented that you should have always a translation (and with values)
 file for english for all your apps otherwise you may get unexpected
 results when using non english as default.

 The last idea but quite complicated, is to mark translation po files in a
 way that the compiler would then compile it setting the translation value
 the same as the message id and such the english check can be removed and
 django translations would still work (however django translation files
 should be marked)

 Final note: This might not be really important, since most of the time if
 you are using translations, english will be one of them, and you will
 always have translation values if the default language is not the default,
 so this issue would not exist as long as this is always true.

--
Ticket URL: <https://code.djangoproject.com/ticket/26337>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/055.442898292897eb197efbfce23b86b5cd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to