Possible to switch language on DB record?

[socceronly]

Is there any way articles, translated, can switch with the selected language?

If we have the English version of an event in News & Events... and they switch to Spanish... how do you change the record output?

JM

 

[socceronly]

I can see in the db how to change the title ect... but is there any way to have a French and English version of a given article?

[opentype]

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. 

[socceronly]

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.

 

[socceronly]

......

Edited February 24, 2021 by socceronly

[Meddysong]

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.