Concurrency (having more than one valid value at a given time) can only be achieved by moving to CRT, concurrent-reliance-temporal Anchor Modeling. In CRT concurrency is managed through the concept of positors, which can be seen as information owners/agents/producers such that each one of them are entitled to having their own value at any point in time. This value may be the same as or different from that of other positors.
You can even set up your own hierarchy of positors, such that if your prioritized one doesn't have a value then you pick one from the default positor instead.
So, you need CRT with as many positors as you have languages.
Of course, there is also a way to do this in UNI, uni-temporal Anchor Modeling, but not as elegant. You can have multiple attributes and knots for the same value, for example HCO_HairColorEnglish and HFA_HaarfarbeGerman. Thanks to table elimination only the attributes of a single language will be accessed during query execution.
However, application logic will have to account for the different table names, so in order to simplify that, perhaps the attributes above would be named HCO_HairColorEN and HCO_HairColorDE instead.
Of the two approaches, I would recommend CRT.
