How about not drupal modules?
pvasili - October 15, 2008 - 07:58
| Project: | Localization server |
| Version: | 6.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
Moved from #281564: How about 7.X?
I think it is the Localization server made more universal.
- What about the project Acquia? (http://acquia.com/downloads) I think it should be added for all ;).
- This project is also in need of translation: http://www.netrift.com
Autor can provide PO files for transfer (module is not free)
- ...
I propose to make import any PO files (in the tar.gz archive).
For example: .tar.gz files have prefix (~).
Only the PO files will be imported from this archive (only all PO files!).
In the archives of a PO file should be similar(equivalent) to a file in Drupal.
This feature will be benefit all. We will be have more translated strings for all Drupal modules .
#1
Subscribe
#2
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.
#3
How do we handle namespace conflicts? Projects not hosted on d.o may use the same name as d.o projects...
#4
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.
#5
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.