Internationalization is a seemingly simple, yet very complex feature to implement. If you have a tightly coupled architecture, it will be a royal pain to implement this beast.
A lot of internationalization will be handled on the back-end with your database - assuming that you are focusing on a data driven website. If this is the case, it will likely just lead to a few changes to your table structure and the queries performed on that data.
For example, let's say your website has to display a welcome message. You'd push this to the back-end into a table that can resemble something like so:
MessageTable
:id
:message
:lang_code
Where lang_code is calculated from your browser. So you could have records that appear like this:
MessageTable
1 Hello There en-us
2 Hola es-sp
3 مرحبا ar-sa
and you would make the language code part of your sql query. Granted you could normalize this out to a greater extent, but I think you might get the idea.
In terms of encoding, I can't really speak much as I'm not entirely up to speed on it. In terms of form submissions, I don't believe it should really matter much, it's just how you handle the strings. You'd probably have to do some extra processing by looking at the encoding and deciding how to manipulate the strings, although they might be unicode.