Publisher does not support the Fluid field type. Please do not contact asking when support will be available.

If you purchased an add-on from expressionengine.com, be sure to visit boldminded.com/claim to add the license to your account here on boldminded.com.

Ticket: Understanding how “Get language from browser” works…?

Status Resolved
Add-on / Version Publisher 3.9.3
Severity
EE Version 6.4.11

Gavin @ JCOGS

May 11, 2023

I have set up site so “Get language from browser” is enabled.
The site has an English translation with the ‘language code’ set to “en”.
The site has a default language of Spanish with a language code of “es”.
The HTTP_ACCEPT_LANGUAGE header returns “en-GB,en;q=0.5”.
When the site loads the default language always shows, and the {publisher:current_language_code} variable returns “es”.
What am I missing?
Thanks for any guidance you can offer on this.

 

 

 

 

#1

BoldMinded (Brian)

Have you tried changing your browser or os default language? If you do that it’ll work. If a user has their browser or os default language set to German then the site will default to German, if German is a defined site language.

#2

Gavin @ JCOGS

Had already done that (see image added to question showing browser settings). Also tried using a browser with cookies disabled (what Firefox calls “Private” and Chrome “incognito”) (documentation suggests this feature may only apply the first time you visit the site) but that makes no difference either. Have had another user test same feature and they get same results. Clearly I’m missing something.

#3

BoldMinded (Brian)

Have you tried changing the OS language? I’ve found that the browser language switching sometimes doesn’t work.

#4

BoldMinded (Brian)

I just double checked this and it’s working for me locally. Make sure the language code defined in Publisher matches a valid code from HTTP_ACCEPT_LANGUAGE, make sure your cookies are clear (e.g. first time user to the site), and make sure the browser is properly setup in that language. The Session->findLanguage() function is where all this happens.

https://www.dropbox.com/s/386uba5ukovv6k7/Screenshot%202023-05-11%20at%207.41.54%20AM.png?dl=0

#5

Gavin @ JCOGS

I’ve stepped through the Session->findLanguage() function and beyond on my local system and can confirm that $this->setBrowserLanguageCode($languageCode[0]); does indeed set the language to ‘en’ as it should. However despite this, when I load a page in a browser window with no existing cookies / session present (i.e. a new empty private / incognito window) the site loads the default language version of the site (i.e. https://newfd.jcogs.net) rather than the english version (https://newfd.jcogs.net/en/), and the variable {publisher:current_language_code} returns es rather than en.

So once again I guess I am missing something.

Any more thoughts?

#6

BoldMinded (Brian)

Try enabling the language prefix even for the default language to see if it tries to perform a redirect or behave differently.

#7

Gavin @ JCOGS

Have tried enabling this option (assume you mean the option Publisher / General Settings / URL Translations / Add URL prefix to the homepage). Seems to make no difference. In doing this I also noticed that (fresh privacy browser window each time): If I open site base URL via a direct link (e.g. domain.com) home page opens without a language slug and uses default langauge. If I open the site with base URL with default language slug (e.g. domain.com/es/) the URL is rewritten to remove the language slug. If I open the site with base URL with optional language slug (e.g. domain.com/en/) the URL remains unchanged, and page shown in appropriate language.

Does any of that help clarify what might be going on?

#8

BoldMinded (Brian)

Can you share a screenshot of publishers url translation settings page?

#9

Gavin @ JCOGS

Done

#10

BoldMinded (Brian)

Try disabling the “Hide the prefix for default language” option. I have the first 3 checked in my local, last one unchecked, and when I go to domain.com it redirects to domain.com/en immediately. You should see the same behavior.

#11

Gavin @ JCOGS

Ahah - great - that’s working now. Client not happy though - they want to hide the default language slug (as site used to not have this, and they are concerned about SEO or some such). No idea if their SEO concerns are well founded, but will present to them as an either / or (no slug, or auto language selection) and they can choose which they prefer…

#12

BoldMinded (Brian)

I think I found the issue, new build in the next comment. You should be able to remove the language prefix for the default language and it should still work.

#13

BoldMinded (Brian)

Comment has been marked private.

#14

Gavin @ JCOGS

Comment has been marked private.

#15

Gavin @ JCOGS

Also - with “Hide the prefix for the default language” set to ‘off’ - if I open https://domain.com in a new instance of a privacy browser, I get the Spanish version … (which has browser URL updated to https://domain.com/es/). HTH

#16

BoldMinded (Brian)

I don’t have time to look into this anymore today unfortunately. As for the version error just remove this block from the addon.setup.php file.

'requires'       => [
        'php'   => '7.4',
        'ee'    => '7.2.17'
    ],
#17

Gavin @ JCOGS

Comment has been marked private.

#18

BoldMinded (Brian)

You mentioned in both cases “with default language in English” - This is Publisher’s default language setting I assume you’re referring to. Do you have your browser set to a different language?

#19

Gavin @ JCOGS

Hi. Sorry if it is confusing. Site has default language of Spanish (code ES) and has translated versions in English (code EN) and Portuguese Portuguese (PT-PT). Testing for new dev version is using a new privacy browser (i.e. no existing cookies / cache) which has the default language setting of English on a computer which also has default language of English. HTH clarify how things are set up.

#20

BoldMinded (Brian)

I’m sorry this has been such a process, but I’m still unable to replicate. Are you able to take a video of the settings page and show what is happening in the browser?

Locally, if I set Publisher’s default language to German, browser default language to English with the “get language from browser” setting on, it’s correctly loading English content in a new browser window. The “hide default language segment” option is working correctly too wether it’s in the on or off state.

#21

Gavin @ JCOGS

Comment has been marked private.

#22

BoldMinded (Brian)

Nothing happens when I go to that link

#23

Gavin @ JCOGS

Comment has been marked private.

#24

BoldMinded (Brian)

I don’t know what happened but the link worked once, I was able to watch the video, but now it won’t load again.

Can you share the template code you’re using in your language switcher?

#25

Gavin @ JCOGS

Comment has been marked private.

#26

Gavin @ JCOGS

Comment has been marked private.

#27

BoldMinded (Brian)

That new link isn’t working again :(

I just abandoned using iCloud Drive, which was free with my family subscription, and started paying for basic Dropbox, b/c iCloud lacked some features. So I know the feeling.

#28

BoldMinded (Brian)

One thing of note that I haven’t tested but noticed in your code:

http://{switch_language_url}

{switch_language_url} should already include the http or https. What happens if you remove the http:// in front of it?

#29

BoldMinded (Brian)

Or does your template not include that and the pasted code block is fubaring the code?

#30

Gavin @ JCOGS

Comment has been marked private.

#31

BoldMinded (Brian)

I’m looking into this again, but I noticed the URL seems malformed. I think you need an & before itemprop.

{switch_language_url}&itemprop=url

#32

BoldMinded (Brian)

This is what I’m seeing when Firefox is set to German as the default language and the default language of my dev site is set to German as well. The hide prefix for the default language is also turned on, and I copied your language switcher code above.

https://capture.dropbox.com/RXm2g4gg9v8PCKRI

#33

Gavin @ JCOGS

So I’ve literally just grabbed this from the site. This is the language menu link for English when the site is set to operate in Spanish.

<a href="https://newfd.jcogs.net/?ACT=49&lang_id=2&url=aHR0cHMlM0ElMkYlMkZuZXdmZC5qY29ncy5uZXQlMkZlbg==itemprop=url"><span class="fi fi-gb"></span> <span>English</span></a>

Itemprop is an attribute for the anchor tag, but not associated with the url. Not sure what you are seeing that makes you think it is.

Glad to see that the auto-language feature can work with the hide default language setting, but unclear why it isn’t working on this site.

Client did some GTMetrix auditing and observed that the there are multiple redirects loading the page, with at least one (he claims, not sure how he determined) is a 302 redirect). A quick squint at the GTMetrix reporting suggests multiple redirects associated with language handling - see image added to question.

Any thoughts?

#34

Gavin @ JCOGS

OK - so looking at the code fragment shown in last posting, your code formatter is borking the code. Have attached a screen grab of the actual HTML …

#35

Gavin @ JCOGS

Comment has been marked private.

#36

BoldMinded (Brian)

The end of the Service/Url.php->redirect() method makes an exit call, so it can’t send anymore html output at that point, and all this happens in EE’s session class before it creates any html to output to the page. EE’s template parser hasn’t even kicked in yet at this point. I don’t see how this is anything I can change.

#37

BoldMinded (Brian)

Have you tried replicating this locally, in a clean/new EE site without LiteSpeed, Cloudflare, and several other things I’m seeing in the headers?

#38

Gavin @ JCOGS

Comment has been marked private.

#39

BoldMinded (Brian)

At this point though, since I can’t replicate it locally, the next step is to create a clean EE install with only Publisher installed and a single template file to replicate the issue yourself. If you can replicate it there then it would prove that there isn’t something unique happening in your main site’s environment, otherwise, there could be some other issue happening on your site that I’m not aware of and can’t debug at this point.

#40

Gavin @ JCOGS

Comment has been marked private.

#41

BoldMinded (Brian)

I’m not asking you to fix the bug for me. I’m asking that you take steps to help debug the situation, and part of debugging is simplifying. It’s mentioned in my support terms that I can ask a customer to do this when I can’t re-create the issue or the issue is not immediately apparent on the customer’s site. We’re now 40 comments into this support thread and there is still no resolution, so it’s time we try something else. You’d be surprised how many times an issue is resolved b/c it turned out to be an add-on conflict of some sort, or something very specific and unique to the customer’s environment, or it turns out to be user error. Recreating the issue in a simplified form gets to the problem faster.

Login to reply