How to resolve I2C address clashes?
There is nothing built into I2C to do this, normally slave devices will have some externals pins that can be set to 0 or 1 to toggle a couple of the address bits to avoid this issue. Alternatively I've dealt with a few manufacturers that have 4 or 5 part numbers for a part, the only difference being its I2C address.
Most devices have specific hardware that handles the I2C communication, that is the slave ACK is in hardware so you really can't hack around it.
As for the translation module, you could buy some $0.50 PIC's with 2 I2C buses and write some quick code to make them act as address translators i guess.
I've just run into this problem with multiple I2C devices with a fixed address. Our solution was to use I/O lines on the microcontroller to force the SDA lines high on the devices that we don't want to address, while the I/O line for the device we're targeting is set as input (high impedance). This means that only the targeted device matches it's I2C address and the others ignore any subsequent data.
The resistors on the SDA line for the inactive devices end up acting as pull-ups for the bus, so the exact value will depend on how many devices you have and what pull-up you need for your bus. So if you choose 10K resistors, then 3 inactive devices gives a 3K3 pullup.
The schottky diodes ensure that the device can still pull the SDA line low enough when transmitting data back to the host.
If none of the I2C devices use clock stretching (handshaking), and if you're bit-banging the I2C master, a simple hack is to have some of the devices swap the clock and data pins. During the transmission of a byte, the device which has the clock and data pins swapped will see each "0" bit as a non-event (data rising and falling with no clock) and will see each "1" bit as an I2C stop and start (clock rising while data is low, fallowed by data rising and falling, followed by clock falling). Intentional stop and start conditions for one device may be seen as data bits by the other, but unless one device has an excessive number of start and stop conditions between "1" bits, it would be unlikely that any device would "accidentally" see a start condition followed by eight data bits without an intervening stop condition.