You will encounter encoding problems. You can handle Swedish and English with ISO-8859-1, but not Polish. You could use ISO-8859-2 for Polish, but then you would need to use other encodings when moving to languages that are not covered with ISO-8859-1 or ISO-8859-2.

So it is best to internationalize the software, using UTF-8, which covers all languages, and using UTF-8 throughout.

Converting from a single-byte to a multi-byte encoding (which utf-8 is) is far from trivial. It will require you to touch almost every string in your application (or at least examine it), and every function that manipulates it. Bear in mind that PHP 6 and Perl 6 have been held up for years because of this. I would not recommend committing to the switch unless (a) you are confident that you can carry it out, and (b) you consider carefully whether it’s worth the effort.

I’d recommend doing some work on a trial basis to see how smoothly it goes, before you commit fully.

From what you say it is clear that you will need more than ISO-8859-1, so you do need internationalization. But if your expected customer base can be handled with the ISO-8859 family of encodings, you have a choice:

1. Implement internationalization in terms of setting the appropriate 8-bit encoding (and including it in webpage encodings, SQL tables, etc.)

2. Implement internationalization by switching to utf-8.

The first option should be a lot easier than the second, so consider carefully what utf-8 gains you.

Notes

1. Since this is based on an open source application I would consider doing this as an improvement to the open-source base for your system. This allows you to get the community’s help, since multilingual support is of benefit to everyone. And if you carry out such a fundamental conversion in your proprietary customized version, you will definitely have trouble merging the next open source version into your codebase.

2. One real benefit of Unicode is that it easily allows a multi-lingual (multi-encoding) site. If the current system is limited to a fixed encoding, tracking multiple encodings in a single system would be an even bigger mess to implement than switching to Unicode. It doesn’t sound like you’ll need this in the foreseeable future, though.

3. Full disclosure: I speak from experience, an attempted conversion that turned out to be very, very difficult. (So this could go either way: maybe I’m just overcautious and you’ll be fine).

A few things to take into account:

On PHP side:

• PHP 5.4 defaulted settings for functions such as
  htmlentities/htmlspecialchars to UTF8 in version 5.4.
• The default charset will be enforced in php.ini to UTF8 in PHP 5.6
  next quarter.
• The PSR recommandations says that UTF8 is the mandatory encoding for files in PHP
• All frameworks and modern libraries are UTF8

On the front end side:

• browser makers and W3C/WHATWG advise using UTF8 for front end files
  (css, js, html)

On Operating systems side:

• all modern OSes in use use UTF8 as defaut encoding, I think the last
  OS I used that isn’t set up by default to UTF8 is Windows XP (it does
  support UTF8, it’s just not necessarily the default)
• you are most likely using a LAMP stack, Linux distros are UTF8 by
  default

So basically, you are swimming in an UTF8 ecosystem and all the modern frameworks, libraries and other external PHP code default to UTF8. PHP itself progressively enforces UTF8 as the default setting, which means that if you keep your code in Latin1, you will likely meet bugs in the long run.

Switching to UTF8 is not really hard, unless you have to deal with data sources for which you can’t control the encoding, my advice is to switch, it will solve a lot of headaches for you in the long run 🙂