For a given project this is the information we'd like to have available:
- L10n server (the url to manually explore and contribute back), defaults to http://localize.drupal.org
- L10n url (template to build the file url), defaults to http://ftp.drupal.org/files/translations/%core/%project/%project-%releas...
- Language list URL, currently http://ftp.drupal.org/files/translations/languages.xml
Which seems a bit too much to specify for each package and also not very flexible if stuff happens like you move the server, change paths, etc...
So I'm thinking we could add a bit more meta-information in the languages.xml file in a way that we just needed to have one server URL and we can fetch everything else from there. Like:
<l10nupdate>
<url>http://localize.drupal.org</url>
<name>Localize Drupal</name>
<filepath>http://ftp.drupal.org/files/translations/%core/%project/%project-%release.%language.po</filepath>
....
</l10nupdate>
This way we just need to specify the meta file url in the info file and we can fetch anything else from there.
l10n url = http://ftp.drupal.org/files/translations/languages.xml
Also we can later build on this. Say I have my own server for a few packages or a few languages and we can have something like
<projects>views,cck,i18n,...</projects>
<fallback>http://ftp.drupal.org/files/translations/languages.xml</fallback>
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | metafile-builder.patch | 5.25 KB | gábor hojtsy |
| #2 | l10n_server.tar_.gz | 1.71 KB | jose reyero |
Comments
Comment #1
gábor hojtsyMake total sense, looks like a good idea. We'd need to cache this information locally still I guess, so we avoid loading this file all the time.
Comment #2
jose reyero commentedThis is a new module, that would be the 'server side' exporting l10n server meta information so a client could auto-configure itself if pointed to the right server.
It extends the languages.xml, so it provides server information: whether you can download translations from it, which languages it has, server url, and also whether the 'l10n_update' module is enabled here....
All the information you may need for the client site to auto configure itself if just pointed to the right server
Comment #3
jose reyero commentedForgot to change the project. If this, or something like this can get into the server side, send the issue back to the 'Localization update' and I will update the client side.
Comment #4
gábor hojtsyOk, here is it in patch form against 6.x-2.x.
1. I've built this into the existing l10n_packager module.
2. Since l10n_packager already had a path template setting, so the update root setting is now only the public root URL which is then used concatenated with the template.
3. I've reworked all multiword XML tags to use underscores: l10nserver => l10n_server, updateurl => update_url, etc.
4. I've found out that the language list generation (before and after the patch equally) had a bug. It was generating an empty language tag and then list language properties thrown together instead of a nice structured list.
5. For consistency, I've modified the language tag that was used to wrap language properties and also for language codes to be only used for the former. The later is not the code tag.
6. Finally, I've made the API version 1.1, since there was an XML file format before (despite its name being different).
Now committing this to 2.x and 1.x and deploying on l.d.o as well.
Comment #5
jose reyero commentedGreat, now there's some work to do on the client side.
Our meta URL is http://ftp.drupal.org/files/translations/l10n_server.xml
Comment #6
jose reyero commentedSorry wrong module
Comment #7
gábor hojtsySymlinked the file to http://localize.drupal.org/l10n_server.xml.
Comment #8
gábor hojtsyCross-post.
Comment #9
jose reyero commentedThe latest version already works with these metadata files. That new url (symlink) will be in next commit, thanks!