Skip to content

Talk submission type is not always localized in API #945

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

Closed
twavv opened this issue Jun 8, 2020 · 4 comments
Closed

Talk submission type is not always localized in API #945

twavv opened this issue Jun 8, 2020 · 4 comments
Labels
size: small Easy and/or quick to do stage: blocked Can't be worked on right now type: bug Needs fix

Comments

@twavv
Copy link

twavv commented Jun 8, 2020

Current Behavior

Currently, querying talks from the API results in either an object with text for various localizations or a plain string (in my experience, using JuliaCon 2019, only the "talk" type is a plain string, everything else is an object with an "en" key).

Expected Behavior

The type of submission_type should be consistent.

Steps to Reproduce

# Real, publicly available data
curl https://pretalx.com/api/events/juliacon2019/talks?offset=25
{
    "count": 156,
    "next": "https://pretalx.com/api/events/juliacon2019/talks/?limit=25&offset=50",
    "previous": "https://pretalx.com/api/events/juliacon2019/talks/?limit=25",
    "results": [
        {
            "code": "YZPSDK",
            ...
            "submission_type": {
                "en": "Lightning Talk"
            },
            ...
        },
        ...
        {
            "code": "8AM9JC",
            ...
            "submission_type": "Talk",
            ...
        },
        ...
    ]
}
@rixx
Copy link
Member

rixx commented Jun 8, 2020

Thank you for bringing this up! This is definitely unexpected/buggy behaviour.

This is due to the behaviour of the library django-i18nfield that we use for internationalisation. We're looking to get a fix for this issue worked into the library, and will then pull it into pretalx.

@rixx rixx added type: bug Needs fix size: small Easy and/or quick to do stage: blocked Can't be worked on right now labels Jun 8, 2020
@oxinabox
Copy link
Contributor

oxinabox commented Jun 8, 2020

@travigd this is one of the things that Pretalx.jl does; normalize that field.

@rixx
Copy link
Member

rixx commented Jun 8, 2020

@oxinabox If you encounter bugs in pretalx like that, it would be very helpful to the project if we knew about them, so that we can fix them – bug reports are welcome.

@oxinabox
Copy link
Contributor

oxinabox commented Jun 9, 2020

I didn't really click that it was a bug.
Thought it was a feature I was using wrong

@rixx rixx closed this as completed in 0e1dc54 Jun 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
size: small Easy and/or quick to do stage: blocked Can't be worked on right now type: bug Needs fix
Projects
None yet
Development

No branches or pull requests

3 participants