2

I am working on a highly customized shop software, based on a open-source one, written in PHP and usual web techniques (CSS, HTML, JS).

I did a lot of customization in the past months/years and developed specific, individual features which are necessary to be successful at our branch.

The shop and the project files are encoded in ISO-8859-1 (company is located in Germany).

Now we want to spread out and use the shop system in different countries (e.g. Sweden, Poland, Great Britain) and customize it to the domestic needs.

But I am afraid that I could encounter some encoding problems afterwards, so my question is:

Is it wise to change the encoding of the whole project and the environment to UTF-8 before I prepare the shop for "multi-shop" usage or should I leave the source at it is and handle (possible) encoding problems for each country as they approach afterwards?

gnat
  • 20,543
  • 29
  • 115
  • 306
Ello
  • 144
  • 1
  • 4

3 Answers3

11

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.

Jukka K. Korpela
  • 2,407
2

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).

alexis
  • 667
  • 3
  • 7
1

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 :)

Pascalc
  • 166