Posted by hass on February 7, 2008 at 7:12pm
5 followers
| Project: | Localization server |
| Version: | 6.x-2.x-dev |
| Component: | Export |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
If i press the project radio in "Source data" fieldset on page "translate/languages/de/export" the releases radios are not updated with the version numbers. I must press "Export" to get an error, select the version radio and press export again.
Comments
#1
Yes, this is how it works now, its not quite user friendly. I am happy to solve this when I update this module to Drupal 6, and can start to use the AHAH features there. Otherwise I welcome a fix for Drupal 5, but I am not going to work on one. (I am not much motivated to work on this, because it is expected that all package generation will be automated on drupal.org, so manual exports will only be for testing purposes, and this option will not get much use).
#2
Gabor, should we bump this to 6.x or close?
#3
Yeah, we would be still better off with nice AHAH treatment.
#4
ok, lets begin.
#5
1. Let's skip whitespace changes (maybe they were the ones already committed?)
2. Let's skip the nojs part. No need to point people that they are lame, if they have no JS.
Did not look/test yet with the other parts.
#6
reroll
#7
Trying to build this into the export form improvements I'm working on but not getting two things:
- what does this refer to? "if you choose 'All' and you change the project, you get the downloadfile as alert" - seeing this would be the role for the JS/NOJS marker on the form
- why do we need to set the form redirect in l10n_community_export_form_submit() if it was an invalid release?
#8
In fact applying this does not make any of the functionality work any different.
#9
Not sure if functionality have changed, but at time of writing you have selected the project and the version list havent updated. You only see the problem if projects don't share the same version numbers.
Long time ago that I've exported po files...
#10
Yes, I know what's the issue, I'm not seeing the patch working.
#11
#12
I think what I've tested was picking a project and then the release list did not show up. If there was already a project selected before and a release, then picking another project would possibly update the release list, but it did not seem to work for the initial selection, which I think is not nice.
#13
ok,now with "initial selection"
[EDIT]
we can remove $form['js'], if we add in l10n_community_export_page_js
$form_state = array('storage' => NULL, 'submitted' => FALSE, 'rebuild' => TRUE);because
l10n_community_export_page_js -> drupal_process_form -> form_execute_handlers('submit', $form, $form_state);without'rebuild' => TRUE.#14
Oh, boy, this was painful. I've looked into cleaning this up, and applying this same technique to the translation form (which is used even more, then this export form). I've also fixed this issue I mentioned above with first project / release selection to work. Instead of setting a random project (the first one) as the default, I think we should just display the whole form as it is.
I've applied the rebuild TRUE method you've provided too.
This is how the full patch looks now for the 6.x-2.x branch.
#15
#16
Ok, I figured that setting the form explicitly to be cached is not required. Apart from that committing the patch (modified version attached). To be ported to 1.x.
#17
Actually, same patch applied with little offsets to 1.x. Committed, thanks!
#18
Oh, and deployed to localize.drupal.org too.
#19
Automatically closed -- issue fixed for 2 weeks with no activity.