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

Providing an alternate href attribute for clients that support client side translation is ok but I fear that it might not be very web compatible. If there are libraries, accessibility plugins or extensions already looking for the href attribute to where the destination will be this software would need to be adjusted to determine the real href the user agent is going to use. Since this is a user setting that software would need to detect whether or not client side translation is enabled.

I think there are lots of scenarios where an alternate href might have issues:
What URI do we show for the status bar when hovering?
What does Copy Link Address do?
Do all CSS attribute selector rules need to be duplicated, etc.

This feature is about a very niche case but with lots of impact for non-english consumers of content. A large percentage of search queries are non-english queries with English locale set. The English locale setting is a status symbol in these markets.

An alternate URI method still misses a property that we need, the ability for the server to influence the next page's language translation. And I believe this is the core of the issue that TAG sees in this request. My position is that the page already has an influence of what the next URI is (whatever language it wants it in) because it is explicitly linking to it. And today search engines might link to server side translation engines. That this proposal is just acknowledging client side translation exists and extending its functionality so that the previous page provides some context to the next page.


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