Skip to content

WT-856 Use Translated Text In Get/Download Firefox Buttons#1132

Draft
dchukhin wants to merge 73 commits intomainfrom
WT-856-download-firefox-buttons
Draft

WT-856 Use Translated Text In Get/Download Firefox Buttons#1132
dchukhin wants to merge 73 commits intomainfrom
WT-856-download-firefox-buttons

Conversation

@dchukhin
Copy link
Copy Markdown
Collaborator

@dchukhin dchukhin commented Mar 9, 2026

One-line summary

This pull request tries to use already-created translations for "Get Firefox" and "Download Firefox" buttons by rendering the text with ftl strings.

Significant changes and points to review

  • In order to not send the same text for translation from multiple places, we now have a FluentOrCustomTextBlock, which allows users to choose some pretranslated text ("Get Firefox", "Download Firefox"), or use custom text:
FluentOrCustomTextBlock FluentOrCustomTextBlockcutomtext
  • the FluentOrCustomTextBlock is used in the DownloadFirefoxButtonBlock
  • all previously created DownloadFirefoxButtonBlocks have had their text mapped to the new choices
  • similarly to the new block, the PreFooterCTASnippet now has a custom_label field for custom text that will be translated. Its label field has been renamed to pretranslated_label, and shows the same pre-translated choices as the FluentOrCustomTextBlock. Choosing "Custom text" allows the user to enter custom text that will be sent for translation.
PreFooterCTASnippet

Issue / Bugzilla link

WT-856

Testing

  1. log in to Wagtail, and find a page that uses the pre-footer snippet. For example, localhost:8000. Observe the value in the (non-firefox) template.
  2. change the value of the pre-footer call to action snippet to a pre-translated choice and view the page in en-US. Observe the updated label.
  3. change the value of the pre-footer call to action snippet to custom text and view the page in en-US. Observe the updated label.
  4. change the value of the es-MX pre-footer call to action snippet to a pre-translated choice and view the page in es-MX. Observe the updated label.
  5. change the value of the pre-footer call to action snippet to custom text and view the page in es-MX. Observe the updated label.
  6. Find a page that uses the download firefox button, and set the text value to be one of the pre-translated choices (for example, "Download Firefox"). Observe that the text in the template. Set another download button text to be some custom text.
  7. translate the page and observe that "Download Firefox" is not one of the translatable text fields, but it is already translated in the template. Observe that your custom text is one of the translatable text fields, and is not translated in the template.
  8. note that none of the pre-translated values should be sent for translation

dchukhin added 30 commits March 3, 2026 10:10
…ocale when the requested locale page is not found
Note: this logic shouldn't be needed, since all of
the locales should be present in the database, but
in case one of the locale records is removed from
the database, but the locale is still referenced
in the code (for example, in the settings), this
logic will handle it.
CANONICAL_LANG matches LANG, unless a page is served
for a fallback locale. In this case, the template
can determine which context variable (LANG or
CANONICAL_LANG) to use in each relevant place.
when a user requests a page and is given content
for a fallback locale, the page links in the
content should match the requested URL's locale.
…ent from alias locale URL when alias locale has no content
… alias Locale does not exist in the database
…when alias Locale does not exist in the database
this fixes an error where translating a page into
the new Locales was causing a server error,
because wagtail-localize was not able to correctly
find the root page in the new Locale.
The separation:
 - makes the logic more readable
 - avoids a scenario where the middleware intercepts
   the request and returns a Wagtail page when it
   should not
…h-2 home page sites

Previously, the middleware's Accept-Language
redirect was hardcoding Wagtail url_path prefixes
as /home and /home-{locale}, which only works when
the site root page is at depth 2. In environments
where Site.root_page is at a different depth (for
example at depth 3 with url_path=/home/home/), the
hardcoded prefixes were not matching pages,
causing 404s instead of redirects for Wagtail
Locales that did not have a specific page.


def convert_pages(apps, schema_editor):
models_and_fields = [
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This list needs to be updated with the new free form page 2026

except (json.JSONDecodeError, TypeError):
pass
if modified:
revision.save(update_fields=["content"])
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing the other field names

from django.contrib.contenttypes.models import ContentType

page_models = [
apps.get_model("cms", name) for name in ("HomePage", "DownloadPage", "ThanksPage", "ArticleThemePage", "FreeFormPage", "WhatsNewPage")
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here too

Comment thread springfield/cms/blocks.py
Base automatically changed from WT-854-language-fallback-for-pages to main April 7, 2026 07:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants