Open talksina opened 2 weeks ago
Thank you for reaching out and sharing the details of the issue. I appreciate the information you've provided. I'll review and test the scenario you've described and get back to you soon.
I created a new page and added two paragraphs with the following visibility conditions:
First Paragraph (Visible for Italian Language Browsers):
Italian (Italy)
in the "Browser Languages" input field.Second Paragraph (Hidden for Italian Language Browsers):
Italian (Italy)
in the "Browser Languages" input field.Please note the following:
127.0.0.1
). For accurate geolocation testing, use an online site where your real IP can be detected. VPNs can also be effective for testing country-based conditions on an online site.For more detailed instructions on changing browser languages, you can refer to this guide.
@talksina please let me know if these steps work for you or if you need further assistance.
Same procedure but it did not work. I'm using an online instance. Case study complex example should be htttps:// backup.plusbrothers.net/tag/lgbt I set visibility rules on "template part" blocks and "queryloop" it should show the English header and footer, and posts from "international" category, if browser language is not Italian. But it doesn't work - for me, at least. The goal was that for common/untranslatable words, the template archive changed to English view according to browser lang.
I also tried with a simple paragraph -haven't got the online test yet- and didn't work as well, I thought it was matter of nested blocks. If needed I will use another test site -not this one- so I let you play with a fake editor user and we try to figure it out better. I'd also suggest you some other rulesets but first let's figure out this one! One step at a time!
Let's start by testing with a simple paragraph block before moving on to more complex block structures.
It seems the issue is that the browser language rule isn't working as expected. Let's focus on a unified test scenario using the Chrome browser to ensure we can replicate the results.
First, please check the Chrome language settings by going to Settings > Languages > Preferred languages. Make sure that Italian (Italy) is on the list, no matter the order.
Next, visit the page containing the paragraph block that should show content for Italian users. Does the paragraph appear as expected when Italian is in the preferred languages list?
For the second test, go back to Chrome settings and remove Italian (Italy) from the preferred languages list. Refresh the page. Does the paragraph for Italian disappear as expected?
If these tests don't work as expected, could you please let me know the version of Chrome you're using and the operating system you're on? This will help me reproduce the issue, as the tests were working correctly on my setup using Chrome and Safari on macOS.
Once we confirm the simple test, we can move on to testing with more complex blocks.
I don't mind testing the site using a fake editor user. Let's work through this step by step to figure out the issue.
@showyaseen - meanwhile I have translated as much as I could into Italian from GlotPress - but "readme stable" is identical to "readme developer trunk" so I have just translated "readme development trunk", don't know if it's possible to copy strings from development to stable and overall I don't know if you can approve translations in projects.
Actually, I'm not sure if we can copy strings from development to stable either. I'm also new to plugin translation on WordPress.org, but I'll check if there's a shortcut to move identical strings across versions.
@talksina thank you so much for the effort you’ve put into translating the plugin.
I think if the strings are identical in both the trunk and stable versions, we should be able to copy them once they're published. From what I’ve read, the translation will be automatically published once 90% of the strings are completed, so no need for my approval.
Also, please let me know if you're still facing the issue with browser detection. I’m happy to help test the site through a testing user account if you can replicate the issue there.
So let's concentrate on a massive test now! I could purge all caches in my browsers and then test it from scratch. Then we repeat further steps. This plugin is a lifechanger and I would really like to make it work -then give you some other ideas.
Awesome! sounds great.
To keep things organized and helpful for anyone facing the same issue, let's discuss new ideas and improvements over at:
https://github.com/showyaseen/intelli-builder/discussions/4
We can focus this issue specifically on the browser detection problem.
Sorry I didn't see the reply, I'll come back to you later. I missed notifications but I'm still here. See you on the other issue.
WHAT: trying to enable conditions in blocks, based on browser language. "show block 1 if browser is in Italian, hide block 2 if browser is in Italian". Steps to reproduce:
CASE STUDY I'd like to use this plugin into: 404 page. I could plan that if browser is in Italian it shows the error message in Italian, if it's different from Italian it should speak English. I assumed it could be due to nested blocks (the group containing the header, the content, the footer) which contain other blocks. So the rule set gets confused. But, leaving complex structures alone, I found the same problem into simple blocks - show a message in one or the other language-. Still to test the countries, as there I should use VPN.
Hope it helps for you to understand if it's a bug from your part, or it's something I'm misusing or misunderstanding. Thanks.