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?

Improve this question
3
  • Afterwards you may have already lost data when people enter text that your database won't store properly, plus you will maybe run into issues with the site crashing in such cases. If you are lucky strings are stored correctly and only displayed weird. But I would recommend testing with all characters in all areas that can be expected to handle text input. Commented Jan 20, 2014 at 10:57
  • 1
    so, do you recommend that i should completly convert the whole project and the database coallation to utf8, build a clean utf8 state and then start to develop the multishop features? Commented Jan 20, 2014 at 11:52
  • UTF-8 has an odd effect of making people think it's 8-bit, when what their looking for is 16-bit Unicode. UTF-8 is a self-expanding format that can store from 8 bits to 32 bits for a single character. That allows it to store a huge range of characters for all languages. It's also stores characters in the least amount of space. (i.e. 7 bits for most ASCII letters). So short answer UTF-8 can store ISO-8859-1 without loosing anything, plus a lot of other encodings. Commented Jan 20, 2014 at 14:30

3 Answers 3

Reset to default
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.

Improve this answer
1
  • thank you, that's what i thought at first but i wanted a second opinion. So, now i'll backup everything and start converting ;) yay! Commented Jan 20, 2014 at 12:32
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).

Improve this answer
11
  • -1: there's no "appropriate 8-bit encoding" for any minimally international application. Commented Jan 20, 2014 at 14:32
  • You'd seriously recommend converting an 8-bit application to Unicode just because, say, it needs to display Polish (and maybe English, which comes for free)? I beg to differ: You'd be wasting your time. Kindly clarify why the ISO version is not "appropriate". Commented Jan 20, 2014 at 14:36
  • 1
    it's not appropriate because it already had to work with German and Swedish. it might be a lot of work (depending on how outdated (i.e. non-unicode-capable) parts of the system are), but hacking out a multi-iso-page encoding switcher is only marginally simpler and won't be a long-term solution. even worse, if you manage to get that monster working, when (not if, when) you finally migrate to unicode, you'll have a lot more problems than originally. Commented Jan 20, 2014 at 14:52
  • It needs to be customizable to different countries, not to support them on one site. A multilingual site is a different animal, as I clearly say in my answer (which you should read more carefully). Commented Jan 20, 2014 at 15:01
  • well, i cloned the source base and the development environment/dbase and already converted the database to utf8. i am now converting the source and templates files to utf8, which seems to work well till now. after that i will look through the code and run some tests to see if anything went ok or manageable. if it wont work i just wasted a few hours, so nothing to fear ;) Commented Jan 20, 2014 at 15:09
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 :)

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.