Lingva & Simply Translate are two different front-ends to Google Translate. I’m not running the software myself because I run Argos locally (for privacy), but when Argos gives a really bad translation I resort to Lingva and Simply Translate instances.
I tried to translate a privacy policy. Results:
Lingva instances:
- translate.plausibility.cloud ← goes to lunch
- lingva.lunar.icu ← gives “414 Request-URI Too Large”
- lingva.ml & lingva.garudalinux.org ← fuck off Cloudflare! Obviously foolishly purpose defeating to surreptitiously expose people to CF who are trying to avoid direct Google connections.
- translate.igna.wtf ← dead
- translate.dr460nf1r3.org ← dead
Simply Translate instances (list of instances broken for me but found a year-old mirror of that):
- simplytranslate.org ← just gives a blank
- st.tokhmi.xyz ← up but results are just CSS garbage
- translate.bus-hit.me (ST fork mozhi) ← shoots a blank result
- simplytranslate.pussthecat.org ← redirects to mozhi.pussthecat.org
- mozhi.pussthecat.org (ST fork mozhi) ← shoots a blank result
- translate.projectsegfau.lt (ST fork mozhi) ←translates the first word then drops the rest; this instance is incorrectly listed as Lingva
- translate.northboot.xyz ← up but results are just CSS garbage
- st.privacydev.net ← up but results are just CSS garbage
- tl.vern.cc ← up but results are just CSS garbage
~~It looks as if Simply Translate is not keeping up with Google API changes.~~ (edit: actually the CSS garbage is what we get when feeding it bulky input -- those instances work on small input)
graveyard of dead sites:
- simplytranslate.manerakai.com ← redirects to vacated site
- translate.josias.dev
- translate.riverside.rocks
- translate.tiekoetter.com
- simplytranslate.esmailelbob.xyz
- translate.slipfox.xyz
- translate.priv.pw
- st.odyssey346.dev
- fyng2tsmzmvxmojzbbwmfnsn2lrcyftf4cw6rk5j2v2huliazud3fjid.onion
- xxtbwyb5z5bdvy2f6l2yquu5qilgkjeewno4qfknvb3lkg3nmoklitid.onion
- translate.prnoid54e44a4bduq5due64jkk7wcnkxcp5kv3juncm7veptjcqudgyd.onion
- simplytranslate.esmail5pdn24shtvieloeedh7ehz3nrwcdivnfhfcedl7gf4kwddhkqd.onion
- tl.vernccvbvyi5qhfzyqengccj7lkove6bjot2xhh5kajhwvidqafczrad.onion
- st.g4c3eya4clenolymqbpgwz3q3tawoxw56yhzk4vugqrl6dtu3ejvhjid.onion
Why this is a bug
Frond-ends and proxies exist to circumvent the anti-features of the service they are facilitating access to. So if there is a volume limitation, the front-end should be smart enough to split the content into pieces, translate the pieces separately, and reassemble. In fact that should be done anyway for privacy, to disassociate pieces of text from each other.
Alternatively (and probably better), would be to have a front-end for the front-ends. Something that gives a different paragraph to several different Lingva/ST instances and reassembles the results. This would (perhaps?) link a different IP to each piece assuming the front-ends also proxy (not sure if that’s the case).
I assume you’re talking about the US, right? Guessing on the basis that Europe does not seem to have credit unions AFAICT.
The ID requirement may be fair enough.. something we have to live with if it’s a legal obligation. But in Europe it’s a bit of a disaster because the post office doesn’t just accept any ID. It must be from the EU and must have a chip that their system can read, so they can collect your residential address and track payers digitally. Of course that all breaks down if the ID doesn’t have a chip, or the chip does not have the info the system is trying to extract. Then the post office just refuses the money. Staff are becoming more and more helpless when digital systems cannot handle various scenarios.