dka: where are we?

dtapuska: Search sometimes redirects pages to server-side translation. That misses out on a whole lot of dynmaic pages. Client-side translation exists in some browsers; produces better experience. Want to avoid server-side translation if we can. Can detect based on prototype chain. Was some discussion in the github issue about whether we should be doing this, whether you know the locale. The server is returning the page, and putting text there and directing you to the server-side translation, so user settings don't come into pplay. The server is controlling things. So I don't think we're taking anything away from the user; allowing use cases that weren't possible before.

hadley: what concerned me when we last looked is that the model of the web is that user gets to control the experience through teh user-agent. Thus the client-server relationship is between the user and the server. This looks like puts a different server in control and takes power away from the user. Specific example?

dtapuska: Example was searching in Google search, searching for a german news site. Ends up with translate attribute that redirects to translate.google.com with url that you were loading. The page you're interacting with is responsible for the next links; that's what we're trying to cnotrol. What's happening with server side translation is that half the page isn't translated (javascript).

dka: the underlying assumption is that the referring site knows something the browser doesn't know? Doesn't the browser send header with its language preferences? What if the server gets two signals that are conflicting? Is the current client-side signal not adequate?

dtapuska: The client-side signal won't translate. What we're after is that search can return pages in any language. If you think about the web from the point of view of non-English, when much of the web is in English. We're trying to enhance the web for that opportunity. If a language is in your accept-language, the server's probably not going to set the hrefTranslate attribute.

hadley: I understand you want the UX in the translate mode to work smoothly; still confused about why to do that in the page rather than in the browser.

dtapuska: in the referrer page, would use hrefTranslate and original href instead of setting href to translate.bing.com?url=... . And translation then works better because it's client-side rather than server-side.

hadley: wouldn't make more sense to do that in http rather than in the referring page?

tess: e.g., browser UI that begins the auto-translating browsing mode.

dka: I still don't understand why accept-language header isn't sufficient. I click link to Der Spiegel, why doesn't Der Spiegel ask me to translate the content to English through its use of Google Translate?

dtapuska: You could handle those pages using accept-language, but a lot of the web doesn't have the resources to deliver that content in different languages.

hadley: Would it make more sense... if you want it to all run in the client... to build a version of translate into the browser?

dtapuska: That's what this is -- that's the client-side translation that occurs.

... it allows the referrer page to serve pages that don't match the language that you can read.

tess: given that the idea is having a browser feature that does translation, presumably with UI in the browser to activate this mode... why does there have to be any difference in the web content at all? Why do I need to cause the translation to happen in my page content? Why does content have to change at all?

dtapuska: mainly, problems with mixed content modes. If you combine language, you get into wierd scenarios where you don't know if you should translate. So we took the approach of being explicit.

tess: Isn't the user turning the feature on the explicit signal?

dtapuska: I'd assume the feature would be on be default. That's the way it works in Chrome today -- translate is on by default but opt-out.

hadley: Since many users aren't native English speakers or don't want content in English, would you imagine this being included on every href since we don't know what users will need translated?

dtapuska: What search team was after was how to make translate attribute work better. I don't think it's applicable to every single href. Not a magical attribute you'd add everywhere.

hadley: It does a bit... it makes it feel it's trying to solve a problem for a particular kind of user that's not about the web itself but about how they expeirence the web -- seems to be the kind of thing that lives in the user agent.

dtapuksa: This attribute lies between the HTML and the user-agent. The user agent looks at this and decides to do something different... like an accessibility thing where you could do something different at the user agent level.

hadley: not more efficient to just have the UA translate things if the user wants them translated?

dtapuska: comes down to that we could get it wrong sometimes

tess: the browser can get it wrong, so sites that link to other sites should change their content to work around it?

tess: so today if your browser backend for autottranslation... what if one browser has a good result and the other browser doesn't. How do you write the page?

dka: One thing I'd like to see is how this works with any translation service, any search provider, and any browser. I'm hearing a lot about how this works with Google ones.

dtapuska: The attribute is feature-detectable. But Tess's problem of whether one browser returns a good result or not is certainly a problem. The referrer page has to pick a translation service...

tess: But with the attribute the referrer page doesn't choose a translation service, that's now a browser decision.

dtapuksa: I don't have a good answer there.

... Previously, if the page wanted translation, they were choosing a translation service that would be good. I'd imagine if it were bad in some browsers they'd have to use hrefTranslate in only some browsers.

tess: Since it's an attribute it's feature detectible... so if writing HTML and most browsers don't have this feature... if I'm writing HTML with translate.google.com?url=... for browsers that don't support hrefTranslate, won't the hrefTranslate then translate it twice if you add it. The fallback story is strange; you have to do content-rewriting.

dtapuksa: The primary target of this is machine-generated pages, not handwritten HTML.

kenneth: how does this work when sharing URLs? This seems like it would be very confusing to people.

dtapuksa: Hopefully in those cases the translation engine pops up and solves it. This is mainly avoiding the roadblock of having users click "I want to translate this page"

Kenneth: so if I'm on a page that's already translated I probably want those translated as well?

dka: Isn't there a social value to the user knowing that the text has been translated and wasn't written as-is by the author? Translation is imperfect. Can get the gist. If I found myself reading broken English and didn't know the pgage hade been translated, is that the experience I want? Shouldn't the user know it's been translate.

dtapuksa: I think there's a user-agent point of view -- UA could indicate that pages are translated in all sorts of fashions. It's up to the UA to provide that signal. That said, people may key off URL being translate.....com?url=...

