WIP: One issue with polylang (in builder)

Bugs
1

Browser: Chrome 128.0.6613.138
OS: Windows

Hi bricks team,

I am building a website with both English and Persian languages. When I create a single post in Persian language, in the Builder, comments and reading time elements (day, week and…). This is while the builder is RTL.

I should also add that in the bricks settings, the Builder language is set to English. It seems reasonable if the translation of the elements is persian. Because I am editing a single post in Persian language.

thanks

2

Hi @HOSEIN,

It sounds like you’re saying the page you’re working on is RTL (Persian), so it should appear as RTL in the canvas while you’re editing in the Builder. Just to clarify, setting the Builder language to English should only affect the Builder’s interface (panels, labels, etc.), not the content you’re working on. So, if your page is in Persian, the canvas should still display it as RTL, regardless of the Builder’s language setting.

If I’ve misunderstood, or if the issue is something else, could you please share some screenshots or a bit more detail? Thanks!

3

Hi @charaf,

The content of the page is RTL. But the translation is not in Persian. But there is no problem in the front end and everything is fine.

Screenshot
Screenshot1148Ă—767 34.8 KB

Also in the reading time element :

Screenshot_1
Screenshot_11128Ă—432 47 KB

4

Hi again,

Let me correct one thing…

I just checked and found that this bug has nothing to do with polylang. Site Language is Persian. When I edit the single post, the content of the builder is RTL, but the comments and reading time elements are in English according to the above screenshot.

I corrected the topic title

1 Like
5

Hi @HOSEIN,

Thank you for your patience.

I was able to replicate the issue with the “Comments” element and have added it to our internal bug tracker. This seems to be a general issue with multilingual sites and is not related to Polylang. However, I couldn’t replicate the problem using the “Reading time” element, which appears to work as expected on my end.

1 Like
6

Hi again @charaf, Thank you for not forgetting this report🙏

You are right, reading time seems to work fine in the latest version. But in dynamic data, {post_date:human_time_diff} also has this problem. Do you approve of this?

screenshot

1 Like
7

Yup, I can replicate that too :slight_smile: added to the ticket :white_check_mark:

1 Like