[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xtm-wg] Re : Style Guide for XTM specs
Bernard Vatant wrote: > > Sam, and other brave editors > > A general practical suggestion for editing prose style. > > The main difficulty is the constant mix-up of technical terms defined in > the spec and used in the syntax, and meta-terms, often very close to and/or > identical/synonymous of the previous ones. That is we have a constant > mix-up of language and meta-language, the first one being itself as much > and maybe more "meta" than the second, and hence the risk that only > veteran topic map hackers will see which is which ... and so much for the > external communication, promotion and marketing. I agree entirely on the complexity of communicating in one language, much less in many. We do have problems in our current usage that must be fixed, but I must respectfully disagree on the solution you propose, which relies too much on font formatting. > So, for the reader (and writer) to be able to make the distinction, the > spec terms should be typed in a characteristic {style} like bold red or > italic blue or something, in a coherent way all along. Any word not in that > style is "meta", even if the same words are used at both level, which is > bound to occur with e.g. "names" or "subjects" , even if it should be good > to avoid it for clarity of discourse. Keeping the *meta* vocabulary to the > minimum core is a *meta* guideline. That's the only way : stick to the > concise, clear and absolutely boring style of good maths litterature. While this may be helpful (and is already done to a great degree in the current online specs), it is problematic for accessibility (ie., use by those unable to discern color or font differences), and spec interoperability, since some browsers do not correctly support all font differentiation (though most do some), but almost all of this is lost in printing. Color simply should not carry important meaning in a text. Hints only. Many people have difficulty differentiating font family differences as well, though this is somewhat more reliable than color. As mentioned, we already use font and color to some degree, but we shouldn't *rely* on it for meaning. > Such a guideline would be particularly useful when translating the spec > into other languages, like French (au hasard). The spec terms will not be > translated, of course, only the meta prose, since the patiently built > english terminology - which is not only a terminology, but an ontology - > will find no exact match in any foreign language or culture, which means > not only the syntactic terms are of course non-translatable for obvious > technical reasons, but the spec users will have to "build knowledge" about > it, by understanding what is the *subject* of every *element* in the > specification. And my hunch is this knowledge is somehow deeply rooted in > the original language and cultural background of the spec authors, and not > as universal, intuitive, and straightforward in any other > linguistic/cultural background that some would think to begin with. Users > will have to learn what "association" or "subject" means, the same way > maths students learn what "vector" or "mapping" means. I'm discussing with Sam the idea of creating some custom markup and an XSLT stylesheet that would translate it into XHTML. Our big problem is lack of time to create tools. There are very few working days between now and mid-January to test out unknown processes. The last one was simply a crunch to get done on time, and none of us have much time to spare in development of processes. Seems a classic IT problem... > For example, the French for Topic is "Sujet", and the French for Subject is > "Sujet" ... (çà commence mal !). So we'll have to keep "Topic" in red bold > in French prose, such as in the following excerpt ( *underlined terms* > should be red bold ) > > [ In the example below, *scope* is used to differentiate the *base names* > of the *topic* "Hamlet" (the play) from "Hamlet" (the character)] > > Would translate in French : > > [Dans l'exemple ci-dessous, *scope* est utilisé pour différencier les *base > names* du *topic* "Hamlet" (la pièce), de "Hamlet" (le personnage)] Yikes. > So much for the "sauvegarde de la francophonie" - but we have no choice ! > Even with such guidelines, the translation will be a tricky exercise (count > me in for some help) Great to hear we can count on you! One of the goals I've had in these specs is both internationalization and accessibility. Hopefully we can strike some kind of reasonable compromise. > BTW feel like all that has something to do with noodles, knowledge and > wisdom, but what is this something ? Noodles are all about wisdom. But if I told you the secret, I'd have to kill you. Or something like that. Murray ........................................................................... Murray Altheim, SGML/XML Grease Monkey <mailto:altheim@eng.sun.com> XML Technology Center Sun Microsystems, 1601 Willow Rd., MS UMPK17-102, Menlo Park, CA 94025 In the evening The rice leaves in the garden Rustle in the autumn wind That blows through my reed hut. -- Minamoto no Tsunenobu -------------------------- eGroups Sponsor -------------------------~-~> eLerts It's Easy. It's Fun. Best of All, it's Free! http://click.egroups.com/1/9699/0/_/337252/_/977271835/ ---------------------------------------------------------------------_-> To Post a message, send it to: xtm-wg@eGroups.com To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC