Skip to content
This repository has been archived by the owner on Jul 8, 2023. It is now read-only.

auto creation of translated fields #164

Open
w4mike opened this issue Jan 19, 2023 · 5 comments
Open

auto creation of translated fields #164

w4mike opened this issue Jan 19, 2023 · 5 comments

Comments

@w4mike
Copy link

w4mike commented Jan 19, 2023

Hi,

I just started a private project using django with strawberry-django-plus.

I would like to use django-translated-fields for translation of some fields in this project.
The reason why I want to use this project is, because it does not introduce too much overhead.
However, I have a glue how to create a field and a resolver for the translated fields, but I would like to also 'automagically' add the fields per language created by this project in the model to the type definition in my strawberry schema.

Can you give me a hint how to do it ?

This would also probably solve my problem when I later want to introduce django-pghistory, where I need to create new types for the history events.

Appreciate all help and answers.

Thanks,
mike

@bellini666
Copy link
Member

Hey @w4mike ,

I can see 3 options here:

  1. You can use custom resolvers for each field that open an override context and resolves the field

  2. You can subclass StrawberryDjangoField and override the get_result, calling super() inside an override context. Then you would use your own field in your types definition

  3. You can write a custom extension that enters the context when the request starts and exists it when it ends: https://strawberry.rocks/docs/guides/custom-extensions (or even for each field individually)

@w4mike
Copy link
Author

w4mike commented Jan 24, 2023

Hi @bellini666 ,

many thanks for your reply.

I will have a look into the three options. For now option 2 and 3 look most promising to me.

Is there a way to extend the field lookup, so I can use field_name: auto ?

How would I get the StrawberryDjangoType inside the constructor of StrawberryDjangoField to add the fields field_name_en, field_name_de, field_name_nl , etc. programmatically ?

Thx,
mike

@bellini666
Copy link
Member

You can define them as functions and get the model using the root parameter. You can even get the argument for the translation as an argument instead of having to define one for each language.

For example:

@gql.django.type(SomeDjangoModel)
class SomeDjangoType:
    @gql.django.field
    def translatable_field(self, root: SomeDjangoModel, lang: str = "en"):
        with override(lang):
            return root.translatable_field

@bellini666
Copy link
Member

In the example above, you can query it like:

someDjangoType {
    translatableField
    translatableFieldEn: translatableField(lang: "en")
    translatableFieldDe: translatableField(lang: "de")
    ...
}

@w4mike
Copy link
Author

w4mike commented Feb 22, 2023

Hi @bellini666 ,

many thanks for your input.
Works like a charm.

I have written an external resolver which I can reuse for any translated field.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants