Closed ryelle closed 3 months ago
I'm not sure if it would've been better to abstract out the plugin directory API code and make it reusable across both (I didn't want to get that in the weeds about it), but perhaps this can be a step towards that, if we want.
I think that rest-api-locale
doesn't make sense to be shipped with the theme. At the very least, it probably makes more sense in the theme-directory plugin. I feel the same way for the rest-api
itself. I wouldn't expect routes to be registered in the theme.
Apart from that code placement, I don't have a super strong opinion as to whether we need to go back and refactor the plugin directory code but it's obviously ideal to do so.
I think that rest-api-locale doesn't make sense to be shipped with the theme. At the very least, it probably makes more sense in the theme-directory plugin. I feel the same way for the rest-api itself. I wouldn't expect routes to be registered in the theme.
I agree, generally, but here I was aiming for "moving fast", so I didn't want to create a chain of PRs and project dependencies, since the theme-directory plugin is still in meta.trac. I can move these routes over to the theme-directory plugin, though.
The other endpoints registered here are for favoriting, which are used in the favorite block - hence bundled with the theme for now. That too could possibly be extracted if we want to try a single favorite block for all the directories, but i wouldn't want to remove it unless the block moves too.
Yep understood. Can we move the locale endpoints over to the theme-directory plugin then and move forward with the rest?
Closing this as https://github.com/WordPress/wporg-mu-plugins/pull/609 created the new API endpoint. The locale banner was added to the site in https://github.com/WordPress/wporg-theme-directory/commit/a4dc92d1f4fa188b17265bf636121e4ebb256151.
Fixes #27 — This adds two API endpoints, a general
locale-banner
and a version that accepts a theme slug (e.g.,locale-banner/twentynineteen
). I've mostly mirrored the plugins endpoint, though I broke the one function into a few steps.On the homepage, the API will suggest other locales if the user has language hints in the request header. The API should never direct a person to the site they're currently on. On single themes, the API should suggest other rosetta sites only if the theme is translated into those languages.
I'm not sure if it would've been better to abstract out the plugin directory API code and make it reusable across both (I didn't want to get that in the weeds about it), but perhaps this can be a step towards that, if we want.
I also expect to reuse
get_transalated_locales
for #28.Screenshots
Hacked a bit since these strings haven't been translated yet, but this is what the banner looks like. I can update this to match the outcome of https://github.com/WordPress/wordpress.org/issues/301.
I've tested a number of cases, here are a subset.
https://wordpress.org/themes/wp-json/wporg-themes/v1/locale-banner/twentytwentytwo/?new-theme=1' -H 'Accept-Language: en-US,en;q=0.8,ko-KR;q=0.5,es-ES;q=0.3
How to test the changes in this Pull Request:
Try out various combinations of header locale (
Accept-Language
header), theme, rosetta origin site, etc. This needs a sandbox to test for the locale database.An example request, a single theme from the French rosetta site, with Spanish & Korean also suggested: