Jump to content

Community

Possible to switch language on DB record?


socceronly
 Share

Recommended Posts

The whole IPS system isn’t built for translatable content at this time. 

In theory, you could create custom editor fields to hold the other languages and then change all the Pages database templates to call the right field based on user’s language settings. It’s doable. I’ve done it for client once, but it’s really not a clean solution. You would also have to think about indexing through search engines and things like that. 

If I remember correctly @Meddysong uses this as well and has explored the ways to deal with this. So he might know more. 

Link to comment
Share on other sites

Thanks, we'll find a solution. 

Possibly just forgo the db and use blocks for now.

🙂

OOOh.

Is there a reasonable way to have the menu change on a language change? 

Like a toggle between two different News & Events databases that point to different pages.  One in English and one in French.

That would ostensibly be the same thing and a lot easier than rejigging the system to swap the content.  

I hate merging posts.

 

Link to comment
Share on other sites

4 hours ago, opentype said:

If I remember correctly @Meddysong uses this as well and has explored the ways to deal with this. So he might know more. 

Wow, what a spectacularly good memory!

Yes, I tweak content to so that English text is shown in Pages if English is selected but Esperanto when the user changes language.

There are a couple of different techniques. The one I've used most often is to add some code within the article itself:

<h1 class="longer-text"><span>{{if member.language()->id === 1 }}We’re a charity which has the aim of providing education to people in and about Esperanto.{{else}}Ni estas bonfara asocio, kiu celas eduki homojn en Britio, kiuj volas lerni Esperanton.{{endif}}</span></h1>

English is the language with the id 1, so if the member is using English, then the text in the if-clause shows; otherwise, they see the else-clause.

Another approach is to use blocks, giving them names with a language marker differentiating them, so block_en and block_eo. That would come in handy for longer pieces of code because you're not forever writing out if-conditions. I can't remember where I've used this but looking through some old blocks, it seems that I have a particular block which creates a variable with the value "en" or "eo" depending on what the current language is:

{{\IPS\Settings::i()->lingvo = substr(\IPS\Member::loggedIn()->language()->short, 0, 2);}}

(The variable gets its value from the first two letters of my language packs: en_GB and eo_XX.)

I presume I must've used that block on a page and then at relevant points added a line within an article to call the relevant block:

{block="block_{$lingvo}"}

or something like that.

My site is such a mess, though, that I can't track down anywhere using that approach. It might be that it didn't work, I suppose. My first approach definitely does work, and a similar one to this second one does with Pages databases too:

<p>{{if substr(\IPS\Member::loggedIn()->language()->short, 0, 2)=="eo"}}{$record->customFieldDisplayByKey('people_bio_eo', 'display')|raw}{{else}}{$record->_content|raw}{{endif}}</p>

 This was all very experimental a few years ago, though. Now I just stick to the first approach, even though it means dozens of if-clauses. It's a headache at the time but if you're not going to change the content, then it's survivable.

Link to comment
Share on other sites

 Share

×
×
  • Create New...

Important Information

We use technologies, such as cookies, to customise content and advertising, to provide social media features and to analyse traffic to the site. We also share information about your use of our site with our trusted social media, advertising and analytics partners. See more about cookies and our Privacy Policy