Re: [w3ctag/design-reviews] hrefTranslate attribute (#301)

> Would you mind clarifying which specific part of the new explainer you're referring to, just for easy access?

Sure thing. The [list of Pros](https://github.com/dtapuska/html-translate#proposal---hreftranslate-attribute) of the API includes the points I'm making here, plus more.

The [Problem Statement](https://github.com/dtapuska/html-translate#problem-statement) section also goes into more detail about the problems caused by sites trying to help out the user with translation without any UA coordination. In particular, it's not just rendering quality.


> Could you elaborate on why a UA couldn't solve this problem by making those settings easier to access (for example, prompting a user who frequently searches via the address bar in language A but has their UA language set as language B to set their UA language to A)? Do the other factors alluded to rule out a purely UA-based solution?

To your first question:

If a user frequently searches via the address bar, then the UA could for sure learn something about their preferences. But almost all interaction with sites, other than the very special case of search, happens in the page itself and the UA (by design) has a limited idea of what is going on.

To your second:

A hypothetical UA that reads all of the content of your websites and observes what you do could build machine learning models that predict your language preferences. To some extent browsers today attempt to do that, by observing the detected language of visited pages and keeping statistics.

But to rely on the UA and only the UA for this is much too limiting, and actually works against open-ness, decentralization and choice. There is room for smart sites to offer suggestions to the browser to help the user experience, with the user's permission.




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