[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 Michelle Lee Kosik kosi...@mail.com changed: What|Removed |Added CC||kosi...@mail.com -- You are receiving this mail because: You are watching all bug changes. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 Allen Stambaugh allen4na...@gmail.com changed: What|Removed |Added CC||allen4na...@gmail.com -- You are receiving this mail because: You are watching all bug changes. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #41 from Brion Vibber br...@wikimedia.org 2011-11-30 16:16:50 UTC --- *** Bug 32725 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #42 from Michael Zajac mich...@zajac.ca 2011-11-30 18:05:50 UTC --- FYI, the lang attribute for elements on the page is supported by VoiceOver, which comes with iOS and works in Safari. It loads appropriate voices when available, and reads various-language text properly. I'm not a regular user, but successfully tested the demo on this page. http://www.456bereastreet.com/archive/201004/using_the_lang_attribute_makes_a_difference/ -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #43 from Brion Vibber br...@wikimedia.org 2011-11-30 18:28:29 UTC --- (In reply to comment #42) FYI, the lang attribute for elements on the page is supported by VoiceOver, which comes with iOS and works in Safari. It loads appropriate voices when available, and reads various-language text properly. I'm not a regular user, but successfully tested the demo on this page. http://www.456bereastreet.com/archive/201004/using_the_lang_attribute_makes_a_difference/ I can confirm this on my iPod Touch (iOS 5.0.1), and it is *awesome*. :) This also works on many of the language links on https://www.wikipedia.org/ which have lang= attributes to specify the language of their contents. The ones in our sidebar still don't, so they get funny accents (ess-pa-NOL instead of ess-panyol). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #44 from Michael Zajac mich...@zajac.ca 2011-11-30 19:22:47 UTC --- This also works on many of the language links on https://www.wikipedia.org/ which have lang= attributes to specify the language of their contents. The ones in our sidebar still don't, so they get funny accents (ess-pa-NOL instead of ess-panyol). Except names in non-Latin writing systems are read out as “unpronounceable.” Adding lang attributes would enable a number of these, including Chinese, Greek, Hindi, Indonesian, Korean, Russian, and Thai. List of supported languages: http://support.apple.com/kb/HT3562 It's remarkable, but right and proper, that this is now mainstream technology, in hundreds of millions of devices in people's hands. We support MathML for Professor Fizzbunkle. Hooray. Let's try to support reading text and following links for the one in 40 with impaired vision. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #45 from Brion Vibber br...@wikimedia.org 2011-11-30 22:04:14 UTC --- (In reply to comment #44) This also works on many of the language links on https://www.wikipedia.org/ which have lang= attributes to specify the language of their contents. The ones in our sidebar still don't, so they get funny accents (ess-pa-NOL instead of ess-panyol). Except names in non-Latin writing systems are read out as “unpronounceable.” Adding lang attributes would enable a number of these, including Chinese, Greek, Hindi, Indonesian, Korean, Russian, and Thai. List of supported languages: http://support.apple.com/kb/HT3562 At least Chinese and Korean do read out, as long as they have the lang set... hence wanting to set them in other places. It's remarkable, but right and proper, that this is now mainstream technology, in hundreds of millions of devices in people's hands. We support MathML for Professor Fizzbunkle. Hooray. Let's try to support reading text and following links for the one in 40 with impaired vision. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #46 from Brion Vibber br...@wikimedia.org 2011-11-30 23:11:03 UTC --- Created attachment 9584 -- https://bugzilla.wikimedia.org/attachment.cgi?id=9584 More limited patch, only adds hreflang lang to sidebar interwiki links -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #47 from Brion Vibber br...@wikimedia.org 2011-11-30 23:13:15 UTC --- Created attachment 9585 -- https://bugzilla.wikimedia.org/attachment.cgi?id=9585 Recording of iOS 5.0.1 VoiceOver reading es, fr, ja, zh sidebar links (before) Readout from iOS's VoiceOver screen reader with es, fr, ja and zh sidebar links -- without the patch applied. Reads as: In other languages. Heading level 5. ess-pa-nol. link. fran-sayz. link. unpronounceable. link. unpronounceable. link. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #48 from Brion Vibber br...@wikimedia.org 2011-11-30 23:14:47 UTC --- Created attachment 9586 -- https://bugzilla.wikimedia.org/attachment.cgi?id=9586 Recording of iOS 5.0.1 VoiceOver reading es, fr, ja, zh sidebar links (after) Readout from iOS's VoiceOver screen reader with es, fr, ja and zh sidebar links -- with the patch applied. Reads as: In other languages. Heading level 5. Español. Français. link. Nihongo. link. Zhongwen. link. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #49 from Brion Vibber br...@wikimedia.org 2011-11-30 23:17:56 UTC --- Short patch above applied on trunk in r104778 (fixes the sidebar links). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #50 from Brion Vibber br...@wikimedia.org 2011-11-30 23:27:57 UTC --- REL1_18 in r104781, 1.18wmf1 in r104783. I'm leaving the bug open for the moment since there's still the hreflang on other links (and potentially if you know the link text isn't overridden you could try a lang, but that's tougher). Also of note: Roan reminded in IRC that the lang attr will be useful when applied to using WebFonts, since we can switch in the appropriate language font if needed based on presence of the lang attribute. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 Sumana Harihareswara suma...@panix.com changed: What|Removed |Added Keywords|need-review |reviewed CC||suma...@panix.com --- Comment #40 from Sumana Harihareswara suma...@panix.com 2011-11-25 19:55:00 UTC --- Marking patch as reviewed, since there's been so much discussion since Brion's initial patch and since trunk's moved on since he posted it. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 p858snake p858sn...@gmail.com changed: What|Removed |Added Keywords||need-review, patch -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #39 from Aryeh Gregor simetrical+wikib...@gmail.com 2011-05-20 18:44:09 UTC --- As usual, I can't resist arguing just a bit more . . . (In reply to comment #37) Then please define “regular browser,” at least broadly. Does this include MSIE 9? Safari 4? MSIE 6? Netscape 4? Mobile Safari? BlackBerry mobile browser? What about the yet-unreleased MSIE 10, Firefox 5, Safari 6, etc? Yes. Those all display web pages in basically the same way, give or take some details. Mobile browsers are a bit different, but they're mainstream enough that they fall into the same category -- a large percentage of people use them regularly. Thus we can easily make informed decisions about how various features will affect them. Just try it out. Search engine spiders and screenreaders work in fundamentally different ways from the browsers we use, and we don't have experience with how they work. (We here means you, me, and the overwhelming majority of Wikipedians/MediaWiki developers/etc.) We cannot easily know offhand what effects our decisions will have on such UAs, so we have to be much more cautious in making decisions based on those effects. Reasoning and evidence needs to be spelled out more explicitly than for regular browsers. Does it include supporting readers who navigate web pages using the keyboard? Exclusively? No, because almost no one does that. (Which, again, is not to say that those people are unimportant, but that other people can't easily evaluate the impact that changes will have on them.) Using a touch device? Yes, many people use smartphones regularly these days. Using a text-only browser? A braille display? Nope. (And why would you not include Google's indexer? I'd bet that more people access more Wikipedia articles through it than any other way.) We use the search results. That doesn't give us more than the most minimal insight into how the indexer works, beyond really basic stuff like it mostly doesn't do JavaScript. I think it's a mistake to categorize “regular” use of a website as that involving a narrowly stereotyped range of technology, especially if we try to define assistive technologies as irregular. This risks specifically ghettoizing a disadvantaged group of people. Design and technical features for accessibility have the potential to improve a whole range of uses of a website. I think it's a mistake to try adding features that you haven't tested and don't intend to test, that no one who reviews your code will test either, and that you'll probably never receive any real-world feedback on, solely based on something you read, where you are in no position to personally evaluate the validity of the source (e.g., have not been provided with info on how exactly specific real-world UAs will handle the feature). The most likely outcome is that the feature is useless, and in some cases it could be harmful. (See bug 15491 for an example of someone making incorrect claims about the accessibility impact of a particular bug, based on theoretical reasoning rather than actual testing.) because the ones who create and maintain site content, and MediaWiki developers and sysadmins, are overwhelmingly people who use regular browsers almost exclusively [Citation needed] It doesn't need a citation, because it's a tautology -- that's my definition of regular browser. Do you argue that more than a small minority (say, 5%) of the people I mentioned use screen readers regularly, or are personally familiar with how search engine spiders work (as in writing them and not just reading the results)? Those are't the standards we are using. We are using current, practical, accepted standards. You assume WCAG is practical. It's certainly not as useless as XHTML2, but it's not such a clearly good standard that I wouldn't prefer real-world info on how screen readers use the lang attribute. If you're aiming for usability improvements, give me an actual user study over a standard any day of the week. Interestingly, this is Google result #5 for WCAG: http://www.alistapart.com/articles/tohellwithwcag2 But FWIW, a quick Google search turns up some data that suggests that specific major screen readers really do use lang, so I'm fine with adding it (although I never had serious objections to start with): http://reference.sitepoint.com/html/core-attributes/lang http://developer.yahoo.com/blogs/ydn/posts/2008/03/yahoo_search_re/ I'd never have objected if that was the original reasoning given for the change, instead of WCAG. Real-world data is always more useful than standards, if your goal is to improve user experience instead of adhering to the standards per se. I see no strong argument against using hreflang attributes, but I don't think they're absolutely necessary. I support adding a feature that might improve the experience with assistive technology, but I'm okay with moving that to a separate
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #36 from Aryeh Gregor simetrical+wikib...@gmail.com 2011-05-19 18:22:13 UTC --- (In reply to comment #34) I don't accept that there's a useful concept of regular browser. The concept of a regular browser is essential, because the ones who create and maintain site content, and MediaWiki developers and sysadmins, are overwhelmingly people who use regular browsers almost exclusively. Any feature whose purpose is to change how pages work in regular browsers is easy for all of us to reason about. If something doesn't affect regular browsers, it's far more likely to be used improperly, because whoever's using it probably won't see the effect. Thus we need to be more careful when deploying it, to take care that it's actually useful. People using screen readers use them to operate (“regular”) desktop browsers. Is the Google search indexer a regular browser, or is Google Language Tools? Or Mobile Safari on an iphone used by a blind person? What about the screenscrapers used by the countless sites that syndicate wikimedia sites? None of these are regular in the sense I mean. That doesn't mean they're unimportant, but it means that it's much more important that we be careful about targeting features at them, because it's hard for almost all of us to directly evaluate the effects. Look at how much snake oil is marketed at SEO, or how often people provide alt text that's useless or even worse than useless (e.g., unpronounceable numeric filenames that screen readers will read out at length). Adding features that you haven't tested on the theory that they might be useful and probably won't hurt is not a great strategy for software development. We're not experts, and we don't have a detailed comprehensive survey of accessibility software and hardware capabilities, nor are we ever likely to. The best we can do is follow accepted, unchallenged standards. If you do have information that disputes them, I would be interested. But grumbling about them is unhelpful. I've argued in the HTMLWG with some of the people who write these standards. My (admittedly biased) take is that they know a lot about accessibility, but often don't fully appreciate the requirements of authors, browser implementers, or non-disabled users. A huge percentage of disputes about HTML5 that had to be adjudicated by Working Group survey, on the order of half, are about accessibility: http://www.w3.org/html/wg/#events That's because it's the browser implementers who edit the HTML5 standard, and the accessibility people are regularly unable to convince them that the requirements they want are reasonable, so the dispute essentially has to be arbitrated. Specs like WCAG are written by a11y experts with relatively little involvement of non-a11y-focused web experts, and IMO should be viewed with a healthy dose of skepticism as a result. (Which is not the same as saying they should be disregarded.) Even aside from that, many standards have a tendency to be impractical or theoretical. Lots of stuff in HTML 4.01 didn't match what any browsers did or intended to do, for instance. The XHTML line of standards after 1.0 was basically never implemented at all. Trusting that what standards say makes sense is maybe a reasonable first guess, but you definitely shouldn't assume it very strongly. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #37 from Michael Zajac mich...@zajac.ca 2011-05-19 20:04:57 UTC --- (In reply to comment #36) The concept of a regular browser is essential, [...] Then please define “regular browser,” at least broadly. Does this include MSIE 9? Safari 4? MSIE 6? Netscape 4? Mobile Safari? BlackBerry mobile browser? What about the yet-unreleased MSIE 10, Firefox 5, Safari 6, etc? Does it include supporting readers who navigate web pages using the keyboard? Using a touch device? Using a text-only browser? A braille display? (And why would you not include Google's indexer? I'd bet that more people access more Wikipedia articles through it than any other way.) I think it's a mistake to categorize “regular” use of a website as that involving a narrowly stereotyped range of technology, especially if we try to define assistive technologies as irregular. This risks specifically ghettoizing a disadvantaged group of people. Design and technical features for accessibility have the potential to improve a whole range of uses of a website. because the ones who create and maintain site content, and MediaWiki developers and sysadmins, are overwhelmingly people who use regular browsers almost exclusively [Citation needed] If something doesn't affect regular browsers, it's far more likely to be used improperly, [...] Yeah, we can't test everything in every browser, not even in every “regular” one. That's why we fall back on standards. Even aside from that, many standards have a tendency to be impractical or theoretical. Lots of stuff in HTML 4.01 didn't match what any browsers did or intended to do, for instance. The XHTML line of standards after 1.0 was basically never implemented at all. Trusting that what standards say makes sense is maybe a reasonable first guess, but you definitely shouldn't assume it very strongly. Those are't the standards we are using. We are using current, practical, accepted standards. But when the topic is accessibility, i.e. the availability of free and open information to a minority who may have disadvantaged access to it, we should be leading and liberal in adopting solutions that may reduce friction without causing appreciable harm. We should definitely use lang attributes here, which are standardized, recommended, and supported. I see no strong argument against using hreflang attributes, but I don't think they're absolutely necessary. I support adding a feature that might improve the experience with assistive technology, but I'm okay with moving that to a separate bug listing if it will give us consensus here. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #38 from Derk-Jan Hartman hart...@videolan.org 2011-05-19 22:25:57 UTC --- I sort of have to agree with Aryeh here. I mean, we could implement aural stylesheets, because it's somewhere in a standard and at the face of it looks very useful. But reality is, NOTHING in the whole world looks at the aural stylesheets, least of all screenreaders and no support is even remotely expected in the future. As such it's an exercise in pointlessness that adds bytes for the 400 million of unique visitors that we have to serve on a monthly basis. Not everything that is in a standard is a good idea in practice. XHTML proved that, and that was even WIDELY supported. I have not seen a good usecase for hreflang just yet, other than the google SEO technique, which is not applicable to interlanguage links. (lang is a different case, I fully support lang). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #33 from Aryeh Gregor simetrical+wikib...@gmail.com 2011-05-18 22:39:05 UTC --- (In reply to comment #32) Lang attributes aren't metadata. For the sake of argument, please interpret my use of metadata to mean information that's served in the webpage but doesn't noticeably affect the behavior of regular browsers. What number of blind people wanting to read Wikipedia, for example, would you consider a “nontrivial percentage?” Oh, pretty much any percentage. 0.1% would be fine, maybe even less. So long as it's not theoretical. What benefit does hreflang have to blind users, in practice? Identifying natural language changes in a document is a priority 1 checkpoint in WCAG 1.0, is required by the WCAG Samurai Errata, and is required for Level AA conformance in WCAG 2.0. None of your references appear to have anything to do with hreflang, as far as I can tell. Am I mistaken? They all seem to be about lang. I think comment 8 was pretty clear that I'm not objecting to adding lang, although I'd be happier if we had data about actual screenreaders that benefit (since WCAG et al. can be pretty ivory-tower sometimes). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #34 from Michael Zajac mich...@zajac.ca 2011-05-19 03:15:51 UTC --- (In reply to comment #33) Fair enough, Aryeh. I was arguing for using lang, which which the standards require, not for hreflang, which they do not (although I don't see any reason not to use HTML markup such as hreflang to tag known page elements, when each page already has about 30 kB of non-content markup, scripts, and style sheets). For the sake of argument, please interpret my use of metadata to mean information that's served in the webpage but doesn't noticeably affect the behavior of regular browsers. I don't accept that there's a useful concept of regular browser. People using screen readers use them to operate (“regular”) desktop browsers. Is the Google search indexer a regular browser, or is Google Language Tools? Or Mobile Safari on an iphone used by a blind person? What about the screenscrapers used by the countless sites that syndicate wikimedia sites? None of your references appear to have anything to do with hreflang, as far as I can tell. Am I mistaken? They all seem to be about lang. Right. I'd be happier if we had data about actual screenreaders that benefit (since WCAG et al. can be pretty ivory-tower sometimes). We're not experts, and we don't have a detailed comprehensive survey of accessibility software and hardware capabilities, nor are we ever likely to. The best we can do is follow accepted, unchallenged standards. If you do have information that disputes them, I would be interested. But grumbling about them is unhelpful. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #35 from Bawolff bawolff...@gmail.com 2011-05-19 03:45:24 UTC --- In the interest of fairness, googling suggest that generated css content is a potential use case for hreflang. You can use css to put ((fr)) after every french link or something like that. Its a kind of far fetched semi-theoretical use case, but its more concrete than anything said so far. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #15 from Andy Mabbett a...@pigsonthewing.org.uk 2011-05-17 11:57:54 UTC --- I disagree fundamentally with Aryeh; metadata should be provided as matter of course, so that it's there when others look for it. We shouldn't wait to be asked for two reasons - many potential users of it will not ask, they'll simply move on; and if they do ask, how long will it take us to implement it? In any case the question is moot, because there are already services wanting to use it, and finding us lacking in not having it: http://shkspr.mobi/blog/index.php/2011/02/qr-codes-for-museums/ -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 Derk-Jan Hartman hart...@videolan.org changed: What|Removed |Added CC||hart...@videolan.org --- Comment #16 from Derk-Jan Hartman hart...@videolan.org 2011-05-17 12:25:09 UTC --- In any case the question is moot, because there are already services wanting to use it, and finding us lacking in not having it: http://shkspr.mobi/blog/index.php/2011/02/qr-codes-for-museums/ @Andy I don't see why we would need hreflang for any of that what you linked to. I mean the iphone Articles app allows you perfectly well to switch between the interwiki language variants of an article, it doesn't need hreflang for that and nor should a QR service. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #17 from Derk-Jan Hartman hart...@videolan.org 2011-05-17 12:25:54 UTC --- For everyone who cannot keep up - lang: denotes the language of the text wrapped in the html element. It is usually only used if the language of the text doesn't match the rest of the text in the page. - xml:lang is the xml variant of lang. Since we are switching from xhtml1 to html5, xml:lang is less important adding both is probably a bit much. - hreflang: denotes the language of the page that the link points to. - alternate: denotes that the link is towards the same content as the current page, but in an 'alternate' version So a href=http://de.wikipedia.org/; hreflang=de lang=nlHoofdpagina van de Duitse Wikipedia/a is valid. It is Dutch language text in an English language page, that links to something written in German. But you cannot use alternate here, because that german mainpage is not the german version of this page that we are currently visiting, bugticket 4901 on bugzilla. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #18 from Derk-Jan Hartman hart...@videolan.org 2011-05-17 12:35:45 UTC --- (In reply to comment #13) I see that Wikipedia now has lang and xml:lang attributes on these links. The latter does seem pointless, since the root HTML element only has the former. We have the lang and xml:lang on inline interwiki links it seems. Not on interlanguage sidebar links. This can be observed in the sourcecode of the English Main page. The interwiki links in the sidebar are 'plain', but the interwiki links at the bottom under section Wikipedia languages have lang links. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #19 from Brion Vibber br...@wikimedia.org 2011-05-17 12:41:57 UTC --- The links you're seeing on http://en.wikipedia/org/wiki/Main_Page are not created automatically -- someone has explicitly placed a span inside the link. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #20 from Brion Vibber br...@wikimedia.org 2011-05-17 12:49:29 UTC --- Anyway long story short: * Adding a 'lang' attribute on interlanguage sidebar links should be easy to do and not a problem, and will help screen readers browser font selection. The text of the link is the native name of the language and therefore in that language. * Adding a 'lang' attribute on inline interlanguage links (inline interwiki links which are prefixes we also interpret as magic sidebar language links) is technically feasible, however may be problematic as we don't know whether the *text of the link* is in any particular language. * Adding cloned 'xml:lang' attributes anywhere is IMO pointless, everybody parses in HTML mode anyway. :) * Adding an 'hreflang' attribute on interlanguage sidebar links and on inline interlanguage links is technically feasible and doesn't hurt. Slight increase in output size, but not too bad I think. There could be some users for whom it would be welcome. Current draft HTML 5 spec for hreflang attribute: http://www.w3.org/TR/html5/links.html#attr-hyperlink-hreflang Note that the bug 20646 dependency isn't actually required for this bug to proceed; we already do interlanguage sidebar selection language name picking based on the interwiki prefix, so this would need only initially cover those cases. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #21 from Brion Vibber br...@wikimedia.org 2011-05-17 13:10:58 UTC --- Created attachment 8545 -- https://bugzilla.wikimedia.org/attachment.cgi?id=8545 Provisional patch Provisional patch adds: * hreflang on inline interwiki links whose prefixes match language names * lang hreflang on sidebar interlanguage links in SkinTemplate-based skins (tested Monobook and Vector) The older skins (Standard, CologneBlue etc) still need to be poked. Might be other funkiness. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #22 from Aryeh Gregor simetrical+wikib...@gmail.com 2011-05-17 14:16:56 UTC --- (In reply to comment #20) * Adding an 'hreflang' attribute on interlanguage sidebar links and on inline interlanguage links is technically feasible and doesn't hurt. Slight increase in output size, but not too bad I think. There could be some users for whom it would be welcome. Sure, but the same could be said of a ton of things. We could put rel=something on loads of our links (http://microformats.org/wiki/existing-rel-values#formats), and start putting RDFa and microdata all over the place. hreflang by itself wouldn't take up much space, but adding every piece of metadata of similar possible utility would make our output unreasonably long. For sanity's sake, we need to draw a line as to what kind of metadata we're going to output, and it's got to be more restrictive than someone might be able to use it. Current draft HTML 5 spec for hreflang attribute: http://www.w3.org/TR/html5/links.html#attr-hyperlink-hreflang You don't want to use the /TR version of W3C specs -- that's usually months outdated. Use the dev.w3.org version instead: http://dev.w3.org/html5/spec/links.html#attr-hyperlink-hreflang (Currently that's also labeled Working Draft, but only because a new Working Draft is awaiting publication. Usually it's labeled Editor's Draft.) Alternatively, use the WHATWG version so you don't have to worry about the W3C's crazy versioning scheme: http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#attr-hyperlink-hreflang The WHATWG version also includes extra features that aren't included in the W3C version because of feature freeze, plus a handful of minor differences. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #23 from Michael Zajac mich...@zajac.ca 2011-05-17 14:43:52 UTC --- (In reply to comment #14) (In reply to comment #13) I see that Wikipedia now has lang and xml:lang attributes on these links. The latter does seem pointless, since the root HTML element only has the former. Are you looking at a different Wikipedia then I am? We're talking about interlanguage links in the sidebar right? Oops; I was looking at the HTML source of the “Wikipedia languages” section of the main page. But this does indicate that there is demand for this from WP editors. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #24 from Andy Mabbett a...@pigsonthewing.org.uk 2011-05-17 14:53:10 UTC --- @Derk-Jan The iPhone app may well work; the service to which I linked does, also. But it's necessary to write code which screen-scrapes, or understands how Wikipedia uses interwiki links and its URL structure (which fails where article titles are not equivalnet (Mona Lista vs La Giaconda, for example)), rather than simply being able to recognise links to alternate (which in British English would be alternative; aleternate meaning something else) versions of a page in other languages through the semantic metadata thoughtfully provided in HTML specifications. The HTML 4 spec defines alternate as [Designating] substitute versions for the document in which the link occurs. While translation is mentioned as one example, there is no requirement that they be literal or word-for-word translations. @Aryeh. Reductio ad absurdum. Please don't. That's not to say we shouldn't use more rel-values (like previous next in Wikipedia navboxes) and other metadata. A while ago, when I downloaded the en-Wiki article on Barak Obama it was 1814 KB; the microformat in it comprised just 110 characters of the emitted HTML code (~0.005% of the full download). That's not as many as in the preceding sentence. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #25 from Derk-Jan Hartman hart...@videolan.org 2011-05-17 15:02:54 UTC --- @Andy, we have that, it's called the API. http://en.wikipedia.org/w/api.php?action=queryprop=langlinkstitles=Main%20Pageredirects=llurl -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #26 from Derk-Jan Hartman hart...@videolan.org 2011-05-17 15:09:49 UTC --- Hmm, i was googling a bit and found this piece of info which has me worried: http://www.google.com/support/webmasters/bin/answer.py?hl=enanswer=189077 Note: rel=alternate hreflang=x is for sites that have only their template translated. It isn't appropriate for multilingual sites that completely translate the content of each page. More information about multi-regional and multilingual sites. Which specifically would be exactly what we do on Wikipedia. So wether or not it's a good idea standard wise, that remark indicates that it might not necessarily be a good idea for our google page ranking of the other languages. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #27 from Michael Zajac mich...@zajac.ca 2011-05-17 15:48:28 UTC --- (In reply to comment #26) Rel=alternate is NOT appropriate in Wikipedia, because it implies that the target is a translation of the same writing. The WP language links point to independent writing, which has been selected as the nearest other-language equivalent; occasionally it is a translation, but often it varies greatly in scope and content. But it might be appropriate in a wiki with a different authoring model (e.g., maybe on Wikisource, which translates original documents), so shouldn't the software accommodate this as an admin-configurable setting? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #28 from Derk-Jan Hartman hart...@videolan.org 2011-05-17 18:37:50 UTC --- Not according to the Google comment. They specifically say that alternate icw hreflang should only be used where the 'interface' (template in their words) language differs, but the content is the same (so the content should not be translated). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #29 from Michael Zajac mich...@zajac.ca 2011-05-17 20:50:07 UTC --- (In reply to comment #28) Not according to the Google comment. According to the HTML5 spec, “If the alternate keyword is used with the hreflang attribute, and that attribute's value differs from the root element's language, it indicates that the referenced document is a translation.” So like I said, rel=alternate is for alternate translations of a document in, e.g., Wikisource, but not for different documents, e.g., different-language Wikipedia articles. http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#rel-alternate That Google note is confusing, and I think you are reading “is for sites that have only their template translated” as “is *only* for sites that have only their template translated.” It is about one scenario, and doesn't exclude others. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #30 from Aryeh Gregor simetrical+wikib...@gmail.com 2011-05-17 22:34:21 UTC --- (In reply to comment #24) Reductio ad absurdum. Please don't. Reductio ad absurdum is a legitimate argument technique, often used in mathematical proofs. What I'm saying is if we're going to add metadata like this to every page, we have to establish a bar higher than someone might theoretically want to use it, because if we only require that, there's no limit to what we could add. I suggest a standard along the lines of a nontrivial percentage of users will benefit from it. If the percentage of users who would benefit is negligible, then it can be provided in some fashion that doesn't require adding bytes to every page. Another possible standard might be we'll add any metadata that has dedicated HTML attributes/elements, but not RDFa/microdata/rel values/etc. without real use-cases. That would allow hreflang but not an unlimited amount of stuff. I don't see the logic in it, though. That's not to say we shouldn't use more rel-values (like previous next in Wikipedia navboxes) and other metadata. A while ago, when I downloaded the en-Wiki article on Barak Obama it was 1814 KB; the microformat in it comprised just 110 characters of the emitted HTML code (~0.005% of the full download). That's not as many as in the preceding sentence. hreflang on every interlanguage link for Barack Obama would add over 160*13 bytes, or about 2 KB, if I count right. Granted, that's only about a quarter of a percent, so it's not exactly a huge issue. I'd be more concerned about stuff in the head, because that will delay loading of the article text. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #31 from Bawolff bawolff...@gmail.com 2011-05-18 01:15:07 UTC --- I suggest a standard along the lines of a nontrivial percentage of users will benefit from it What about a trivial percentage? Is there a single user (who actually exists, not potentially could exist) that would benefit from hreflang attribute? Even if the cost of doing this is very small, if there's not a single user I'd call it bloat. The google note in comment 26 is the only remotely related use-case that I see listed here (the QR codes is asking for content-negotiation with accept-language headers, which is rather different), but even the google note is talking about link style links, where this bug is talking about inline links in the sidebar. And from my reading the google note is more looking for a way to translate the interface, aka ?uselang=de, then the actual content. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #32 from Michael Zajac mich...@zajac.ca 2011-05-18 05:47:31 UTC --- (In reply to comment #30) if we're going to add metadata like this to every page, we have to establish a bar higher than someone might theoretically want to use it, Lang attributes aren't metadata. They are part of the document structure required for universal access. What number of blind people wanting to read Wikipedia, for example, would you consider a “nontrivial percentage?” I'm sure the comment wasn't meant to trivialize people who require assistive technology by reducing their importance to a statistic, but that's what it amounts to. Identifying natural language changes in a document is a priority 1 checkpoint in WCAG 1.0, is required by the WCAG Samurai Errata, and is required for Level AA conformance in WCAG 2.0. A project that claims “openness” should attempt to meet basic accessibility standards. References: WCAG 1.0 Guideline 4. Clarify natural language use http://www.w3.org/TR/WCAG10/wai-pageauth.html#gl-abbreviated-and-foreign WCAG 1.0 HTML Technique 2.1 Identifying changes in language http://www.w3.org/TR/WCAG10-HTML-TECHS/#changes-in-lang WCAG Samurai Errata for WCAG 1.0 Guideline 4. Clarify natural-language usage http://wcagsamurai.org/errata/errata.html#GL4 WCAG 2.0 Guideline 3.1 Readable: Make text content readable and understandable. http://www.w3.org/TR/WCAG20/#meaning How to Meet WCAG 2.0 Guideline 3.1.2 Language of Parts http://www.w3.org/WAI/WCAG20/quickref/#qr-meaning-other-lang-id Techniques for WCAG 2.0 H58: Using language attributes to identify changes in the human language http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/H58 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #11 from Andy Mabbett a...@pigsonthewing.org.uk 2011-05-16 11:35:37 UTC --- HREFLANG combined with rel=alternate would allow parsers to determine, for any article, the existence and location of equivalent articles in other languages. Meta headers with the same properties should also be used for the same reason. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #12 from Aryeh Gregor simetrical+wikib...@gmail.com 2011-05-17 00:02:48 UTC --- That's hypothetical. If we add metadata to every page just because theoretically someone could use it, we'd be adding practically unlimited quantities of metadata. We shouldn't be adding this stuff to every page unless we know of specific users who actually need it for some real-world purpose. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 --- Comment #13 from Michael Zajac mich...@zajac.ca 2011-05-17 02:52:27 UTC --- I see that Wikipedia now has lang and xml:lang attributes on these links. The latter does seem pointless, since the root HTML element only has the former. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 Bawolff bawolff...@gmail.com changed: What|Removed |Added CC||bawolff...@gmail.com --- Comment #14 from Bawolff bawolff...@gmail.com 2011-05-17 04:51:39 UTC --- (In reply to comment #13) I see that Wikipedia now has lang and xml:lang attributes on these links. The latter does seem pointless, since the root HTML element only has the former. Are you looking at a different Wikipedia then I am? We're talking about interlanguage links in the sidebar right? I can't seem to see it. (also I grepped for xml:lang in trunk, its not used in the html output anywhere as far as I can tell. I could see the lang attribute potentially useful to screen readers needing to switch rules when pronouncing (It'd be nice if someone with an actual screen reader could confirm that), but hreflang seems really useless, unless someone can actually name an actual existing application that does something with it. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 Michael Zajac mich...@zajac.ca changed: What|Removed |Added Blocks||10467 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 Chad H. innocentkil...@gmail.com changed: What|Removed |Added CC||liang...@gmail.com --- Comment #9 from Chad H. innocentkil...@gmail.com 2010-08-10 16:38:25 UTC --- *** Bug 24741 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 The Evil IP address theevilipaddr...@hotmail.de changed: What|Removed |Added CC||theevilipaddr...@hotmail.de --- Comment #7 from The Evil IP address theevilipaddr...@hotmail.de 2010-07-14 18:56:41 UTC --- I think that the hreflang should really be added to the interlanguage links that appear within the sidebar, since it's sure that this is the language of the link. But for the usual interwiki inline links, be it by adding a colon before the interlanguage link or by an interwiki link (i.e. to another project) should not have the lang attribute, since they may be piped and then it would be wrong to mark them as a foreign language. Also, Brion makes a good point above describing the usage of stuff like google or the like. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 Aryeh Gregor simetrical+wikib...@gmail.com changed: What|Removed |Added CC||simetrical+wikib...@gmail.c ||om --- Comment #8 from Aryeh Gregor simetrical+wikib...@gmail.com 2010-07-14 19:15:19 UTC --- hreflang is unlikely to be useful. Nothing I know of uses it, and I don't think we should add it just because we can. Adding lang= to interwiki links is more reasonable, although I'm not sure how necessary it is. Do we have any actual complaints from users, or is it just theoretical WCAG stuff? Is anyone with a screen reader really going to sit and listen to the list of languages anyway? If so, how much does it help the screen reader if the language is specified explicitly? Maybe we should add all these attributes just because WCAG says so, but I'd be happier if we had more concrete data than that. If we do add lang=, we have to be careful, because several of our language codes are nonstandard. Also, certainly we shouldn't add a duplicate xml:lang= as well, that's just a waste of space. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 Brion Vibber br...@wikimedia.org changed: What|Removed |Added Depends on||20646 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 4901] lang and hreflang attributes for interwiki links
https://bugzilla.wikimedia.org/show_bug.cgi?id=4901 Michael Zajac mich...@zajac.ca changed: What|Removed |Added Blocks||367 --- Comment #6 from Michael Zajac mich...@zajac.ca 2009-01-19 17:38:49 UTC --- Identifying language changes is a Priority 1 checkpoint in WCAG 1.0 (http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-identify-changes), and an AA guideline in WCAG 2.0. This bug adversely affects accessibility, and blocks Bug 367 Markup accessibility issues (tracking). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
