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).
One of the (otherwise helpless) bankers I spoke to said Visa is probably not accepted by Geldmaat. I thought the banker had to be wrong but maybe they meant to say visa debit does not work. Yet I have a receipt from a functional Geldmaat machine which says “visa debit” in a field named “app. label”. Then at the bottom of the receipt it (incorrectly) says “credit card account … credit limit …” which actually reflects the card balance.
Some point of sale terminals are said to only work with visa credit or visa debit, but then I’ve had banks tell me their cards act like what the machine wants it to be. I’m fuzzy on the details. There are situations where you have to choose “credit” or “debit” on the terminal, and the bank says I can choose credit even if it’s debit, and vice versa. So it’s hard to pin down what’s going on. I don’t even get why the distinction between the two exists at the network API level. It’s not the business of the merchant or the ATM to know those details.
I can only imagine that perhaps it’s there for casino situations. A credit card holder once went to LasVegas with a credit card from a region where gambling is illegal. One of the laws was that it’s illegal to collect on a gambling debt. So he took a cash advance on his credit card inside a casino, lost it all, then returned home and told the bank it’s a gambling debt, get lost. My understanding of the story is that he got off the hook for the debt on that basis. But I wonder if that’s why this distinction exists on the card networks.
Another theory is that credit cards have more buyer’s protections and higher fees to the merchant and so some merchants don’t like that and want to insist on debit cards. But the ATM seems like the reverse of that.
Anyway, maybe not all Geldmaat machines are the same.
I appreciate your insight. Perhaps some of the refusals is related to visa debit incompatibility.
Well free to the customer but the ATM likely still profits. My bank eats the atm fee but they have no deal to hide the fee from the customer. So I agree to the fee, see the fee on the receipt, and the fee appears on the bank statement followed by a credit back in the amount of the fee. EU accounts probably just hide the fee from the customer otherwise ATMs would not be sustainable.
update
This page says:
(emphasis mine)