Share existing strings [#1048738]

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

Comment #1

Gábor Hojtsy

he/him

Hungarian

Hungary

CreditAttribution: Gábor Hojtsy commented 2 February 2011 at 15:00

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.

Comment #2

xpound CreditAttribution: xpound commented 2 February 2011 at 15:40

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?

Comment #3

Gábor Hojtsy

he/him

Hungarian

Hungary

CreditAttribution: Gábor Hojtsy commented 2 February 2011 at 15:23

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.

Comment #4

xpound CreditAttribution: xpound commented 2 February 2011 at 15:42

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

Comment #5

Gábor Hojtsy

he/him

Hungarian

Hungary

CreditAttribution: Gábor Hojtsy commented 2 February 2011 at 15:53

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?

Comment #6

xpound CreditAttribution: xpound commented 2 February 2011 at 17:41

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

Comment #7

Gábor Hojtsy

he/him

Hungarian

Hungary

CreditAttribution: Gábor Hojtsy commented 2 February 2011 at 17:48

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.