# WeatherMaster: twenty-three weather sources, two API keys, and a heading with nothing under it

> WeatherMaster is an Android weather app in Kotlin that lets you pick a different provider per location, drawing on a list of twenty-three sources that mixes national weather agencies, commercial vendors and alert-protocol broadcasters in one flat enumeration. The readme around it is mostly links, and two of those links are decoration rather than content.

**PranshulGG/WeatherMaster** — A Weather app for android with multiple sources 🌦🌞☔

- Repository: https://github.com/PranshulGG/WeatherMaster
- Stars: 3,151 · Forks: 151
- Language: Kotlin
- License: GPL-3.0
- Published: 2026-08-27 · Updated: 2026-08-27 · Language: en
- Canonical page: https://hysenlabs.com/projects/pranshulgg-weathermaster

## Twenty-three weather sources in one flat list and only two marked as needing a key

The weather source list is the substance of the readme, and it is a single bulleted enumeration with no grouping. Counted, it names twenty-three providers plus a closing line promising more. Inside that list sit at least three different kinds of thing. A dozen or so are national weather agencies: the United States service, the Scandinavian pair, the German, French, Finnish, Canadian, Indonesian and Italian services, Japan's, India's, and a service from the United Kingdom and one from Spain. A handful are commercial vendors, including two that appear to resell other agencies' data. And three are alert broadcasters rather than forecasters: the World Meteorological Organisation's severe weather centre, an open alert server, and the Central Weather Authority. Nothing on the page says which category a source falls into, so the only way to tell a direct agency feed from a reseller is to already know the brands.

## The key configuration lives per location and in two settings screens

Two entries in that list carry a parenthetical note that they require your own API key, with a link to the provider's sign-up page for each. Everything else in the list is presented as working without anything from you. The paragraph that follows the list explains what that means in practice: some sources need a free key from the provider before you can select them, and you add yours either from a location's weather source picker or from a settings screen for API key configuration. So the key is bound to a place rather than to the app, which means the same provider can be configured for your home and not for the office you are asking about, and a source you have a key for cannot be chosen anywhere until it has one. That is a more granular model than most weather apps use, and it is also the part of the readme with the least explanation of what happens when a key is wrong or expires.

## One entry in the provider list is a country name

Read down the list and twenty-one of the entries are organisations. One is a commercial weather brand. One is a generic reference to the United Kingdom's service rather than to the organisation that runs it. And one entry is simply a country. Whatever the app is doing with it, a bare country name among twenty-two brand names is either shorthand for a national provider or a placeholder that was never filled in, and the readme offers no way to tell which. It is a small thing next to the fact that two of the sources need your own credentials, but it is the kind of entry that tells you the list was assembled incrementally from whatever each contributor happened to add, rather than designed. The closing line promising more sources is formatted differently from the rest of the list, in bold italics, which is the only place the page marks that the list is provisional.

## The screenshots heading has nothing under it

There is a heading for screenshots, positioned between the badge row and the weather source list, and it is followed immediately by the next heading. No image, no link to a gallery, no text. The same is true of the page's overall shape: the readme is built almost entirely from HTML containers and badge links rather than prose, and the four internal links in the navigation row point to Features, Contact, License and Translate, of which only one, the translation link, leads to something outside the repository. Everything else is an anchor into this same document, which is a reasonable thing for a readme to do and means the page has no content of its own outside the source list, the translation section, a contact address and a licence sentence. For an app whose entire pitch is a long provider list, that is defensible. For a page someone lands on from a store listing, it is thin.

## The translation badge is repeated about thirty-eight times

The translation section invites you to help translate the app on a crowdsourced platform, links that platform, and then repeats the same link to it roughly thirty-eight times in consecutive lines. Each repetition is its own element: some are bare anchor tags wrapping the link, others are badge images wrapping the same destination. There is no variation in the URL, the alt text or the surrounding markup, so the repetition is not a set of badges for different languages; it is the same one copied. It is the kind of artefact that survives because nothing breaks, and it is worth knowing about if you are reading the rendered page, because a reader arriving from that section has to scroll past thirty-eight identical links to reach the contact section below it. The section also contains the one line of real content it has, an invitation to open an issue to request a language.

