Are there ways I can get a Pokemon's Pokedex entry description? I've tried looking in the API documentation to come with no avail. The closest thing I could find was a Pokedex JSON but even that didn't contain the Pokemon's PD entry description alongside with Pokemon Species. Unless I didn't look hard enough do you know where I can fetch a Pokemon's dex entry description?
Thanks
I guess you missed the flavor-text-entries in apiv2.
This is for pikachu
GET https://pokeapi.co/api/v2/pokemon-species/25
A part of the output
{
"flavor_text": "It has small electric sacs on both its\ncheeks. If threatened, it looses electric\ncharges from the sacs.",
"language": {
"name": "en",
"url": "https://pokeapi.co/api/v2/language/9/"
},
"version": {
"name": "firered",
"url": "https://pokeapi.co/api/v2/version/10/"
}
}
Similarly it's available for other game versions as well.
to add onto #Rinkesh P's answer, you can replace the '\n's with spaces. The '\n' is actually an escape sequence in ASCII. It's mainly used in programming languages such as C, Pearl, and Java. But in most cases, you're probably just gonna load up the description and display it in HTML --So just write up a function to replace it with a space(' ').
Related
After integrating the Google DLP API, the ListInfoTypes() currently returns the name, description, supported types of the infotypes present in the infotypes reference. Is it possible to also obtain the region for the infotypes like "Australia" or "Argentina" as a seperate field?
Currently this is my output:
"name": "AUSTRALIA_MEDICARE_NUMBER",
"displayName": "Australia medicare number",
"supportedBy": [
"INSPECT"
],
"description": "A 9-digit Australian Medicare account
I need the Region as well for example Region: "Australia" for every other infotypes.
I also got around to see locations.infoTypes.list() but I'm not sure which location I should enter in the filter to get any value.
Looking at the REST API there doesn't appear to be identifying data that can be formally used to determine the region. If we look at the InfoTypeDescription JSON structure found here:
https://cloud.google.com/dlp/docs/reference/rest/v2/ListInfoTypesResponse#InfoTypeDescription
we see that "name" is described as an "internal name of the InfoType". I wondered if we could depend on a structure of the string ... perhaps (.)*_.* as a regular expression grouping. While this might work, it shouldn't be relied upon without investigation of more samples and the docs don't describe the structure.
If you really need a solution, my recommendation would be to dump ALL the InfoTypes and then manually group the "name" fields into the regions of interest to you. You could then store this as CSV or JSON and have a reference piece of data that you could use in your app and regenerate as needed.
It's a great feature request I'll forward to the team. In the short term you can hack the name as ones that are regional will say they are in their name.
I am working on Schema.org Resort schema for a ton of resorts on a travel website and am trying to find the most efficient ways of filling out the schema with regards to amenities.
The current code looks something like this:
"amenityFeature": [
{
"#type":"http://schema.org/LocationFeatureSpecification",
"name":"Spa",
"value":"true"
},
{
"#type":"http://schema.org/LocationFeatureSpecification",
"name":"Internet Access",
"value":"true"
},
{
"#type":"http://schema.org/LocationFeatureSpecification",
"name":"Tennis Courts",
"value":"true"
}
]
My question is, can I write it like this instead to shorten lines of code:
{
"#type":"http://schema.org/LocationFeatureSpecification",
"name":[
"Spa", "Internet Access", "Tennis Courts"
],
"value":"true"
}
When I test it in Google’s Structured Data Testing Tool, it doesn’t give any errors. Here is what it looks like in the SDTT when I write it the short way:
And here is what it looks like if I do it the first/long way:
If I do it the short way, I want to make sure all those items are getting listed as amenities and not just different names for the same amenity. Otherwise, I'll go the long route.
No, each LocationFeatureSpecification represents one feature:
Specifies a location feature by providing a structured value representing a feature of an accommodation as a property-value pair of varying degrees of formality.
Your second snippet would represent one feature with multiple names.
I have an entity called #spare_part and this entity has 4 values with the following example synonyms each:
both with synonyms filter, oil level indicator
not_defined with a synonym spare part
only_gear with synonyms valve, seal
whole_gear_box with a synonym complete set of gearbox
I want to be able to handle multiple entities given in the same input and address them later on, if needed. With this purpose I have coded the following in JSON editor:
{
"context": {
"sparepartrequest": "#spare_part.values"
},
"output": {
"generic": [
{
"values": [
{
"text": "You want an offer for the following parts: <?
$sparepartrequest.join(', ') ?>."
}
],
"response_type": "text",
"selection_policy": "sequential"
}
]
}
}
I have created a context variable called sparepartrequest as can be seen from the code lines above. For instance when the user says "I want an offer for a filter and a seal", the output of the bot is the following sentence:
You want an offer for the following parts: both, only_gear.
I don´t want the bot to prompt back the names of the values of the entity #spare_part, I rather want it to store the exact input of the user, for our case which would be filter and seal. So if the bot worked as I wanted it to, the output would look like the following:
You want an offer for the following parts: filter, valve.
Again, I believe that this can be handled with JSON Editor. Thank you !
Use two context variables. sparepartrequest as already done and sparepartrequest_literals as follows:
"sparepartrequest_literals":"<? entities['spare_part'].![literal].join(', ') ?>".
Then, in your text response call it by $sparepartrequest_literals to print the mentioned parts or use $sparepartrequest to refer to the detected values.
Hi I have a field in a user collection called "Address".User saving their address from a textarea in my application. mongodb convert it to new line like following.
{
"_id": ObjectId("56a9ba0ffbe0856d4f8b456d"),
"address": "HOUSE NO. 3157,\r\nSECTOR 50-D",
"pincode": "",
},
{
"_id": ObjectId("56a9ba0ffbe0856d4f8b456d"),
"address": "HOUSE NO. 3257,\r\nSECTOR 50-C",
"pincode": "",
}
So now When I am running a search query on the basis of "address".Like following:
guardianAdd = $dm->getRepository('EduStudentBundle:GuardianAddress')->findBy(array(
'address' => new \MongoRegex('/.*' .$data['address'] . '.*/i'),
'isDelete' => false
));
echo count($guardianAdd);die;
it does not give any result. My Searchi key word is : "HOUSE NO.3157 SECTOR 50-D".
However if I am searching using like: HOUSE NO. 3157 its giving correct result.
Please advice how to fix this.Thanks in advance
First of all, trailing .* are redundant. regexps /.*aaa.*/ and /aaa/ are identical and match the same pattern.
Second, you probably need to use multiline modifier /pattern/im
Finally, it is not quite clear what you want to fix. The best think you can do is to provide some basic explanation of regex syntax in the search form, so users can search properly, e.g. HOUSE NO.*3157.*SECTOR 50-D to get best results.
You can make some bold assumptions and build the pattern with something like
$pattern = implode('\W+',preg_split('/\W+/', $data['address']))
which will give you a regexp HOUSE\W+NO\W+3157\W+SECTOR\W+50\W+D for different kind of HOUSE NO.3157 SECTOR 50-D requests, but it will cut all the regex flexibility available with bare input, and eventually will result with unexpected response anyway. You can follow this slippery slope and end up with your own query DSL to compile to regex, but I doubt it can be any better or more convenient than pure regex. It will be more error prone for sure.
Asking right question to get right answers is true not only on SO, but also in your application. Unfortunately there is no general solution to search for something that people have in mind, but fail to ask. I believe that in your particular case best code is no code.
I have a content like:
"emailAddress":"akashu87#gmail.com","UserName":"Akash Udupa","active":true,"emailAddress":"coolrohit#rediffmail.com","UserName":"Rohit Hegde","active":true,"emailAddress":"manohar_k#rediffmail.com","UserName":"Manohar Karnam","active":true,"emailAddress":"satishgk#hotmail.com","UserName":"Satish GK","active":true
I want to display only the values of UserName in CSV file through PERL like the following:
Akash Udupa
Rohit Hegde
Manohar Karnam
Satish GK
I am sure you guys will ask me what I have tried. Problem is I am very new to PERL. So can anyone help me with perl code? Please.
Thanks in advance.
There are two ways to do this; the right way, and the fragile way. Since your JSON has its braces and brackets stripped away, you've already started down the path to the fragile way:
my $string = q{"emailAddress":"akashu87#gmail.com","UserName":"Akash Udupa","active":true,"emailAddress":"coolrohit#rediffmail.com","UserName":"Rohit Hegde","active":true,"emailAddress":"manohar_k#rediffmail.com","UserName":"Manohar Karnam","active":true,"emailAddress":"satishgk#hotmail.com","UserName":"Satish GK","active":true};
while ( $string =~ m/"UserName"\s*:\s*"([^"]+)"/g ) {
print "$1\n";
}
This anchors to the "UserName" tag, and allows whitespace (but does not require it) between the tag and its value. It then looks for a double-quote, and captures everything until the next quote into $1.
A brief introduction to Perl's regexes is contained in perlrequick, which comes with Perl. My regex solution doesn't use any constructs not explained in that document. As a matter of fact, perlintro, which should be considered required reading for Perl users, provides information sufficient to this task.
Since it's possible that the logic that stripped away the JSON might have broken something, and since the JSON might possibly throw something at you that our one-off regular expression isn't equipped to handle, it would be wise to revert to the original un-adulterated JSON, and parse it with a proper parser, like this:
use JSON;
my $json = <<'EOJSON';
[
{
"emailAddress": "akashu87#gmail.com",
"UserName": "AkashUdupa",
"active": true
},
{
"emailAddress": "coolrohit#rediffmail.com",
"UserName": "RohitHegde",
"active": true
},
{
"emailAddress": "manohar_k#rediffmail.com",
"UserName": "ManoharKarnam",
"active": true
},
{
"emailAddress": "satishgk#hotmail.com",
"UserName": "SatishGK",
"active": true
}
]
EOJSON
print "$_->{UserName}\n" for #{decode_json($json)}
If the JSON module is too heavy-weight for you, look at JSON::Tiny, which is minimal, well tested, and free of dependencies.
Both the regex and the parser approach will work with the original JSON, so you may find that your code can be simplified by just eliminating the section that strips brackets and braces from the original JSON. Once you've done that, the JSON parser solution can be one line of code. It's a lucky day when removing code can make the code more robust without removing features.