Rename operation in Input Formats from 'Configure' to 'View Configuration'

I changed the component from base system into filter.module

in Drupal 5.6 line 318 in forum.module can be changed from:
-- $form[$format->name]['configure'] = array('#value' => l(t('configure'), 'admin/settings/filters/'. $id));
++ $form[$format->name]['configure'] = array('#value' => l(t('view configuration'), 'admin/settings/filters/'. $id));

If I click on "configure" for Full HTML, I can change the name, choose roles, what filters are applied, etc. Why would "view" (which really implies a read-only kind of thing) be more appropriate (since you really can do more than just view, here)?

The main reason behind the request for the name change is because after a user clicks configure (in operations on admin/settings/filters), the user lands on the view page in Drupal 5.x (edit page in Drupal 6.x) which has another tab called configure next to view tab (for Drupal 5.6 or edit for Drupal 6.x)

If the user were to click on configure operation in admin/settings/filters they should land on the page with the configure tab highlighted or the operation title (configure) should be renamed according to the page the user lands on after clicking (view for 5.6, edit for 6.0.)

While configure is a better description of whats on the page/form/node, the user should then land on a page/form/node that is titled configure instead of a view or edit page.

The names of the pages that the user lands on right now is can remain unchanged and the settings they have access can remain unchanged on that page, its the title of the operations link (on admin/settings/filters) that needs to be renamed with the title of the page to which the link leads to.

As in Drupal 6.0, edit is a better title for the page than the title of view in Drupal 5.6
If title Edit was carried over to Drupal 7, then the operation title in admin/settings/filters should be renamed from configure to edit.

OK. That sounds reasonable. But, for D6 and beyond, why not change the "configure" on /admin/settings/filters to "edit" so that it will match the highlighted tab when one clicks it.

I just added that (in a more recent edit before seeing your query) to the post above:

As in Drupal 6.0, edit is a better title for the page than the title of view in Drupal 5.6
If title Edit was carried over to Drupal 7, then the operation title in admin/settings/filters should be renamed from configure to edit.

I made the suggestion for the operation title of view after checking the page title in 5.6 but before checking the title of the page in Drupal 6.0

After looking at Drupal 6.0, the operation title of edit sounds more reasonable.

line 34 of filter.admin.inc
-- $form[$format->name]['configure'] = array('#value' => l(t('configure'), 'admin/settings/filters/'. $id));
++ $form[$format->name]['configure'] = array('#value' => l(t('edit'), 'admin/settings/filters/'. $id));

Cool. Make a patch. IMHO, it would be A Good Thing(tm).

Awesome!

Drupal 5.7 Patch

Manually changing the line works on a live site, I haven't tested it using auto patching.

Drupal 6.0 RC 4 Patch

Same as above, manually changing the line works on a live site, yet to be tested using auto patching.

Patch for Drupal Head (I'm assuming head patches make it to Drupal 7)

While this (the patch for Drupal 6) is past string freeze, it uses the same string ("edit") as, say, menu items on admin/build/menu-customize/navigation page (and possibly others).

As stated, it does clear up the confusion where one clicks on "configure", but lands on a page named "Edit", where a "Configure" tab is also shown, but not selected.

Since it removes a usability problem without inconveniencing translators, I'm moving this to a 6.x bug report.

Patch should to be created from root of drupal so that it can be applied from the root of drupal.

Otherwise this applied cleanly, fixes said bug, and is RTBC IMO.

Here's the patch for Drupal 6.0

I think its created in root. I went with the instructions on http://drupal.org/node/113172 for the earlier patches. For the latest patch I opened the drupal folder, right clicked the whitespace on the window and then chose CVS>Patch using Tortoise CVS.

The patch should be ready to commit if it can be applied from root. I'd like to thank Greggles for letting me know how to get started with patching (http://groups.drupal.org/node/8745)

Hmm. I'm not sure what command your using or where from, but when I apply your patch from drupal root with www $ patch -p0 < filterep6.patch, patch asks me where filter.admin.inc is and I have to specify modules/filter/filter.admin.inc.

I created this patch with www $ cvs diff -up modules/filter > 219584.patch and it applies fine without needing me to specify the location of filter.admin.inc. I hope that helps.

I didn't make any code changes in this patch.

Unfortunately, this didn't get into Drupal 6 before release, so we'll try for 7.x-dev (and work backwards, if Gabor chooses).

Thanks for fixing up the patch.

I wouldn't mind which release the patch gets integrated into.

@SteveJB: TortoiseCVS doesn't create patches from the root in the way that they refer to it here. Yes, it does start from the root of the directory structure and will create patches for all of the changed files. However, it doesn't include the pathing in the patch file indicating the directory where the file being patched is located. I haven't found any way to change the settings for this functionality.

Well Scoutbaker, Tortoise was the quickest way to make a patch. I'd rather have a somewhat working patch out right now (that could be tested and adapted into a working patch) rather than wait around till I am able to work with WinCVS.

WinCVS seems to be the best for patching from windows. Tortoise was used to get a patch out ASAP and as quick and easy to use as it is, it isn't as functional as WinCVS.

@SteveJB: I was not judging the patch, I was merely providing information about the functionality of TortoiseCVS that I had discovered in my own use of that tool. In #16 you seemed unsure, and Bevan mentioned it in #17.

I want to hold of committing this patch until http://hojtsy.hu/blog/2008-feb-04/supporting-wysiwyg-editing-better-drup... lands. Gabor is making some additional UI changes to the input formats so I'd recommend that you follow up with him.