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

Force localisation to english #207

Closed
gdec31 opened this issue Nov 24, 2023 · 5 comments
Closed

Force localisation to english #207

gdec31 opened this issue Nov 24, 2023 · 5 comments

Comments

@gdec31
Copy link

gdec31 commented Nov 24, 2023

Hello,

I have my open api explorer that works well, thank for all contributor.

My API documentation is only in english and, if I configured my browser to support the french localisation (i'm french), I have my openapi explorer mixed between french and english. I just want to have the english locale.

Is it possible to have an option to force the usage of a localisation ?

@wparad
Copy link
Member

wparad commented Nov 24, 2023

Hmmm, that's a good point. While we wouldn't want to have a setting to do this, it does make sense to try to source the language of the spec from the spec itself. Does the openapi spec contain a property that specifies the language/locale of the spec?

@gdec31
Copy link
Author

gdec31 commented Nov 24, 2023

There seems to be no solution yet in the openapi spec :
OAI/OpenAPI-Specification#274

A possible solution could be to use the overlay OAI/Overlay-Specification#36

@wparad
Copy link
Member

wparad commented Nov 24, 2023

I don't think an overlay is necessarily the best approach here, it would be a trade-off with just adding a custom vendor field.

Actually looking at OAI/OpenAPI-Specification#70, I saw the suggestion of potentially using the Accept-Language and Content-Language headers. Some more thought might need to go into that, but that starts to feel like the potentially right direction.

The Argument being, the navigator tells your spec which languages to select, and then your spec language header controls the actual display on our side.

I totally agree having part of the spec in one language and the rest of the spec in another doesn't make sense. So I do want to say this issue will be dealt with as soon as it seems like there is a good path forward here.

@wparad
Copy link
Member

wparad commented Nov 27, 2023

Given that the library accepts both urls and spec objects, requiring use of a response Content-Language might not be feasible. That means the best solution here would be to introduce a vendor extension. I'm not sure what the best name is or at the moment where it should go. But in any case we would more than happy to accept a PR including the processing of that value.

@wparad wparad closed this as completed in ecac6c7 Dec 27, 2023
wparad added a commit that referenced this issue Dec 27, 2023
…fication

Allow specifying the locale of the spec. fix #207
@wparad
Copy link
Member

wparad commented Dec 27, 2023

This is now supported via the info.x-locale property in the latest version of the library.

splitbrain added a commit to dokuwiki/dokuwiki that referenced this issue Jan 5, 2024
splitbrain added a commit to dokuwiki/dokuwiki that referenced this issue Jan 7, 2024
splitbrain added a commit to dokuwiki/dokuwiki that referenced this issue Jan 7, 2024
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

No branches or pull requests

2 participants