How about not drupal modules?

Subscribe

I've committed http://drupal.org/node/321544 which is a nice enabler for this kind of functionality. It allows multiple connectors to co-exist on the same site, so would allow for l10n_localpacks and a .po file handler connector to co-exist on the same server. I think this would be a requirement for you, since you'd not like to setup two different servers for different kinds of modules.

Next step is adding a connector module which would handle pure .po files letting you translates those. I think this is more of an enabler for people outside the Drupal community to use l10n_server as a self-hosted community translation service for Gettext files, not necessarily Acquia or Netrift modules to being parsed. Both the Acquia and Netrift modules are GPL, so you should be able to just put them under l10n_localpacks and let it parse the code.

How do we handle namespace conflicts? Projects not hosted on d.o may use the same name as d.o projects...

I'd expect you are not going to translate Linux tools with an l10n_server while at the same time you are also handling Drupal modules. The non-drupal.org hosted Drupal modules have the same problem with namespacing that they cannot be installed at the same time as the other module so they need to make up their own namespace tricks (prefixes, etc) to ensure they will not conflict as far as I see.

Or in other words, the namespace conflict already exists, since you cannot just go and install both modules at once due to PHP restrictions, so people are working against it already.

I think this is something we already discussed at Drupalcon Paris and this is what I understood the idea was:

• You can update Drupal and contrib modules translations from localize.drupal.org
• You can update other modules from a different server, either your company server or the one 'recommended' by the module builder
• We are adding the localization server to be used in the info file of the module, if other than l.d.o

Thus we should be able to build a mixed set up on which each package 'knows' where to update its translations from. Then if you want to update an standard package from your own server either you patch the info file with a different 'translation server' or you do some 'alter' on the package information before you fetch the translations.

No namespace conflicts should exist on this model, as your Drupal set up should resolve them locally, then go for the right server.

Supporting non-Drupal source code should be possible via either custom connector modules you write and/or #204171: Add connector to load bare .po files. Because this issue only deals with the server side, we can mark it duplicate of #204171: Add connector to load bare .po files I believe.

This is now committed, released in Drupal 6.x-2.x-beta2 and is blogged about at http://hojtsy.hu/blog/2010-may-05/using-drupal-collaborative-software-tr... for your information.