Weather Skins Not Working

[Yincognito]

I agree, and that occurred to me first thing, but it really can't work that way. Substitute does not "change" the value of a measure, but only the string value that is obtained when some other measure "asks for" the string value of the measure. Child measures are not using the string value of the parent measure, and in fact don't "ask for" any value at all. The child measures values are automatically populated by WebParser itself as a part of the plugin functionality.

The other issue is that the entire weather.com site is ginormous, and using RegExpSubstitute on the entire value pretty much brings Rainmeter to its knees...

Yep, agreed on the first paragraph, it's the way WebParser and Substitute work - that's why I mentioned it's a "hypothetical" situation. I have doubts regarding second paragraph though, because as you might remember, I do a TON of such substitutions in my Feeds skin, for similar strings in length (or even longer) and the delay in parsing that is similar with the delay in parsing weather.com.

Anyway, I fixed the thing in my skin as well. I created a variable Q=\\" and just used it (i.e. #Q#) instead of the hardcoded quotes in my other variables that are involved in regexp substitutions, in case they revert the change tomorrow or something. Added ,"\\"":""" to my own "common substitute" variable and that was it. Had to slightly modify my "data" pattern, but the changes were minor.

Apperently we got away easy this time...

[JamX]

Yes, It's working again thanks to all of you

Capture.JPG

Yincognito:
Good, clever, solution with the variable declaration Q=\\"
You indeed never know what the site designers will do in the future.

[Yincognito]

Yeah, that does seem to work, but crap, that's a lot of changes.

Some other undesirable changes that I noticed. There are now more characters encoded as \uNumber, for example \u0219 aka ș (and probably others), so that might pose a problem for using a weather skin in some local languages, as DecodeCharacterReference doesn't cover the \uNumber cases, as far as I know. One cannot use a substitution like "\\u([0-9A-F]+)":"[\x\1]" either, because of that substitution / variable / character reference order I once talked about here with you and probably Brian as well.

[SilverAzide]

^ Dang it. Yeah, the weather in Russian is completely hosed.

[balala]

So it seems like two steps are needed.

1) Replace all " with \\" in all RegExp options in the various WeatherComJSONMeasures*.inc files.
2) Add ,"\\":"" to the end of #CommonSubstitute# in the WeatherComJSONVariables.inc file.

And bingo...

1.jpg

Right, it indeed does work now. But a new problem arises and can't figure out a solution. Maybe someone can.
The problem is when using other language than English, which has characters with diacritics. For instance if I replace the Language variable within the WeatherComJSONVariables.inc file with Language=hu-HU (Hungarian), this is what I get:

HU.png

As you can see, the description is not ok. The "framed" character should be an é, but it appears as u00E9.
Same for Romanian: with the Language=ro-RO variable, I get this:

RO.png

This time the framed character should be a ț instead of u0163.
I tried to fix this by adding a DecodeCharacterReference=1 option to the appropriate WebParser measures into the WeatherComJSONMeasures3Day.inc file. Didn't help. Finally I ended up by adding the DecodeCharacterReference=1 option to all WebParser measures of the WeatherComJSONMeasures3Day.inc file, but didn't help either.
So, is the only solution a substitution?
Thanks for any idea.

[jsmorley]

Right, it indeed does work now. But a new problem arises and can't figure out a solution. Maybe someone can.
The problem is when using other language than English, which has characters with diacritics. For instance if I replace the Language variable within the WeatherComJSONVariables.inc file with Language=hu-HU (Hungarian), this is what I get:
HU.png
As you can see, the description is not ok. The "framed" character should be an é, but it appears as u00E9.
Same for Romanian: with the Language=ro-RO variable, I get this:
RO.png
This time the framed character should be a ț instead of u0163.
I tried to fix this by adding a DecodeCharacterReference=1 option to the appropriate WebParser measures into the WeatherComJSONMeasures3Day.inc file. Didn't help. Finally I ended up by adding the DecodeCharacterReference=1 option to all WebParser measures of the WeatherComJSONMeasures3Day.inc file, but didn't help either.
So, is the only solution a substitution?
Thanks for any idea.

This is no doubt a result of my stripping off all the \ characters in #CommonSubstitute#. Let me chew on this just a bit.

Edit... No, it's not that specifically.

[Yincognito]

This is no doubt a result of my stripping off all the \ characters in #CommonSubstitute#. Let me chew on this just a bit.

I doubt it. It is present in the page source itself:

Code: Select all

[8,9,9,8,8,7,6,6,5,4,4,4,5,5,4,4,5,6,8,11,11,10,10,8,8,8,8,8,8,7,6,7,6,7,8,8,9,11,12,13,13,14,14,15,12,11,11,11],\"wxPhraseLong\":[\"Par\u0163ial \u00EEnnorat\",\"\u00CEn mare parte \u00EEnnorat\",\"\u00CEn mare parte \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"\u00CEn mare parte senin\",\"\u00CEn mare parte senin\",\"\u00CEn mare parte senin\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Furtuni cu fulgere izolate\",\"Furtuni cu fulgere izolate\",\"Furtuni cu fulgere izolate\",\"Furtuni cu fulgere izolate\",\"Furtuni cu fulgere izolate\",\"Furtuni cu fulgere izolate\",\"Furtuni cu fulgere izolate\",\"Furtuni cu fulgere izolate\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"\u00CEn mare parte senin\",\"\u00CEn mare parte senin\",\"Par\u0163ial \u00EEnnorat\",\"\u00CEn mare parte senin\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"\u00CEn mare parte \u00EEnnorat\",\"Averse\",\"\u00CEn mare parte \u00EEnnorat\",\"\u00CEn mare parte \u00EEnnorat\",\"\u00CEnnorat\",\"\u00CEnnorat\",\"\u00CEn mare parte \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\"]

Notice the \uHexNumber occurences.

P.S. Yet again, when I switch to the "API mode" in my skin, there are no issues and the characters are displayed properly, so it's probably a result of the escaping thing on the main site. In other words, more than just quotes are escaped, one way or another.

[jsmorley]

I doubt it. It is present in the page source itself:

Code: Select all

[8,9,9,8,8,7,6,6,5,4,4,4,5,5,4,4,5,6,8,11,11,10,10,8,8,8,8,8,8,7,6,7,6,7,8,8,9,11,12,13,13,14,14,15,12,11,11,11],\"wxPhraseLong\":[\"Par\u0163ial \u00EEnnorat\",\"\u00CEn mare parte \u00EEnnorat\",\"\u00CEn mare parte \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"\u00CEn mare parte senin\",\"\u00CEn mare parte senin\",\"\u00CEn mare parte senin\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Furtuni cu fulgere izolate\",\"Furtuni cu fulgere izolate\",\"Furtuni cu fulgere izolate\",\"Furtuni cu fulgere izolate\",\"Furtuni cu fulgere izolate\",\"Furtuni cu fulgere izolate\",\"Furtuni cu fulgere izolate\",\"Furtuni cu fulgere izolate\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"\u00CEn mare parte senin\",\"\u00CEn mare parte senin\",\"Par\u0163ial \u00EEnnorat\",\"\u00CEn mare parte senin\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"\u00CEn mare parte \u00EEnnorat\",\"Averse\",\"\u00CEn mare parte \u00EEnnorat\",\"\u00CEn mare parte \u00EEnnorat\",\"\u00CEnnorat\",\"\u00CEnnorat\",\"\u00CEn mare parte \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\",\"Par\u0163ial \u00EEnnorat\"]

Notice the \uHexNumber occurences.

So they have replaced all literal characters that are outside of the range of ASCII with Unicode references?

[Yincognito]

So they have replaced all literal characters that are outside of the range of ASCII with Unicode references?

Seems like it, yeah. So far, I can only confirm the quotes (escaped with \) and the local characters in my language (escaped with \u), but as SilverAzide and balala confirmed, it is true for other languages like Russian, Hungarian, etc.

EDIT: This can, of course, be circumvented if only a substitution like "\\u([0-9A-F]+)":"[\x\1]" would work (or if DecodeCharacterReference would do the \uNumber decoding, on demand - I guess such an option could be added, although it might be some work involved), or if the entire string / superparent (doesn't have to be the entire site, though, just the JSON part) would be transferred into a String measure where it could be properly manipulated through (I believe, successive) substitutions, so that they won't interfere with the [\xNumber] character reference variable happening before the other variables parsing in Rainmeter...

[jsmorley]

Seems like it, yeah. So far, I can only confirm the quotes (escaped with \) and the local characters in my language (escaped with \u), but as SilverAzide and balala confirmed, it is true for other languages like Russian, Hungarian, etc.

EDIT: This can, of course, be circumvented if only a substitution like "\\u([0-9A-F]+)":"[\x\1]" would work (or if DecodeCharacterReference would do the \uNumber decoding, on demand - I guess such an option could be added, although it might be some work involved), or if the entire string / superparent (doesn't have to be the entire site, though, just the JSON part) would be transferred into a String measure where it could be properly manipulated through (I believe, successive) substitutions, so that they won't interfere with the [\xNumber] character reference variable happening before the other variables parsing in Rainmeter...

I don't think we can depend on DecodeCharacterReference for this, as that is designed to decode HTML characters references like &#nnnn;, &#xhhhh;, or &name;. This is an unfortunate situation, as I think the only current alternative is some kind of massive lookup / substitution on all these possible characters, which a bunch.

It might be that the API / JSON approach might be the way forward.