Broken Links (#1612)[deploy site]

* annotate references to googlecode so they are not parsed as valid url

this allows us to keep historical reference without broken links

* fix broken links

---------

Co-authored-by: Sri Harsha <12621691+harsha509@users.noreply.github.com>

website_and_docs/content/blog/2010/going-atomic-how.md

@@ -13,13 +13,13 @@ This is the second of my technical posts. Again, if you’re interested in the i
 
 We left our intrepid heroes in a tight spot: they’d decided to write a shared library of code, to be used by the various webdriver implementations and selenium core, but the requirements for doing this seemed to be at odds with it actually happening.
 
-Fortunately, at about the same time we started down this path, Google Open Sourced the [Closure compiler](closure-compiler.googlecode.com). This is a Javascript compiler that takes as input a set of Javascript files, and which outputs Javascript. It can be configured to either pass the code through untouched into a single file, or it can compile a script aggressively, removing unused code-paths and minifying the output as much as possible. The Closure compiler is used on a lot of Google products, so we know that it’s reliable and consistent.
+Fortunately, at about the same time we started down this path, Google Open Sourced the [Closure compiler](https://developers.google.com/closure/compiler). This is a Javascript compiler that takes as input a set of Javascript files, and which outputs Javascript. It can be configured to either pass the code through untouched into a single file, or it can compile a script aggressively, removing unused code-paths and minifying the output as much as possible. The Closure compiler is used on a lot of Google products, so we know that it’s reliable and consistent.
 
-In order to get the best out of the Closure compiler, we’re writing the atoms using the [Closure library](closure-library.googlecode.com). This isn’t as well known as some of the other JS libraries out there, but it’s solid, well tested and is being actively developed. It also features an easy-to-use extension of JsUnit, which makes writing tests a far simpler task than might otherwise be the case, and it has an easy to use mechanism for modularizing code.
+In order to get the best out of the Closure compiler, we’re writing the atoms using the [Closure library](https://github.com/google/closure-library). This isn’t as well known as some of the other JS libraries out there, but it’s solid, well tested and is being actively developed. It also features an easy-to-use extension of JsUnit, which makes writing tests a far simpler task than might otherwise be the case, and it has an easy to use mechanism for modularizing code.
 
 So, given that we could compile a single Javascript function (and it’s dependencies) into a minified fragment of JS, we were all set, right? Not quite.
 
-The problem is that the atoms are being extracted from two frameworks that have a different way of viewing the world. As an example, Selenium 1’s “[getAttribute](http://selenium.googlecode.com/svn/trunk/docs/api/java/com/thoughtworks/selenium/Selenium.html#getAttribute(java.lang.String))” method only returns the value of a particular attribute, whereas WebDriver’s “[getAttribute](http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/WebElement.html#getAttribute(java.lang.String))” method will return the value of either a property or an attribute (because sometimes it’s hard to remember whether something is an attribute or a property of an element)
+The problem is that the atoms are being extracted from two frameworks that have a different way of viewing the world. As an example, Selenium 1’s getAttribute (`http://selenium.googlecode.com/svn/trunk/docs/api/java/com/thoughtworks/selenium/Selenium.html#getAttribute(java.lang.String)`) method only returns the value of a particular attribute, whereas WebDriver’s getAttribute (`http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/WebElement.html#getAttribute(java.lang.String`)) method will return the value of either a property or an attribute (because sometimes it’s hard to remember whether something is an attribute or a property of an element)
 
 As with all problems in computer science, an extra level of indirection is used to solve this issue.
 

website_and_docs/content/blog/2010/going-atomic-why.md

@@ -25,7 +25,7 @@ So, we decided to use Javascript.
 
 Because this shared code was to be composed of the smallest useful fragments of functionality required for browser automation we decided to refer to them as “Browser Automation Atoms”, or “atoms” for short. Rather than write them from scratch, the easiest thing to do was to extract them from the existing code — this is stuff that’s been battle-tested, so we know it’s robust.
 
-There was one very obvious fly in the ointment: not every driver is written in Javascript. Although we have a [mechanism available](http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/JavascriptExecutor.html) in every browser for executing JS, it’s wildly inefficient to dump an enormous lump of code on to the JS engine of the browser whenever you want to query the DOM. After all, most of the code would not be needed, and not all JS engines have been created equal. Some are blazingly fast. Others, not so much.
+There was one very obvious fly in the ointment: not every driver is written in Javascript. Although we have a mechanism available (`http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/JavascriptExecutor.html`) in every browser for executing JS, it’s wildly inefficient to dump an enormous lump of code on to the JS engine of the browser whenever you want to query the DOM. After all, most of the code would not be needed, and not all JS engines have been created equal. Some are blazingly fast. Others, not so much.
 
 It would also be nice to break the code up into manageably-sized modules, rather than being in a single, monolithic file, which implies some clever “module loading” capability. Except this code isn’t always going to be executing inside an environment where writing “script” tags to load additional scripts is possible. You can’t do that in the guts of a firefox extension, though you can load files other ways. However we tie modules together will need to cope with that.
 

website_and_docs/content/blog/2010/selenium-1-0-2-release-firefox-3-6-and-snow-leopard-support.md

@@ -14,6 +14,6 @@ of our efforts are on Selenium 2.0, we understand that there are millions of Sel
 still need the 1.x line supported. That’s why we’ve said from the start that our goal is make 2.x 
 100% backwards compatible with 1.x. And that’s why we’re releasing a new version of Selenium RC today.
 
-[Download it here](http://selenium.googlecode.com/files/selenium-remote-control-1.0.2.zip).
+Download it here (`http://selenium.googlecode.com/files/selenium-remote-control-1.0.2.zip`).
 
 In addition to many bug fixes, the biggest improvements in this version are support for both **Firefox 3.6 and OS X Snow Leopard**.

website_and_docs/content/blog/2010/selenium-1-0-3-released.md

@@ -10,8 +10,8 @@ description: >
 ---
 
 
-Hot off the heals of [1.0.2](/blog/2010/selenium-1.0.2-released-firefox-3.6-and-snow-leopard-support/), 
-we’re releasing Selenium Remote Control 1.0.3. You can [download it now](http://selenium.googlecode.com/files/selenium-remote-control-1.0.3.zip).
+Hot off the heals of [1.0.2](../selenium-1-0-2-release-firefox-3-6-and-snow-leopard-support/), 
+we’re releasing Selenium Remote Control 1.0.3. You can download it now (`http://selenium.googlecode.com/files/selenium-remote-control-1.0.3.zip`).
 
 There is no functional difference between this version and 1.0.2, other than it is packaged up a little nicer and we’ve clarified the relationship between selenium-server and the client drivers. That is: we are **not** releasing new client drivers with future 1.x releases. The reason is that we locked down the API in version 1.0.1 and so there is no need to push out the same code each time. As such, when you download 1.0.3, you’ll see all the client drivers are labeled version 1.0.1, which is expected.
 

website_and_docs/content/blog/2010/selenium-2-0-beta-1-release.md

@@ -12,12 +12,12 @@ description: >
 We recently released the first of the betas for Selenium 2. It’s available for Java, C# and Ruby. If you’ve been holding off trying Selenium 2 because of the alpha label, then the biggest improvement you’ll see is with the new WebDriver APIs, but there’s a lot more!
 
 *   A promise of relatively stable APIs
-*   For Firefox only right now, an API for dealing with [alerts, prompts and confirms](http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/WebDriver.TargetLocator.html#alert()).
+*   For Firefox only right now, an API for dealing with alerts, prompts and confirms (`http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/WebDriver.TargetLocator.html#alert()`).
 *   A brand new IE driver.
-*   Better [selenium emulation](http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/WebDriverBackedSelenium.html) when using webdriver
-*   And a better implementation of webdriver’s API backed by the [traditional Selenium technology](http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/SeleneseCommandExecutor.html).
+*   Better selenium emulation (`http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/WebDriverBackedSelenium.html`) when using webdriver
+*   And a better implementation of webdriver’s API backed by the traditional Selenium technology (`http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/SeleneseCommandExecutor.html`).
 *   Ubiquitous use of [Sizzle](http://sizzlejs.com/) for emulating CSS selectors where native CSS selectors aren’t supported
-*   The [advanced user interactions](http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/interactions/package-frame.html) API
+*   The advanced user interactions (`http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/interactions/package-frame.html`) API
 *   An update to the AndroidDriver’s Android app.
 
 Of course, we’d love this release to be completely bug free, but this is, after all, a beta, so there are some known issues:
@@ -30,7 +30,7 @@ You can download it from here:
 
 [http://code.google.com/p/selenium/downloads/list](http://code.google.com/p/selenium/downloads/list)
 
-You can read the [javadocs](http://selenium.googlecode.com/svn/trunk/docs/api/java/index.html) and the [ruby docs](http://selenium.googlecode.com/svn/trunk/docs/api/rb/index.html).
+You can read the javadocs (`http://selenium.googlecode.com/svn/trunk/docs/api/java/index.html`) and the ruby docs (`http://selenium.googlecode.com/svn/trunk/docs/api/rb/index.html`).
 
 An obvious question is “When will the beta end?” The short answer is when we’ve implemented the alerts and prompts and advanced user interactions APIs in all supported browsers. We expect there to be some flex in some APIs (removing deprecated methods, and within the advanced user interactions API) but what you have here is basically what you’re going to get when we hit 2.0 final. I have no idea how long this will take, but if you’re interested in helping out, [let us know!](http://groups.google.com/group/selenium-developers)
 

website_and_docs/content/blog/2010/selenium-2-0a5-released.md

@@ -11,8 +11,8 @@ description: >
 
 I’m pleased to announce the release of Selenium 2.0a5, available for [immediate download](http://code.google.com/p/selenium/downloads/list). This release brings a host of changes under the hood, and represents the efforts of many contributors. Highlights include:
 
-*   New [interfaces](http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/html5/package-frame.html) for dealing with HTML 5 elements.
-*   An API for “[implicit waits](http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/WebDriver.Timeouts.html)“: quietly waiting until an element is present before continuing with a test. You can use them like this: `driver.manage().timeouts().implicitlyWait(15, TimeUnit.SECONDS)`
+*   New interfaces (`http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/html5/package-frame.html`) for dealing with HTML 5 elements.
+*   An API for implicit waits (`http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/WebDriver.Timeouts.html`): quietly waiting until an element is present before continuing with a test. You can use them like this: `driver.manage().timeouts().implicitlyWait(15, TimeUnit.SECONDS)`
 *   A revamped Firefox driver.
 *   More shared code between Selenium and WebDriver.
 *   You can now pass firefox profiles to the remote webdriver (this includes extensions and proxy settings!)

website_and_docs/content/blog/2010/selenium-2-0a6-released.md

@@ -16,12 +16,12 @@ You’ll be pleased to hear that the Selenium 1.0 APIs have remained constant, s
 *   Android support: you can now [download the APK](http://code.google.com/p/selenium/downloads/detail?name=android-server-2.0a6.apk) and run webdriver tests using Android 1.6 to 2.2.
 *   Firefox 4 support.
 *   Experimental IE9 support
-*   New APIs for dealing with [HTML5 elements](http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/html5/package-summary.html) (best implemented, for now, by the mobile webdrivers)
+*   New APIs for dealing with HTML5 elements (`http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/html5/package-summary.html`) (best implemented, for now, by the mobile webdrivers)
 *   A richer .Net API
 *   A move to [Sizzle](http://sizzlejs.com/) for locating elements using CSS in browsers that don’t have a native API for that.
 *   Far better support for running your existing Selenium RC tests using WebDriver, helping you make a managed migration to the newer APIs.
 
-There are also lots of nice touches for the more technically inclined, including the ability to re-use instances of [FirefoxProfiles](http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/firefox/FirefoxProfile.html), better configurability when requesting a remote webdriver instance, better resource management and more shared code between the Selenium and WebDriver implementations.
+There are also lots of nice touches for the more technically inclined, including the ability to re-use instances of FirefoxProfiles (`http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/firefox/FirefoxProfile.html`), better configurability when requesting a remote webdriver instance, better resource management and more shared code between the Selenium and WebDriver implementations.
 
 Thank you to everyone who has taken the time to report a bug on our [issue tracker](http://code.google.com/p/selenium/issues/list), or raised problems on one of our [mailing](https://groups.google.com/group/webdriver) [lists](http://www.google.com/url?q=http://groups.google.com/group/selenium-users), or shown up for some of the banter on the IRC channel: without your involvement, the project wouldn’t be half as much fun, and wouldn’t be as capable as it is. Thanks are also due to the development team, who have poured an enormous amount of work into this release (538 revisions in under 90 days, or about 6 check-ins each and every day)
 

website_and_docs/content/blog/2011/bug-bash.md

@@ -9,7 +9,7 @@ description: >
   When the Selenium and WebDriver projects merged, all those moons ago, we moved the infrastructure from something we hosted to Google Code.
 ---
 
-When the [Selenium](http://selenium.googlecode.com/) and WebDriver projects merged, all those moons ago, we moved the infrastructure from something we hosted to Google Code. One reason for doing this was to make it easier for people to file bugs and feature requests. And it looks like people have been filing a _lot_ of bugs and feature requests.
+When the Selenium (`http://selenium.googlecode.com/`) and WebDriver projects merged, all those moons ago, we moved the infrastructure from something we hosted to Google Code. One reason for doing this was to make it easier for people to file bugs and feature requests. And it looks like people have been filing a _lot_ of bugs and feature requests.
 
 In the run up for the 2.0b2 release, we’ll be running a Bug Bash. This will run from the 24th January all the way to the end of the 30th January. The aim will be to focus on clearing our bug list as much as possible, so that beta2 will be the best release of Selenium yet. We will, of course, be recognizing people who squash the most bugs here on the blog, and we’re hunting out goodies to mail to the top bug bashers once the week is over.
 

website_and_docs/content/blog/2011/selenium-2-0b2-released.md

@@ -16,10 +16,10 @@ Between beta 1 and beta 2, we held a week-long Bug Bash, during which we closed
 *   A more stable, capable iPhone driver.
 *   Updated [Android driver](http://code.google.com/p/selenium/downloads/detail?name=selenium-server-2.0b2.zip&can=2&q=).
 *   Improved python bindings for Selenium WebDriver. The namespace is now “selenium.webdriver”
-*   Added “[Selenium.getCssCount](http://selenium.googlecode.com/svn/trunk/docs/api/java/com/thoughtworks/selenium/Selenium.html#getCssCount(java.lang.String))” to mirror “Selenium.getXpathCount”
-*   “[WebElement.getText()](http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/WebElement.html#getText())” performs more consistently across different browsers.
+*   Added Selenium.getCssCount (`http://selenium.googlecode.com/svn/trunk/docs/api/java/com/thoughtworks/selenium/Selenium.html#getCssCount(java.lang.String)`) to mirror “Selenium.getXpathCount”
+*   WebElement.getText() (`http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/WebElement.html#getText()`) performs more consistently across different browsers.
 *   Mono users can use the .Net bindings
-*   Continued to improve the [WebDriverBackedSelenium](http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/WebDriverBackedSelenium.html). If you’re looking to migrate from Selenium 1 to Selenium 2, and want to take your time, this is a useful stepping stone.
+*   Continued to improve the WebDriverBackedSelenium (`http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/WebDriverBackedSelenium.html`). If you’re looking to migrate from Selenium 1 to Selenium 2, and want to take your time, this is a useful stepping stone.
 *   Reworked the Advanced User Interactions APIs. The big change is that the WebDriver APIs no longer rely on classes from the AWT.
 *   .Net users now have more support classes, to make writing tests less tiresome.
 *   The remote webdriver makes better use of sockets, which improves stability and scalability on Windows.

website_and_docs/content/blog/2011/selenium-2-0b3-the-next-gen-browser-release.md

@@ -20,7 +20,7 @@ It’s been about 5 weeks since the release of beta 2, so we’re very pleased t
     *   IOptions.Speed
 *   Even more improvements to the Java webdriver-backed selenium
     *   We’ll document the migration path before 2.0b4 is out!
-*   A significantly faster [Android Driver](http://selenium.googlecode.com/files/android-server-2.0b3.apk)
+*   A significantly faster Android Driver (`http://selenium.googlecode.com/files/android-server-2.0b3.apk`)
 
 As well as these changes, there’s also the regular clutch of bug fixes and tweaks. For the number crunchers, there were a total of [331 changes](http://code.google.com/p/selenium/source/list?num=331&start=11749) that landed in the 5 weeks since the last release, with the 5 most active contributors working on each of the different languages supported by Selenium.