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

gábor hojtsy’s picture

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).

meba’s picture

Gabor, should we bump this to 6.x or close?

gábor hojtsy’s picture

Version: 5.x-1.x-dev » 6.x-1.x-dev
Category: bug » feature

Yeah, we would be still better off with nice AHAH treatment.

tobiasb’s picture

Status: Active » Needs review
StatusFileSize
new7.89 KB

ok, lets begin.

gábor hojtsy’s picture

Status: Needs review » Needs work

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.

tobiasb’s picture

Status: Needs work » Needs review
StatusFileSize
new5.16 KB

reroll

gábor hojtsy’s picture

Status: Needs review » Needs work

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?

gábor hojtsy’s picture

In fact applying this does not make any of the functionality work any different.

hass’s picture

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...

gábor hojtsy’s picture

Yes, I know what's the issue, I'm not seeing the patch working.

tobiasb’s picture

Status: Needs work » Needs review
StatusFileSize
new4.42 KB
gábor hojtsy’s picture

Title: Export: selecting a project does not update releases radios » Selecting a project does not update releases radios on export
Component: Code » Export

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.

tobiasb’s picture

StatusFileSize
new4.92 KB

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.

gábor hojtsy’s picture

Title: Selecting a project does not update releases radios on export » Selecting a project does not update release options
Version: 6.x-1.x-dev » 6.x-2.x-dev
StatusFileSize
new12.82 KB

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.

tobiasb’s picture

Status: Needs review » Reviewed & tested by the community
gábor hojtsy’s picture

Version: 6.x-2.x-dev » 6.x-1.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)
StatusFileSize
new12.72 KB

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.

gábor hojtsy’s picture

Version: 6.x-1.x-dev » 6.x-2.x-dev
Status: Patch (to be ported) » Fixed

Actually, same patch applied with little offsets to 1.x. Committed, thanks!

gábor hojtsy’s picture

Oh, and deployed to localize.drupal.org too.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.