This is more or less the concept I was mulling over as
a very general
solution, but I realised that it does have a big disadvantage: naive
users 'correcting' the translation may simply shift the error into the
opposite version. Or, more specifically, there is no way of
distinguishing a translational correction from a factual one.
Completely agree. That why I think an explicit mark up that says
Simplified "apple" IS Traditional "orange" is necessary.
On the UI issue, it seems feasible to have two UIs coexisting together
without running two separate sites: we can store two versions of every
message key in the cache or the database. For example, for "mainpage",
we will have "mainpage_cn" that maps to the Simplified title of the
mainpage, and "mainpage_tw" that maps to the Traditional title of the
mainpage. One mainpage can then be the redirect of the other. When
rendering the UI, we will look for things with _cn in the message
cache if the language preference is zh_cn, and _tw for zh_tw. I hacked
up some code to do this and it is now runing on the test site,
. I am not sure if I got the
message caching part right, because I currently don't have a way to
test it. I think right now the messages are coming from the database.