Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Hi! Thank you! Unfortunately this did not help. However, something changed. Now the widget shows Cupertino in the city field. Previously it was blank. Anyway, the "validating" issue still present.
But nothing appears in the Console app?
 
But nothing appears in the Console app?
That's what i see in the Console:

16.01.26 20:56:08,980 com.apple.Dock.agent: 2026-01-16 20:56:08.979 DashboardClient[163:403] error [1001] setting colorSpace to Color LCD colorspace
16.01.26 20:57:58,125 Dock: kCGErrorIllegalArgument: CGSReleaseWindow: Invalid window 2
16.01.26 20:57:58,125 Dock: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
 
@Wowfunhappy DeepL recently updated their API, and the current translation widget no longer works. It looks like you'll have to use a POST request now.

it's a really quick fix:
JavaScript:
function performXMLRequest (encodedText, encodingType, translationType, callback)
{   
    var sourceLang = translationType.substr(0, translationType.indexOf('_')).toUpperCase();
    var targetLang = translationType.substr(translationType.indexOf('_') + 1, translationType.length).toUpperCase();
    
    var url = 'https://api-free.deepl.com/v2/translate';
    var body = 'text='+encodeURI(encodedText)+'&source_lang='+sourceLang+'&target_lang='+targetLang;
    
    var xml_request = new XMLHttpRequest();
    xml_request.onload = function(e) {xml_loaded(e, xml_request, requestID++, callback);}
    xml_request.onerror = function() {callback(null,"");}
    xml_request.open("POST", url);
    xml_request.setRequestHeader("Authorization", "DeepL-Auth-Key "+deeplAuthKey);
    xml_request.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
    xml_request.setRequestHeader("Cache-Control", "no-cache");
    xml_request.send(body);
    
    //alert("Translation URL: " + url); //uncomment for debugging
    
    return xml_request;
}
 
Last edited:
@Wowfunhappy DeepL recently updated their API, and the current translation widget no longer works. It looks like you'll have to use a POST request now.

it's a really quick fix:
JavaScript:
function performXMLRequest (encodedText, encodingType, translationType, callback)
{  
    var sourceLang = translationType.substr(0, translationType.indexOf('_')).toUpperCase();
    var targetLang = translationType.substr(translationType.indexOf('_') + 1, translationType.length).toUpperCase();
   
    var url = 'https://api-free.deepl.com/v2/translate';
    var body = 'text='+encodeURI(encodedText)+'&source_lang='+sourceLang+'&target_lang='+targetLang;
   
    var xml_request = new XMLHttpRequest();
    xml_request.onload = function(e) {xml_loaded(e, xml_request, requestID++, callback);}
    xml_request.onerror = function() {callback(null,"");}
    xml_request.open("POST", url);
    xml_request.setRequestHeader("Authorization", "DeepL-Auth-Key "+deeplAuthKey);
    xml_request.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
    xml_request.setRequestHeader("Cache-Control", "no-cache");
    xml_request.send(body);
   
    //alert("Translation URL: " + url); //uncomment for debugging
   
    return xml_request;
}
Thank you! I have a bunch of really minor updates I need to do, I'm really hoping I can get to them soon!
 
just a quick side project i did that i thought was worth sharing
here is another modified weather widget that uses the weather channel (weather.com) as the source
it uses apple maps for location search
my goal was to make the data match with what the ios 8-15 weather app would display, as that also uses the weather channel + apple maps
feel free to use if you prefer weather.com
this does not require any api key. it uses apple's commercial api key for the the weather channel api, and apple's own mapkit tokens for the mapkit js api.
(thanks claude for helping debug the code to translate the weather.com api response to the main widget, which was a nightmare for me)
 

Attachments

  • Like
Reactions: Wowfunhappy
^ Super cool! I'd be a little nervous about repurposing their commercial API key like that, but it's neat that it works!
 
^ Super cool! I'd be a little nervous about repurposing their commercial API key like that, but it's neat that it works!
well, millions of users spammed the api with that key every day in that era. and the ones who are on older devices with ios 15 still do. it probably has an unlimited quota anyways, i don't think apple or the weather channel would care.
 
stocks widget seems to be down again. worked like a charm a couple days ago. EDIT: Sorry, mistakes were made.
 
Last edited:
A suggestion for those users facing the Weather Widget location "Validating..." issue. If your Mac has wifi, enable it and connect to your local network. Then reboot. Hopefully this will push the Widget to the next step. This helped me and the Weather Widget is working fine again.

