Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Customize field label #768

Open
coreyar opened this issue Nov 24, 2024 · 4 comments · May be fixed by #770
Open

Customize field label #768

coreyar opened this issue Nov 24, 2024 · 4 comments · May be fixed by #770

Comments

@coreyar
Copy link

coreyar commented Nov 24, 2024

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 an instanceof TranslationField and modifying the verbose name.

The library creates the verbose name using build_localized_verbose_name which is used in build_localized_intermediary_model and TranslationField.

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 to build_localized_verbose_name.
This should also work for build_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

@last-partizan
Copy link
Collaborator

Hello.

Why do you want to change field labels? Give some examples, please.

And what other options have you considered?

@coreyar
Copy link
Author

coreyar commented Dec 1, 2024

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.

@last-partizan
Copy link
Collaborator

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)

@coreyar
Copy link
Author

coreyar commented Dec 4, 2024

I took a look and I think that adding it to the TranslationOption makes the most sense.

The default method would be

def get_verbose_name(self, verbose_name, language):
        return build_localized_verbose_name(verbose_name, language)

and then the change to the TranslationField

- self.verbose_name = build_localized_verbose_name(translated_field.verbose_name, language)
+ self.verbose_name = trans_opts.get_verbose_name(translated_field.verbose_name, language)

The other place this affects is in build_localized_intermediary_model where I can add getting the options to access the correct function for getting the verbose_name. Maybe we need a second for the plural verbose name.

I think TranslationOptions makes the most sense and is also logical for updating the documentation.

@coreyar coreyar linked a pull request Dec 4, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants