Update to add, when reverting the changes mentioned in the ticket, it no longer gets the storage URL, but the actual URL correctly, and the error messages show in the correct language.

In my case $previousUrl is a storage link (myurl.test/storage/images/downloads/hobby/SDS_thumbnail_mobile.jpg), which does not contain a locale, which means Site::findByUrl() does not return an actual site.

What's the URL of the page you're submitting the form on?

You mentioned that you're submitting the form via AJAX, can you provide the code you're using?

The URL of the page I'm submitting the form on is either myapp.url/de/tools/shoplocator or myapp.url/de/hobby/produkte/<some_product>.

The AJAX looks as follows, it's all in a separate function which is called the moment the form-ajax-submit button is clicked;

let form = $(e.target).closest('form');
let formHtmlElement = form[0];
let formErrorSpan = form.find('span[data-failure]');
let failureMessage = formErrorSpan.data('failure');

// clear potential previously set validation errors
forms.clearValidationErrors(form);

// show spinning loader
$('#envelope-icon').addClass('d-none');
$('#spinning-loader').removeClass('d-none');

// Get the formData for this form. (Doing this in the AJAX call results in an Illegal Invocation error)
let formData = new FormData(formHtmlElement);

$.ajax({
        url: formHtmlElement.action,
        type: 'POST',
        data: formData,
        processData: false,
        contentType: false,
    })
      .done(response => {
          if (response.success) {
              let confirmationRow = $('#confirmation-row');
              let formRow = $('#form-row');
              let formButton = $('.form-ajax-submit');

              confirmationRow.removeClass('d-none');
              formRow.addClass('d-none');
              formButton.addClass('d-none');

              $('html, body').stop(true,true).animate({
                  scrollTop: (confirmationRow.offset().top - 20)
              }, 500, 'linear');

              forms.enableSubmit(e);
          }
      })
      .fail(response => {
          if (response.status === 404) {
              console.log(response.responseJSON.message);

              formErrorSpan.html(failureMessage);
              formErrorSpan.show();
          } else {
              $.each(response.responseJSON.error, function (formFieldName, validationErrorText) {
                  let formField = form.find(`[name=${formFieldName}]`);
                  let formFieldValidationSpan = form.find(`span.${formFieldName}`);

                  formFieldValidationSpan.html(validationErrorText);
                  formFieldValidationSpan.show();
                  formField.addClass('is-invalid');
              });

              // This just enables the submit again on error.
              forms.enableSubmit(e);
          }
      });

We use the following ajaxSetup

$.ajaxSetup({
    headers: {
        'X-CSRF-TOKEN': $('meta[name="csrf-token"]').attr('content'),
        'Accept-Language': $('html').attr('lang'),
        'X-Requested-With': 'XMLHttpRequest',
    },
});

We render forms in an Antlers PHP file, using

<div class="d-none" id="composed-view-data" data-countries='{{$ htmlentities($countries) $}}' data-languages='{{$ htmlentities($formSites) $}}'></div>
{{ form:no_shops_shoplocator name="no_shops_shoplocator" id="no-shops-shoplocator" }}
    <div class="row d-none" id="confirmation-row">
        <h2>{{ confirmation.title }}</h2>
        <p>{{ confirmation.content }}</p>
    </div>

    <!-- {{# if an error occurs that is not related to a specific field it will be shown here #}} -->
    <span class="invalid-feedback invalid-form" data-failure="{{ translate key='failure' }}"></span>

    <div class="row" id="form-row">
        <!-- {{# render all form fields that have been defined in the statamic blueprint.
             how formfields are rendered can be changed through antler files in /resources/views/vendor/statamic/forms/fields #}} -->
        {{ fields }}
            <div class="form-group col-{{$ percentageToColumn($width) $}}">
                <label for="{{ translate key="$handle" }}">
                    {{ translate key="$handle" }}
                    {{ if validate|contains:required }} * {{ /if }}
                </label>
                {{ field }}
                <span class="{{$ $handle $}} invalid-feedback"></span>
            </div>
        {{ /fields }}
    </div>

    <div class="w-100 mx-0 mt-5 mb-lg-0 row justify-content-end px-lg-0 px-3">
         <!-- {{# submit button, the 'form-ajax-submit' is picked up by jquery that will submit this form through ajax #}} -->
         <button class="btn col-12 col-lg-3 col-xl-2 btn-disabled RobotoMedium me-lg-3 form-ajax-submit" disabled>{{ translate key="submit" }}
             <i class="ms-2 fa fa-angle-right"></i>
             <i id="spinning-loader" class="fas fa-circle-notch fa-spin d-none"></i>
         </button>
    </div>

{{ /form:no_shops_shoplocator }}

Why would $previousUrl be an image? 🤔

That's what I'm wondering as well @jasonvarga.

That specific image was throwing a 404, but for me, the behavior is reproducible on pages without 404's due to images. and on pages with other forms.

But I guess session()->previousUrl() as used in the new code can return storage urls, whilst URL::previous() as used before the change can not? But that's purely hypothetical.

I'll see if I can create a reproducible repo/zip-file sometime soon.

Do you have multiple of these forms on a page and do they take you to the file on success? If so, is the error only happening after the first submission?

Hey @ryanmitchell

There's only one of these forms on a page, at all times. There can be other forms on the same page, but these are not handled through Statamic.

Not quite sure what you mean with the following. What file are you referring to?

do they take you to the file on success?

Ok - I was thinking if you had multiple forms on the page and it redirected to the file then it would set the previousUrl() to be that file, so when you next submitted the form it would get that value. I guess not.

Ah right, no that's not happening as far as I am aware. Upon success, I can see the submission in the control panel and I get the e-mail delivered to my mailbox, so that's all working as intended.

The problem is really with the displaying of localized error messages.

Are you able to replicate this issue on a fresh site or provide access to the site where you're experiencing this issue?

Heya @duncanmcclean

Did some more tinkering. It did happen due to the 404 on an image, which causes $previousUrl to take the value of the URL that is 404'ing. (I could swear I saw it happening without the 404, but I can't reproduce it, and it could have been caused by cache).

I've taken some time to create a minimal reproducible example on a fresh site, where I can reproduce it by creating an img element with a non-existing image.
If that element is not present, everything works as expected. If it is present, the validation errors will no longer be translated.

I'm setting up the Github repo right now, will comment in a minute.

That would make sense as the missing image would hit the Statamic/Laravel session handler and so set the last URL.

@ryanmitchell That does make sense, but it doesn't do that if I manually reverse the changes made in ec9e5c5 then everything works as expected.

Even with the missing image, the messages will be properly translated.

@duncanmcclean My Github SSH keys are giving me grief, so here's a ZIP archive containing the example app.
statamic-reproducible-example.zip

It did happen due to the 404 on an image

Technically, it's working as expected from Statamic's perspective. It's using whatever the last page you visited was to determine the site.

In your case, since that's a 404'ing image, it hits Statamic/Laravel and it gets counted as the "previous page". If you fix the 404'ing image, it should work fine.

Right, but that does not happen prior to those changes, and it's kind of weird from a user's perspective to see un-translated error messages just because there is an image missing.

But, seeing that you've closed the issue, I guess that means you'll not be looking into it further.

Actually, I have an idea of how we can fix it while not breaking things for headless sites (which was the reason for that change).

I took the liberty of testing the changes you proposed, works like a charm, thanks!