Offline translation of cache descriptions (Argos Translate)

[AgreeDK]

Problem Statement

When traveling abroad, a large share of caches are only listed in the local language. Many users would benefit from being able to translate a cache's description into their own UI language directly inside OpenSAK — without requiring an internet connection in the field, and without any per-use cost.

Proposed Solution

Proposal: Argos Translate

Argos Translate is an open-source, offline machine translation library for Python (MIT-compatible, based on OpenNMT/CTranslate2). Key properties relevant to OpenSAK:

Fully offline once language packages are downloaded — no API key, no ongoing cost, no internet required at translation time
Runs locally on CPU, translation itself is fast (well under a second per paragraph on typical hardware)
Language packages ("argosmodels") are ~50–200 MB per pair and are downloaded once, then reused indefinitely
Not every language pair exists directly; Argos automatically pivots through an intermediate language (e.g. de → en → da) when no direct pair is installed, at some cost to translation quality
Translation quality is decent — good enough to understand what a cache is about, hints, and warnings — but noticeably below commercial engines like Google Translate or DeepL

This was manually tested against real German cache description text with acceptable results (via de → en → da pivoting, since no direct de → da package exists).

Why not a commercial API (Google Cloud Translation / DeepL)?
Google Cloud Translation API gives much better quality (500,000 chars/month free tier, permanent), but requires every user to set up their own Google Cloud project with billing enabled and an API key — meaningful setup friction for a free open-source app, plus a hard internet dependency
DeepL's API Free tier has been discontinued; only a one-time 1M character development/evaluation grant remains, not a recurring free allowance — no longer viable for production use at no cost
Unofficial "free" wrappers around Google's web translator violate Google's ToS and can break or get IP-blocked without notice — not something to ship in a distributed app

Argos Translate is the only option that is both genuinely free on an ongoing basis and works fully offline, which matters for a geocaching app used in areas with poor or no mobile coverage.

Proposed implementation

1. Language package management (Settings)
   New "Offline Translation" section in Settings
   List of available source languages with install/remove controls per language pair
   Packages should be downloaded ahead of time (e.g. before a trip, on reliable Wi-Fi) — not silently in the background
   Show installed size and allow removal to free disk space
2. Translation action (Cache detail view)
   "Translate description" button/action on the cache detail panel
   Detects cache listing language if possible, otherwise lets the user pick source language manually
   Runs translation locally, no network call
3. Storage
   Add fields to the cache model, e.g.:
   translated_description (text)
   translation_source_lang / translation_target_lang
   translation_locked (bool)
   translation_locked follows the same pattern as the existing "lock cache against import overwrite" mechanism: once a cache has a stored translation, re-importing GPX/PQ data must not overwrite it
   A small indicator (icon/badge) shown on the cache to signal a stored translation exists, similar to the existing corrected-coordinates warning triangle
4. Open questions for discussion
   Should translated text be stored in a separate field (keeping the original description untouched), or should it be shown as an alternate view/tab? (Leaning towards a separate field + toggle, to preserve the original at all times.)
   Should the language package list be bundled with a subset of common languages by default, or fully opt-in/on-demand?
   Do we want auto-detection of the source language, or always let the user pick explicitly?
   Should translation apply only to the long description, or also short description / hints / logs?
   References
   GitHub: https://github.com/argosopentech/argos-translate
   Website/docs: https://www.argosopentech.com/

[AgreeDK]

@CheminerWill
@Allyn56
@C3GPS
@nagisml
@blazerat
@Fabio-A-Sa
@hansblom
@donathtom
@n3oklan
@theyoungstone
@Surfoo

Hi all, if you have time I would like to get your review/comment on this, thanks

[Allyn56]

I assume the translation will be able to be sent to the GPS via the export or Send to GPS functions? I think it would be good to have a non-internet reliant translate capability.

Should translated text be stored in a separate field (keeping the original description untouched), or should it be shown as an alternate view/tab? (Leaning towards a separate field + toggle, to preserve the original at all times.) - I think either approach works._
Should the language package list be bundled with a subset of common languages by default, or fully opt-in/on-demand? - It depends on the size of each module and how it impacts speed or performance. -I would see how opt-in/on-demand works first since or suggest language modules by regions._
Do we want auto-detection of the source language, or always let the user pick explicitly? - I would prefer something that autodetects first try then option to choose if that doesn't work._
Should translation apply only to the long description, or also short description / hints / logs? - If the intent is to have this usable from a GPSr then translate should work for descriptions (long and short), hint and logs (or at least selected logs)

[AgreeDK]

Addendum: language detection for mixed-language listings

Many caches (especially DE/NL/CZ owners) write the description twice — once in the local language, once in English underneath. Translating the whole blob wastes storage and translates text that's already understandable.

Proposal

Use a lightweight language detection library (e.g. py3langid — fast, pure Python, no heavy model to bundle) to detect language per paragraph rather than on the whole description at once, since paragraph breaks typically already mark the boundary between the two language versions in bilingual listings.

Processing flow:

Split the description into paragraphs
Run language detection on each paragraph
Only translate paragraphs that are NOT already in the target language (or not already in English, if the user is comfortable reading English and only needs help with e.g. German/Czech/Dutch)
Reassemble: paragraphs that were already understandable are kept as-is, only the foreign-language paragraphs are replaced by their translation

This both saves storage (no duplicate translation of text that was already in English) and saves translation time (Argos isn't run unnecessarily on text that's already understandable).

Known limitation: hints

Hints are often short (one or two sentences) and sometimes mix languages within the same sentence without a clear paragraph break — language detection is markedly less reliable on very short text. Likely need a manual "translate anyway" fallback button for cases where auto-detection guesses wrong or is low-confidence on short text.