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.

Comments

how about if we add a list in L.D.O to define the contexts meanings. It can be a reference to modules authors (and translator I think)

Now, we can define a new context like:
$long_may = t('May', array(), array('context' => 'Long month name'));

in other modules, the author maybe define it as:
$long_may = t('May', array(), array('context' => 'The long month name'));

both have same meanings but different contexts. we need to translate twice.

also, it listed which modules contains "May" are using the contexts now and which aren't yet.

We should get this documented where developer docs are, on the drupal.org handbooks IMHO: http://drupal.org/node/322729 We should extend that section with elaborate discussion of contexts and a "registry" of contexts and their explanations maybe.

I think it's important to emphasize that these are linguistic, and not technical contexts. I.e. i18nstring for Drupal 6 had its own 'contexts' in the form of string groups - one for taxonomy strings, one for menu strings, one for views etc. The end result was that if I had a "News" view with a "News" menu item and also a "News" taxonomy, I'd need to translate it three times, even though it's used in the same context. That shouldn't happen IMHO.

The "string groups" concept is supported by Drupal core itself. i18nstrings merely provides more string groups beyond the "built-in" string group, that is used for the interface. That is used to separate the translatable strings per technical use, right. Whether you want to share translations with those and the interface is not always trivial unfortunately.

...here, but did not get much of a reaction.
There are two problems.

Strings that are ambiguous in the english original

Example: views. Developers often are not aware of the ambiguity (sometimes because they are not native English speakers, sometimes because they are) for example the word report translates to dozen different translations in many languages (a report, report something, show, denounce, ...).

Strings that need to be translated differently depending on the context, even if they are not ambiguous in English

This happens whenever there are more differenciated translations for an English word, e.g. some languages have different words for night, "early night" or "early morning". I heard there are languages where the words "one" to "seven" have a translation depending on whether it is birds that are counted (I kid you not).

These ambiguities cannot be avoided because the author cannot provide a context if he/she is not aware of the translation problem in a different language he/she does not speak. So the only reasonable way to handle these cases seem to be the issue queue. I hope developers have enough understanding to provide these contexts so that the drupal translations can improve.

As a rule of thumb if you translate a module and you need to go into the module UI or the source code to find out how to translate a string correctly then the module is missing context information.

I've started a handbook page about this at http://drupal.org/node/1369936. Any comments welcome! (Please comment in the issue at http://drupal.org/node/1035716)