Having fun with the revelation that Kagi Translate is actually something like a thin wrapper over an LLM, so you can pass anything you want as the "to" language in the URL's query string and it will do its best to "translate" your text to that
https://translate.kagi.com/?from=en&to=pentagon+speak&text=I+think+we+should+break+up.
Translate to "marxist academic"
https://translate.kagi.com/?text=I+think+we+should+break+up.&from=en&to=marxist+academic
Translate to "instagram thot"
https://translate.kagi.com/?text=I+think+we+should+break+up.&from=en&to=instagram+thot
Translate to "slurping soup eater"
https://translate.kagi.com/?text=I+think+we+should+break+up.&from=en&to=slurping+soup+eater
@jalefkowit and, since this is fedi and SOMEONE is going to ask what the real RFC 8675 is:
This document specifies the initial version of a YANG module "iana-tunnel-type", which contains a collection of IANA-maintained YANG identities used as interface types for tunnel interfaces. The module reflects the "tunnelType" registry maintained by IANA. The latest revision of this YANG module can be obtained from the IANA website. Tunnel type values are not directly added to the Tunnel Interface Types YANG module; they must instead be added to the "tunnelType" IANA registry. Once a new tunnel type registration is made by IANA for a new tunneling scheme or even an existing one that is not already listed in the current registry (e.g., LISP, NSH), IANA will update the Tunnel Interface Types YANG module accordingly. Some of the IETF-defined tunneling techniques are not listed in the current IANA registry. It is not the intent of this document to update the existing IANA registry with a comprehensive list of tunnel technologies. Registrants must follow the IETF registration procedure for interface types whenever a new tunnel type is needed.
Jason Lefkowitz
SnoopJ
