Today we are happy to release qLabel, an open source JavaScript library that looks up and displays the labels of entities marked-up in a Web site in the language of the user. You can use qLabel in any Web document - below are some examples of where it might come in handy.

Some web sites provide content in a very structured form - think of restaurant menus, schedules, images with textual annotations, catalogs, etc. For example, this is a map of the inhabited continents:

Providing this content in different languages is as easy as looking up how all the mentioned entities in the SVG map are named in the other language. If we want to display the content in German, we need to know that South America is Südamerika in German and replace it.

The same works for Chinese:

Or, to take a language that Google Translate does not support yet, such as Uzbek:

The labels that we have used so far are from Wikidata, a sister project of Wikipedia launched in 2012. Wikidata supports more than 300 languages, but there aren't labels for all entities in all languages yet. Let’s take a look at Hindi:

We see that the Hindi name for Australia is still missing. But adding that is as easy as going to the Hindi view of Wikidata for Australia and add the label, and likely by now someone has already fixed it (and that would be visible here if those images above would indeed be embedded SVGs instead of PNG files - see the live map demo). You can improve the content in Wikidata and make more knowledge accessible to everyone.

In these cases, there is no need for intelligent translation algorithms in order to translate the Website: it is enough to look up the label for the mentioned entities in the language of the reader and display them in place. qLabel does exactly that.

The Website author annotates the entities mentioned in the page with unique identifiers, and qLabel looks up the name for these entities in the language requested by the user and displays them. No need to wait until your translation service of choice supports your language, it only depends on the underlying lexicon of entities and the languages they support.

Every entity is marked up with a URI, which is then used to look up the labels in the requested language. Take a look at the examples: the above map, a tournament schedule, a food menu, and tour dates. You can use any URI that supports look-up using Linked Data standards, in particular Google’s Freebase and Wikidata, but you can also publish your own set of entities and labels as RDF or JSON-LD and use them — and at the same time releasing them to the Semantic Web!

Read more about qLabel and how you can use it. Contributions to the code base are more than welcome, the source code is on Github.  Let us know about how you use qLabel!

Thanks and kudos to rdfquery, Wikidata, any23, Freebase, Universal Language Selector, the Wiki Atlas, and the Wikidata Multilingual Picture Dictionary.

By Denny Vrandečić, Ontologist, Google Knowledge Graph 

We are proud to release Wicked Good XPath, a Google-authored pure JavaScript implementation of the DOM Level 3 XPath specification. We believe it to be the fastest XPath implementation available in JavaScript.

To use Wicked Good XPath, simply download the wgxpath.install.js file and include it on your webpage with a script tag. For example:
<script src="wgxpath.install.js"></script>

Then call wgxpath.install() from your JavaScript code, which will ensure document.evaluate, the XPath evaluation function, is defined on the window object. To install the library on a different window, pass that window as an argument to the install function.

Despite the growing popularity of CSS selectors, XPath remains a useful mechanism to locate elements in an HTML document. It has particularly heavy usage in the context of frontend web testing tools like Selenium and Web Puppeteer. Sometimes there is simply no way to reference an element on the page other than with an XPath expression.

For those who have never used XPath, here is a taste:

On a Google search results page, the XPath expression //li[@class=”g”][3] identifies the third search result. Here is a snapshot from the Chrome extension XPath Viewer showing the third result selected when that expression is used.

A key challenge when using XPath, however, is that it is not natively supported on every browser. Most notably, Internet Explorer does not provide native XPath support for HTML documents. As a result, users turned towards pure JavaScript implementations of XPath. In 2005, Google engineers released AJAXSLT, which included a correct, but slow, XPath evaluator. Running web tests on IE using AJAXSLT was time-consuming.

Fast-forward to 2007, Cybozu Labs released JavaScript-XPath, a new JavaScript XPath implementation that was 10 times faster than AJAXSLT. The web testing tools began using it instead, and life was good... for a while. The JavaScript-XPath quickly fell out of maintenance, and bugs became tough to get fixed. Also, since it wasn't written in Google Closure, it was tricky for us Googlers to integrate into our JavaScript applications. A rewrite was necessary.

