TYPO3 Core

I forgot to handle the default language. Here is the corrected function call:

$this->pi_getFFvalue($this->cObj->data['pi_flexform'], $field, $sheet, 'l'.($GLOBALS['TSFE']->sys_language_isocode ? $GLOBALS['TSFE']->sys_language_isocode : 'DEF'))

Thanks for your detailed solution.

But could you please explain me more exact what the problem is? In other words, I get german status messages of newloginbox on a system with 'de' as language defined in the template.

What version of of typo3 and newloginbox do you have installed?

A newsgroup-posting helped me to have an idea what you mean. Do you think about a situation of a multilanguage-site with different message-texts in different-languages?

Hi,

yes exactly. If you have a multilanguage website, means you have active page language records in your treeroot, you will get a whole set of flexform fields for each language. That of course makes sense because you want to have different status messages in each language and not just one. From the backend side there is no problem, for each language a set of messages is stored in pi_flexform in the xml structure. But at the moment, the FE doesn't care about that, it just always displays the default language messages. My patch fixes this, that the messages are printed in the current language or at least the value of the right localized flexform field is printed. At the moment there is no fallback option, but this shouldn't be that hard, I could do this, but I think you can handle this yourself ;-)
One thing I'm not sure about ist: Is $GLOBALS['TSFE']->sys_language_isocode available without static_info_tables? If not we must get the isocode from somewhere else, but I think it does not depend on static_info_tables, so we have no problem.

As written in the documentation of the core api static_info_tables is needed to get language-dependent flexform-configuration working. A note in the source-code shows that sys_language_isocode is only set with static_info_tables.

Further the isocode is only set if at least one alternate page language record exists.

I've got some questions, maybe someone may help me to understand this.

I'm not familiar with multilanguage-installations but I've set up a test-environment. Given a one-tree-setting and a page with several alternative language records. The content has to be written multiple times, one per language (of course translated :-) ). So far ok.

But now I have a plugin like newloginbox. AFAIK I need to insert it in each alternate language record, otherwise it wouldn't be display in each language. And now:
- What sense makes it to have a multilanguage-flexform-configuration when I have to configure the plugin several times (one time per language and then only one language)?
- Wouldn't it not be easier to switch off the flexform-multilanguage-feature (no multiple language-configuration shown in the flexform, no problem in reading it)?

With a two-tree-setting it would be the same.

I don't get the sense of this flexform-multilanguage-feature but as it exists there should be one ;-) I didn't find an answer in the documents I've read until now.

Ok now I get your point. If you don't use multilingual flexforms, we can forget the whole discussion, you're right. But then you should switch of localization in your flexform, what maybe is not the best idea. I think the feature is great because it is much more clear in a one tree environment to have only one content element that contains all language overlays. Then you see very fast if there is something missing in a translation. That doesn't mean, that you would lose any flexibility in translation, you always have the posibility the place content elements dedicated to one language, or only some languages, or even set a complete new version of the whole page for each language. All these three "paradigms" can get mixed up with multilingual flexforms. That's quite cool and flexible I think. Another thing that is only possible with directly translated content elements: you can merge images or any other field of the element into the translated version, so you only have to store it once in the default language version and it gets displayed in all translations if there is none.
Well, this are just some thoughts about the localization features of TYPO3, if you want to know more, you definitely should have a look in the localization guide in the core documentation section.

The fact that we need static_info_tables, can be managed with a simple if statement, that shouldn't be a problem. It wouldn't change anything for installations without static_info_tables and add the cool features for all others.

I hope you get my point. We have made many multi-language sites and believe me, this multilanguage flexforms will save your life ;-)

Thanks for your explanations. I think you wouldn't be very happy if I'd switch the multilingual-flexform off ;-)

Now some remaining points:
- Your patch solves the problem for the texts. The configuration-options (forgotten-password link etc) are always taken from default. I personally think that this does make sense but should be documented clearly to avoid confusion. Or is there a need to have language-independent settings? Unfortunately it isn't possible to switch the multilanguage-feature off only for the configuration items. So the flexform-dialog may be confusing. We could also add a TS-option to decide whether the options are taken from default or from a separate language.
- In the case of language-independent configuration items it would certainly make sense to switch the multilanguage-feature off for the userlisting plugin because there are no text to be configured in the flexform.
- I don't know what you mean with your mentioned fallback-option. Maybe I'm able to code it but I don't know what... ;-)
- I don't think that we have to check for static_info_tables because the whole multilanguage-flexform-feature from core-side doesn't work without it. The code has only to be functional even if sys_language_isocode is not set. But a note about this in the documentation would perhaps be useful.

Hi,

- yes this is not very nice. But the idea with the TS option, to decide, if the configuration values should only be taken from the default language, would be pretty cool. The default should be to use language specific values, as this is what the flexforms show.
- Ok this makes sense but should be documented ;-)
- If you have an empty flexform value in one language different from default, just because there was no text entered, we could fallback to the text that maybe entered in the default language. Perhaps this behaviour should also be configurable via TS. Clear what I mean?
- Ok, then we have to check if $GLOBALS['TSFE']->sys_language_isocode is empty, and if it is we have to set it to DEF, but this is already done by my patch. (The inline if)

Yeah, would be cool to have these features and I think it's really not hard to implement...

This works for me.

Thanks

lang is disabled in felogin flexform