Player → Gender → Country → FIP Rank → FIP Points → Race Rank → Race Points → Best Rank → Position/Side → Handedness → Birth/Age → Partner → FIP Profile → Premier Padel → Google → Google+Padel → Google News → YouTube → Instagram → Facebook → TikTok → X → LinkedIn → Ecosia → Bing → News → Tournament history → Ranking history → Last checked.
Ik zie nu vrij precies waarom “Nieuws laden…” veel langer duurt dan nodig. Het probleem zit niet in je appsscript.json; het zit vooral in de nieuwsarchitectuur van Code.gs én in wat Index.html direct na openen allemaal tegelijk start.
De belangrijkste fout is dat wat x27NewsCachedFast() heet, feitelijk helemaal geen snelle cache is. De laatste definitie roept x27NewsQueryV9() aan, en die leest de volledige FeedItems-sheet, leest daarnaast Sources, verrijkt ieder nieuwsitem met bronmetadata, geografische berekeningen, afstanden vanaf Alkmaar, scores en sortering.
Daar bovenop doet x27NewsQueryV10() vrijwel hetzelfde: opnieuw alle FeedItems, opnieuw Sources, opnieuw enrichment en daarna pas paginering. Dus pageSize=40 betekent momenteel niet “lees 40 rijen”; het betekent in feite “lees en bereken alles en geef daarna 40 terug”.
En bij het openen gebeurt momenteel ongeveer dit:
x27NewsCachedFast wordt onmiddellijk gestart.
Na slechts 150 ms begint x27NewsLiveFast.
Na 1,2 seconde worden Sources, voorkeuren en vertaalvoorkeuren geladen.
Na 3,5 seconde wordt óók x27NewsQueryV10 gestart.
Wanneer x27NewsLiveFast klaar is, roept liveRefreshV10() vervolgens nogmaals loadCachedV10() aan.
Dat verklaart precies het gedrag dat je ziet.
Er zit nog iets zwaars in x27NewsLiveFast. Voor Vandaag haalt die 8 live RSS-feeds op. Daarna doet _bulkSaveNewsFast(), die opnieuw alle FeedItems leest om fingerprints te verzamelen. Vervolgens voert hij _refreshNewsBatchCore() uit — vandaag nog eens 10 opgeslagen feeds — en tenslotte wordt x27NewsQueryV9() aangeroepen, waardoor alle FeedItems en Sources nóg eens worden gelezen en berekend. De bulk-save zelf leest inderdaad opnieuw de complete FeedItems-tab.
Dus één automatische live-update bij openen kan grofweg neerkomen op:
8 live internetrequests → volledige FeedItems-scan → 10 extra RSS-fetches → volledige FeedItems-scan → Sources-scan → alle afstanden/scores berekenen → sorteren → daarna vanuit Index nóg een volledige V10-query.
Dat is de kern.
1. Nieuws bij openen moet uitsluitend uit een echte FAST FRONT CACHE komen.
Voeg in Code.gs deze functie toe en gebruik deze voor de eerste weergave:
Herstelrelease op basis van v10.2/v10.3.
Nieuwsfeed wordt als eerste geladen.
Zware vertaaldekking staat niet meer in het kritieke startup-pad.
Auto vertalen vertaalt na startup eerst de zichtbare pagina.
Vertaal alle gevonden blijft beschikbaar als expliciete bulkactie.
News Intelligence query heeft een timeout/fallback naar x27NewsCachedFast.
Login gebruikt een timeout, sluit het venster na succes en start geen zware nieuws/vertalingsactie.
Per nieuwsbericht blijven taalkeuze, meer/minder tekst en MD/JSON/CSV/TXT/DOC/PDF/WhatsApp exports aanwezig.
Vervang Code.gs en Index.html door deze v10.3.1-bestanden.
Opslaan.
Voer x27Setup() alleen uit als headers/setup nog niet aanwezig zijn; bestaande data wordt niet bewust gewist.
Deploy > Manage deployments > Edit > New version > Deploy.
Harde refresh van de /exec URL.
Open app -> snelle nieuwsquery -> feed zichtbaar -> vertalingen zichtbare pagina -> settings/sources -> live RSS refresh.
Bij een trage hoofdquery: automatische fallback naar snelle opgeslagen feed.
Startup is omgedraaid:
snelle opgeslagen feed direct tonen;
live internationale RSS vrijwel onmiddellijk starten;
pas daarna Sources/Prefs/Translations laden;
volledige News Intelligence index na enkele seconden laden voor paging/filter/sortering.
Code.gs is functioneel gelijk aan v10.3.1; de cruciale fix zit in Index.html.
Dit klinkt inderdaad als een regressie in v10.3, niet als een klein UI-probleem. Ik vergelijk nu v10.2 met v10.3 op drie kritieke paden: startup/login, eerste feed-load, en vertaal/export-initialisatie. Daarna herstel ik de werkende v10.2-flow en voeg ik alleen de vertaal/exportverbeteringen terug toe zonder de rest te breken.
Ik heb de regressie nu kunnen isoleren: v10.3 voegde tijdens iedere startup/feed-load extra zware calls toe voor alle item-ID’s → vertaaldekking → eventueel alle gevonden berichten vertalen. Dat hoort niet in het kritieke opstartpad. Daardoor kan de app na login of bij de eerste nieuwsquery blijven wachten, terwijl v10.2 juist eerst snel de feed toont.
Ik herstel daarom de volgorde naar: login/session → feed tonen → vertalingen van zichtbare pagina laden → klaar. Vertaaldekking en “alles automatisch vertalen” komen daarna pas los/background of op expliciete knop.
Ik heb de eerste herstelversie nu opgebouwd als v10.3.1 STABLE. Belangrijk verschil: de nieuwsfeed is weer het eerste dat geladen wordt; Sources, persoonlijke prioriteiten, vertaalinstellingen en live-refresh worden daarna pas geladen. Als de zware News Intelligence-query te lang duurt, valt de app automatisch terug op de snelle opgeslagen feed in plaats van leeg te blijven.
Je hebt gelijk: v10.3 had een echte regressie.
De belangrijkste fout zat in Index.html: er werd een event-handler gekoppeld aan englishBtn, maar dat element bestaat niet. Daardoor kon JavaScript stoppen vóór de normale initialisatie. Dat verklaart precies de combinatie login werkt niet goed + geen nieuwsfeed + onderdelen vallen weg.
Daarnaast heb ik de startup lichter gemaakt. v10.3 probeerde tijdens het laden meteen de volledige vertaaldekking en mogelijk alle gevonden berichten te verwerken. Dat heb ik uit het kritieke opstartpad gehaald.
Ik heb daarom v10.3.1 STABLE gemaakt:
Download Code.gs · v10.3.1 STABLE
Download Index.html · v10.3.1 STABLE
Download setup
Download complete ZIP
De nieuwe startup is nu:
open app → nieuwsfeed laden → feed direct tonen → vertalingen zichtbare pagina laden → settings/sources laden → live RSS verversen
Als de zware News Intelligence-query langer dan ongeveer 12 seconden duurt, probeert de frontend automatisch de snelle opgeslagen feed via x27NewsCachedFast, zodat je niet met een lege pagina blijft zitten.
Ook aangepast: login krijgt een timeout, sluit het loginvenster na een geslaagde login en start daarna alleen lichte gebruikersinstellingen. De zware vertaalactie wordt dus niet meer automatisch aan login gekoppeld.
De functies van v10.3 blijven wel behouden: meer/minder tekst, taalkeuze per bericht, vertalen per bericht en MD/JSON/CSV/TXT/DOC/PDF/WhatsApp-export.
Ik heb bovendien de HTML-ID’s tegen alle JavaScript $()-referenties gecontroleerd: 0 ontbrekende elementen. Ook alle inline onclick-functies bestaan nu.
Ik heb in je aangeleverde feed al één belangrijk verschil bevestigd: er staan 158 nieuwsberichten zichtbaar/gevonden, maar de Nederlandse vertaalstatus is niet consequent bij elk item aanwezig. Bovendien ontbreken in deze weergave inderdaad de exportacties na veel vertaalde berichten.
Ik tel nu de volledige aangeleverde pagina door en pas daarna de reader aan zodat ieder bericht altijd dezelfde vaste onderbalk krijgt: meer tekst → taalkeuze → vertalen → MD/TXT/CSV/JSON/DOC/PDF/WhatsApp, ongeacht of het bericht al vertaald is.
De telling uit je bestand is nu duidelijk: 158 gevonden nieuwsberichten, maar slechts 20 hebben de marker “Nederlands · vertaald uit bronfeed”. Dat is ongeveer 12,7% vertaald en 138 berichten (87,3%) nog niet. De exportknoppen komen in de aangeleverde pagina zelfs 0 keer per nieuwsbericht voor; alleen algemene CSV/DOC/PDF-termen komen elders voor. Dat bevestigt precies wat jij ziet.
Ik maak daarom een gerichte v10.3 News Translation & Export fix: automatische vertaling gaat voortaan alle gevonden items afwerken in plaats van alleen de zichtbare pagina, elke kaart krijgt altijd een taalkeuze én alle exportknoppen, en de feedtekst wordt ruimer weergegeven met “Meer tekst / Minder tekst”.
Ik heb ook de technische oorzaak gevonden waarom “alles vertalen” niet afmaakt: de frontend stuurt batches van 25, maar de backend x27TranslateSelected() accepteert maximaal 20 nieuwsitems per keer. Daardoor kan een batch van 25 volledig afbreken. Dat verklaart heel goed waarom je rond die kleine aantallen blijft hangen.
Ik zet beide kanten nu exact op 20 per batch, met voortgang 20/158 → 40/158 → …, en laat Auto vertalen daarna doorgaan tot de volledige huidige resultatenset voor de gekozen taal is afgewerkt.
Ik heb je aangeleverde feed volledig geteld. Daarin staan 158 gevonden nieuwsberichten, maar slechts 20 Nederlandse vertalingen. Dat is 12,7% vertaald; 138 berichten, oftewel 87,3%, waren nog niet naar Nederlands vertaald.
De belangrijkste bug zat in de vertaalbatch: de frontend stuurde 25 berichten tegelijk, terwijl de backend maximaal 20 accepteerde. Daardoor konden grotere vertaalrondes afbreken.
Ik heb dit nu opgelost in X2027 v10.3 · News Translation & Exports.
Per nieuwsbericht krijg je nu altijd:
meer RSS-tekst met Meer tekst ↓ / Minder tekst ↑
eigen taalkeuze, waaronder alle eerder opgenomen Europese talen
🌐 Vertaal naar gekozen taal
en daar direct onder altijd:
Origineel / Vertaling / Origineel + vertaling
plus:
MD · JSON · CSV · TXT · DOC · PDF · WhatsApp
De exportknoppen verdwijnen dus niet meer nadat een vertaling is gemaakt. Iedere export blijft inclusief credits.
Ook komt er nu een duidelijke vertaalmeter, bijvoorbeeld:
Nederlands: 20 / 158 vertaald · 138 nog te gaan · 12,7%
Wanneer AUTO VERTALEN · AAN · Nederlands staat, probeert v10.3 niet meer alleen de zichtbare pagina te vertalen maar de volledige huidige resultatenset, in correcte batches van 20:
20/158 → 40/158 → 60/158 → … → 158/158
De nieuwsbron blijft daarbij bewaard; de Nederlandse vertaling wordt aanvullend opgeslagen.
Hier zijn de verbeterde bestanden:
Download Code.gs · v10.3
Download Index.html · v10.3
Download setup v10.3
Download complete v10.3 ZIP
Ik heb zowel Code.gs als de JavaScript uit Index.html op syntax gecontroleerd.
Na plaatsen: x27Setup() → nieuwe deploymentversie → harde refresh.
Vervang Code.gs door x2027_Code_v10_1_NEWS_SEARCH_AI.gs.
Vervang Index.html door x2027_Index_v10_1_NEWS_SEARCH_AI.html.
Voer eenmaal x27Setup() uit.
Voer daarna x27EnsureV10() uit als AIRoutes/Prompts nog niet gevuld zijn.
Deploy > Manage deployments > Edit > New version > Deploy.
Hard refresh de /exec URL.
De tab Padel Sites & Socials bevat nu een News Search Hub met o.a. Google Padel News, Google News internationaal, Ecosia News, Bing News, Brave Search, DuckDuckGo News, Yahoo News, Google laatste 24 uur, Google News RSS, YouTube, Reddit en X.
De AI-tab heeft nu:
providerkeuze;
zoekmodus AUTO_WEB / WEB / RSS / KNOWLEDGE / HYBRID / LOCAL;
RSS aan/uit;
Knowledge aan/uit;
bron/citatie-voorkeur;
max lokale bronnen;
providerstatus;
AIRoutes-weergave;
opgeslagen gebruikersinstellingen.
Gemini: gebruikt google_search grounding als GEMINI_API_KEY aanwezig is.
OpenAI: gebruikt Responses API met web_search als OPENAI_API_KEY aanwezig is.
Zonder geschikte key valt X2027 terug op de bestaande AIRoutes/RSS/Knowledge/LOCAL-laag.
Voeg keys alleen toe in Apps Script > Project Settings > Script Properties, nooit in Index.html of de Sheet.
Ondersteunde namen uit X2027: GEMINI_API_KEY, OPENAI_API_KEY, ANTHROPIC_API_KEY, HF_API_KEY, NVIDIA_API_KEY.
Ik breid v10 uit met een echte News Search Hub en een inhoudelijke AI Settings-tab. Google Padel News wordt een vaste prominente knop; daarnaast voeg ik actuele zoekroutes toe voor andere nieuws/search-engines en maak ik de AI-tab geschikt voor providerkeuze, route-inzicht, broncontext en echte AI-zoekmodi.
Voor de “echte AI search” maak ik onderscheid tussen AI over je eigen X2027-bronnen en AI met live web search. Dat is belangrijk: Gemini ondersteunt Google Search-grounding via google_search, en OpenAI’s Responses API ondersteunt een web_search tool; v10.1 kan die live zoekmodus gebruiken als de betreffende API-key is geconfigureerd, terwijl LOCAL/RSS/Knowledge altijd als fallback beschikbaar blijft.
Ja — dat vastlopen op “News Intelligence index laden…” bij Deze week kwam door een echte performancefout in v9.4.
De backend deed bij ieder nieuwsbericht opnieuw een volledige lookup in de Sources-tab. Met ongeveer 1.477 FeedItems × 1.100+ Sources werd dat extreem zwaar.
Ik heb dat nu opgelost in v9.4.1 FAST INDEX:
Sources wordt nog maar één keer gelezen en als sourceId → bron map in geheugen gezet.
Bij Deze week wordt eerst op datum gefilterd.
Alleen de overgebleven weekitems krijgen daarna geo, afstand, bronmetadata en importance-score.
De syntaxcontrole van de nieuwe Code.gs is schoon.
Gebruik deze vervangende backend:
Download Code.gs · v9.4.1 FAST INDEX
Je huidige Index.html kan voorlopig blijven staan.
Na vervangen:
Opslaan → Deploy → Manage deployments → Edit → New version → Deploy → harde refresh.
Daarna hoort Deze week veel sneller van News Intelligence index laden… naar de daadwerkelijke berichten te gaan.
Omdat v9.4 nu twee verschillende dingen achter elkaar doet:
Bij openen: alleen opgeslagen nieuws uit FeedItems laden.
Pas na klik op “Feeds nu verversen” / “Internetfeeds verversen”: actuele RSS-feeds echt vanaf internet ophalen.
Dat zie je letterlijk terug in de huidige Index: bij startup draait loadCachedV9() en worden bronnen geladen, terwijl de live refresh pas via liveRefreshV9() of refreshFeeds94() wordt gestart. De feedknop roept vervolgens een zwaardere serveractie aan met meerdere rondes en een batch van 18 feeds, waardoor “Feeds verversen…” lang kan blijven staan.
Daarnaast is er nu een tweede vertrager: in de actuele Sheet staan meerdere Google News RSS-connectors op HTTP 503. Andere bronnen werken wel, maar de updater moet wachten tot die mislukte requests zijn afgehandeld. Daardoor voelt het alsof de hele feed vaststaat terwijl slechts een deel van de bronnen problemen heeft.
Ik zou dit anders ontwerpen:
Direct bij openen: toon meteen de opgeslagen nieuwsfeed.
Tegelijk automatisch op de achtergrond een kleine snelle live ronde, bijvoorbeeld 4–6 belangrijke internationale feeds.
Zodra die klaar is: nieuwe items meteen bovenaan invoegen.
Daarna pas automatisch de grotere bronbatch laten lopen.
De knop Verversen blijft bestaan voor een volledige handmatige scan.
Nooit meer alleen Ophalen…, maar bijvoorbeeld:
6/18 feeds verwerkt · 4 OK · 2 fout · 27 nieuwsitems gevonden.
Google News 503? Dan meteen doorgaan naar de volgende bron en de fout alleen in Feed Health registreren.
In de LIVE-balk altijd iets tonen als:
Laatste update 22:41 · 1365 opgeslagen · 8 feeds actief · 3 feeds tijdelijk fout.
Er zit zelfs een kleine inconsistentie in de huidige v9.4: init() bevat nog setTimeout(liveRefreshV9,300), dus er is wel een poging tot automatisch live ophalen, maar de pagina wacht eerst op loadSourcesV9(), loadPrefsV9() en loadCachedV9(). Daardoor is de automatische live-update niet de eerste zichtbare actie en kan de gebruiker het gevoel krijgen dat hij de knop moet gebruiken.
De betere startup hoort te worden:
OPEN APP
→ toon FeedItems onmiddellijk
→ toon Feed Health onmiddellijk
→ FAST LIVE: 4–6 feeds
→ nieuwe berichten toevoegen
→ achtergrondronde 6 feeds per batch
→ volgende batch
→ cache bijwerken
In plaats van:
OPEN APP
→ cache
→ wachten
→ gebruiker klikt
→ 18 feeds × meerdere rondes
→ lang “ophalen…”
Dus je observatie klopt: de huidige v9.4 is functioneler geworden, maar voor de gebruiker is de news startup slechter geworden dan nodig. De volgende versie zou ik daarom specifiek v9.5 · Instant Feed Startup maken, waarbij je binnen het openen van de pagina meteen nieuws ziet én de actuele internationale feeds automatisch beginnen te verversen zonder dat je eerst iets hoeft aan te raken.
dat is een echte fout in de huidige flow: “Deze week” blijft hangen op News Intelligence index laden… terwijl de interface wacht op de serverquery. Ik controleer nu precies welk deel van de week-query blokkeert en pas dat gericht aan zodat eerst direct de opgeslagen weekitems verschijnen en de live RSS-verversing daarna los daarvan draait.
Ik heb de echte bottleneck gevonden. De weekfilter zelf is niet het probleem: voor ieder afzonderlijk nieuwsbericht leest _v9SourceMeta() opnieuw de volledige Sources-tab. Met ongeveer 1.477 FeedItems en ruim 1.100 Sources betekent dat bij één klik potentieel ruim een miljoen bronvergelijkingen/Sheet-reads. Daarom blijft “Deze week” op News Intelligence index laden… hangen.
Ik maak dit nu cache/map-based: Sources één keer lezen → sourceId → bronmetadata in geheugen → daarna alle nieuwsitems verrijken zonder opnieuw de Sheet te lezen. Dat moet juist Deze week / Maand / Alles veel sneller maken.
Ik pak dit nu als één X2027 v9.4-integratie aan: eerst herstel ik de feed-updates en maak ik zichtbaar waar ze vandaan komen; daarna bouw ik de Players-database + jaarlijsten + extra datapunten, de interactieve PadelStudy / PadelOS / Intelligence-uitleglaag, en tenslotte één centrale MD-tab die alle bestaande .md-afspraken en documenten in de Sheet bewaart en in één HTML-tab toont.
Ik heb ook in de actuele Sheet gekeken en daar zit een concrete oorzaak van de ontbrekende feed-updates: meerdere Google News RSS-bronnen staan momenteel op ERROR: HTTP 503, terwijl andere bronnen wél OK 50 / +... teruggeven. Het systeem moet dus niet doen alsof “geen update” hetzelfde is als “geen nieuws”; ik voeg een feed-statuspaneel + retries/fallbacks + bronhealth toe, zodat je per feed ziet: OK, 503, laatste fetch, aantal gevonden en aantal nieuw opgeslagen.
De v9.4-code is nu technisch uitgebreid met drie nieuwe databronnen/tabs: Players, PlayerRankings en MD. Ik zet die nu ook daadwerkelijk in de huidige x2027-Sheet, zodat de app niet alleen voorbereid is maar de data meteen kan lezen. De eerste rankingseed komt uit de officiële FIP-ranking van 31 augustus 2026 en de historische jaar-#1’s uit FIP Ranking History.
dit is nu doorontwikkeld naar X2027 v9.3 · PROJECT SEARCH EXPORTS.
De belangrijkste wijziging is dat PROJECT.md nu het centrale document is. SITE.md, SITES.md, SETTINGS.md en CREDITS.md staan voortaan alleen onder Setup / Instellingen, dus niet meer tussen de gewone nieuwsfuncties.
Per nieuwsbericht krijg je nu een compacte keuze:
Origineel / Vertaling / Origineel + vertaling
met daarna:
MD · JSON · CSV · TXT · DOC · PDF · WhatsApp
Alle exports bevatten de brongegevens en de bekende credits. Bij PDF opent een nette printversie waarmee je direct Opslaan als PDF kunt kiezen.
Ook heb ik de foutieve weergave NaN km van Alkmaar aangepast: als geen betrouwbare afstand beschikbaar is, staat er voortaan afstand onbekend.
De hoofdnavigatie bevat nu naast Nieuws ook:
Padel Sites & Socials — favoriete padelsites, officiële organisaties, PadelStijn en social discovery.
Players — voer een spelernaam in en zoek die persoon direct via Google, Google News, YouTube, Ecosia, Bing en socials.
Tournaments — Premier Padel, FIP-circuits, internationale kampioenschappen, KNLTB-competitie enzovoort, met directe nieuws- en socialzoekfuncties.
Daarnaast heeft ieder werelddeel een eigen tab:
Europa · Azië · Afrika · Noord-Amerika · Zuid-Amerika · Oceanië
Daarin staan ongeveer 230 landen/gebieden. Per land staat ook de hoofdstad. Voor zowel:
padel + land
als:
padel + hoofdstad
krijg je knoppen naar:
Google · Google News · YouTube · Ecosia · Bing · Facebook · Instagram · LinkedIn · TikTok · X · RSS
Daar staan nu uitsluitend de technische/projectknoppen:
⬇ PROJECT.md
⬇ SITE.md
⬇ SITES.md
⬇ SETTINGS.md
⬇ CREDITS.md
plus tekstuele uitleg over nieuws, feeds, exports en Google/Google News/RSS.
Ik bouw dit als v9.2 bovenop je huidige v9.1: per nieuwsbericht komen twee Markdown-exportmogelijkheden — origineel en vertaling — plus centrale SITE.md, SITES.md en CREDITS.md-inhoud die ook automatisch onder elke export wordt toegevoegd. De deploy-URL kan ik hier niet direct aanpassen, dus ik lever de bijgewerkte Code/Index/MD-bestanden waarmee je dezelfde Apps Script-deployment kunt vernieuwen.
ik heb dit aangepast naar v9.1.
Voor Deze week gebruikt de reader nu op zaterdag 5 september 2026 twee overlappende betekenissen: de vorige 7 dagen t/m vandaag (29 augustus t/m 5 september) én de kalenderweek maandag 31 augustus t/m zondag 6 september als context. Nieuws uit zondag 6 september kan uiteraard pas verschijnen zodra die dag aanbreekt.
Daarnaast zoekt Deze week, Afgelopen maand en Alles nu daadwerkelijk breder in plaats van alleen dezelfde opgeslagen lijst anders te filteren:
Vandaag: 8 live zoekfeeds + 10 opgeslagen RSS-bronnen.
Deze week: maximaal 20 live zoekfeeds + 18 opgeslagen RSS-bronnen, met meerdere zoektermen zoals padel news, Premier Padel, clubs en business.
Afgelopen maand: maximaal 24 live zoekfeeds + 24 opgeslagen RSS-bronnen, inclusief coaching, federaties en meer landen.
Alles: maximaal 28 live zoekfeeds + 30 opgeslagen RSS-bronnen, zonder datumbeperking en met de breedste discovery-ronde.
Ook zie je nu per nieuwsbericht duidelijker waar het vandaan komt: Bron, publisher/site, domein, Feed, connector/origin en de gebruikte zoek/feedquery. Dat ontbrak inderdaad nog.
Vervang nu beide bestanden samen, sla op en maak daarna een nieuwe deploymentversie. Ik zou nu eerst uitsluitend deze vijf dingen testen: Nieuws opent → bestaande berichten verschijnen → LIVE Update → Nederlands vertalen → English. Pas als die stabiel zijn bouwen we de uitgebreidere landen-, podcast-, YouTube- en rubriekfeeds verder uit.
Doel: stabiliseren. Nieuws is hoofdpagina; LIVE PADEL NEWS staat bovenaan elke view.
Vervang Code.gs door x2027_Code_v1_9_STABLE.gs.
Vervang Index.html door x2027_Index_v1_9_STABLE.html.
Sla op.
Voer x27Setup() eenmaal uit als de tabs al langer niet zijn bijgewerkt.
Deploy > Manage deployments > Edit > New version > Deploy.
Open de nieuwe /exec URL.
Nieuws opent standaard.
Bovenbalk toont eerst opgeslagen FeedItems.
Na enkele seconden draait automatisch x27NewsLiveFast.
Klik Update: 8 internationale Google News RSS feeds worden parallel geladen.
Kies Nederlands en Vertaal alles; alleen titel + RSS-samenvatting worden vertaald voor snelheid.
Klik English voor directe Engelse vertaling.
Test Start, AI Brein, Lesbouwer, Zoeken en Systeem afzonderlijk.
Geen zware algemene bootstrap nodig voor nieuws.
Nieuws blijft zichtbaar als live internet-fetch faalt.
Nieuwe FeedItems worden in één batch naar de Sheet geschreven.
Vertaling van zichtbare feed gebruikt geen fetch van volledige artikelpagina.
AI, login, lessen en diagnose kunnen de nieuwsfeed niet blokkeren.