Problems with language-alternate fields

[apeisa]

I cannot get language-alternate fields working. I have tried to use title_se, body_se and summary_se. I have one additional language ("se") added, which contains zero translations. I need to have all my news in two languages and wanted to use language-alternate fields for this (like to have that separate languages in own tab). I have had zero luck to get pw recognize my alternate fields.

I watched the video (http://processwire.com/api/multi-language-support/multi-language-fields/) several times, and I cannot figure out what I am missing. I have added those fields to template, added some content etc... but no luck. I don't get the small label above the field, nor does the content change with language.

I have tried this on two different sites.

[ryan]

Can you double check that you have the LanguageSupportFields module installed? Also, I did fix a related issue a couple weeks ago, just in case you are running on an older version.

Just tested here with a simple textarea field and is working. I created "summary" and "summary_se". It's identifying "summary_se" with the label "Swedish" above it. Let me know if you still can't get it working after double checking the items above. I'll need to know which fieldtype you are using so that I can duplicate a test here as closely as possible.

[apeisa]

Nope, I still cannot get it working. Not sure what I am doing wrong. Just to make sure it isn't something very obvious that I do wrong, I have attached several screenshots here:

Modules

Languages

Fields

Template

Edit page

If there isn't anything wrong with my settings, I am happy to give you superuser access to this site if you want to check it out.

[ryan]

Thanks for the screenshots. I think it looks good, though I am confused about what the 'default' language is? The field 'body_se' that has the English label 'Body' while the 'body' (default) field that has the label 'Sisalto'. Shouldn't it be body_se that has the label 'Sisalto' and body that has the label 'Body'? Not that it likely matters here, but just wanted to make sure I understood.

The screenshots are helpful and gave me ideas on more to try to duplicate locally (TinyMCE in particular). If I can't duplicate locally, it would be good for me to take a closer look at your installation, so I'll let you know what I find after testing locally.

[apeisa]

Default is kind of mixed Finnish/English, body for Swedish is just for test. I have tried all kinds of titles

I have tried to make other fields also (title field, text, textarea without tinyMCE etc). I first created them just duplicating fields (Advanced -> duplicate) and then renamed the summary_1 to summary_se. Then I tried without duplicating, just creating new fields (thought that maybe duplicating is causing the issues - but nope).

Also might be worth mentioning, that when I started, I didn't had the LanguageFields installed. But I installed it and created those fields again, but still no luck to get it working.

[ryan]

I tried creating a new body_se field and made it TinyMCE, and all still worked here (I also created it by cloning the existing 'body' field). So I think I need to take a closer look at your installation. Please email or skype over login info at your convenience.

[Michael Murphy]

I have also been having quite a few issues with the multi-language fields in the most recent versions of PW. I thought they might be related to the problems Apeisa is having, but just as I had finished writing down my issues, thinking it might be a bug, it's probably related to using an old version of PHP (version 5.2.17 and PW only supports > 5.2.4) - On 5.2.17 the language-alternate fields don't work (however the Multi-language fields work fine).

So maybe check your PHP version is > 5.2.4?

Well, here are the issues that I had :

My first issues are probably more related to installing and testing the Repeater module - my conclusions are : don’t use the Repeater field with multi-language fields that are AutoJoined or if you have changed PageTitle field type to a TextLanguage.

I could not sort the tree or save pages - lots of errors about columns in field list : “Unknown column 'data1008' in 'field list’” - eventually i managed to completely break my install after trying to add an additional language (front end and backend were not accessible and showing an Error Exception: Unknown column 'field_title.data1031' in 'field list’)

So I tried again, and on my second install (2.2.0.1), I did not install the Repeater module. I also decided to use the “language alternative field” approach for Page titles to be safe. This is my setup :

title (default PW field - PageTitle)

title_de (for German titles - Text)

body (for English and German body text - TextareaLanguage)

On local host MAMP install it all works as expected (navigation titles and content change when switching languages)

But when I transfer it to the server the language alternative fields stop working (in the navigation titles) BUT strangely the TextareaLanguage body fields do switch properly. So the content changes but the navigations titles don’t.

MAMP is using PHP Version 5.3.6

Server is using PHP Version 5.2.17

And this was the point where I realised PW only supports PHP version 5.2.4 and above, so I can't really compain.

Sadly, it's one of them horribly cheap shared hosting setups that clients seem to love, so no hope that they'll be upgrading php versions anytime soon. Why do clients spend so much designing and building a website, and then peanuts on hosting?

[apeisa]

Michael, I am sure that your post will be helpful. It feels like environment issue of some kind, since we are running php 5.3+

Ps: 5.2.17 > 5.2.4

[Michael Murphy]

whoops, how embarrassing - been reading version numbers wrong! PHP 5.2.17 > 5.2.4 so maybe it is a bug.

[apeisa]

Michael: I have made same mistake, actually many times

I guess it is some php setting that is causing this... interesting to see. I just send my site profile for Ryan to examine. If it runs fine on his environment, then this is definitely an environment issue.

[ryan]

