Essential insights from Hacker News discussions

Web Translator API

Here's a summary of the themes discussed on Hacker News, with direct quotes:

On-Device Translation and LLMs in Browsers

A significant portion of the discussion revolves around browsers, particularly Chrome and Firefox, integrating on-device Large Language Models (LLMs) for functionalities like translation. Users express interest in this approach, citing privacy and efficiency benefits.

  • "Chrome embeds a small LLM (never stops being a funny thing) in the browser allowing them to do local translations." - Raed667
  • "I assume every browser will do the same as on-device models start becoming more useful." - Raed667
  • "Firefox also has on-device translations for what its worth." - its-summertime

Practical Implementation and Command-Line Tools

Several users are interested in utilizing translation models outside of the browser, specifically as command-line interface (CLI) tools. They discuss the ease of use and the viability of smaller models for this purpose, as well as the need for multilingual capabilities.

  • "What's the easiest way to get this functionality outside of the browser, e.g. as a CLI tool?" - Asraelite
  • "Last time I looked I wasn't able to find any easy to run models that supported more than a handful of languages." - Asraelite
  • "ollama run gemma3:1b" - ukuina
  • "Try to translate a paragraph with 1b gemma and compare it to DeepL :) Still amazing it can understand anything at all at that scale, but can't really rely on it for much tbh" - diggan
  • "If you need to support several languages, you're going to have to have a zoo of models. Small ones just can't handle that many; and they especially aren't good enough for distribution, we only use them for understanding." - _1

Model Specificity and Performance

There's a discussion about the trade-offs between model size, language support, and translation quality. Users point out that smaller models might struggle with a wide range of languages or nuanced translations, while larger models may not be suitable for all devices due to performance constraints.

  • "Small ones just can't handle that many; and they especially aren't good enough for distribution, we only use them for understanding." - _1
  • "That depends on what counts as “a handful of languages” for you." - JimDabell
  • "Plus, mistral-small3.2 has too many parameters. Not all devices can run it fast. That probably isn't the exact translation model being used by Chrome." - jan_Sate
  • "I haven’t tried it myself, but NLLB-200 has various sizes going down to 600M params:" - JimDabell
  • "mftrhu: Setting aside general-purpose LLMs, there exist a handful of models geared towards translation between hundred of language pairs: Meta's NLLB-200 [0] and M2M-100 [1] can be run using HuggingFace's transformers (plus numpy and sentencepieces), while Google's MADLAD-400 [2], in GGUF format [3], is also supported by llama.cpp." - mftrhu

Standardization Process and Browser Implementation Practices

A considerable portion of the thread is dedicated to critiquing the standardization process and Chrome's perceived practice of shipping features unilaterally. Users express concern that Chrome might be pushing its own APIs as de facto standards, echoing past behavior.

  • "What compatibility? It's Chrome-only." - tempodox
  • "While this might be useful, be mindful: - it's experimental - the "specification" is nowhere near a standards track: https://webmachinelearning.github.io/translation-api/" - troupo
  • "Of course it's already shipped in Chrome, and now Chrome pretends that its own Chrome-only API is somehow standard. Expect people on HN to blame other browsers for not shipping this." - troupo
  • "This gives strong IE vibes." - nachomg
  • "This is the W3C standardization process. The W3C is not a prescriptive standardization body. It doesn't have any regulatory power giving it any teeth to go after vendors acting in bad faith. So the W3C process is descriptive and encourages a period of competitive divergence in implementations. It is only after the early adopters have hammered on the features and figured out which parts they like best that a Web API can then start to get standardized." - moron4hire
  • "The literal "Draft Community Group Report" (and not a working draft) is a literal link to w3c standardization process: https://www.w3.org/standards/types/#CG-DRAFT Since the words "not on the W3C Standards Track" from the document didn't persuade you, you could go to the actual w3c process and answer a few simple questions..." - troupo
  • "For a person who is so confidently talking about the w3c standards process, I'm surprised you don't. w3c doesn't explicitly state this. Except for the final few stages, all steps in the process contain the following: "Software MAY implement these specifications at their own risk but implementation feedback is encouraged." However. Since this is browsers we're talking about, it means that whatever browsers ship enabled by default will remain in the wild forever because people will immediately start depending on that implementation." - troupo
  • "The way to do it, especially for APIs that are nowhere close to being "waiting for final acceptance" is: ship behind a flag, iron out issues and differences, perhaps change the API (and changes to API happen all the time), then ship. Of course, Chrome shits all over this process and just ships whatever it wants to ship." - troupo
  • "I honestly don't understand the arguments Mozilla have against it." - sandstrom
  • "Safari/webkit is positive (though no official stance yet): https://github.com/WebKit/standards-positions/issues/339#iss..." - sandstrom

User Experience of Auto-Translation

There's a division in opinion regarding the practical utility of auto-translation features. Some users find existing auto-translation to be of poor quality and intrusive, while others believe native browser implementation could be beneficial by allowing users to disable it if they prefer.

  • "Can we please NOT autotranslate the web? I have yet to find a site where the quality of autotranslate does not make me stop using that site." - lynx97
  • "sandstrom: This is not auto-translation. Rather, it's an API developers can use to add inline translation to web apps." - sandstrom
  • "The good news is that if the browsers offered this natively, websites wouldn't need their own implementation of this. And if it's in the client (the browser), you're most likely gonna be able to turn it off globally, just like how you like it." - diggan
  • "Worst case scenario a user-script/extension could monkey patch it out, but probably clients will let you disable it." - diggan