However, we went beyond merely porting the library to Google Closure and fixing a couple bugs. We identified some significant additional performance improvements, such that our version runs about 30% faster than the original. On top of that, the Closure compiler was able to minify our code down to a mere 25K, 40% smaller than JavaScript-XPath's 42K. Finally, the code is structured and documented in a way that we believe will make future maintenance quicker and easier.

We would like to thank our two Google interns, Michael Zhou and Evan Thomas, for doing the bulk of the development on this project.

By Greg Dennis and Joon Lee, Google Engineers

Leak finder for JavaScript helps web application developers find memory leaks in their JavaScript programs.

In garbage-collected languages, such as JavaScript, you cannot have traditional memory leaks by forgetting to free memory: when all references to an object are dropped, the object is garbage-collected and the memory is freed.

However, JavaScript programs can leak memory by unintentionally retaining references to objects. For example the references can be pointers to objects stored in a data structure in a JavaScript library (e.g., Closure) instead of the application code. If an object is unintentionally retained, all objects it points to are kept alive as well. This will lead to superfluous memory consumption.

Example (using the Closure JavaScript library):

goog.Disposable is an interface for disposable objects. Before dropping the last reference to an object which is an instance of goog.Disposable (or its subclass), the user code is supposed to invoke the method dispose()on the object. This method can release resources, e.g., by disposing event listeners. However, a web application might forget to call dispose() before dropping all the references to an object.

Leak finder can detect such goog.Disposable objects which were not disposed, and print out useful information (such as the stack trace when the object was created) about them. It produces machine-readable output and can be used as a part of test automation.

In order to find leaks, Leak Finder relies on goog.Disposable monitoring mode. The mode gathers all created but not yet disposed instances of goog.Disposable (and its subclasses) into an array goog.Disposable.instances_. This array will keep the objects alive. However, if an object is only kept alive by this array and other Closure data structures, it is a leak, since the user code doesn't contain any pointers to the object, and it cannot call dispose() on it.

Leak finder can be configured to detect other types of memory leaks and it can be used with JavaScript libraries other than Closure.

The Leak finder project page contains instructions for checking out the source code and using the tool.

By Marja Hölttä & Jochen Eisinger, Chrome team (Munich)

Once in awhile at Google our illustrators get excited about lasers, Morse code, H. G. Wells’s The War of the Worlds – and then come up with beautiful Google doodles that find their way onto our homepage. Sometimes our programmers also get excited and team up with the illustrators, and that’s how we found ourselves with Google doodles celebrating Les Paul’s guitar, Pac-Man, Jules Verne’s bathyscaphe, and even your own customized turkey that you could then share on Google+.

I’m one of those people who is more comfortable with 80 monospaced characters endlessly repeated than with a paintbrush. Earlier this year I worked with Sophia Foster-Dimino from the Google doodle team on a doodle celebrating Stanisław Lem, my favorite sci-fi writer and philosopher.

 

Just like picking the right paintbrush and palette is important for all our doodles, so is figuring out the right technologies and proper user interface for those we want to make interactive. That’s something I’m personally really excited about and that’s why today I wanted to share that excitement and the entire source code of the Stanisław Lem doodle with you – accompanied with an article explaining HTML5 technologies that we used… or didn’t use:

• read the article about Stanisław Lem doodle on HTML5 Rocks
• view the complete source code 

Please note: We are sharing the code of the doodle under the Apache 2.0 License, but the images and animations accompanying the doodle under the Creative Commons BY-NC-SA 3.0 License. The big difference between those two is that the first one allows commercial re-use, whereas the second one forbids it.

So take it for a spin, play with it, and if you do something interesting, find a flaw, or have a comment – let us know at [email protected]. Thanks!

