In the Sharing tab for Languages, add the option to make "Offline remote translation synchronization". This should be done by storing a list of the local translations made (in case it doesn't exist) and sending it by Cron/Update operations, or through a "Manual Sync" button. The main advantage of this is to make it faster to translate (the synchronization process takes around 1-2-several seconds that can make a difference when you are translating several strings).

BTW: Being Portuguese, I want to configure the remote localization server as Portuguese (pt-pt). However, when I try to change the server URL from http://localize.drupal.org to http://localize.drupal.org/translate/languages/pt-pt (which I think it's the right one), I get the following error:

Invalid localization server address specified. Make sure you specified the right server address.

What is wrong? I've the key-API defined!

Comments

Gábor Hojtsy’s picture

I swear I've seen a "share existing strings" issue somewhere, which would be very similar, but could not find it now. Anyway, I think this was suggested, or something very similar was suggested before, so you are not alone.

On the language front, the URL of the server is not the URL of the language team. The language team is decided based on the language code you use in Drupal, so you can contribute to multiple language teams with l10n_client.

xpound’s picture

What I've sugested it's not quite the same. The idea is to make this sync process the least heavy to the system. However it would be a great addition to the module.

Question: how can I find out what is my (portuguese) localization server?

Gábor Hojtsy’s picture

If you intend to contribute to localize.drupal.org, you should just set the suggested (default) server, localize.drupal.org. It will figure out the right language to submit to based on your local language code setup. It will attempt to contribute to the same remote language code.

xpound’s picture

Hummm... being so, I don't get the advantage/reason of specifying a remote server. But, thanks for the info. :)

Gábor Hojtsy’s picture

The reason to specify a remote server is that then whenever you enter a translation it is saved on the remote server too. You give back to the community. What's not clear in this?

xpound’s picture

Well, if by any means the specific language server will get the new translation strings even if we define it as the global http://localize.drupal.org, then I think it's useless the need of this field. It can be set internally. Just that...

Gábor Hojtsy’s picture

The *server* is http://localize.drupal.org, not http://localize.drupal.org/translate/languages/pt-pt, http://localize.drupal.org/translate/languages/pt-pt is a translation group running on the http://localize.drupal.org server. You can contribute to any number of groups on the same server. Imagine you run 3 foreign languages on your site. As you translate to those languages (given the user with the API key has the permission), you can contribute to all three languages seamlessly.

The server field is there to allow you to specify other servers. Some Drupal distributions like Open Atrium run their own localization server (https://translate.openatrium.com/), so you can contribute to them too. It is generally the best choice to accept the default setting unless you specifically want to contribute to a 3rd party localization server.

xpound’s picture

Thanks. Understood! :P

And what do you think about the sugestions?

Gábor Hojtsy’s picture

It sounds like a good suggestion, and as I said, I think there was another similar one I think already, but could not find it to point you there.