## The internal links only resolve on the hosting site's readme view

Every internal link in the navigation row carries a query parameter that asks the hosting site to render the file through its own readme view rather than serving the file directly. That is what makes the links work when someone clicks them on the hosting site, and it is what makes them inert everywhere else: in a local clone, in an editor preview, in a mirror, or in any tool that reads the file as text. Three of the four fragments are percent-encoded emoji rather than words, so a Markdown renderer or an anchor generator that does not decode them will produce links that point at nothing. It is a small incompatibility with no effect on the majority of readers, but it means the table of contents of this project only exists in one renderer, which is also consistent with the screenshots heading being the one section with nothing in it.

## A store release lane sits in the tree for an app with no store artefact documented

The repository carries a directory whose name is the mobile release automation tool, plus a translation platform configuration file, a preview directory and the Gradle wrapper for both platforms. The readme documents three distribution channels: the release page, a third-party application repository, and a Google Play listing. So there is a release lane configured for a mobile store in the tree, and no store artefact other than the Play listing appears anywhere on the page. Either the lane is there for a platform the project does not yet publish to, or the readme has not caught up with the channels it does. The application identifier also differs between the two links that expose one: the third-party repository path ends in a different suffix from the Play listing's, so the same build is indexed under two names in two stores.

## A privacy document sits in the tree and the readme does not link it

The top level of the repository contains a privacy document next to the licence and the contribution guide. The readme's navigation row points to features, contact, licence and translation, and stops there, so the privacy document is in the repository and unreachable from the page that describes the app. For a weather application that asks for location, contacts a long list of third-party providers, and stores per-location API credentials, that is the one document a reader is most likely to want and least likely to find. The contact section offers an issue tracker and a bare address, so the information is not absent, but the file exists and is not linked, which is the part worth fixing rather than the part worth writing about.

## Conclusion

WeatherMaster suits someone who lives where the default provider is poor and wants a second opinion for that one place, because the source picker is per location rather than global, and it suits someone who reads a national agency feed directly rather than through a reseller. It is a poor fit if you want one provider's data everywhere, since the two sources that need your own key have to be configured before they can be selected at all. Before you rely on it, check which of the twenty-three actually serve your region and whether the one you want needs a key, and read the privacy document in the repository rather than assuming the app tells you what it sends, since the readme does not link it.

## FAQ

### What is the WeatherMaster Android app?

It is a weather app for Android written in Kotlin that draws on a long list of weather providers. Its readme says it is inspired by a phone maker's own weather application, and it is distributed through the release page, a third-party application repository and a Google Play listing, with translations managed on a crowdsourced translation platform.

### Which weather sources does WeatherMaster support?

The readme names twenty-three, in one flat list with no grouping, mixing national weather agencies, commercial vendors and alert-protocol broadcasters. Two entries are marked as requiring your own API key with a link to the provider's sign-up page. The rest are presented as working without anything from you, and the page does not say which category any given entry falls into.

### How do I add an API key to WeatherMaster?

For the sources that need one, you add it either from a location's weather source picker or from a settings screen for API key configuration. Because the key is bound to a place rather than to the application, a provider cannot be selected anywhere until it has a key, and the same provider can be configured for one location and not another.

### Is WeatherMaster free, and what licence is it under?

The readme does not address price anywhere. It states that the project is licensed under version 3 of the GNU General Public Licence and points at the licence file, and it links three distribution channels. Nothing on the page says whether the application or its source is free of charge.

### Does WeatherMaster have a privacy policy?

The repository contains a privacy document at its root. The readme's navigation row links to features, contact, licence and translation and does not include it, so the document is in the repository and not reachable from the page that describes the application.

### How do I build WeatherMaster from source?

The repository carries a Gradle build written in the Kotlin dialect, an application module, the wrapper for both platforms, a translation platform configuration, a mobile store release lane and a preview directory. The readme gives no build command, no minimum Android version and no toolchain version, so nothing on the page tells you what to run or what you need.

## Sources

- [Official README](https://github.com/PranshulGG/WeatherMaster#readme)
- [Project repository](https://github.com/PranshulGG/WeatherMaster)
- [Release notes](https://github.com/PranshulGG/WeatherMaster/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pranshulgg-weathermaster