Michael, thanks for the description. It should be okay to use multi-language fields in a repeater (at least I have before), but it's been awhile. I will locate whatever the issue is and fix. There is an instance there where both repeater and LanguageSupport hook into the same thing, so could be that I need to add a load priority to that (that's my initial guess anyway).

Antti has sent me a site profile to test so I hope to be able to reproduce the non-working language alternate fields and have a fix for that shortly.

[seddass]

I too get a similar error as Michael: Unknown column 'data1012' in 'field list' as 1012 is page id of my default language.

I see it after I create & save a new page (with title, name, template fields), before the state when the page is editable with all input fields, before to be published. The error occurs only in pages using template with Repeater field. When i refresh the page after the error..all is fine, the title and all other fields were saved before the error.

Hope this helps.

[ryan]

Seddass, are you running the latest PW? Some fixes were put in a couple weeks ago, and those fixes may resolve the issue you are running into. Let me know if you are already running the latest or if they don't resolve it, and I'll get back to work on it.

[seddass]

I am using the latest PW commit. I will try to send a link to exported site profile by email, hoping it will make things easier.

Thanks!

[ryan]

Thanks for sending me the profile Seddas--I will take a look and fix. I did actually just commit some updates earlier today that may possibly resolve this particular issue, but since I was focused on fixing another issue, I think there's only a 50% chance of that. So I will be testing this soon.

[seddass]

Thanks, I think I am in the other 50%

I have tried to find a quick fix.. The default language doesn't always return true when using $language->isDefault in LanguageSupportFields.module (around 322 row). I have replaced the row with if($language->isDefault || $language->id == 1012) and this allowed me to continue the work but it is not a good solution. I will attach the exception details, hoping they will help. Nothing is urgent. Thanks again.

Hmm, probably I should use ... || $language->name == 'default') instead.

[joe_g]

Hello,

I ran into this issue: When using markdown as text filter the default language isn't fetched (if the alternate textarea isn't filled out)

Disable markdown and it works fine

Ion PW 2.2.3

An upgrade might help in my case, perhaps?

edit: Problem remains in 2.3 – I suppose a empty textfield with markdown isnt empty, maybe ther is a <p></p> in there or something...

Edited April 11, 2013 by joe_g

[ryan]

Problem remains in 2.3 – I suppose a empty textfield with markdown isnt empty, maybe ther is a <p></p> in there or something...

I'm guessing that's the case (a blank <p></p> added by Markdown). Can you try replacing your /wire/modules/LanguageSupport/LanguageSupportFields.module with the attached? I think this may fix it.

LanguageSupportFields.module

[joe_g]

Yep, works perfect. 

Thanks .. !   

[kixe]

Hello Community,

after a colleague recommended PW to me I am playing around with it since two weeks. Now I can imagine the big potential PW has and I am really happy about it because it fits perfectly to what I have been searching for since a long time.
Now I would like to do a small project with it to get motivation of something real visible.

The project should be in three different languages. I implemented the modules and it seems to work fine. But the problem is, that the frontend is always shown in the default language. I put some different users to the platform and set different languages to them. In the backend the language switches to the users language but not in the frontend.   Maybe I forgot something in the template. I don't know. Please help to save time.
Thanks in advance.

kixe

[Soma]

hi kixe

Good to hear you stay with PW and making progress.

What approach are you using for multilanguage? Separate tree or same page with language fields?

Well as you might already found out, language on front-end is default as user language has no effect apart from the backend. The url is the starting point for your php script to define what language is accessed and you then set the $user->language according. So if you have language segment domain.com/en/ you get the first segment to read what language the user accesses. When using the new language page names module this is done automatic. So the only thing you need to to is a language switch so the user can change language.

I've seen you posted also in the language page names module thread... the last example of Ryan is currently the most easy way (requires latest dev version).

[kixe]

I am using on localhost same page with three language fields. Even tried out language page name module and (which is important here) "frontend user login". That's why I was a little bit astonished, the language didn't switch after login via frontend.

I am thinking about to use PW-Users for "Comments" or small Forum. In this cases it would be nice to have the language also switched in the frontend, after setting a language to the user!

I have already implemented a language switcher on the page, which is working fine.
Which Api should be used to get the /en/ or /de/ from the url-path to use it in links on the template. Something like $user->language->ISO-Code ('en' for english for example)

If I use $user->language->name the language name in the current language appears, like set in the backend (for example "francais", for french in french)
Thanks for help.
kixe

[ryan]

Which Api should be used to get the /en/ or /de/ from the url-path to use it in links on the template. Something like $user->language->ISO-Code ('en' for english for example)

The value returned by $page->url() will reflect the URL of that page in whatever the user's language is. Because the LanguageSupportPageNames module sets the language based on URL, it doesn't matter what your user's language setting is. It only matters what URL they are at. But you can get the page's URL in any language by passing the language to the localUrl() function:

$url = $page->localUrl($language); 

Also make sure you are running the 2.3.0 dev branch because this is a module in development, and the version in the dev branch is much newer. You may want to use LanguageSupportPageNames for production use until 2.3.1.