Re: [w3ctag/design-reviews] Web Translation API (Issue #948)

We agree with and support the user need. Here are our thoughts...
  
1. It would be good to have a list of use cases. We could think of some from our own experience, but they may be different than the ones you had in mind. Having an explicit list of use cases ensures that everyone is on the same page.

2. Please continue chatting with the I18N WG folks about [issue 11](https://github.com/WICG/translation-api/issues/11), and [streaming input support](https://github.com/WICG/translation-api?tab=readme-ov-file#streaming-input-support).
  
3. We're concerned about the use of the network. Specifically, use of the network to download a model, or use of the network to actually perform the translation, could introduce both delay and privacy issues. Is it possible for the developer to specify: "only do this if network access is not required"? We feel that differentiation between fast-local, slow-local (i.e. with downlaod), and remote/cloud-based cases is important for MVP.
  
4. We loved the approach you propose to partitioning, and using a fake download, to mitigate fingerprinting!
  
5. We recommend a translation-specific namespace instead of `ai`.
  
6. Why is a separate namespace needed at all? We understand these objects are not constructible due to the asynchronicity, but since they are creating instances of the same class, making this obvious by adding the factory as a static method of this class seems more consistent with precedent. Same for the `capabilities()` method, we don't understand why this needs to live in a different namespace, and we think that the more objects this API is spread across, the harder it will be for authors to understand how the different parts fit together.
  
6. We think there should be a prominent note encouraging developers to make use of professional translation of pre-existing content rather than doing automatic translation wherever they can - for both accuracy and efficiency reasons.
    
7. It seems to make more sense, and help simplify the API and alleviate some privacy concerns if the UA renders the download progress bar.
  
8. We did wonder if it would make sense to have a single object for the detection and translation, since they are so related (and often detection is the first step to translation). Was this direction explored?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/948#issuecomment-2256555364
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/948/2256555364@github.com>