dka: Feel like this has been a good discussion; sorry if you're hearing negativity.

dtapuksa: This is a proposal, what we wanted to do was experiment with this and determine whether it gets better engagement. That's the state of the world for this feature. Trying to run experiments with this attribute. See if it's a good/bad idea. Obviously want to get TAG feedback on the approach we prototyped.

dka: Would also be good to get feedback from other search providers and other translation service providers.

dtapuska: Do have feedback from Microsoft, not from others. If you have contacts, happy to reach out.

dka: Leave this open in a monitoring sense, and hear back about the experiment?

dtapuska: I'll ping the issue when we have experiment feedback.

Hadley: We had dtapuska on a call, and he still doesn't seem to agree with our suggestions about how the web platform works. Not sure what we should do next?

David: My memory of that thread is that there was also a fair bit of misunderstanding in the issue.

Hadley: Which misunderstandings are you thinking of? If we can, that would be useful

Torgo: Let's look at it next week. If we still aren't happy, having cleared up those miscommunications... I'll add David to it, since he's going to do that

Hadley: I had another look at this. Looks like dtapuska opened it again... didn't know that was possible.

Peter: I re-opened it after he asked.

Hadley: Looks like he has taken feedback on board, but hasn't resolved my fundamental issue that the UA doesn't determine the language of the page...

... User agent is there for the user to express their preference to a website. Breaks that model for the preference to come from the referring website. We already have lots of discussion of this on the issue.

Peter: Ironic that Google.com is notoriously bad at selecting the language for the user when you change locations, on google.com anyway.

Hadley: So what should we do? David?

David: Maybe we should figure out what has changed with the request. I agree with your concern about the outgoing page choosing the language.

Hadley: Let's bump this week.. you're right, we should look at the changes that have been made. We still have the same underlying concern, though, and it doesn't seem to have been addressed.

David: It's not clear what changes have been made; the PR hasn't changed as far as I can tell.

Hadley: Great, we can just ask what has changed.

Hadley: We only have 1 minute left, I would like to spend more time than that on this issue.

Hadley: discussed recently?

(looks like we discussed it 4 weeks ago)

Hadley: (reads chrishtr's last comment) Still seems like it's changing relationships: putting the referring site in the position of being the user agent. I feel like we keep going in circles on this.

Hadley: Also 4 comments up... misses that what we meant by "one browser" is that the only browser team involved is Google.

Hadley: Fundamentally I think this is from the ethical principles -- just not the way we think things work.

Alice: curious what you thought of chrishtr's answers to the second quoted question in this comment

Hadley: As someone who cares about Privacy, it frightens me that we would transfer responsibility for knowing my preferences to the website. He says relying on the UA only is too limiting to know what preferences are, works against openness, decentralization, and choice. It doesn't in the way I think about those terms. I feel like his last sentence about "smart sites" is useful but very different from offering suggestions to the next site.

Hadley: I'm stuck -- we already closed this "unsatisfied"; that's what I keep coming back to. I think we're fundamentally on different pages here about how the web works.

Peter: I'm also consider the explanier suggests it would influence the Accept-Language HTTP header... which it really shouldn't be doing.

Hadley: Have we written that down?

Peter: Not sure.

Hadley: We had in our feedback a year ago, from Paris... we talked about Accept-Language from the UA as an alternative. So I don't think it was in the explainer then.

Peter: I agree it's the wrong design; I don't see anything convincing me otherwise.

Alice: how convinced are you about the use cases they've explained?

Hadley: not convinced because the way I'm reading the use cases, they're use cases about developer of one website wanting more control about what happens on another website.

Peter: Only thoughts are either (a) close again or (b) invite Dave to a call to try to explain to us what we're missing?

Hadley: I'm up for that.

Alice: I could...

Hadley: Did we have a call with him before?

David: I think so.

Peter: I'm happy to if we think it would make progress. Make the offer... leave it up to him?

Hadley: I don't remember chrishtr being in the discussion then -- maybe a conversation with both would be useful?

Alice: I'm happy to ask if they could join us.

Hadley: complications - we discussed tradeoffs and knock-on effects. We agreed they would expand on these issues in the explainer which has not really been done. This is largely where it was. they did add a ToC which we asked for. doesn't encapuslate the richness of our discussion. We had concerns - not reflected. David commented - expanding on his concern that the asusmption is that one site knows more about the language preference than the browser, this promotes a walled garden view of the web. I understood they had made achange to make it more browser-centric.

David: it was always a hint to the browser to translate that site into the language specificed.

Hadley: so the browser must do something sensible with that?

David: if the search engine sends to the browser that the user wants this translated into X then maybe the browser should ask "is this your prefered language"?

Hadley: what would you like them to do with it? ... permisison prompt when href tranfstalte is encountered from non-trusted sites. how much belongs in the spec vs implementation specific.

David: i think it's worth mentioning that idea informatively.

Hadley: I don't see most of what we wanted in the explainer. we talked about the permission model and the danegrs of giving blanked protections. They have added one line to the answer to the privacy & security questionnaire. I feel the explainer doesn't capture the thought process that went into shaping htis proposal - so UAs can't make sensible decisions about what the dangers are. So i feel we have put a lot into this - open for a year - 2 calls on it - and a long issue thread - don't feel we can go further.

Dan: We should close ?

David: we should say something like "we were expecting a bit more change to the explainer" - one last chance. I could craft that.

O