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

This was discussed in the call today, for which [minutes](https://github.com/w3ctag/meetings/blob/gh-pages/2019/telcons/11-12-minutes.md) should soon be available.

-----

I wanted to follow up on one point I raised in the discussion today.  @chrishtr made the good point that one of the motivating factors here is that (a) many users don't know how to configure browsers or even understand the difference between the browser and the website and (b) the sites they're using (say, Google or Facebook) might be able to figure out through the text that the user types or interacts with what language the user wants to speak.  I found this to be the most convincing argument for work in the problem space of having the site suggest the user's desired language.

However, this particular proposal results in each site being allowed to fix things for outbound links from *their* site, but the user's browser still not knowing the user's preferred language, and thus not being able to suggest the correct translation for all sites.  This can push the user towards a more **walled-garden view of the web** -- if Google is the only site that knows their preferred language, then they can only browse the web starting from Google.  If Facebook is the only site that knows the user's preferred language, then they can only browse the web starting from Facebook.  But if the underlying mechanism was instead a way for the site to suggest to the browser that it knows something about the user's preferred language, then the browser might be able to ask the user if they prefer another language (perhaps even by asking in both its currently configured language and the newly proposed language).

During the call I suggested the first idea that came to mind, that the site could just directly suggest to the browser what they think the user's preferred language is, and the browser could choose to act or not act on that information.  Now I realize that the browser could, if it wanted, do something with the `hrefTranslate` information and make the same suggestion to the user based on that information.  (Would it make sense for the explainer to suggest this possibility?)

-----

There was one other issue @hadleybeeman asked me to raise at the beginning of our discussion and I said I'd rather move on to the other points -- but I never actually managed to come back to it.  I think we were also somewhat concerned that many of the fallback options here require javascript.  I think it's also worth thinking about the different sorts of **fallback** that might be desired.  I feel like we discussed this issue before but I don't see it above, so I'll state it here (possibly again).

In particular, if the linking site's first preference is to link to `https://example.com/` with `hrefTranslate=hi`... it seems different sites might have different preferences for what should happen as fallback if the browser doesn't support client-side translation.  Option (1) might be that the linking site would prefer the user just go to `https://example.com/` without any translation or other intervention.  Option (2) would be that the linking site would prefer to link to `https://translate.google.com/translate?sl=en&tl=hi&u=https%3A%2F%2Fexample.com%2F` in order to use server-side translation.  Currently the mechanism proposed here defaults to (1), even though I suspect more sites probably want (2), whereas doing fallback type (2) requires Javascript.  Perhaps that's OK; it at least keeps the markup "cleaner" from a certain perspective.

At the very least, it seems like the explainer should mention the question of fallback for browsers that don't support the feature, point out that the attribute should only be implemented in implementations that support client-side translation so that feature detection works, and perhaps give an example of feature detection.

I'd also note the explainer currently says:

> Automatically fallback to server-side translation if client side isn’t supported

... which isn't really true, since that's not the fallback that happens automatically.

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