Translator GitHub: repo map for Pot

The translator client this guide maps lives at pot-app/pot-desktop. That repository holds source, licence text, issue tracking, and the Releases list used for every honest install link on this site.

Homepage marketing can move. The GitHub repo stays the durable map for filenames, licence, and security contacts when you need to prove what you installed.

What to open first

• Releases — the only download door this guide recommends for the translator binaries.
• README_EN.md — usage modes, services, plugins, and install notes.
• LICENSE — GPL-3.0 text for the client.
• Security tab — upstream vulnerability reporting.

Stars and activity

Star counts and push dates on this site come from the live GitHub fetch at build time. They are signals, not proof of safety by themselves. Pair them with the licence, the release signatures you choose to check, and your own service choices inside the app.

Issues and plugins

Bug reports belong on the upstream issue tracker. Plugin templates and community extensions are linked from the README plugin section. Keep .potext files you trust listed on the machine ticket beside the translator version.

Continue with releases, safety, and plugins.

Desk checklist that stays boring

Write the Releases URL, the exact filename, and the hotkey list on the same ticket you use for OS imaging. A translator desk fails when those three facts live in different chat threads. After every reimage, install the same file, restore the same services, and prove one selection pass before you install plugins.

Shared rooms should appoint one person to watch the upstream tag notes when a new release appears. That person updates the ticket, not a random mirror bookmark someone saved during a blocked SmartScreen prompt. The goal is a dull, repeatable translator path that survives staff turnover.

If two people insist on different doors, pick one official path for demos and keep the other as a documented exception. Mixing deb and AppImage on one Linux image is how silent update drift begins. Mixing a Releases exe with an unknown “translator setup” zip is how adware returns.

Filename discipline

Copy filenames character for character. Pot assets use a predictable pattern: pot_, version, architecture, then setup, dmg, deb, or AppImage. Extra words inserted by download portals are a warning sign. If the browser renames a file during save, rename it back to the Releases name before you archive it on a USB key.

Checksum companions and signature files exist for people who verify them. Everyday desks can still be honest without a full signature lab, as long as the bytes came from the official tag and the name still matches. When in doubt, delete the local copy and download again from Releases instead of repairing a suspicious binary.

Keep screenshots of the Releases page beside the ticket when auditors ask where the translator binary originated. A dated screenshot plus the filename is enough evidence for most classroom and contractor inventories.

Service and plugin hygiene

Services decide where text travels. Plugins expand OCR, dictionary, or collection features. Neither should be installed from a random attachment. Prefer links documented in the upstream README or the official plugin templates, and store .potext files next to your ticket notes.

When a service requires an API key, store that key in the password tool you already trust, not in a plaintext sticky note on the desktop. Rotating keys is easier when the translator client is only one consumer among several.

Review the enabled list quarterly. Unused cloud engines still expand the set of vendors that could see text if a hotkey is pressed by accident. Offline-friendly engines deserve the same review so you know which desks can work on a plane.

Teaching the selection habit

New users often paste into a browser because that muscle memory is older than any overlay. Sit with them for three short documents and only allow the Pot selection hotkey. The fourth document usually sticks. If it does not, the hotkey is probably fighting another app.

Clipboard listening is optional and intense. Turn it on for dedicated translation sprints, then turn it off so ordinary copy operations stop opening panels. Screenshot OCR is the right tool when text cannot be highlighted, not the first tool for every paragraph.

Document success with a one-line note: date, filename, hotkey, and service name. That line is the seed for the next rebuild and for the first-hour checklist on installed.

FAQ

Is the GitHub Releases door enough for a translator install?

Yes. Prefer pot_*_x64-setup.exe, matching macOS dmg files, or Linux deb or AppImage from pot-app/pot-desktop Releases. That keeps the translator binary aligned with the tag you documented on the machine ticket.

Do I need a package manager for this translator?

No. This guide treats GitHub Releases as the primary door. Optional package-manager commands that were not locked for the site stay out of the main story so the install remains honest.

What if SmartScreen blocks the translator setup?

Confirm the file name matches Releases, open the more-info path when Windows shows it, and avoid a second download from a random mirror. If the hash or name drifts, stop and re-check the official tag assets.