Editorial Standards

Our scope is Morse code itself - the translator and converter, the alphabet, learning and practice, audio and light signaling, history, crafts, and apps. We deliberately stay out of unrelated cipher systems, general telegraphy hardware, radio law, and non-Morse codes; when a topic brushes against those, we cover only the part that touches Morse.

How we decide what to publish

Our editorial calendar is built from public search demand, the gaps we find in existing coverage, and questions that come out of our own tool testing. Every piece runs the same path: the editor-in-chief approves the topic, a category editor drafts it, a designated fact-checker re-checks the claims, and a senior editor signs off before it goes live.

Our independence is non-negotiable, and it is specific:

• We do not accept payment to publish a favorable write-up of a Morse app, tool, or product.
• We do not accept payment to change the ranking, scoring, or recommendation of an app after we've tested it.
• We are not owned by, partnered with, or financially related to any app maker, hardware brand, or software platform.
• Revenue comes from (a) display advertising sold on a programmatic basis, (b) affiliate commissions on purchases made through links in our crafts and apps roundups, and (c) occasional, clearly labeled sponsorships.

Affiliate links

Some links in our crafts and apps coverage are affiliate links that earn us a commission. They never influence which products we select or how we rank them. No affiliate partner receives preferential placement, and we will rank a better app with no affiliate link above a worse one that carries one. See our full affiliate disclosure.

Sponsored content

When we run a sponsorship it is clearly labeled, editorially controlled by us, and kept separate from our verdicts: sponsored content never takes the form of an app review verdict and never appears inside a best-and-worst roundup. The full terms a brand agrees to - labeling, the narrow product-accuracy fact-check, and our volume caps - live on our advertise page.

Conflicts of interest

Editors disclose any financial, personal, or employment relationship that could create a conflict; the editor-in-chief evaluates each and recuses people as warranted. If an editor departs Translate Morse Code to join a company we cover, every article they authored is re-reviewed by a remaining senior editor within 90 days.

Every chart and translation we publish traces directly to an authoritative Morse code reference - the ITU-R M.1677-1 standard, ARRL, and other established Morse references - never to a sponsor, a press contact, or a forum thread. In practice, any claim must trace to one of three things: an authoritative reference, our own verification or tool test, or an explicitly named and trusted source.

Not every source carries equal weight, so we tier them:

Tier 1 - Primary sources (preferred)

• The ITU-R M.1677-1 international standard, documented in our verification log.
• ARRL and other recognized amateur-radio bodies.
• Established, long-cited Morse references and primers.
• Primary historical records.

Tier 2 - Trusted third-party sources

• Named amateur-radio clubs and Morse organizations we have explicitly vetted.
• Reputable reporting that cites a primary standard we can trace back ourselves.
• On-the-record statements from app makers or vendors, always attributed.

Tier 3 - Contextual sources (not cited as evidence)

• Forum posts, Reddit, and user communities - quoted for color only, with the underlying claim verified against Tier 1 or 2.
• App support chat and vendor marketing - a lead to verify, not an authority until confirmed.
• Other media roundups - context only, never a substitute for our own verification.

If a claim cannot be supported by a Tier 1 or Tier 2 source, it is either removed or explicitly qualified with language that communicates the uncertainty.

Every article carries a real byline. We do not publish unattributed articles.

Our position on AI

We do not generate article body copy with AI. We use AI tooling as a working aid - grammar checks, transcript drafts, brainstorming - but the final writing is done by a human. Where AI sits in our research or verification pipeline (for example, flagging mismatches or generating comparison tables), the underlying data is verified by hand and reviewed by a person before anything is published.

Our reference data comes from three places, in order of authority: the ITU-R M.1677-1 standard (alphabet, numerals, punctuation, and timing), ARRL and amateur-radio references (prosigns, abbreviations, and edge cases), and our own hands-on tool testing - running reference strings through the translator as text, sound, and light and recording the date.

What we test

• The core character mappings, checked dot-by-dot (A-Z, 0-9, punctuation, prosigns including SOS, AR, and SK, plus non-English characters).
• Timing and spacing - the dot as the base unit, the dash at three units, the three-unit gap between letters and the seven-unit gap between words, and Farnsworth timing.
• Tool output - text conversion in both directions, and audio and light playback.
• Apps - tested hands-on across web, iOS, and Android for accuracy, features, and ease of use.

What “Last verified” means

Every chart carries a visible “Last verified” date. It is not the publish date and not an automatic timestamp - it is the day a human on our team last checked that content against the standard and our tools. Apps update and standards get revised, so we would rather show an honest, slightly older date than fake recency.

Our testing process

1. 1Locate the source (ITU-R, ARRL, or an established Morse primer).
2. 2Read the standard line by line.
3. 3Cross-check edge cases - prosigns, abbreviations, non-English characters, and Farnsworth timing.
4. 4Test the tools with reference strings until they match exactly.
5. 5Date-stamp with the verification date.
6. 6Log the mappings, timing, and sources in a standardized internal sheet.
7. 7Editorial sign-off - a second editor confirms everything traces to an authoritative standard.

