Open coreyar opened 1 week ago
Hello.
Why do you want to change field labels? Give some examples, please.
And what other options have you considered?
The client would like the labels to have the full language rather than the language code.
I ended up overriding the verbose_name in formfield_for_dbfield
but it s a bit of a hack.
Yeah.
Well, let's make it happen. If you would prepare PR, I'll review and merge it.
But, maybe we should not touch TranslationOption
.
Maybe we should add a setting, like
BUILD_LOCALIZED_VERBOSE_NAME = "modeltranslation.utils.short_localized_verbose_name" | "modeltranslation.utils.long_localized_verbose_name"
And use from django.utils.module_loading import import_string
to load this function.
(This is only suggestion, if you think of better option, let's hear it)
Currently Translation fields are set with a verbose name of the model name and appended with the translation language code in brackets.
It would be nice to be able to customize the verbose name. I wasn't able to find a nice way to do this. I ended up overriding
formfield_for_dbfield
checking for aninstanceof TranslationField
and modifying the verbose name.The library creates the verbose name using
build_localized_verbose_name
which is used inbuild_localized_intermediary_model
andTranslationField
.I think this would make sense to add to the TranslationOption. Looking at the current shape of the options there isn't an obvious way to add a custom verbose name.
With the custom verbose name option,
TranslationField
can use this when set and fallback tobuild_localized_verbose_name
. This should also work forbuild_localized_intermediary_model
because the options are ready during lazy registration.If this is interesting I am happy to implement once the update to TranslationOption is confirmed