Well, it does not work as you describe. We have separate language template sets (DE, EN, FR) and configured per department (DE, EN, FR departments).
Our page: https://support.pambill.com/?lang=en
As you see, we add the lang variable. But still, when a new ticket is created on the https://support.pambill.com/?lang=en page, the ticket confirmation email sent is always in the default language set (German in our case) and not in English.
If it's using the default template set then it sounds like you did not configure the Department to use the correct template set. Make sure when you are creating the Ticket it is being routed to the correct Department. You can configure the Department via Help Topic as well.
Cheers.
The routing is the issue, how can we get that done?
Can you please explain how? We have been pulling our hair out on this issue. We tried filter, but were not successful at all.
Thanks for the support.
Yes, it's quite simple. For Help Topics, simply set the Department. Then when a Ticket is created in that Help Topic it gets routed to the configured Department.
For Filters you set whatever criteria you want and set the action to Set Department.
Cheers.
Yes, that part is clear. Where does the language come in? As new tickets always go to the default language set in OST. If you have additional languages, these are ignored with new created tickets.
We are already use different templates. Each template is used for a other language. So we have one template for german, one for english and one for french.
The problem is still that the correct template is not automatically selected by the system on base which language the end user have selected. So teh FIRST responder mail is not in the end users selected langauge.
So
and/or
You can’t. The language they select on the front end does not get passed through to the departments nor email templates. We hope to change this in v2.0.
Cheers.
Ok, we understand that it is currently not possible to support customer selected languages within the OST system automatically, and you hopefully change this in the next minor version of OST.
Maybe it is possible to add a filter which works on POST parameters as a workaround?
This is generally a good feature for the future as it allows implementing OST in several custom systems.
This will be after v2.0 release which is the full codebase rewrite; this is not slated for release for a while.
Cheers.