How and when we re-verify

Verification is not one-time. We re-verify on a schedule (refreshing the “Last verified” date), on a trigger (an app update or a reader report), and whenever an authoritative reference is revised.

What we won't claim

• We won't present non-standard variants without noting they are not in an authoritative reference.
• We won't publish a chart without a “Last verified” date.
• We won't average mappings from forums, users, or comments - every mapping traces to an authoritative standard.
• We won't guarantee proficiency - learning the alphabet isn't the same as copying at speed, and we point you to our learning guides instead.

Fact-checking at Translate Morse Codeis never performed by the person who wrote the draft. Three roles touch every article: the draft author (a category-owning editor who researches and writes, but isn't the final authority), a designated fact-checker (assigned by subject - usually our reference-verification editor for the alphabet, prosigns, and timing, or the tools editor for the translator, audio, light, and app reviews), and a senior editor who reviews the fact-checker's notes and signs off. No article publishes without all three.

What gets checked

• Morse specifics - the alphabet, numerals, punctuation, prosigns, and timing, all cross-referenced against the standard.
• Claims attributed to our own testing - traced to the internal test log, and removed if unsupported.
• Claims attributed to third parties - verified against the original source, never secondhand.
• Comparisons and rankings - grounded in hands-on testing of each option.
• Dates and currency - the “Last verified” date confirmed on publication and re-checked on a cadence.

The workflow

1. 1The author submits the draft with a source list.
2. 2The senior editor assigns a fact-checker by subject.
3. 3The fact-checker reviews line by line, flagging every verifiable claim as confirmed, needs-source, needs-revision, or remove.
4. 4Each flag is checked against its cited source, with revised language proposed where needed.
5. 5The author revises; disagreements escalate to the senior editor.
6. 6The senior editor confirms every flag is resolved and signs off.
7. 7The article goes live with its byline and the reviewer's name where applicable.

The whole process typically takes 2-4 business days after the draft is submitted, depending on complexity and volume.

How we handle uncertainty

Not every question has a cleanly sourceable answer. When sources disagree or an edge case is unsettled, we say what we know and label what we don't, we never present speculation as fact (predictions and guesses are framed as such - “we expect,” “early indications suggest”), and we flag the claim for follow-up so we can revisit it.

What fact-checking doesn't cover

• Subjective assessments - words like “intuitive” are editorial judgments, grounded in testing but not fact-checked.
• Future claims - we don't verify predictions about unannounced updates; we attribute them to their source.
• Third-party ad content - ads served by programmatic networks are not fact-checked by us.

Articles older than 18 months are flagged for review. Reference charts and roundups are re-verified on a cadence and re-stamped with a new “Last verified” date, and best-and-worst roundups are refreshed at least once per calendar year. We never silently backdate.

When a significant event affects our coverage between scheduled re-verifications - a corrected chart, an app that changed, a new release, or an updated standard - we update the relevant article within 14 business days and note the change with a dated inline update tag.

Getting things right matters more than getting things first. When we make an error - and every publication does - we fix it quickly, fix it visibly, and make the record easy to audit.

How to report a correction

Send it through our contact page with three things:

1. 1The article URL.
2. 2The specific statement (a quote or screenshot helps).
3. 3The correct information and its source (ITU-R, ARRL, a Morse primer, and so on).

You don't need to be an expert - report it in good faith. We would rather get ten reports where nine are fine than miss the one real error.

Our response commitment: we aim to acknowledge your report within 48 hours and act on verified corrections within 7 business days. If verification takes longer - re-checking a chart against the standard or re-testing a tool - we'll tell you and give you an estimated timeline.

How we categorize and handle corrections

Substantive corrections are factual errors that could mislead a reader - a wrong character mapping, incorrect timing, a misstated translation, a flawed app comparison.

What we do:

• Add an inline “Correction (date):” note above the original.
• Strike the original rather than delete it, so readers see what changed.
• Add a public entry to the corrections log below.
• If it materially changes an app recommendation or reference chart, add an update banner and notify readers via on-site alerts where possible.

Minor edits- a typo, a broken link, a renamed reference, an updated app-store URL, or formatting - don't affect substance.

What we do:

• Fix silently. No log entry, no inline note.

Major retractions apply when a core argument, recommendation, or methodology is fundamentally flawed and inline corrections can't salvage it.

What we do:

• Add a retraction banner to the top explaining what went wrong.
• Preserve the original at its URL with the banner as a permanent notice.
• Publish a new article from scratch, linked from the banner, if the topic still warrants coverage.
• Add a log entry with a clear “Retraction” label.

Our commitment to reporters

We take every report seriously regardless of who sends it, and we never retaliate or publicly identify a reporter unless they give explicit permission - for instance, if they want credit in the “Flagged by” column below.

Public corrections log

A reverse-chronological record of every substantive correction and retraction. We never remove entries.

This log will fill in as corrections are made. An empty log on a new site means we just launched - not that we're hiding anything. Check back, and hold us to it.