Translation service

Just imagining how this might work.

Perhaps node.load() should return an array of nids and language codes for any translations?

This would make the data available with fewer calls (node.load() and then another node.load() of the translated content) instead of first calling a node.load and then calling and then calling node.load again?

This would still require two calls though to get translated content...Maybe language should become a(n optional) parameter for node.load that will automatically return the node in the requested language?

Anyone else have any thoughts?

I would vote for the extra/optional parameter that defaults to the default language, and maybe the system.connect that returns an array of the available languages (of the 'system').
As said, it saves some roundtrips to the server.

Here is simple Localizer services module.

It wraps some built-in services methods (currently node.load, taxonomy.getTree, system.getVariable and view.getView) to add an optional $lang parameter. New methods are called like node.load_localized.

It's not flexible enough currently. I am thinking on dynamically parsing existing method declarations and adding $lang param to them. Localized methods should be provided only if the original modules (node_services.module for example) do exist and are enabled. Parameter passing to original methods should not be hard-coded also (for the cases of parameters change).

Of course, there are other options to provide L10n to services.
Instead of creating new module we could patch original ones (node_service.module for example) to expose additional param when Localizer module is enabled.

Any thoughts?