Last modified: 2014-09-24 01:22:06 UTC
This patch adds xml:lang links, as described in http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-meta.html#sec_20.5.2. to all pages with interlanguage links. A diff against the current (2005-jan-30 09:00 UTC) CVS REL1_4 is attached. The results can be seen in the source for the two pages http://playwiki.wegge.dk/MediaWiki and http://wiki.wegge.dk/MediaWiki_customizations Diff against current code: --- Programming/MediaWiki/REL1_4/includes/SkinTemplate.php 2005-01-30 09:21:07.976778061 +0100 +++ playwiki/includes/SkinTemplate.php 2005-01-30 09:42:07.552766175 +0100 @@ -328,7 +328,8 @@ class SkinTemplate extends Skin { $nt = Title::newFromText( $l ); $language_urls[] = array('href' => $nt->getFullURL(), 'text' => ($wgContLang->getLanguageName( $nt->getInterwiki()) != ''?$wgContLang->getLanguageName( $nt->getInterwiki()) : $l), - 'class' => $wgContLang->isRTL() ? 'rtl' : 'ltr'); + 'class' => $wgContLang->isRTL() ? 'rtl' : 'ltr', + 'language_code' => $nt->getInterwiki()); } if(count($language_urls)) { $tpl->setRef( 'language_urls', $language_urls); diff -rup -xCVS Programming/MediaWiki/REL1_4/skins/MonoBook.php playwiki/skins/MonoBook.php --- Programming/MediaWiki/REL1_4/skins/MonoBook.php 2005-01-22 22:45:48.000000000 +0100 +++ playwiki/skins/MonoBook.php 2005-01-30 09:51:16.091509526 +0100 @@ -60,7 +60,13 @@ class MonoBookTemplate extends QuickTemp <?php if($this->data['usercss' ]) { ?><style type="text/css"><?php $this->html('usercss' ) ?></style><?php } ?> <?php if($this->data['userjs' ]) { ?><script type="text/javascript" src="<?php $this->text('userjs' ) ?>"></script><?php } ?> <?php if($this->data['userjsprev']) { ?><script type="text/javascript"><?php $this->html('userjsprev') ?></script><?php } ?> - </head> + <?php if( $this->data['language_urls'] ) {foreach($this->data['language_urls'] as $langlink) { ?> + <link title="<?php echo $langlink['text'] ?> version" + rel="alternate" + xml:lang="<?php echo $langlink['language_code'] ?>" + resource="<?php echo $langlink['href'] ?>" /> + <?php } } ?> +</head> <body <?php if($this->data['body_ondblclick']) { ?>ondblclick="<?php $this->text('body_ondblclick') ?>"<?php } ?> <?php if($this->data['nsclass' ]) { ?>class="<?php $this->text('nsclass') ?>"<?php } ?>> <div id="globalWrapper">
Created attachment 239 [details] The patch as an attachment
Created attachment 4130 [details] Patch updated to apply to trunk as of r25921
Created attachment 4131 [details] Alternate version of patch with HTML 4.01-compatible link info The original version of the patch uses <link> attributes recommended in an XHTML 2 draft spec, but these don't seem to be seen by existing user agents. This alternate patch uses lang, hreflang, and href instead of xml:lang and resource attributes, matching HTML 4.01 recommendations. I can confirm that the language alternates are listed in Seamonkey's navigation bar if activated and by lynx. Note that this may actually annoy lynx users, as does the existing OpenSearch description link, but that's because lynx is kind of bad about putting these supplementary links in totally the wrong place. :P This version of the patch also applies proper HTML escaping... The hardcoded English string 'version' in the title is probably not too super.
Rather than hardcoding this into MonoBook.php, this should probably be done in a skin-independent way, pumping entries into the list of header links on OutputPage which will get used by any skin. Note also bug 4901, for adding lang attribs to the clickable interlanguage links.
Fixed up in r46059, with a completely different patch.
Reopening per comments on r46059.
Would someone like to test the rel="alternate" on the inline <a href>s and confirm whether it seems to work? If working, they should show up in the navigation bar when enabled in SeaMonkey.
SeaMonkey and "Firefox + Site navigation bar extension" do show this, yes. [More] L [Other Versions] Opera doesn't seem to provide [More], nor [Documents]; so Opera doesn't show this (at least not by default).
Putting the rel= on the language link certainly seems like the correct thing here. I don't think we need an extra fifty million <link>s just for the sake of Opera.
Note: I tried this at Betawiki (r46385), and there it's *not* in the <a href=""> link but in a <link>. Will it work properly in href-links too? ---- By the way: You could turn around title and rel in <link title="..." rel="alternate" (for uniformity with the other <link> tags).
(In reply to comment #10) > Will it work properly in href-links too? The semantics are the same, per the standards. I don't know if all user-agents will treat them the same. If any don't, that's probably a bug on their part.
Created attachment 5883 [details] Patch adds rel=alternate and languages onto links. This patch doesn't seem to trigger the appropriate mechanisms in SeaMonkey.
+ title="<?php echo $langlink['text'];?>" Doesn't this just repeat the text of the link? Why is it necessary? Also, doesn't it need to be htmlspecialchars()ed? (I don't think anyone's come up with a language called Bjegka"fka0###&@!! yet, but it's probably just a matter of time.) + lang="<?php echo $langlink['interwiki'];?>" + hreflang="<?php echo $langlink['interwiki'];?>" + xml:lang="<?php echo $langlink['interwiki'];?>" Okay, that's just *excessive*. Only one of these should be needed. Or maybe two, if you really think it's important to mark up the fact that the word is in the same language as its target. We don't mark up different languages anywhere else in the interface, is there any good reason for it? It's going to add up to quite a lot of extra markup clutter on large articles . . .
(In reply to comment #13) > + title="<?php echo $langlink['text'];?>" > > Doesn't this just repeat the text of the link? Why is it necessary? Also, > doesn't it need to be htmlspecialchars()ed? (I don't think anyone's come up > with a language called Bjegka"fka0###&@!! yet, but it's probably just a matter > of time.) Ahem. I am far too used to having abstraction libraries.
Andrew, am I right in seeing that Aryeh did review your patch?
*** Bug 32725 has been marked as a duplicate of this bug. ***
Did this patch get merged?
