We discussed this in detail for #ldodomination. Localize.drupal.org would
- let teams push translation releases for core
- it would make weekly snapshots of whatever translation there was for contrib projects every week
1. We need to find the exact path where we gonna export these tarballs. We should reuse ftp.drupal.org.
2. We should only generate new tarballs for the supported branches of modules and for the latest version on each branch. Old versions should still be able to translate the old package which we generated before on the branch for that version. But we would not update that anymore.
3. Tarballs are generated per-language per module release. Like "Panels 6.x-3.0-de", "Panels 6.x-3.1-de", "Panels 6.x-3.2-de" or "Panels 6.x-3.0-fr", etc.
4. "Tarballs" might not even need to use tar, since we discussed we should export one big .po file per module and gzip that. (This cross-depends on verification on whether PHP supports gzip natively widely - link to come).
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | compact-mode.patch | 6.85 KB | gábor hojtsy |
| #3 | comment_remove.patch | 6.38 KB | pp |
Comments
Comment #1
gábor hojtsyCross referenced with #568996: Knowing the file paths, grab latest translations for projects when installing and #568998: Drupal (PHP) client requirements vs. localization packaging.
Comment #2
seutje commentedsubscribing
Comment #3
pp commentedThis patch add "comment remove" checkbox to translation's export form.
Comment #4
gábor hojtsyI've renamed it to compact mode and added a better description to the checkbox. It would be good if we could also skip wrapping the strings in compact mode, in my tests at #568998: Drupal (PHP) client requirements vs. localization packaging, it helped 3% in the size if I removed those wrappings in a Finnish Drupal 6 core translation.
Committed the patch, but we still need to work on this optimization left AND a cronjob to actually generate files in a static directory from these for ftp.drupal.org to pick up.
Comment #5
gábor hojtsyAh, this was the refined patch FYI.
Comment #6
gábor hojtsyRepurposing for the packaging in l10n_packager. I've set up #593282: Set up syncing of l10n_packager files to ftp.drupal.org for the infrastructure task.
Comment #7
gábor hojtsyAlso noting that when we actually start generating files, we need to do that on www1 specifically, so it should not be done in a normal Drupal cron but instead from a script invoking our APIs. The project packaging script does the same. The reason is that the files directory is on NFS, so writing to that from other webnodes that much is prohibitive. Even if that would not be the case, we have so much to package, that it would not work in a normal Drupal cron process anyway. We will probably need to somehow split up the process to multiple cron runs or something.
Comment #8
gábor hojtsyMarking a dupe of #594570: Packaging module for l.d.o (l10n_packager), since Jose used that to actually implement this code.
Comment #9
gábor hojtsy