Re: translations of documentation
Raul Miller <rdm@test.legislate.com> writes:
Thanx for the input Raul.
> Craig Brozefsky <craig@onshore.com> wrote:
> > SP supports this and it would even make the building of our parser
> > interface and tree comparison code easier. I didn't want to introduce
> > Formal Architectures, because I wanted to keep the complexity down,
> > but I think that if we do statically define wether an element is
> > always floating or structural we severely limit the usefullness.
>
> Can you talk a bit about the nature of this limitation? I just don't
> see it as that big of an issue.
It means that the LI semantics of an element are static, and cannot be
modified by the author as they see fit in order to better represent
the LI portion of the document for each instance. This is not
something that I think would be a real world problem with any
frequency. But if we're trying to create a system with somewhat
complete capabilities, I would want the ability for the author to give
some indication of the LI properties of a particular instance of an
element, without having to change the LI properties of all other
instances of that element.
I guess the tao suggests we shoot for "real world", instead of
conceptual completeness 8^)
> I don't buy this [yet]: If the layout is that different you can't rely on
> the document structure being the same, either.
You could rely on SECT and CHAPTER structures remaining the same,
while relationships between smaller structural components change(P to
TABLE as in my example). Tho, this is why I suggested the ":language"
property on the definition of the LI floating elements, to indicate
which set of languages it's significant for.
Actually, the system I'm proposing is not really designed to enforce
the type of relationship you suggested in that example with the two
paragraphs around a table(or was it image). That is an issue of
ordinality of particular instances of floating elements. I do not
think that is a relationship that we want to try and capture.
> Anyways, Debian documents tend to have a rather straight-forward
> structure without a lot of fancy layout -- we have a practical need
> to support a variety of media, and you just shoot yourself in the
> foot if you try to get overly elaborate about this.
I would like to keep it as simple as possible, which is why I left out
modification of LI properties of particular element instances from the
original idea. We've just gone back and forth about wether or not we
feel that giving the author that control is neccesarry, and wether
it's worth the added complexity.
I'm leaning towards the LI properties of elements being static,
meaning that the element has the same LI properties everywhere it
appears in the document, and this cannot be overridden by the author
on a per instance basis. This saves us from the Formal Architecture
stuff, and I think it hits a sufficient part of our "real world"
cases.
> In my opinion, this is a portability issue, and you can't sanely tackle
> portability issues without real examples of the issues.
The "real example" of choice would IMO be to proceed with a
lightweeght implementation of this and try and see how it fits the
workflow of a real translation. Comparing two static documents is not
going to help us much. The basic idea I have put forth of extracting
a tree representation of the LI structure of the SGML document is
drawn from the work done by The SGML technologies Group on the
European Union's Budget publishing process which has over a dozen
target languages and a very complicated document structure.
Again, thanx for your input.
Reply to: