HelpSpot Help Desk Software | HelpSpot Blog | HelpSpot Support

Suggestion for multilinguality


#1

Sorry to bomb you with so many comments today. I wanted to start a new thread because this is a different issue also related with categories but with a different approach.

The categories that we have created target different types of users:

  • Tools: Language is normally English.
  • Internal Helpdesk: Language is normally Catalan.
  • Client Helpdesk 1: Language is normally Catalan/Spanish.
  • Client Helpdesk 2: Language is normally French.

Eventually, it would be nice that the Request/Forums and emails for each category (only customer-facing texts; admin interface is OK in English) are in the default language of the category (and also as a much less important thing, that the language could be overriden at the request level).

Actually, it would even be interesting for us that each category had the option to have its own portal (in some cases a category may require a different customer-facing approach even with language; in some cases forums are required, in others not.

For us it is important to have a common database because the people behind these different categories is the same.

Would it be a possibility to install another instance in another URL but pointing to the same database to do this partially (for example, to tweak the language php code/config code/templates to achieve different personalities with the same database)? Are there any caveats to take into consideration in this scenarion of one database shared by two instances of the HelpSpot PHP code?


#2

No problem, it’s great to have these discussions in the forums that’s what they’re here for.

This is an interesting idea. I think you could do some of what you want, but not all of it. You could have 2 installations pointing to the same database. That would allow you to customize the portal in a different language. You could do it from the language file or even customize the portal templates themselves using this info:
http://www.userscape.com/helpdesk/index.php?pg=kb.page&id=9

However, you wouldn’t be able to customize the emails by language because the emails are stored in the database so changing them in one installation would change them in both. One solution though may be to have no text in the emails other than the notes from the request. This way the email goes out just in the language you write it in. You could have a predefined response with formatting in different languages for the emails. This wouldn’t work for autoresponses from mailboxes though if you plan on using those.

Of course as you referenced you could have multiple HelpSpot installations, that’s allowed under the license, but it makes reporting very difficult and of course requires different logins in different locations.

This thread is very useful though so keep them coming. We’re noting all these ideas and will be incorporating these types of things into future releases to make multilingual help desks easier to manage in HelpSpot in the future.


#3

Thanks for the response and for being so receptive for comments. We are in learning mode with Helpspot and I do recognize that some of our needs will sound awkward.

Although this thread is originally about multilinguality, let me focus it on a specific scenario that we are thinking about (not multilingual but would it exersise the single database with several HelpSpot instances model.

We currently have Helpspot in a server system within our intranet, pointing to a SQL database.

We were thinking about deploying a second instance in our Website server, which is located in a DMZ. We were thinking about opening the ports in the website server for SQL Server communication towards the SQL Server in our intranet so that the instance in the website server acts basically as a portal.

One important remark is that the URL most likely won’t be the same in both instances and we would like that the links to issue histories in customer-facing mails point to the right external interface for the portal. We anticipate a very low workload on the portal, but we would like to offer that feature of a user being able to check on a request and even eventually activate the forum abilities.

We expect that the bulk of the transaction workload will be in the internal server in the intranet (the one that currently is up).

The questions are:

  • In this scenario with two different base URLs pointing ot the same database do you anticipate any issue?

  • Are there any caveats to take into account for the installation of the additional instance of Helpspot? The installation steps that I was thinking about were: a) copy the distribuiton files for 1.03 plus the e-mail fixes and tweaks to the language php file. b) Set the right URL and database values in config.php at the server, but do not run installer.php as everything should be already all set.


#4

I think this should mostly work. It’s never been tested in exactly this way, but since the database handles everything I don’t see any issues there. The steps you have should be fine. In fact you could simply copy the entire directory because HelpSpot writes no files to disk so the directories for multiple installations should be identical. The only difference will be in config.php you’ll need to adjust the cHOST variable because the URL’s will be different for the 2 installations.

This is where you will have a little trouble. In the email templates and mailbox auto responders there are placeholders which are interpreted to point back to the portal for things like checking your status and so on. The change you’ll need to make is to remove the placeholders and instead put the full URL’s in to the request check page and so on. The reason is that when your intranet installation receives an email or sends one it will replace those URL placeholders with references to the intranet URL portal rather than the public portal.

For example in the auto reply you’d need to replace ##REQUESTCHECKURL## with:
http://pathtohelpspot.com/index.php?pg=request.check&id=##ACCESSKEY##

As you say there’s no need to run installation.php. Also in future releases you would only need to run the installation.php script once, since it’s only function during an update is to update the database.

Otherwise I think things should work. Give it a shot and let me know how you make out.