Guild Wars 2

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?

Your proposal is good as it has been described, but I don’t understand why to work with more than one language simultaneously.

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.

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.

Lawton Campbell.8517:

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:

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.

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.