Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#24739 closed Bug (fixed)

Document translation fallback behavior change in 1.8

Reported by: Nicola Owned by: nobody
Component: Internationalization Version: 1.8
Severity: Release blocker Keywords:
Cc: Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I updated from 1.7 to 1.8

in my templates and python code I have string in my native language (italian),

so my po files look likes this:

1) locale en

msgid "original string in italian"
msgstr "english translated string"

2) locale it

msgid "original string in italian"
msgstr ""

now in settings I have:

LANGUAGE_CODE = 'en'

my browser is in italian so request.LANGUAGE_CODE is "it"

in django <1.8 the fallback translation is taken from the it po file, in django 1.8+ en translation is used since my default LANGUAGE_CODE is "en", if I set LANGUAGE_CODE to "it" the fallback string from it po file is used

Change History (8)

comment:1 Changed 3 years ago by Tim Graham

Severity: NormalRelease blocker
Summary: 1.7 => 1.8 i18n behaviour changeUndocumented i18n behavior change in 1.8 (or a regression)
Triage Stage: UnreviewedAccepted
Type: UncategorizedBug

Reproduced and bisected to a5f6cbce07b5f3ab48d931e3fd1883c757fb9b45.

comment:2 Changed 3 years ago by Claude Paroz

Apart from the unexpected change, isn't the new behavior the most correct?

Maybe you might check that master keeps this behavior, as [3cf1c02695481900] touched this part of the code. But at first sight, it shouldn't affect the use case you described.

comment:3 Changed 3 years ago by Nicola

New behaviour:

  • if a string is not translated for a locale django use the translated string (if any) from the default locale

Old behaviour:

  • if a string is not translated for a locale django use the untranslated string for the same locale

what is most correct is an opinion, I like the old behaviour since all untranslated strings should be equals,

your opinion could be that an untranslated string should show the value for the default locale and not the untranslated one

however is easy enouth to use a tool like poedit to copy all the translations from the original string, so if you like more the new behaviour is just a matter to document it

Last edited 3 years ago by Nicola (previous) (diff)

comment:4 Changed 3 years ago by Tim Graham

Claude, could you propose a patch (docs or otherwise) at your convenience?

comment:5 Changed 3 years ago by Claude Paroz

#24503 was partially related.

What about:

  • docs/releases/1.8.txt

    diff --git a/docs/releases/1.8.txt b/docs/releases/1.8.txt
    index fb0438a..c5f3e72 100644
    a b Miscellaneous 
    11591159* :func:`django.utils.translation.get_language()` now returns ``None`` instead
    11601160  of :setting:`LANGUAGE_CODE` when translations are temporarily deactivated.
    11611161
     1162* When a translation doesn't exist for a specific literal, the fallback is now
     1163  taken from the :setting:`LANGUAGE_CODE` language (instead of the untranslated
     1164  ``msgid`` message).
     1165
    11621166* The ``name`` field of :class:`django.contrib.contenttypes.models.ContentType`
    11631167  has been removed by a migration and replaced by a property. That means it's
    11641168  not possible to query or filter a ``ContentType`` by this field any longer.

comment:6 Changed 3 years ago by Tim Graham

Has patch: set
Summary: Undocumented i18n behavior change in 1.8 (or a regression)Document translation fallback behavior change in 1.8
Triage Stage: AcceptedReady for checkin

I'd suggest "instead of from the" -- otherwise, good!

comment:7 Changed 3 years ago by Claude Paroz <claude@…>

Resolution: fixed
Status: newclosed

In 1046c8af:

Fixed #24739 -- Documented translation fallback change

Refs #24503.

comment:8 Changed 3 years ago by Claude Paroz <claude@…>

In 7915cbb:

[1.8.x] Fixed #24739 -- Documented translation fallback change

Refs #24503.
Backport of 1046c8afec from master.

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