Research & Sources

What counts as a source on this site

On Morse Trainer, a source is anything that helps a reader verify or better understand a public page. That can include general telegraph and radio history, operating references, public-domain archives, product documentation, or a first-party page that explains how the site itself works. The key point is not the format of the source. The key point is whether it improves accuracy, context, or a reader's ability to learn.

For practical pages, a source may be a training concept or operating convention rather than a formal citation list. For history pages, a source should support the basic factual frame before the page adds original explanation. For support and policy pages, the source is often the site itself: how the product actually behaves, what the help pages say, and what the public-facing UI exposes.

How history, media, and culture pages are handled

History pages are written to summarize a topic in original language, not to copy the shape of another article and swap in different wording. The goal is to explain why Morse mattered in a given setting, how the communication system was used, and why the detail still matters to modern learners. When a page mentions a famous message, a film scene, or a wartime use case, it should do so because the example adds understanding, not because the site needs filler.

Media references are especially easy to overdo. A short discussion of a film, game, or historical image is usually enough if the point is clear. Long quote blocks, repeated plot summaries, and transcript-style padding make a page feel busy without helping the reader. This site prefers concise context, original explanation, and a direct link back to the learning lesson.

Culture pages follow the same rule. If a page talks about scouting, education, or public memory, the page should explain what Morse did in that setting and why the example still matters. That is more useful than collecting trivia or repeating the same claim from several angles.

How corrections and disputes are handled

If a reader finds an error, the first step is to identify whether the problem is factual, editorial, or a broken link. A factual issue may need a content rewrite. An editorial issue may need a clearer heading or better structure. A broken link may need a simple repair. The page should not pretend all three problems are the same.

Readers can send corrections through the public Contact page. If the question is really about how the site works, the Help Center or FAQ may solve it faster. When a correction changes the public meaning of a page, the update should also be reflected in the visible last-updated label or the structured dateModified field so the site remains honest about its maintenance state.

If a disagreement is about interpretation rather than a simple typo, the site should favor clear explanation over argument. The point of the page is to help readers learn, not to win a debate. A short correction with a better explanation is usually better than a long defense of a weak paragraph.

What this site avoids

Morse Trainer avoids pages that look long but do not teach much. It also avoids quoting large chunks of copyrighted material, pretending scraped text is original research, or building a page around one recycled paragraph repeated in different forms. The public site should feel like a maintained learning resource, not a collection of generic filler.

That also means the site does not treat advertising as a reason to expand or distort content. If a page is worth keeping, it should be worth reading even without ads. If a page only exists because it can be monetized, it is probably not strong enough to keep.

How references are chosen in practice

When a topic is historical, the site prefers general reference material that supports the timeline, technology, and operational context. When a topic is about learning, the site prefers practical training experience and clear teaching logic. When a topic is about the product itself, the site prefers first-party documentation, visible UI behavior, and the public support pages that explain real use.

This approach keeps the writing usable. A learner does not need every source detail in order to benefit from the page. They need enough context to trust the explanation, enough clarity to keep moving, and enough structure to know where to go next if they want more depth.

Why the page exists for reviewers too

Reviewers looking at a site like this need to see more than a practice UI. They need to understand what the public knowledge layer is, how it is maintained, and how the site separates editorial decisions from monetization decisions. This page gives that explanation in one place so the rest of the site does not have to repeat it everywhere.

That same clarity helps normal readers. When a site explains how it picks sources and handles corrections, it becomes easier to trust the rest of the learning library because the maintenance process is visible instead of implied.

Where to go next