Translation projects are now moving entirely to localize.drupal.org (see #980658: META ISSUE: get d.o language projects all on localize.drupal.org). The existing projects are probably best kept for history and until their issues are running out / migrated the discussion system to be put into place on l.d.o. But new translation projects should not be created anymore. Because translation projects are only different in their taxonomy term, this is not as easy as switching a permission on d.o. We need some custom code to check for this.
Comments
Comment #1
gábor hojtsyRelated: #980686: Output a big warning on project/translations and translation projects.
Comment #2
dwwYeah, reason 82124 we really want the difference project types to be separate node types and the Project-ness of them to be fields that can be applied to any node type. That's what the 7.x-2.* branch of Project* will be for. ;)
Meanwhile, this should be a pretty easy patch for drupalorg_project.module. I'd be happy to review/commit/deploy once it's ready.
Cheers,
-Derek
Comment #3
mr.baileysWould attached patch do the trick? It just removes "Translations" from the options array on the
project_project_node_formwhen creating a new project and when editing an existing project that is not a translation.Comment #4
gábor hojtsyThis looks great. Two things: 1. can we make the 6 a constant? 2. can we add a little description under the selection field that "Translation projects are now moved to localize.drupal.org" or something like that? That would be awesome IMHO.
Comment #5
gábor hojtsyThink someone who was directed there by outdated docs, books, etc would only get informed once they try to create the translation there. If they have no option for that, let's avoid them submitting support requests.
Comment #6
mr.baileysThanks for the feedback, new patch attached (although feel free to adjust the wording some more if necessary)
Comment #7
gábor hojtsyGreat. Don't think absolute URLs need url() wrapping though, that is not core practice either AFAIR. Updated patch attached.
Comment #8
gábor hojtsyBTW translation project type seems to be 29, not 6:
Comment #9
gábor hojtsyWhere did you get 6 from? Was that a placeholder actually?
Comment #10
mr.baileysYes, I was incorrectly assuming that, when using the drupalorg installation profile, the vocabulary term IDs would match those on drupal.org, which as it turns out is not the case :)
Will re-roll with the correct constant (29) later today.
Comment #11
mr.baileysLooks like this also needed a reroll because #987068: Add major issue count to contributor block went in. Now (re-)using the correct term id for translation projects.
Comment #12
gábor hojtsyGreat, I think this looks good now. mr.baileys also ran it with the drupalorg install profile.
Comment #13
dwwSorry, fell off my radar. Looks great. Committed to HEAD. Meanwhile, here's a similar patch to deny new releases of existing translations. See #1019354: Remove packaging script support for translations. Tested with drupalorg profile and working fine.
Comment #14
dwwComment #15
dwwCommitted to HEAD, merged into bzr, and deployed both. Yay. ;)
http://drupal.org/node/add/project-project
http://drupal.org/node/add/project-release/11349
Comment #16
gábor hojtsyGreat, thanks.
Comment #17
moshe weitzman commenteddrush still allows folks to download these releases. we will soon remove thus functionality.
so, are there drush commands out there that download from l.d.o? If so, we will keep localization out of core drush.
Comment #18
gábor hojtsyMoshe: yes, l10n_update has drush integration for its current functionality. As the l10n_update functionality is broken down into smaller pieces, the drush commands should keep improving. But the support is there and is kept in mind :)