Arthur.7249:

Hello,

I’m starting to look at this APIto play with it a little and use it in my project. I was wondering if the parameter lang could have a greater effect on the API results.

Let me explain with the following exemple :

I f I look up this item :

https://api.guildwars2.com/v1/item_details.json?item_id=28445

I get the result in english wich is great but now, I want this result in French. So i use :

https://api.guildwars2.com/v1/item_details.json?item_id=28445&lang=fr

And there is the result in French (well not quite…) :

{"item_id":“28445”,“name”:“Arc solide de feu”,“description”:"",“type”:“Weapon”,“level”:“44”,“rarity”:“Masterwork”,“vendor_value”:“120”,“icon_file_id”:“65015”,“icon_file_signature”:“C6110F52DF5AFE0F00A56F9E143E9732176DDDE9”,“game_types”:[“Activity”,
“Dungeon”,
“Pve”,
“Wvw”],“flags”:[“SoulBindOnUse”],“restrictions”:[],“weapon”:{"type":“LongBow”,“damage_type”:“Physical”,“min_power”:“385”,“max_power”:“452”,“defense”:“0”,“infusion_slots”:[],“infix_upgrade”:{"attributes":[{"attribute":“Power”,“modifier”:"62"},
{"attribute":“Precision”,“modifier”:"44"}]},“suffix_item_id”:"24547"}}

See, only the name is translated, why not the other attributes like “type” or “game_types” ?
I’m sure their translation exists somewhere in ArenaNet data base. Could this be taken under consideration for future API updates ?

Thanks for reading me.

PS : Sorry if my English is bad, as you may have deduce, I’m French, wich is why I’m interested in this subject

smiley.1438:

Any other values than the name and description are for internal use only, thats why the lang parameter is basically useless in this case and some other APIs. See these proposals of mine for example:
https://forum-en.guildwars2.com/forum/community/api/The-general-suggestion-thread/2070794
https://forum-en.guildwars2.com/forum/community/api/API-Suggestion-World-vs-World/2455807

StevenL.3761:

So the question is why something like:

“type”:“Weapon”

isn’t translated to:

“type”:“Arme”

You don’t want that because you’d have multiple names to indicate the same type.

At best, this means that you’d have duplicate code for every supported language.

A more likely scenario is that an English item won’t be recognized as equal when compared to the exact same item in French.


myEnglishLongbow.type = "Weapon"

myFrenchLongbow.type = "Arme"

myEnglishLongbow.type != myFrenchLongbow.type

Arthur.7249:

Hello, thank you for your answers.

I agree I will use these information for internal purpose but what if I want to build a french versoin of http://www.gw2db.com. With custom filters on types, attributes, etc… . Then I should managed the translation myself…

As for comparing items in diferrent languages, I personnaly don’t have this need. In additon, all datas are comming from Arenanet, I’ll just use the item_id to identify them.

As you said and as I started to imagine it, I would duplicate the data for each languages, adding the lang parameter to each table of my database. For exemple, I would create a table item_types with the following structure :


item_type_id     lang        label
1                              fr             Arme
1                              en            Weapon
This would allow me to make request for diferrent languages and compare items in diferent language not by comparing the label of the type but its’ id.

I know most of the people looking into the API “speak” English (as this forum doesn’t exists in other languages) but people using apps we make may not… I’m a bit disapointed that ArenatNet isn’t going further reagarding this translation. I think it should not be to hard to give a full translation of these data.

What do you think ?

smiley.1438:

Have a look at this:

https://github.com/codemasher/gw2-database

problem solved

Arthur.7249:

Thank you but it doesn’t fit my need.

You still sotre information about types/rarity/weight in english. If i want to provide a filter on item type for french people, I dont want a drop down list with “Weapon” but with “Arme”.

Someting else bother me in your item sql script :


  `pvp` tinyint(1) unsigned NOT NULL DEFAULT '0',
  `attr1` tinytext COLLATE utf8_bin NOT NULL,
  `attr2` tinytext COLLATE utf8_bin NOT NULL,
  `attr3` tinytext COLLATE utf8_bin NOT NULL,
  `unlock_id` MEDIUMINT(6) unsigned NOT NULL DEFAULT '0',

It seems you can store only three attributes. What about celestial items ?

smiley.1438:

Thank you but it doesn’t fit my need.

It does, actually. We’re running a multilanguage search/bot edit/item database with it.

for example:

http://gw2wbot.darthmaim.de/rss/renamedItems/
http://gw2wbot.darthmaim.de/smiley/
http://gw2treasures.de/

You still sotre information about types/rarity/weight in english. If i want to provide a filter on item type for french people, I dont want a drop down list with “Weapon” but with “Arme”.

It’s a common agreement that code is usually written in english as it is easy to understand. If i had written all my code in german, you wouldn’t even understand most of it? Would you?

Why do you want to have the (internal, sometimes even uninformative, in fact: identifiers) names in your language – you can easily do this in you front end via javascript. Once again, have a look at that code and see how i solved it for 4 languages (You could even poulate the dropdown fields with localized strings with a little effort…). It’s all in here:

https://github.com/codemasher/gw2-database/blob/master/gw2itemsearch.html

Someting else bother me in your item sql script :


  `pvp` tinyint(1) unsigned NOT NULL DEFAULT '0',
  `attr1` tinytext COLLATE utf8_bin NOT NULL,
  `attr2` tinytext COLLATE utf8_bin NOT NULL,
  `attr3` tinytext COLLATE utf8_bin NOT NULL,
  `unlock_id` MEDIUMINT(6) unsigned NOT NULL DEFAULT '0',

It seems you can store only three attributes. What about celestial items ?

I stored the attribute combinations just for quick searches as most attribute combinations (to be exact: all except for celestial) consist of just 3 values. It would be an idea to also store the attribute prefix/suffix in a single column to enhance this – or you could just do a fulltext search (%…%) on the data fields where the full json response is stored.