Hello,

We believe we have found a bug in xLanguage in relation to the display of language tags inside textarea elements in forms. There does not seem to be a support or bug reporting forum on the xoopsforge.com website, so we are posting this here.

Background:

xLanguage provides excellent multi-language capabilities within a XOOPS site by buffering the entire page output and then prior to sending the page to the web browser, it performs a series of regular expression matches on the page that converts all text in language tags to the current language.

ie: "[en]English text[/en][fr]French text[/fr]" becomes "English text" in the final page that the user sees, when English is the current language.

If this search and replace functionality happened everywhere on all pages, there would be a problem, because webmasters need to be able to see the full text with language tags when they are editing content in the site. It would not be a good thing if you entered a news story in English and French and then when you went back to edit it, the search and replace functionality only displayed the English text to you.

Therefore, xLanguage does some clever escaping of the language tags when they appear inside a form element. Essentially, it ignores [en][/en][fr][/fr] when they occur inside form elements.

That way, the search and replace logic does not take place inside form elements, and that allows webmasters to edit the full text of content in their website in all languages.

Problem:

The regular expression used to escape language tags inside textareas does not work when the contents of the textarea box include HTML tags. More specifically, the pressence of < and > characters trips up the regular expression matching and results in the language tags being parsed inside the textarea.

This is a problem for webmasters since they can no longer edit the content in all languages in their website; only the current language appears in affected textarea boxes.

As long as the contents of the textarea box does not include < or > characters, then everything works correctly. However several different textarea boxes in XOOPS are normally containers of HTML code, including HTML blocks.

Fix:

It appears that changing the following line in include/functions.php in the xLanguage module will fix the problem.

Change this:
$patterns[] = '/(\]*>[^\<]*\<\/textarea>)/isU';

To this:
$patterns[] = '/(\]*>.*\<\/textarea>)/isU';

The change simply replaces the "[^\>]*" to ".*" which should have the effect of matching any text inside the textarea, whereas the original expression matched anything except a > character, as far as I can tell (regular expressions are not my strong suit).

xLanguage uses this regular expression to identify textarea boxes, and it then flags them in such a way that the language tags in them are not parsed, thus displaying all text to the webmaster. Since this regular expression was tripping up on HTML tags, it was not recognizing the textarea, and the text inside was being parsed just like any other.

Issues:

We do not know if there was a particular reason that "[^/>]*" was used instead of the simpler ".*" so perhaps this change introduces some other issue. In that case, some more sophistocated matching expression will be required that still takes HTML code into account.

Thanks for reading, I hope this helps and can make it into a future release of the module.

--Julian

This issue could perhaps be put in a separate thread, but it's related to the other issue above in a way. For completeness, we'll post it as a reply here.

There appears to be a problem when text with language tags, that is to be parsed by xLanguage, appears in a page immediately before a
tag. What happens is that the
tag is removed, if the current language is not the last language in the language-tagged text.

ie: imagine your output webpage, prior to xLanguage parsing everything, contains this text (pardon my French!):



If English is the current language, then the line break in the middle of that paragraph would be removed by xLanguage.

If French is the current language, then the line break would remain.

I can't think of a good reason for this to be the case, but perhaps it was introduced to handle some kind of special situation.

Unfortunately, this behaviour breaks the page layout, sometimes in significant ways. We uncovered the problem when we noticed that when a form element has a caption and a description, rendered by the xoopsForm class, there is supposed to be a space between the caption and the description. But because of this behaviour of xLanguage, if the caption has language tags in it, then the space between the caption and description is only present when the currently active langauge is the last language present in the text.

It seems most sensible that the parsing of language tags should result in replacements of only the language text, and not any elements of the page layout, including simple line breaks. Since there are bad side effects of this behaviour on the appearance of pages, we recommend it be changed.

I would be interested to know the rationale for including this behaviour though, perhaps there is some important issue we're overlooking.

To change the current behaviour so that line breaks are not affected by language tag parsing, change the following in the include/functions.php file in the xLanguage module:

On line 193 (in xLanguage 3.0), change this:
(\]\|\])

To this:
\]

Thanks for reading, I look forward to any response.

--Julian

Thanks.

Added to xlanguage bug tracker.
http://dev.xoops.org/modules/xfmod/tracker/?group_id=1135&atid=701

Thanks, very useful correction

(it seems that it not has been corrected in the last release, xLanguage 3.02)