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

Serve language packs depending on requested version #140

Open
ocean90 opened this issue Dec 17, 2018 · 5 comments
Open

Serve language packs depending on requested version #140

ocean90 opened this issue Dec 17, 2018 · 5 comments
Labels
[Component] API Concerns REST API Endpoints, e.g. for incoming webhooks [Type] Bug Bugs and regressions in existing functionality

Comments

@ocean90
Copy link
Member

ocean90 commented Dec 17, 2018

Issue Overview
Since #133 the version of the theme/plugin is used for the version field in the API. But the actual download URL is still the same for all versions.

Expected behavior
The path to the language pack includes the version of the language pack.

Additional context
WP.org API: https://api.wordpress.org/translations/themes/1.0/?slug=twentynineteen

@ocean90 ocean90 added [Type] Bug Bugs and regressions in existing functionality [Component] API Concerns REST API Endpoints, e.g. for incoming webhooks labels Dec 17, 2018
@swissspidy
Copy link
Collaborator

Should we try to expose all possible versions via the API?

@ocean90
Copy link
Member Author

ocean90 commented Dec 17, 2018

Good point. Only the latest version which match the requested version actually. Examples:

https://api.wordpress.org/translations/themes/1.0/?slug=twentyseventeen&version=1.0 (only 1.0)
https://api.wordpress.org/translations/themes/1.0/?slug=twentyseventeen&version=1.8 (1.0-1.8, depending on availability)

@ocean90 ocean90 changed the title Language packs are not stored by version Serve language packs depending on requested version Dec 17, 2018
@swissspidy
Copy link
Collaborator

That means we should make the version number a part of the file name or put them into folders like on WordPress.org. The latter is probably easier

Either way, I think we should add a CLI command to remove old files that can be run when upgrading. It would basically do half of what uninstall.php does.

@swissspidy
Copy link
Collaborator

Either way, I think we should add a CLI command to remove old files that can be run when upgrading

We could extend wp traduttore cache clear for that.

For running the complete uninstall routine there is wp plugin uninstall.

@swissspidy
Copy link
Collaborator

Only the latest version which match the requested version actually. Examples:

Hmm, sounds like we need to store a list of language packs per project in gp_meta or something. Otherwise we have no idea what kind of files there are on the server.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Component] API Concerns REST API Endpoints, e.g. for incoming webhooks [Type] Bug Bugs and regressions in existing functionality
Projects
None yet
Development

No branches or pull requests

2 participants