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

So my summary of where we are I think is roughly this:
* @dtapuska's use case largely starts from the idea that client-side translation provides a better user-experience than server-side translation because client-side translation can work well on a much wider range of pages (using the range of web APIs) rather than only on largely-static pages
* today only some browsers have client-side translation, and the options for fallback that are available today to provide one experience for browsers with client-side translation and one for those without aren't very good.  In particular, authors can offer server-side translation everywhere, or they can offer client-side translation in browsers that have it falling back to no translation without client-side translation, but they can't easily offer client-side translation in browsers that have it falling back to server-side translation for browsers without. *I see the ability to provide that fallback as the core use case that this spec enables, although I'm not sure if @dtapuska would agree with that characterization.*
* @hadleybeeman points out that **another** significant advantage of client-side translation is that the client may have a better idea of the user's desired language than the server, **and** that this is well within the space of choices that are normally chosen by the client rather than the server.  I believe most or all of the TAG agrees with this.

The solution proposed in this issue has two characteristics that the TAG is concerned about (though we've had much more discussion of the first; I'm not sure how widely the second concern is shared):
* has the server choose the language for client-side translation
* addresses fallback using a javascript-only mechanism, by requiring detection of `hrefTranslate` support and replacement of the `href`

I believe there exist alternative solutions that would avoid one or both of these problems while still addressing the use case of allowing sites to depend on client-side translation but fall back to server-side translation in implementations that don't support client-side translation.

For example:
* a solution that provides only for javascript feature-detection of client-side translation would fix the first problem though not the second
* a solution that provides a second `href`-like attribute that would be used (when present) instead of `href` by browsers that support client-side translation would address both of them, although with the disadvantage that in the case when it is used (i.e., the case where the author wants fallback from client-side translation to server-side translation) the more "semantic" href is in an attribute other than `href`

I'd note that the TAG's preference for what language is used makes the "fallback" here less exact of a fallback (since it may be falling back to displaying a different language when using server-side translation than it would when using client-side translation).  However, I think we feel that that is the correct thing to do in the service of providing the best experience available for each case.

-- 
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-483960678