Open
Conversation
The original field might not be in the fallback chain. `__get__()` falls
back to the original field if all else fails, so it may be surprising
that `instance.field_i18n` falls back to the original field but
`Model.objects.values_list('field_i18n')` does not.
Note that this change might break existing applications.
…cate fields Cover two cases that were previously broken: - ForeignKey kwargs passed as attname (e.g., organization_id) instead of field name (organization) when constructing from serialized data - Both original field and translated virtual field for the default language present in kwargs simultaneously (e.g., from deserialized data)
When model instances are constructed from serialized data, ForeignKey fields may be passed using their column name (attname, e.g., category_id) rather than the field name (category). Add _resolve_fk_object() to look up the related object so that default_language_field traversal works in this case. Also fix the duplicate-field guard: when both the original field and a translated virtual field for the default language are present with compatible (equal or both-falsy) values, silently prefer the original field value instead of raising ValueError. This situation arises naturally when deserializing data that includes redundant virtual fields.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
So far, modeltrans assumed that the value of an original field (a translatable field when used without a language suffix; for example
title, but nottitle_nl) is in the Django default language, which is the one specified by the settingLANGUAGE_CODE. Translations to any other language will be stored in the model's implicitly generated JSON field.In some cases, it may be desired to use per-record default languages instead of a single global default language. For example, for a model for organizations from different parts of the world, each instance has a name that is in the respective local language and it may be desired to use this local-language name by default instead of storing it in the JSON field and leaving the original field empty for potentially many instances.
This PR adds an argument
default_language_fieldtoTranslationFieldthat allows users to refer to a field that specifies the language of the original field. The default language field can be either in the same instance or in another reachable via foreign keys using the__syntax.Example:
Now, no matter the
LANGUAGE_CODEsetting, for both of the following instances thenamefield will contain the localname and the JSON field
i18nwill be empty:In addition, the names are also available in
amsterdam.name_nlandhelsinki.name_fi.Please see the documentation for this feature (
docs/pages/working-with-models.rst) for some caveats.In particular, changing the default language is not supported at the moment because it's nontrivial when
__is used indefault_language_field, but if there is interest in that I could try writing some code for that as well.I also found what could be considered a bug in modeltrans (issue #84). So far, the current PR fixes it when
default_language_fieldis used, but it doesn't change the behavior whendefault_language_fieldis not used in order to keep the behavior the same for existing applications. Perhaps it would be a good idea to make this the default behavior, however.I'm happy to receive feedback and make some changes if needed.