canTranslate() fails to call mapToRemoteLanguage()

Uh, ugly.. We need a test for that!

Also you should provide universal format diffs.
Use git checkout an it is the default mode...

The format looks fine. Also the code correction.

But you should also extend our tests to make surr this case has test coverage and will never fail again with future updates!
http://drupal.org/simpletest-tutorial-drupal7

Hm. Not sure. Depends on the contract of getSupportedTargetLanguages(), does it receive/return internal or mapped language codes?

In e.g. the Gengo translator, we're doing the mapping within that function, so this would result in double mapping (Actually, it looks like Gengo already does double mapping ?!).

So, whatever we do, we need better documentation to define which function receives mapped language codes and which one doesn't.

One way to put it would be to define that we always do the mapping within TMGMTTraslator and the plugin class already receives the mapped language code and only has to work with that.

Yes we should also use different variable/argument names for local and remote languages.
I consider local "native" so in addition to documentatiom we should alwsys add prefix/postfix in case we deal with remote codes.

Berdir you are right, i didn't check in detail if this suggested change is right or wrong.
Thought the test would provide me the relevant aspects to follow.

getSupportedTargetLanguages() method should always return local language codes. There is getSupportedRemoteLanguages() which is expected to get language codes as defined by remote system. To make it clear here is the list of methods dealing with language codes and their responsibilities:

Methods to get mapping info:

getSupportedRemoteLanguages() - gets array of language codes in lang_code => lang_code format. It says with what languages the remote system can deal with. These codes are in the remote format.
getRemoteLanguagesMappings() - remote language codes may differ from local so this method should provide pairs of local_code => remote_code.
getDefaultRemoteLanguagesMappings() - we might know some mapping pairs prior to configuring a plugin, this is the place where we can define these mappings.
mapToRemoteLanguage() & mapToLocalLanguage() - I think these are obvious - helpers to map local/remote.

Methods where remote to local mapping occurs:

getSupportedTargetLanguages() - as mentioned, this should always return local language codes. So within this method the mapping should be executed.
getSupportedLanguagePairs() - gets language pairs for which translations can be done. The language codes must be in local form.

Method where local to remote mapping occurs:

requestTranslation() - here the logic to post the job to the translate service is implemented, and so the local language code has to be flipped to remote

Based on the above the provided patch is wrong, as well as google/ms plugins. Gengo somehow follows this, however incorrectly as canTranslate() is attempting to map lang codes again. Berdir, Miro, if you agree with the above concept I will open an issue to revise all plugins and unify the mappings logic.

Generally agree, but..

The things you described should be 100% cristal clear in the in-code documentation.
You should possibly define a @defgroup with @section
http://drupal.org/node/1354#defgroup

Since i'm mobile i dunno if they are already used. But i guess we can always improve it.

Finally after introducing these api's, yes they shpuld be applied to ALL known plugins.
So let's check all of them and create followup issues.

Closing this as it will be solved conceptually here: https://drupal.org/node/1999024

Here, works as designed is the right one. The other plugins wrongly dealing with the API need fixing.