The Weather Widget (Wowfunhappy's version) was working fine for me for many months. I tried iPodNano3's version and it worked fine for a few days then everything went blank as I got hit by the location "Validating..." issue. This happened on my Mac Pro (Ethernet) but not on my MacBook Pro (wifi) both running Mojave. I suspected that the location input was not being passed along onto the system. Tried many workarounds (e.g. re-enabling Location Services, etc.) but nothing worked until I enabled wifi.

During the many reboots, I reinstalled both versions of the Widget mentioned and both failed and worked again after wifi was enabled. I am now using iPodNano3's version on the Mac Pro but Wowfunhappy's version on the MacBook Pro. For some strange reason iPodNano's version does not recognise "Taipei, Taiwan" as a valid location when is running on the MacBook Pro using wifi. Can't explain this... makes no sense at all.

Here is where I got the idea to enable wifi... the Weather Widget in Tahoe sometimes fails to update until wifi is enabled even for desktop Macs on a wired network. Apparently this is a well known bug. I have experienced this several times on my Mac mini M4 Pro. In Tahoe and now Mojave, you can disable wifi after the weather is updated.
 
Last edited:
A suggestion for those users facing the Weather Widget location "Validating..." issue. If your Mac has wifi, enable it and connect to your local network. Then reboot. Hopefully this will push the Widget to the next step. This helped me and the Weather Widget is working fine again.

The Weather Widget (Wowfunhappy's version) was working fine for me for many months. I tried iPodNano3's version and it worked fine for a few days then everything went blank as I got hit by the location "Validating..." issue. This happened on my Mac Pro (Ethernet) but not on my MacBook Pro (wifi) both running Mojave. I suspected that the location input was not being passed along onto the system. Tried many workarounds (e.g. re-enabling Location Services, etc.) but nothing worked until I enabled wifi.

During the many reboots, I reinstalled both versions of the Widget mentioned and both failed and worked again after wifi was enabled. I am now using iPodNano3's version on the Mac Pro but Wowfunhappy's version on the MacBook Pro. For some strange reason iPodNano's version does not recognise "Taipei, Taiwan" as a valid location when is running on the MacBook Pro using wifi. Can't explain this... makes no sense at all.

Here is where I got the idea to enable wifi... the Weather Widget in Tahoe sometimes fails to update until wifi is enabled even for desktop Macs on a wired network. Apparently this is a well known bug. I have experienced this several times on my Mac mini M4 Pro. In Tahoe and now Mojave, you can disable wifi after the weather is updated.
sorry, the search results are out of my control and the widget is just programmed to display whatever the apple maps server gives back. however, i did find that taipei is under the SubAdministrativeArea type rather than Locality, which is what most cities are under. i have updated the attachment in my reply with a new version that also adds SubAdministrativeArea to the search parameters. taipei appears in the results.
 
  • Like
Reactions: Lasthenia
sorry, the search results are out of my control and the widget is just programmed to display whatever the apple maps server gives back. however, i did find that taipei is under the SubAdministrativeArea type rather than Locality, which is what most cities are under. i have updated the attachment in my reply with a new version that also adds SubAdministrativeArea to the search parameters. taipei appears in the results.
"Taipei City, Taiwan" weather now available. Thank you very much!

Yes of course, the search results are completely out of our control.
 
ski report widget fix that uses the weather channel's ski conditions api endpoint and current observations api endpoint to get data. uses apple maps to search for ski resorts. still using apple's weather.com api key and mapkit js tokens. it properly displays the new (past 24 hours) snowfall, the base snow length, number of open trails, snow condition, and temperature. it will also display a big "CLOSED" sign if the resort is currently closed.

simply go to the back and enter in a ski resort name. it should (hopefully) get validated by apple maps. you can choose from multiple results. the full address of the ski resort will be displayed.

Screen Shot 2026-04-24 at 0.00.45.png
Screen Shot 2026-04-24 at 0.03.43.png
 

Attachments

Last edited:
  • Like
Reactions: Wowfunhappy
As this thread seems to host all things Dashboard widgets, I think it wouldn't be inappropriate to mention that I've just noticed a 3rd-party widget, "Currency Converter" by Paolo Grifantini, stopped updating exchange rates after Feb 19 of this year. The widget makes reqs to three destinations–quaresoft.com with GET (resp: 501 Bad Gateway), ecb.europa.eu with CONNECT (no resp) and ecb.int with GET (resp: 301 Moved Permanently).

It was a super-handy widget that provided a lot more currencies than the stock Apple one.

Screen Shot 2026-05-04 at 05.20.32.png


P.S. Something's definitely not OK with the Stocks data retrieval, as the endpoint appears to cut off periodically. It's currently showing "Error retrieving chart" and no data.
 
Last edited:
ski report widget fix that uses the weather channel's ski conditions api endpoint and current observations api endpoint to get data. uses apple maps to search for ski resorts. still using apple's weather.com api key and mapkit js tokens. it properly displays the new (past 24 hours) snowfall, the base snow length, number of open trails, snow condition, and temperature. it will also display a big "CLOSED" sign if the resort is currently closed.

simply go to the back and enter in a ski resort name. it should (hopefully) get validated by apple maps. you can choose from multiple results. the full address of the ski resort will be displayed.

View attachment 2624555View attachment 2624556
Just downloaded & unzipped & clicked on the Ski Report.wdgt on my 10.14.6 (Mojave) it said (translated from Turkish) Ski Report.wdgt can't be opened because it's been damaged. You should place it in Recycle Bin.
 
Just downloaded & unzipped & clicked on the Ski Report.wdgt on my 10.14.6 (Mojave) it said (translated from Turkish) Ski Report.wdgt can't be opened because it's been damaged. You should place it in Recycle Bin.
Turn off Gatekeeper. You may need to use the Terminal command on Mojave. (I don't think the opt-click > open trick works for Dashboard Widgets?)
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.