Proposal: New optional parameter ?langs=
Zok.4956:
When I want to get the Name of an item (as an example) in different languages, I have to make an extra API request for every language in the same request.
Example:
https://api.guildwars2.com/v2/items/28445?lang=en
https://api.guildwars2.com/v2/items/28445?lang=de
https://api.guildwars2.com/v2/items/28445?lang=fr
https://api.guildwars2.com/v2/items/28445?lang=es
To make 4 requests and get all the data 4-times just for the different names seems inefficient for me.
My proposal: We introduce a new optional parameter “langs” that asks for different languages in one data-record/request. If “langs” is not set everything will be like it is now. But if “langs” is set the language dependent fields will be put in an sub-array.
Example:
https://api.guildwars2.com/v2/items/28445?langs=en,de,fr,es
Gives something like (not all fields included …):
[id] = 28455
[lang] = Array
(
[en] = Array
(
[name] = Strong Soft Wood Longbow of Fire
[description] =
)
[de] = Array
(
[name] = Starker Geschmeidiger Holz-Langbogen des Feuers
[description] =
)
[fr] = Array
(
[name] = Arc long en bois tendre solide de feu
[description] =
)
[es] = Array
(
[name] = Arco largo de madera blanda de fuego fuerte
[description] =
)
)
[type] = weapon
What do you think?
Elfo Bianco.3786:
Your proposal is good as it has been described, but I don’t understand why to work with more than one language simultaneously.
Lawton Campbell.8517:
Your proposal is good as it has been described, but I don’t understand why to work with more than one language simultaneously.
It would make it take fewer requests to pull e.g. /v2/items into a local database.
It’s not a bad idea but it would require more refactoring than I have spare time for, I think.
Zok.4956:
Your proposal is good as it has been described, but I don’t understand why to work with more than one language simultaneously.
I put the API-data (i.e. items) in a local database that serves the webrequests of local users (that could use the system in more than language), so I have to store the several languages in the database.
Storing the data in a local database (and regularly check the API for updates/changes) gives additional information, i.e. I have “first seen” and “last changed” database-timestamp fields for items and other API-data.
Zok.4956:
It’s not a bad idea but it would require more refactoring than I have spare time for, I think.
OK, I understand that. As long as the API-server has enough free ressources, this optimization is only kind of “nice to have” from my point of view.
Zok.4956:
Your proposal is good as it has been described, but I don’t understand why to work with more than one language simultaneously.
I put the API-data (i.e. items) in a local database that serves the webrequests of local users (that could use the system in more than language), so I have to store the several languages in the database.
Storing the data in a local database (and regularly check the API for updates/changes) gives additional information, i.e. I have “first seen” and “last changed” database-timestamp fields for items and other API-data.
Another advantage to serve the requests of web-users from a local database is: The website still works even when the API is down.