Weather Skins Not Working

[balala]

No problem - I'm glad it worked. Put it to the test as many times as you want, as this will no doubt lead to a better implementation, if by any chance there are still issues with the approach. There shouldn't be however, unlike the V1 code, which indeed worked only for small Unicode intervals.

No, there were no problems at all, at least not from my point of view. I'm using the substitutions for the Romanian and Hungarian characters, but at least those are perfectly alright. They are working so far, so I'm gonna use the substitutions given by your code.
Excelent work. I'm amazed by it.
Many - many congratulations again.

Too bad I didn't come up with this automated code a couple of years earlier though, when I built my own "decoder substitute" that handled multiple encodings in HTML (something that DecodeCharacterReference doesn't handle), but then, it's not like I manually built that one either - I just used some Notepad++ regex replacements on a wiki list of Unicode characters instead.

Don't worry. Better later, than never, I suppose.

P.S. Don't forget to delete the last comma from the sustitute, when using it - I could have bothered with doing that automatically as well, but didn't.

This is not a problem. It has to be done only once, so it's alright.

[JohnBurns]

I'm so stupid, I don't seem to be able to apply the changes properly to make them work....guess I need to find alternate way to put skins on my pc's. Oh, well that seems to be the way life is going for me in todays' life.

[Yincognito]

Excelent work. I'm amazed by it.

Nah, you're too kind. It was no big deal, I had the decimal to another base code already built (the kind of code that jsmorley used to call "hideously complicated" because they conflicted with his beloved Lua alternative, LOL - but apparently those bits come handy in situations like these one), it was just a matter of adding decimal base iteration and joining the substitute pairs to it, so the easiest part.

I'm using the substitutions for the Romanian and Hungarian characters, but at least those are perfectly alright. They are working so far, so I'm gonna use the substitutions given by your code.

Yep, I'm yet to implement the substitution in my weather skin, as I've been busy with other visual tweaks in my suite in the meantime, but tomorrow I'll do it, as I want to have all 3 "modes" (i.e. V2 site JSON, V3 site JSON and V3 bare/APIKey JSON) in my weather skin continue to work. The reason is that just as I predicted a couple of weeks ago when talking about the changes to weather.com, it pays to have the weather skin flexible so that when something like this arrives one can switch to a working alternative while he builds a workaround of some sort. In my case it was easy to have the weather skin working again until the \" and the \uNumber substitutes were attempted, the only thing I had to do is paste the API key in a measure (that measure uses an IfMatch to choose between the site mode and the bare JSON mode based on whether the API key is blank or not - in other words I can parse either the site or the bare JSON just by pasting or removing the key from the measure's String option).

[brax64]

First of all let me thanks all of guys for the astonishing work you're doing, the time and effort you're throwing at this it's encomiabile to say the least.

I did implement in my skins the last include file from jsmorley and it's working nicely, obviously in English (and Italian too, my mother tongue).
Regarding to gather the lat, long data, I think that the skin designers can easily take care of that part and write it in the new variable that will be used
to get the proper API to parse...
Every weather skin that I know of, already ask to the end user to choose the location/language in some way, trough settings skin or directly modifying some .ini file, so new skins will ask for lat/long instead...just my 2 cents...

Cheers

[Yincognito]

Every weather skin that I know of, already ask to the end user to choose the location/language in some way, trough settings skin or directly modifying some .ini file, so new skins will ask for lat/long instead...just my 2 cents...

Yes. The question that skin designers (including jsmorley, who will tackle on the issue later tomorrow) must decide on is whether to let the users "manually" find their own lat/long, or do it "automatically" in their skins through a 3rd party reverse geocoding site. Each of those options are simple enough for both the user and the skin designer, so it's just a matter of skin designer's preference and how much "user friendly" he wants his skin to be, really.

That being said, in most weather skins users had to search their "location code" (which had even less connection to their actual location name than lat/long) in the past anyway, so I don't think switching to the lat/long format would be a shock or something unreasonable to them, if that's the option chosen by the skin designer.

[brax64]

...

That being said, in most weather skins users had to search their "location code" (which had even less connection to their actual location name than lat/long) in the past anyway, so I don't think switching to the lat/long format would be a shock or something unreasonable to them, if that's the option chosen by the skin designer.

Agreed, did find this free API that can be useful for this purpose; it return coordinates referred to a street address:

http://www.datasciencetoolkit.org/street2coordinates/2543+Graystone+Place%2c+Simi+Valley%2c+CA+93065

[Yincognito]

Agreed, did find this free API that can be useful for this purpose; it return coordinates referred to a street address:

http://www.datasciencetoolkit.org/street2coordinates/2543+Graystone+Place%2c+Simi+Valley%2c+CA+93065

There were already other posted links earlier in this thread (and other weather threads as well) regarding such sites, but having another one to add to the list certainly doesn't hurt. Having said that, the link seems to work for US locations, but doesn't for other "less domestic" locations - I live in Europe and can't find my location, for example.

[bruiser_brody]

Am I doing something wrong? I saw the post where I was to change all " to \\" in WeatherComJSONMeasures

So I did a ctrl + H and found all RegExp=(?siU)"getSunV3CurrentObservationsUrlConfig":.*units:\s*([meh]) and changed them all to RegExp=(?siU)\\"getSunV3CurrentObservationsUrlConfig":.*units:\s*([meh]) and saved them all.

Then in WeatherComJSONVariables, I add ,"\\":"" to the end of this string: CommonSubstitute='"':"","^null$":"","\\u002F":"/","\\u005C":"\","\\u003C":"<","\\u003E":">","\\":""

Any help would be appreciated. Thank you!

[brax64]

Am I doing something wrong? I saw the post where I was to change all " to \\" in WeatherComJSONMeasures

So I did a ctrl + H and found all RegExp=(?siU)"getSunV3CurrentObservationsUrlConfig":.*units:\s*([meh]) and changed them all to RegExp=(?siU)\\"getSunV3CurrentObservationsUrlConfig":.*units:\s*([meh]) and saved them all.

Then in WeatherComJSONVariables, I add ,"\\":"" to the end of this string: CommonSubstitute='"':"","^null$":"","\\u002F":"/","\\u005C":"\","\\u003C":"<","\\u003E":">","\\":""

Any help would be appreciated. Thank you!

HI,
You might want to download the complete .inc set file made by jsmorley and replace your old ones; it's the fastest and easier way to get you up and running in no time without getting crazy to find out what went wrong while you were editing your files.
You may find th new .inc files here

https://forum.rainmeter.net/download/file.php?id=22526

Cheeers

[bruiser_brody]

Thanks brax64!