Figure out how to handle translations in returning content.

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, ...)

Bumping version

After battling with another i18n site, I realize what exactly is needed as a translation/multi-language service comes down to how you setup multi-language sites, and how/where you use to pull the data thru services… as there are several ways to achieve this (and none straightforward ones)

——

as an example use case
a full-flash site, loads a menu, when menu_item is selected it loads the node

what is needed exactly
1. a way to get all the languages out of the drupal install, which could be a system method (or additional info for system.connect) *
2. load the appropriate menu** in a certain language, cfr. #740836: menu_service: menu.get language argument which provides this
3. load the node, which actually does not require to specify any language, as the menu only contains nodes from a certain language

conclusion
in this case only 2 (1 if the patch is committed) extra methods are needed, and node load does not need an extra argument (you need to know the nid anyways to load the node, if you know the nid from the menu, then the language is already determined)

——

as said, this goes for this particular use case,
what other ways are needed? (as adding a optional language parameter to every method is overkill)
eg.
OK for search service
not needed IMO for views service, as you can set this as an argument in the view itself
taxonomy? (rarely use that one so I cannot tell)
…
a translation service that only handles the strings saved by locale
a contrib project for i18n to load i18n system variables, amongst others
…

——

* once you start with pulling languages out of the system you most probably will need other system variables that are language dependent as the front_page, but those are set by the i18n which is not core anymore… so the most straightforward option would be to setup your own service (in contrast with several method calls eg. system.getLanguageList and i18n.getVariables, in order to save some service calls)

an example of what this custom service could be:

function myCustom_service_connect() {
  global $user;
  
  $return = new stdClass();
  $return->sessid = session_id();
  $return->user = $user;
  
  $return->site_name = variable_get('site_name', 'drupal');
  $return->server_time = date('H.i.s_d.m.Y_O', time());

  if(module_exists('translation') && module_exists('i18n'))
  {
  	$return->i18n = TRUE;
  	
  	$lang_list = locale_language_list('native');
  	foreach ($lang_list as $lang_code => $lang_str) 
  	{
  		$lang = new StdClass();
  		$lang->code = $lang_code;
  		$lang->name = $lang_str; 
  		$return->i18n_language_list[] = $lang; 
  		
  		
  		$return->site_frontpage[$lang_code] = $lang_code . '/' . i18n_variable_get('site_frontpage', $lang_code); 
  	}
  }
  else
  {
  	$return->i18n = FALSE;
    $return->site_frontpage = variable_get('site_frontpage', '');
  }
  
 
  
  return $return;
}

** about multi-language menus, rumor goes that with the core locale and content translation modules you could setup an multi-language site, one menu with all the nodes in it, and the nodes are shown according to the current language…
unfortunately this setup didn't work for me, in order to have only the menu items shown from a particular language, the i18n module was required (otherwise all languages where shown at the same time), and each language needed its own menu (so i18n only shows the menu from a certain language)…
in short, the use case above has the nodes grouped by language in a separate menu by design

in my experience, setting up a i18n site in drupal is not really straightforward, quite some improvements from D5>D6, but it should be handled better in the core
(how is D7 doing btw?)

If the Service API is accessed via an URL which have a language code (eg. /fr/services/amfphp), then the $language will be correctly set and views with a "Content Negotiation" (i18nviews module) filter will return the corresponding nodes.

Bumping to 3.x

I really can't see this going into services core to be honest - it would however make an ideal contrib module if anyone is interested, so marking as won't fix.

It seems like theres got to be a way to make this happen with 7.x pretty easily I just think we need to look into it a bit more.

If anyone has anymore insight on something they've done custom wise, let me know and ill see if theres a way we can get it into core.

Hello All,

Im using (drupal 7) the services module with rest and in18 module for translations. I don't have a content for each language. I have a content that has several fields translated.

Did anyone solve the question to get the content from the rest services but in a certain language?

I saw many posts but i notice that have some time. Can i pass an argument with the defined language, make a call to a service to set the language in the session, some other solution?

Thanks

Best Regards,

Wont fix in 3.x but ive added it as a list of things to do for 4.x