Home » Groups » Internationalization

Automatically fetching translations

public
groups: Internationalization · Translations
meba@drupal.org - Wed, 2008-03-05 22:09

Hi!

In D5, we introduced Autolocale module, enabling users to import translations after enabling module / during installation. However, this had few caveats, as timeouts on cheap shared hosts, etc.

In D6, Autolocale is built-in core, using batch API and just works very well.

What do you think next step should be? From my point of view:

"Let Drupal automatically fetch translations from a server".

Imagine an user, enabling a module. Drupal polls Drupal.org (or something else), downloads a translation, imports it. No need to download any package, packages for modules will be smaller.

This could be done for installer and/or contribs.

What do you think and how do you think we can do this?

Just my $0.02:
- Installer is a great place for this, contrib may not be (Translations are already packed with contribs)
- Gabor mentioned (at DrupalCon in Boston) that it may be done using Localization client. Is it wise? Any other approaches?
- I can imagine a very easy implementation using curl()/fopen()/xmlrpc() (having a failback) to query Drupal.org/... for a translation, download it, extract (how to do this without Archive/Tar.php?) and import.

Please post your ideas so we can eventually get this to D7 :-)

» Login or register to post comments
 

Comments

Freso's picture
Freso - Sat, 2008-03-08 12:31

First, comments to the initial post:

  • It should always be possible to manually download translations. People may have security or other concerns with regards to having Drupal automagically speak with foreign sites - even if that foreign site is drupal.org. (Or they may be developing or using Drupal on a local machine or in a LAN without internet connection.)
  • I'd definitely say "yes" to having this in l10n_client - as this would both enable us to use it for Drupal 6 when the Drupal.org l10n_server launches, so that we can test etc. If it works flawlessly, l10n_client (or the client functionality) can be ported and integrated into D7 core. (IIRC, this has also been one of the long term goals of l10n_server and l10n_client, to be able to communicate with each other across the web.)
  • I think it would be fine if l10n_client/Drupal would look up translations as the strings were encountered in the interface, like it is now. That way, it will fetch the most fresh/latest translation, have the bandwidth usage spread out over a good while (and progressively less of it), and it would not fill up the database with strings that no one has used (and might never use).
  • Fetching translations per-string instead of per-package (module, theme, ...) would also let the downloaded translation "packages" be smaller, as common strings wouldn't be downloaded every time a package is installed.
  • I would definitely say to use xmlrpc(), at least if importing a few strings at a time (per the above). If we're importing entire core/module translations, it might be better to use curl() or some such and fetching regular PO-files. fopen() on remote files should not be assumed to be allowed/possible to use on a given server, as it could easily be disabled for security reasons with allow_url_fopen (one should always be wary of opening remote files). Also, if we're fetching text/plain PO-files, we wouldn't need Archive_Tar to handle the downloads.

Second, my own thoughts:

  • One thing I think would be awesome to have, is the ability to continuously keep your translations in sync. We would not want to override all strings that had been customised though. This could perhaps be made possibly with a moderation system, where new, "incoming" translations could be reviewed and either accepted as-is, accepted with changes (to fit the site's customisation), or rejected altogether. (This could also come with a setting to have all translations accepted before being applied on the site (if the site admin wants total control over what the site says) and with a setting to always accept new translations (for sites that use the official translation and doesn't mind the occasional term change).)
  • Having just seen the recording of Dries' latest "State of Drupal", perhaps we should be thinking RDF-like for string fetching? Or perhaps this is for D8. This is all very abstract in my head right now, and will need a wee bit longer to manifest itself properly in my mind, so that I can tell you (more) precisely what I mean. :)
  • The standing issues for full site localisation/translation (menu, site variables, ...) are probably a bit more important to get into D7 right now, even if this would be very cool. And we'll also need to actually have l10n_server produce a proper ("1.0 final") release.

--
Frederik 'Freso' S. Olesen


Login or register to post comments