One of the great advantages of Drupal translation is that the modules and themes share the same text space. So if a module has 'Home' translated, it does not need to be translated separately in the other 23 modules you use on your site. One of the disadvantages of that is that Drupal does not know/care about the module the string is coming from, so if you have short strings which can mean different things based on their use, Drupal is not capable of translating them differently. At least not until Drupal 7!
Let's take a simple example: "View". This can mean a lot of different things. A view as in something in views module, a view as in an SQL database view, a view as in "how nice is the view from your window", or view as in "click to view this post". One long standing example in Drupal core is "May". Drupal has strings for both long and short month names, like January, Jan, February, Feb, etc. But May is the same for short and long. No difference.
Well, Drupal 7 introduces string contexts to solve this problem. For "May", it adds the "Long month name" context, so we know if its not the normal short month name (which lacks context), but the explicitly told long month name. The way this looks like in code is as follows:
$long_may = t('May', array(), array('context' => 'Long month name'));
You can read more on the API page for t() and friends (this syntax can be used with other localization functions too), but the general concept is really simple: you elaborate on the context of the short string being used. Contexts are to be used for places where the string itself is too short to give enough context and could lead to mistranslation, or can have multiple translation in different uses. It is not to be abused wholesale for module strings, but only to be used after consideration.
Now contexts are something developers need to introduce in their modules to help translators. Only a few contributed module authors jumped on the bandwagon so far, and maybe not all of them use the API correctly yet. Good news is that Hilde Austlid (zirvap from the Norvegian teams) started a great practice of tagging related issues with "string context", so we can track issues across projects which deal with string contexts.
I'm hopeful that contexts will be a great way to solve translation conflicts, when short strings are impossible to translate in different ways otherwise. We should try to do our best to use it well and not to abuse the great powers we got though. Establishing guidelines as to when to use contexts (and what kind of short strings to leave context-less - such a short month names in core) is still to be done.