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?

This feature will only be considered for D6 or higher.

Is there a way to pass a language for search.nodes ?

where does localizer_set_language() comes from???
set_language() is a hook?

It's relatively easy to set up a locale_service module that expose the list of available languages and allow the consumer to set the current language. It can then be stored in session and used transparently on every existing method. What's missing is an elegant way to actually do the locale switch based on the current session variable before the actual service method is called.

Can we define additionnal hooks to allow *_service modules to intercept calls and alter some values before the actual service method is called.

Maybe Drupal need some AOP features ? ;)

After a little more thinking about it, I definitively prefer systematically pass a "language" parameter to all method call and maintain it on the client-side instead of setting it in a drupal side-session.

I'll study the authentication mechanism in order to understand how the method signature is dynamically modified (api key, ...)