Answers.Body: <p>This was a configuration error on our part. Clean URLs was not fully functional - the language prefix was missing from the beginning of non-clean URLs so the final URLs were resolving to only the default language.</p>
  
  <p>Adding <code>$conf['clean_url'] = 1;</code> to the settings file resolves the issue.</p>
  
  <p>Thank you @bgm for helping with the demo site so that we could narrow this down to an issue with our site specifically.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-11-29T03:44:48.387Z
Answers.LastActivityDate: 2018-11-29T03:44:48.387Z
Answers.UserDisplayName: freeform.steph
Answers.Body: <p>Are you using the Canadian Tax Receipts extension?</p>
  
  <p>If so, can you test this patch: <a href="https://github.com/jake-mw/CDNTaxReceipts/pull/86" rel="nofollow noreferrer">https://github.com/jake-mw/CDNTaxReceipts/pull/86</a> ?</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-10-26T21:56:13.110Z
Answers.Text: Thanks for your reply, unfortunately no, we are not using this extension on this particular site.
Answers.UserDisplayName: freeform.steph
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-10-26T22:42:53.460Z
Answers.Text: I've updated the original post to include the list of enabled extensions
Answers.UserDisplayName: freeform.steph
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-10-29T12:54:48.013Z
Answers.Text: I updated our bilingual demo site (https://demo.symbiotic.coop) to 5.7-rc, but haven't been able to reproduce the issue.
Answers.UserDisplayName: bgm
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-11-06T04:34:28.483Z
Answers.Text: Thank you for updating the demo site! I've tried switching to Garland to rule out a theme issue, have tried disabling CiviDiscount, and played around with the Drupal language settings all to no avail. I am quite stumped on this one.
Answers.UserDisplayName: freeform.steph
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-11-06T13:05:56.097Z
Answers.Text: Can you try this patch: https://github.com/civicrm/civicrm-core/pull/13050 ?
Answers.UserDisplayName: bgm
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-11-06T15:02:04.977Z
Answers.Text: Thank you! I will give that a shot and get back to you later today.
Answers.UserDisplayName: freeform.steph
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-11-07T04:10:43.163Z
Answers.Text: Unfortunately the patch did not resolve our issue. What's interesting is that the option labels for custom price options appear in the correct language, as well as the page title - but that's it. Is the demo site using a price set with custom price fields, or just basic price options? We've been testing with a membership form, as well as a donation form, both using price sets.
Answers.UserDisplayName: freeform.steph
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-10-26T12:46:57.387Z
Answers.LastActivityDate: 2018-10-26T12:46:57.387Z
Answers.UserDisplayName: bgm
Body: <p>When using a contribution form in French with the confirmation page enabled, the page redirects to the English confirmation page url instead of the French.</p>
  
  <p>Start here: <a href="https://domain.ca/fr/civicrm/contribute/transact?reset=1&amp;id=[cid]" rel="nofollow noreferrer">https://domain.ca/fr/civicrm/contribute/transact?reset=1&amp;id=[cid]</a></p>
  
  <p>End here: <a href="https://domain.ca/en/civicrm/contribute/transact?_qf_Confirm_display=true&amp;qfKey=[key]" rel="nofollow noreferrer">https://domain.ca/en/civicrm/contribute/transact?_qf_Confirm_display=true&amp;qfKey=[key]</a></p>
  
  <p>If I manually switch to the French url, everything looks OK, but if you hit the CiviCRM 'go back' button, it will take you back but switch to English again.</p>
  
  <p>Similarly, if you attempt to go to the confirmation page but the form doesn't validate, while the URL doesn't change, the contents switch to English - all except for price set options (price set labels and help text are in English though). </p>
  
  <p>This is our set-up: </p>
  
  <ul>
  <li>Drupal 7 with language detection based on url language prefix (en, or
  fr) </li>
  <li>Multilingual site using CiviCRM 5.6.1 (latest at time of writing)</li>
  <li>'Inherit CMS Language' is enabled</li>
  <li>Default language is en_CA, secondary language is fr_CA</li>
  </ul>
  
  <p>Extension enabled:</p>
  
  <ul>
  <li>iATS Payments</li>
  <li>Summary Fields</li>
  <li>ExtendedReport</li>
  <li>CiviDiscount</li>
  </ul>
  
  <p>The bilingual demo site is currently out of date so I've been unable to confirm if this is just us or 5.6.x in general.</p>
  
Tags: <contribution-page><translation>
Title: Contribution page validation errors display and confirmation screen switch to default language instead of remaining in the current language
ThreadText: # Contribution page validation errors display and confirmation screen switch to default language instead of remaining in the current language
  
  (Asked by: username_0 on 2018-10-26)
  
  When using a contribution form in French with the confirmation page enabled, the page redirects to the English confirmation page url instead of the French.
  
  Start here: <https://domain.ca/fr/civicrm/contribute/transact?reset=1&id=[cid]>
  
  End here: <https://domain.ca/en/civicrm/contribute/transact?_qf_Confirm_display=true&qfKey=[key]>
  
  If I manually switch to the French url, everything looks OK, but if you hit the CiviCRM 'go back' button, it will take you back but switch to English again.
  
  Similarly, if you attempt to go to the confirmation page but the form doesn't validate, while the URL doesn't change, the contents switch to English - all except for price set options (price set labels and help text are in English though).
  
  This is our set-up:
  
  * Drupal 7 with language detection based on url language prefix (en, or
    fr)
  * Multilingual site using CiviCRM 5.6.1 (latest at time of writing)
  * 'Inherit CMS Language' is enabled
  * Default language is en\_CA, secondary language is fr\_CA
  
  Extension enabled:
  
  * iATS Payments
  * Summary Fields
  * ExtendedReport
  * CiviDiscount
  
  The bilingual demo site is currently out of date so I've been unable to confirm if this is just us or 5.6.x in general.
  
  **Tags:** contribution-page, translation
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2018-11-29. Score: 1 | Accepted answer
  
  This was a configuration error on our part. Clean URLs was not fully functional - the language prefix was missing from the beginning of non-clean URLs so the final URLs were resolving to only the default language.
  
  Adding `$conf['clean_url'] = 1;` to the settings file resolves the issue.
  
  Thank you @username_1 for helping with the demo site so that we could narrow this down to an issue with our site specifically.
  
  
  ---
  
  ### Answer by username_1 on 2018-10-26. Score: 0
  
  Are you using the Canadian Tax Receipts extension?
  
  If so, can you test this patch: <https://github.com/jake-mw/CDNTaxReceipts/pull/86> ?
  
  > **Comments:**
  > **username_0**: Thanks for your reply, unfortunately no, we are not using this extension on this particular site.  
  > **username_0**: I've updated the original post to include the list of enabled extensions  
  > **username_1**: I updated our bilingual demo site (https://demo.symbiotic.coop) to 5.7-rc, but haven't been able to reproduce the issue.  
  > **username_0**: Thank you for updating the demo site! I've tried switching to Garland to rule out a theme issue, have tried disabling CiviDiscount, and played around with the Drupal language settings all to no avail. I am quite stumped on this one.  
  > **username_1**: Can you try this patch: https://github.com/civicrm/civicrm-core/pull/13050 ?  
  > **username_0**: Thank you! I will give that a shot and get back to you later today.  
  > **username_0**: Unfortunately the patch did not resolve our issue. What's interesting is that the option labels for custom price options appear in the correct language, as well as the page title - but that's it. Is the demo site using a price set with custom price fields, or just basic price options? We've been testing with a membership form, as well as a donation form, both using price sets.  
  
  ---
  
  