By Marcin Wichary, Senior user experience designer, Chrome

We are pleased to announce the open source release of a Javascript coverage analysis tool called ScriptCover. It is a Chrome extension that provides line-by-line Javascript code coverage statistics for web pages in real time without user modification of the site. Results are collected when the page loads and continue to be updated as users interact with the page. These results can be viewed in real time through a reporting tool which highlights the executed lines of code for detailed analysis. ScriptCover is useful when performing manual and automated testing and in understanding and debugging complex code.

Short report in Chrome extension popup, detailing both overall scores and per-script coverage.

Sample of annotated source code from the detailed report. First two columns are line number and number of times each instruction has been executed.

We envision many potential features and improvements for ScriptCover, e.g.:

• support other coverage metrics, e.g. path coverage and condition coverage
• support richer reports and exporting to HTML and XML
• submit Javascript coverage statistics to a server and analyze combined statistics for selected users, dates, etc.
• map user actions to related Javascript code

Want to get involved with ScriptCover and make it better? Join the team! To get started, visit our project page, join the community, read documentation and download the code.

By Ekaterina Kamenskaya, Software Engineer in Test, Google

Google JS Test is a JavaScript unit testing framework that runs on the V8 JavaScript Engine, the same open source project that is responsible for Google Chrome’s super-fast JS execution speed. Google JS Test is used internally by several Google projects, and we’re pleased to announce that it has been released as an open source project.

Features of Google JS Test include:

• Extremely fast startup and execution time, without needing to run a browser.

• Clean, readable output in the case of both passing and failing tests.

• An optional browser-based test runner that can simply be refreshed whenever JS is changed.

• Style and semantics that resemble Google Test for C++.

• A built-in mocking framework that requires minimal boilerplate code (e.g. no $tearDown or $verifyAll calls), with style and semantics based on the Google C++ Mocking Framework.

• A system of matchers allowing for expressive tests and easy to read failure output, with many built-in matchers and the ability for the user to add their own.
  
  

See the Google JS Test project home page for a quick introduction, and the getting started page for a tutorial that will teach you the basics in just a few minutes.

By Aaron Jacobs, Google Engineer

Can you spot the error in the following webpage?


Unless you are one of the 56 million Internet users who read Arabic, the answer is probably no. But BidiChecker, a tool for checking webpages for errors in handling of bidirectional text, can find it:


Oops! The Arabic movie title causes the line to be laid out in the wrong order, with half of the phrase "57 reviews" on one side of it and half on the other.

As this example demonstrates, text transposition errors can occur even if your web application is entirely in a left-to-right language. If the application accepts user input or displays multilingual content, this data may be in one of the right-to-left languages, such as Arabic, Hebrew, Farsi or Urdu. Displaying right-to-left text in a left-to-right environment, or vice versa, is likely to cause text garbling if not done correctly. So most user interfaces, whether left-to-right or right-to-left, need to be able to deal with bidirectional (BiDi) text.

Handling BiDi text can be tricky and requires special processing at every appearance of potentially BiDi data in the UI. As a result, BiDi text support often regresses when a developer adds a new feature–and fails to include BiDi support in the updated code.

Called from your automated test suite, BidiChecker can catch regressions before they go live. It features a pure JavaScript API which can easily be integrated into a test suite based on common JavaScript test frameworks such as JSUnit. Here's a sample test for the above scenario:


// Check for BiDi errors with Arabic data in an English UI.
function testArabicDataEnglishUi() {



 // User reviews data to display; includes Arabic data.



 var reviewsData = [



 

 {'title': 'The Princess Bride', 'reviews': '23'},


 

 {'title': '20,000 Leagues Under the Sea', 'reviews': '17'},


 

 {'title': 'ستار تريك', 'reviews': '57'} // “Star Trek”



 ];





 // Render the reviews in an English UI.


 var app = new ReviewsApp(reviewsData, testDiv);


 app.setLanguage('English');



 app.render();







 // Run BidiChecker.



 var errors = bidichecker.checkPage(/* shouldBeRtl= */ false, testDiv);



 // This assertion will fail due to BiDi errors!



 assertArrayEquals([], errors);

}

