sergiorett

Hello Anca,

Thank you for your reply. I have now checked all the points you mentioned.

1. “Do not translate certain paths”

This option is not enabled.

Under:
TranslatePress → Advanced → Exclude Strings & Pages → Do not translate certain paths

no option is selected and the paths field is completely empty.

2. Does the issue appear only on the homepage or on other pages as well?

This is an important finding:

The problem appears only on the homepage of the secondary language.

For example:

https://reverserettgreece.gr/en/

fails, while internal pages under the English language path load normally.

I tested the Rett syndrome page and it opens correctly under the /en/ language path.

So translated internal URLs are working; the problem is specifically with the root homepage of the secondary language.

3. Does the issue also appear with another language, such as French?

Yes.

I tested French as the secondary language and:

https://reverserettgreece.gr/fr/

shows the same problem.

I then discovered something even more specific: the issue is not tied to English or French themselves.

Whichever language is configured as the secondary language, its homepage fails.

In other words:

• the default-language homepage works;
• the secondary-language homepage fails;
• changing the secondary language does not change the behavior;
• internal pages of the secondary language can still load.

This makes the problem appear related to secondary-language homepage routing, rather than to a specific language.

4. Have I used another translation plugin, such as GTranslate?

No. I have not used GTranslate or another translation plugin on this site.

5. Redirect rules outside .htaccess

I have already checked several possible sources:

• .htaccess contains only the standard WordPress rewrite rules and normal compression/cache directives.
• There is no Redirection plugin in use.
• I disabled all other plugins and tested with only TranslatePress active; the problem remained.
• I temporarily disabled the hosting-level Force HTTPS option; the problem remained.
• I also tested with the security/SSL plugin disabled; no change.
• WordPress Address and Site Address are both configured as:
  https://reverserettgreece.gr

I do not have direct access to the web server’s NGINX configuration, so if you believe this should also be checked, I can ask the hosting provider to verify it.

6. Additional HTTPS-related behavior

There is another detail that may be relevant.

When accessing the homepage of the secondary language, the browser sometimes reports that the site does not support a secure connection and appears to fall back to, or attempt to use, an HTTP version.

I have attached a screenshot showing this behavior with /fr/.

This is especially interesting because:

• the default Greek site works correctly over HTTPS;
• internal translated pages can load;
• only the secondary-language homepage is affected;
• the same behavior occurs regardless of which language is configured as secondary.

I had also noticed earlier that the TranslatePress Google API credential test reports:

http://reverserettgreece.gr

as the HTTP Referrer, even though the website itself is configured and served over HTTPS.

The Google Translation API test itself succeeds with 200 OK.

7. Staging site

At the moment I do not have a staging environment available on the current hosting plan.

The live site has now been launched in Greek, so I prefer not to leave a broken secondary-language homepage publicly exposed.

I can temporarily activate TranslatePress on the live site for additional diagnostics if necessary, or I can provide a staging environment once I upgrade the hosting plan.

Based on the above, the issue now seems specifically related to the homepage handling of the secondary language, possibly involving canonical redirects, language-root routing, or HTTPS scheme detection.

Please let me know what you would recommend checking next.

Kind regards,
Sergey Dmitriev