Sign inRegisterCheck connection

Preserving Unit and Language Cookies When a Weather Dashboard Moves

How a weather dashboard stored units and language in cookies, and what a migration should preserve so presentation state is not mistaken for climate metadata.

Back to Cumulus weather software guides

A weather dashboard that remembers Celsius after you open Graphs is using browser state, not a second thermometer. Historically that state lived in cookies: unit system, language of the chrome, sometimes which panel was open. At /aboutus/cookiepolicy the question is not “what must a policy disclose.” It is how the dashboard stored those choices, and what a migration should preserve so a later archive does not treat a visitor preference as climate metadata.

This article is the storage-and-migration note. The About-section cookie-policy document covers disclosure classes (preference versus analytics). The EU cookie project article covers the engineering tension of putting a notice on templates that also set preference cookies. Modern TNET Weather does not migrate third-party Cumulus skins and does not treat old cookies as live account data.

Historical context

Cumulus sites were often a set of PHP pages on shared hosting. The station program processed web tags on the PC and uploaded HTML, or the host read realtime.txt and printed values. Visitors still wanted one unit system across Gauges, Graphs, and the front page. A cookie is a small named value the browser sends back on the next request. Templates used that mechanism because it survived navigation without putting ?units=C on every link.

Typical first-party keys were not standardized. Community skins invented names: units, u, lang, language, a packed string of flags. Some templates also wrote localStorage when browsers started offering it. The scientific fact is the same: presentation state on the client, separate from the logger’s configured units.

The logger’s units are part of the observed record’s metadata. They say how the station stored the number. A visitor cookie that converts the number for display is derived presentation. If you archive screenshots or scraped HTML without recording which layer you captured, a Fahrenheit station becomes a fake Celsius series.

The original dashboard controls at this URL are not rehosted. There is no live unit picker here.

What the dashboard actually stored

Treat the historical cookie jar as three buckets. Only the first two belong in a weather-dashboard migration plan.

1. Unit preference

A code for temperature, pressure, and precipitation display. Sometimes one cookie held all three; sometimes each quantity had a key. The dashboard applied a conversion function to values that originated in the station packet or in tagged HTML.

What to preserve in a migration:

  • the native unit of the source file (from Cumulus configuration or from the packet’s own unit tokens);
  • the conversion rule the skin used, if you still need to read old saved HTML;
  • a note that converted figures in a scrape are derived.

What not to preserve as climate:

  • the last visitor’s choice, unless you are studying the website as an interface, not the atmosphere.

The Cumulus Wiki realtime.txt page documents that the live packet includes unit tokens with the values (last checked 13 August 2026). Those tokens are source metadata. A cookie that ignores them and forces inHg is a display override.

2. Language preference

A code for the chrome: “Temperature,” “Wind,” month names, maybe a translated Zambretti-style phrase. The numbers should not change when the language changes. If they did, the skin was translating and converting in one step, which is a defect to record, not a feature to copy.

What to preserve:

  • which language files the template shipped;
  • whether numbers were locale-formatted (comma versus point) so a later parser does not smash 21,5 into 215.

Locale separators on files (dayfile.txt, monthly logs) follow the station program’s settings, not the visitor cookie. The Cumulus Wiki dayfile page is the file-side reference. Do not let a browser language cookie rewrite how you parse the archive.

3. Chrome flags

Open panels, selected graph, “do not show the notice again.” These are interface state. They have no meteorological meaning. A migration can drop them unless you are reconstructing the old UI for a museum screenshot.

Analytics identifiers, if the skin later added them, are not dashboard preferences. They are out of scope for a units-and-language migration. Do not copy them into a new host “to keep continuity.”

What a migration should preserve

A move from shared-host PHP to a new static site, to Cumulus MX JSON, or to another domain is a chance to separate layers.

Keep with the station archive

  • software name and version;
  • configured native units;
  • latitude, longitude, elevation, and siting notes if you have them;
  • file contracts (realtime.txt, dayfile.txt, monthly logs) as written.

Keep with the website archive, labeled as website

  • template or skin name;
  • the preference-cookie names and their meaning;
  • whether the public HTML was stored already converted.

Do not promote into the station archive

  • visitor unit cookies;
  • language cookies;
  • consent-flag cookies;
  • any third-party identifiers.

The test is simple. If deleting the cookie would change the atmosphere, you mislabeled the field. Deleting a unit cookie should only change the label on an unchanged quantity.

If you republish historical dashboard HTML, stamp it as a dated website capture and state the display units. Do not drop it into a climate table as if the logger had been reconfigured.

Practical migration checklist

  1. Inventory cookie names from the old skin (source, not from memory). Record purpose and an example value.
  2. Read native units from Cumulus configuration or from packet tokens, not from a browser.
  3. Decide the new default display independently. You are not required to honor a decade-old units=F cookie on a new host.
  4. If you still offer a unit toggle, implement it as explicit presentation state. Query strings are easier to archive than silent cookies; cookies are easier for visitors. Either way, label converted values as converted.
  5. Do not migrate analytics cookies onto a new domain as a convenience.
  6. Do not restore a consent cookie as proof of a legal decision. A flag named cookiesAccepted in a 2011 skin is not a 2026 record of lawful basis.
  7. Follow current Cumulus docs for files you still produce: Cumulus Wiki Software and Cumulus MX on GitHub (last checked 13 August 2026).

Failure modes

Scraping the dashboard instead of the files. HTML that already shows °C, scraped daily, looks like a Celsius station. The dayfile may still be Fahrenheit. Prefer the files; treat the dashboard as a view.

Copying cookie names into a new stack. MX and modern templates do not owe the old key names. Reuse of lang=en across products is coincidence unless you documented it.

Treating a missing cookie as missing data. Empty storage means “use the native default,” not “the thermometer failed.”

Mixing this path with a login. Some CMS bookmarks glued cookie-policy URLs to action=login fragments. This page is not an account gate and does not set session cookies for a member area.

Modern relevance

MX may expose JSON over HTTP instead of a one-line text file, but operators still convert units in the browser or in a phone app. The migration rule is unchanged: native units travel with the source; display units travel with the view; never file the view in the climate drawer.

TNET’s public research records treat units as part of source quality. A visitor preference is not a source.

TNET research bridge

Source identity, native units, and the difference between a file and a display are the same questions TNET states for public records in data sources, quality controls, and methodology. That page does not document Cumulus cookie names. The Cumulus legacy hub lists related historical pages.

Sources