We’ve just released BidiChecker as an open source project on Google Code, so web developers everywhere can take advantage of it. We hope it makes the web a friendlier place for users of right-to-left languages and the developers who support them.

By Jason Elbaum, Internationalization Team

By Jason Huggins, Software Engineering Team and Selenium Co-Creator

I'm happy to announce "Selenium Ice", a new tool for developers who test web applications in Internet Explorer with Selenium. This first version of Ice is limited in scope — it simply adds a new namespace ("window.ice") to every web page, for which developers can write code in C# that is callable from JavaScript. In the future, Ice will be used by the Selenium project team as a building block for providing more native control over the IE browser process. With this native access, Selenium will be able to more reliably catch and close unexpected dialog windows, provide better information when JavaScript errors occur, or do things that require interaction with the operating system, like handling file uploads and downloads. Ice can also serve as a base for linking in faster XPath support in IE — an oft-requested feature among Selenium users.

The Ice project was developed using Visual C# 2008 Express Edition, so no development licensing fees are required beyond access to a machine running Windows. There's an NAnt script for continuous integration, a WiX script for automated creation of a Microsoft Installer (.msi), and a system test script written in Python that can launch IE and ensure that the extension works correctly.

The code is all Open Source and available under the Apache 2.0 license. You can check out our project site on Google Code and may want to join our Selenium Ice discussion group. We always love to hear from you, so let us know what you think of our cool new code!

By Brad Neuberg, Dojo Contributor and Google Gears Developer Advocate

The Dojo project is a leading open source Ajax framework for developing advanced web applications in JavaScript. Dojo consists of many modules for powerful cross-browser development, such as modules for offline, modules for graphics, and more. One of these modules is known as Dojo Storage.

Dojo Storage makes it possible to store large amounts of data (hundreds or megabytes of K) on the client-side, way beyond the 4K limit of cookies. Developers are given a simple key/value storage abstraction, similar to a hash table. What makes Dojo Storage unique is that it automatically determines the best way to achieve this. If Google Gears, a small open-source plug-in that teaches current browsers new tricks, is present then this will be used for storage; if the browser supports HTML 5 DOM Storage, such as Firefox 2, then this is used; and finally, if none of the others are available, then a hidden Flash applet is used to store the data permanently. There are even Adobe AIR storage providers (thanks to SitePen and Adobe) if you are running in an AIR environment!

Dojo Storage has been around for a few years. However, when Dojo made the big move to the Dojo 1.0 architecture, the Flash and HTML 5 storage providers broke; plus, new versions of Flash and new browsers made the old design inefficient. I have seriously re-factored the Flash storage system to be much faster and simpler and fixed bugs in the HTML 5 and Gears storage systems. There is now a new storage.js profile build that you can grab and include in your page to easily use Dojo Storage with the three main browser storage providers: Gears, HTML 5, and Flash. The new Dojo Storage will come out as part of the Dojo 1.1 release coming soon.

I've created a screen cast demoing the different storage providers in action:



Enjoy!

By Brian Fitzpatrick, Open Source Programs Office

It's been about a year and a half since we launched project hosting on Google Code, and we're now home to over 80,000 projects. From small two-person projects to projects with dozens of contributors, we've got all kinds: utilities, javascript libraries, gadgets, University CS classes, hundreds of Google's own open source projects, and many more.

We continue to work to add more features as well as improve the scalability and reliability of the Google Code hosting service, and in order to keep you more up to date with what we're up to, we've setup shop here in the new Google Open Source blog. You can expect to see posts here that cover new features and bugfixes, reviews of Open Source engineering best practices, and other bits and bobs that we think are relevant to open source software development.

So stay tuned—2008 is looking to be a great year for us.