Symphony.

Simple question:

Is there a way to add a GET parameter to the parameter pool from within a template rather than through the URL?

Right now, only www.domain.com/?lang=en works for me.

This does not work so far:

<xsl:param name="url-lang">en</xsl:param>

It would be nice to set a default value from within a template here.

It should work. Where are you placing it? It should be straight after <xsl:output />.

should work as alpacaaa says used it plenty of times.

However if you are using some multilingual extension note that it could be looking for the value in your url-parameters (you might have to do some htaccess redirect to add the param)

Do you need the parameter in your template or in a datasource? I asked the same in your very similar question (please don't double post). Using <xsl:param/> makes it only available in your template. If you need it in a datasource filter, use the enumerator syntax {$url-lang:en} to set a default value.

@klaftertief: Sorry for not making this clear earlier. But there is, in fact, no datasource involved here I think.

I am using the Session Monster extension to set a lang parameter. This works great when a user sets it manually through the URL, e.g. www.domain.com/?lang=de. But before he does so, the page is largely empty because I have no parameters to work with. It would be nice to default the language parameter to en somehow.

<xsl:param name="url-lang">en</xsl:param>

... doesn't work at all, even when I put it straight after the <xsl:output /> as alpacaa suggested.

I think the core problem is that the Session Monster XML only appears after the GET parameter has been set through the URL:

<session-monster>
  <item name="lang">en</item>
</session-monster>

Before that, I have no Session Monster XML and thus no parameter to work with :-(

How can I set a default value here?

(The solution is probably easy, but I can't see it because I'm such a Symphony n00b still.)

But you are using session-monster/item somewhere to fetch (Data Source) or filter (XSLT) your data, are you? Why don't you just add a fallback there? Either an enumerator as Jonas pointed out (Data Source) or a simple choose statement using your default language in the otherwise statement (XSLT).

Maybe you could post template so get a better understanding of what you are doing?

Your XSLT fires after all Data Sources and Events have run, so you cannot set a default for a parameter in the XSLT for a Data Source or Event to use.

<xsl:param name="url-lang">en</xsl:param>

What the above does is set $url-lang (available in your XSLT) to be en by default, however if a user goes to a URL such as example.com/?lang=de, then the de will override the default.

As @Nils mentioned, if you need to provide this sort of fallback at a Data Source level, try {$url-lang:en}, which will use the value of $url-lang if it exists, otherwise en.

OK, I think I've got it working.

Actually, there never was any datasource involved in this problem. I am not using any datasources to filter my entries by language. I rather filter for languages at the template level:

This is what I put in my master.xsl stylesheet just after <xsl:output/>:

<xsl:variable name="language">
<xsl:choose>
    <xsl:when test="/data/session-monster/item[@name='lang']">
        <xsl:value-of select="/data/session-monster/item[@name='lang']"/>
    </xsl:when>
    <xsl:otherwise>
        <xsl:text>en</xsl:text>
    </xsl:otherwise>
</xsl:choose>   
</xsl:variable>

So, using the $language variable from above I can now do a lot of this sort of thing in my utilities:

<xsl:value-of select="*[name() = concat('name-', $language)]" />

which returns either the name-de or name-en field value, depending on the language that has been set.

So lucky, it finally works now. I don't even know exactly what did the trick. But I learned something from every comment here. So thanks a lot.

P.S: Any idea on how to prettify my n00b code?

I don't think it can get prettier than this.

But this one is kind of sad:

<xsl:value-of select="*[name() = concat('name-', $language)]" />

How come you're not using multilingual field?

How come you're not using multilingual field?

I looked into that. Maybe next time I will use it.

Even though it looks a bit sad, it actually offers quite a bit of flexibility.