Skip to content

"Translate this page" button position is inconsistent across page menus #911

Description

@rypptc

The problem

The three-dot action menu for pages appears in three different contexts in the Wagtail admin. The order of actions is inconsistent across these contexts, causing the "Translate this page" option to appear in a different position depending on where the user accesses it.

Position of "Translate this page"

View URL Position
Page listing /admin/pages/ 10 (last, requires scrolling)
Page index /admin/pages/<id>/ 5
Page editor /admin/pages/<id>/edit/ 6

Full order across all three menus

# Listing /admin/pages/ pri Editor /admin/pages/<id>/edit/ pri Index /admin/pages/<id>/ pri
1 Edit 2 Edit 10 Edit 10
2 View live 6 Add child page 15 Move 20
3 Add child page 8 Move 20 Copy 30
4 Move 10 Copy 30 Delete 50
5 Copy 20 Delete 50 Translate this page 60
6 Delete 30 Translate this page 60 Unpublish 60
7 Unpublish 40 Unpublish 60 History 65
8 History 50 History 65 Sort menu order 70
9 Sort menu order 60 Sort menu order 70
10 Translate this page 60

pri = the priority value assigned to the button when registered via the Wagtail hook. Lower values appear first.

Root cause

The buttons in these menus are added via two separate Wagtail extension hooks. wagtail-localize registers the "Translate this page" button in both:

  • register_page_listing_more_buttons — called when rendering the page listing menu (/admin/pages/)
  • register_page_header_buttons — called when rendering the page index (/admin/pages/<id>/) and page editor (/admin/pages/<id>/edit/) menus, distinguished by the view_name parameter ("index" or "edit")

wagtail-localize registers the "Translate this page" button with priority=60 in both hooks from the same function (wagtail_hooks.py lines 169 and 181). However, each hook defines its own priority values independently with no shared or documented scale:

  • In register_page_listing_more_buttons values range from 2 to 60 — so priority=60 is the maximum
  • In register_page_header_buttons values range from 10 to 70 — so priority=60 falls in the middle

When two buttons share the same priority, Wagtail sorts them alphabetically by label. This determines the final behavior:

  • In the listing: "Sort menu order" (S) < "Translate this page" (T) → Translate ends up last
  • In the editor/index: "Translate this page" (T) < "Unpublish" (U) → Translate appears before Unpublish

Steps to reproduce

1. Page listing — go to /admin/pages/ and open the three-dot menu next to any page. "Translate this page" appears last and requires scrolling to find.

Image

2. Page index — go to /admin/pages/<id>/ and open the three-dot menu. "Translate this page" appears in position 5.

Image

3. Page editor — go to /admin/pages/<id>/edit/ and open the three-dot menu. "Translate this page" appears in position 6.

Image

Expected behavior

Actions that appear across all three menus should maintain a consistent relative order. In particular, "Translate this page" should appear in a similar position in all three contexts, making it easier to discover and use. A user who learns where to find the option in one context should be able to find it in the others without confusion.

Proposed solution

Short term: Review the priority value assigned to the "Translate this page" button in wagtail_hooks.py (lines 169 and 181) so that it appears in a consistent and visible position across all three menus.

Longer term: It may also be worth opening an issue in the Wagtail core repository, since the priority scales of both hooks are independent and a shared convention could help plugin authors position their buttons more predictably.

Alternative solutions

The most straightforward fix would be to change priority=60 to a lower value in wagtail_hooks.py (lines 169 and 181). However, since both hooks share the same function and use different priority scales, any single value will produce a different relative position in each context. A more complete solution would require changes to how the button is registered across both hooks.

Additional context

No response

Working on this

Contribute to the discussion to help this move forward. Explain your use cases, discuss possible solutions, research how to adapt existing code, or compatibility concerns.

Once others agree with the proposed changes, anyone can contribute to this. View our contributing guidelines. Add a comment to the issue to explain what approach you are taking.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions