Feedback: Suggestions To Cater For Multilingual Sites

[Meddysong]

The IPS team has done, in my opinion, some stellar work to make this new iteration accessible for people who want to or need to have multilingual sites. Translation is a doddle, and I love that descriptions for categories, menu items, on-screen messages, products etc are customisable depending on the language that the user selects. This is all excellent and was the major factor in my decision to hold off on developing our web suite until IPS 4 is released, since my site must be available in two languages.

There is, however, room for improvement. Some of it might even be a deal-breaker for me since it relates to core site infrastructure. Consider the following on my site. It's fabulous, with everything changing (except, frustratingly, for the site name or logo) depending on the user's language choice. Great!

My first menu item is a link to a page. And here's where the problems arise. As an admin setting up the site, I don't have the means to enter language-specific content on my pages in the same way that I can when choosing a category description for the forums, gallery or downloads apps, a product description in Commerce and so on. Whatever I type will be displayed, irrespective of the user's language choice.

In the case of my site, the English user will be happy. Everything on his page is in English, and he clicks the English text 'About Us' and receives an article written in English:

This all falls down for the Esperanto user. Everything displays for him in Esperanto, he clicks the menu item 'Pri Ni' ... and receives an article written in English. Everything else is displaying as it should - for example, the breadcrumbs read Hejmo > Pri Ni instead of Home > About Us. It looks like I've not taken into consideration his needs (a chunk of my users won't be able to read English) or that I've made an error in my page, linking to the wrong one from his perspective.

The story is the same for the custom block that displays on the same page. Whatever text I entered will display on the page irrespective of the user's language choice. There's no way to distinguish it.

So, what is a multilingual site owner to do in this situation? Use both languages in a page and block? Yuck. That would greatly compromise professionalism. Have the content in one language with a message in it saying "If you want to read this in one of our other languages, click here" and links to other pages? That's a solution of sorts but it's not ideal and, again, compromises the professionalism of the site.

So, please, please could the IPS team tackle this and consider adapting things for a future release? I'm not asking for anything radical along the lines of allowing (or even forcing) users to write forum posts in several languages. Clearly that's unworkable. But admins should have the option when setting up the infrastructure of their site to display permanent features such as pages and blocks in the language of their user if they want to. That's not an option at all here and it's a glaring hole in what otherwise is exceptional software and a fabulous multilingual experience.

I'd be particularly interested in reading @mark's thoughts on this, since he strikes me as particularly invested in providing a fully multilingual suite.

Some more thoughts and questions relevant to it:

- If there's a chance that SEO might be damaged by having different content for the same URL, then couldn't there be an option to have a language-specific slug or filename?

- If the admin chooses not to avail himself of the option to enter language-specific content, then as with category descriptions etc, the content for the default language can appear.

- I've asked this question a few times here and on the preview site and never received a response. Why is it that a site can only have one name or logo rather than language-specific ones? The name of my charity changes depending on the language used and I'm currently compelled to choose one or the other. I'd rather have the English name displaying when the language is set to English and the Esperanto one when the user has selected that.

- For those of us who are willing to attempt to work around this by entering code into our pages rather than using the WYSIWYG function, what is the correct syntax for the following?

{{ if $lang=2}}
HTML to display in language 2
{{else}}
HTML to display otherwise

Thank you in advance for your consideration. I accept that it's probably too large a job when you're at RC stage but I'd be very grateful to see such an adjustment appear on the Feature Plan at some point.

 

[Marcher Technologies]

 

- For those of us who are willing to attempt to work around this by entering code into our pages rather than using the WYSIWYG function, what is the correct syntax for the following?

{{ if $lang=2}}
HTML to display in language 2
{{else}}
HTML to display otherwise
{{endif}}

{{if member.language()->locale === 'en_US' }}
HTML to display for english
{{else}}
HTML to display for second language
{{endif}}

This can be extended for further languages of course. Would have used esperanto in the example but I don't know the locale code off the top of my head for that. Checking locale seems more flexible than id, but you have access to the entire language row if needed regardless via member.language() in templates, and \IPS\Member::loggedIn()->language() from within php.

[Meddysong]

Thanks, Marcher. I'm not surprised you don't have the Esperanto locale stored to memory - I can't find a host which actually has it already! It's EO_xx.

I tried adding that code as source but hit upon a problem.

Here it goes:

Oh, it's displaying as text:

Ah ... it's  because the editor is adding paragraph tasks around my double curly braces.

Is it supposed to do that if I'm adding code to the source? I would've thought not but wouldn't want to raise it as a bug if this is expected behaviour and just me not knowing what I'm doing.

[BomAleold]

Template conditional/logic is available/parsed on block content?

[Meddysong]

I've tried experimenting with a new page manually built. The code I'm using is built on what Marcher set out above using both the member.language() and \IPS\Member::loggedIn()->language() forms for combinations of en_US, en_US.UTF-8, eo_XX and eo_XX.UTF-8.

It never generates an error (yay!) but consistently determines that the {{else}} condition applies, even when it shouldn't. In the following screenshot I'm set to English (USA) and am asking for the text "<p><em>HTML to display for English</em></p>" to be the result.

Any suggestions?

(The full code I used to generate that is in the following spoiler tags.)

<p>The text below uses <strong>\IPS\Member::loggedIn()->language()->locale === 'en_US'</strong></p>
{{if \IPS\Member::loggedIn()->language()->locale === 'en_US' }}
<p><em>HTML to display for English</em></p>
{{else}}
<p><em>HTML to display for second language</em></p>
{{endif}}
<p>That's the wrong result, since I'm currently set to en_US.</p><!--Comments added after seeing result-->
<hr />
<p>Let's try rescripting it by using <strong>member.language()>->locale === 'en_US'</strong></p>
{{if member.language()->locale === 'en_US' }}
<p><em>HTML to display for English</em></p>
{{else}}
<p><em>HTML to display for second language</em></p>
{{endif}}
<p>Um, no. That should be the first language.</p><!--Comments added after seeing result-->
<hr />
<p>Let's try indicating UTF-8. First, with <strong>\IPS\Member::loggedIn()->language()->locale === 'en_US.UTF-8'</strong></p>
{{if \IPS\Member::loggedIn()->language()->locale === 'en_US.UTF-8' }}
<p><em>HTML to display for English</em></p>
{{else}}
<p><em>HTML to display for second language</em></p>
{{endif}}
<p>Still wrong.</p><!--Comments added after seeing result-->
<hr />
<p>And now for <strong>member.language()->locale === 'en_US.UTF-8'</strong></p>
{{if member.language()->locale === 'en_US.UTF-8' }}
<p><em>HTML to display for English</em></p>
{{else}}
<p><em>HTML to display for second language</em></p>
{{endif}}
<p>Nope, still no luck.</p><!--Comments added after seeing result-->

 

 

 

[Nathan Explosion]

Test against this instead maybe?

\IPS\Member::loggedIn()->language()->bcp47()

Found that in one of the templates.

Throw this at the top of your page to check what is being output for the language:

{expression="\IPS\Member::loggedIn()->language()->bcp47()"}

 

[Marcher Technologies]

I've tried experimenting with a new page manually built. The code I'm using is built on what Marcher set out above using both the member.language() and \IPS\Member::loggedIn()->language() forms for combinations of en_US, en_US.UTF-8, eo_XX and eo_XX.UTF-8.

It never generates an error (yay!) but consistently determines that the {{else}} condition applies, even when it shouldn't. In the following screenshot I'm set to English (USA) and am asking for the text "<p><em>HTML to display for English</em></p>" to be the result.

Any suggestions?

(The full code I used to generate that is in the following spoiler tags.)

Hidden Content

 

 

​I went back and dumped the contents of \IPS\Member::loggedIn()->language(), and realized that is not at all what I thought it was upon reading \IPS\Lang, my apologies. That's actually an array of locale information, things like thousands/decimal separator.

same code, but use 'short' instead of 'locale':

{{if member.language()->short === 'en_US' }}
HTML to display for english
{{else}}
HTML to display for second language
{{endif}}

 

[Meddysong]

 

{expression="\IPS\Member::loggedIn()->language()->bcp47()"}

​It was indeed the correct en_US. Thank you for your help

 

same code, but use 'short' instead of 'locale':

{{if member.language()->short === 'en_US' }}
HTML to display for english
{{else}}
HTML to display for second language
{{endif}}

You're a gentleman, Marcher. That worked perfectly and it's what I'll be using from now on. Thank you for helping me