Merging zh and en versions of clreq (urgent)

chaps,

it's currently a little more difficult to manage translation across two 
(and soon more) documents than i think it should be.  We also need to 
find an easy way to keep the markup in synch across versions, and ensure 
that all content is available (whether translated or not) in each 
version of the document.

to eliminate many of the difficulties involved, i'd like to merge the 
current zh and en versions of the document into one.  This was also the 
way jlreq was developed, although in that case there was quite a lot of 
markup and lots of post-processing involved.  It's also the way we are 
looking to do the Tibetan layout document, per Chunming's suggestion.

i've attached a sample of how this can work - see the first part of 
chapter 2.2. I tried to minimise the complexity for clreq, and produced 
a much simpler method than that used for jlreq.

the main differences are as follows:

1. each low-level block of content (eg. p, li, figcaption, etc) occurs 
twice, once in zh and once in en.  (Occasionally, there is a slightly 
different structure to the en and zh versions, and if they aren't 
corrected, these are kept parallel.)

2. each of the above blocks has a data-lang attribute with a value of zh 
or en (later we can add zh-hans and zh-hant).

3. ids are attached only to the next structural element up the hierarchy 
whenever possible, eg. sections have ids but not headings.  This avoids 
duplicate ids.

4. inline markup with ids, such dfn, start with en or zh, eg. <dfn 
id="en_def-kai">...</dfn>

5. currently the images are the same in both documents, so i haven't 
duplicated those, however we could do in the future, if needed.

we could use dynamic styling to hide one language or another for 
checking/review.

when we publish the doc to TR we could run a small script to separate 
the versions of the doc into their various language versions, although 
we could also just publish the WD with mutliple languages - which may 
help some reviewers (we can discuss this later).

*i'd be grateful if you could respond quickly to say whether or not you 
see a major obstacle with this approach.  If the majority agree, i'll do 
it myself (during my non-work time), and expect to finish it by the 
weekend.  That way we can minimise any delay to FPWD publication.*

thanks,
ri