- From: Karl Dubost <karl@w3.org>
- Date: Tue, 25 Mar 2003 14:54:44 -0500
- To: www-qa@w3.org
- Cc: wendy@w3.org
Hi, this a proposal to close this long standing action item.: Karl & Mark Propose the details for managing dated Glossary versions. Right now, the page has for address http://www.w3.org/QA/glossary I propose to keep the address at this place and to write a redirect in .htaccess RedirectMatch temp /QA/WG/glossary(.html)?$ http://www.w3.org/QA/WG/2003/03/glossary-20030325 As usual we will have the Latest, Previous version, and This version Information for the links. I propose that a new version of the glossary is issued at the same time than the specification are published. To avoid differences between the specification and the glossary and to help to maintain as much as possible the QA glossary as meta glossary of possible refinements in specifications. * This proposal relates somehow to the one, we have to deal for the more general glossary project: Karl, Mark, and Wendy (owned by Karl) coordinate with WAI and develop a how-to draft for entering definitions into the glossaries 2003-02-17 http://lists.w3.org/Archives/Public/www-qa-wg/2003Jan/0018 We discussed at the meeting in Seattle that we have to define a general process for WG to define information inside a specification and outside, and how does it relate to the W3C glossary? When a WG is defining a term, it would be necessary to have to top-down approach for the editor: 1. Look if the word is defined in the general glossary. 1.1 If it is, use this definition and refer to the general glossary for its definition. Comment: This method implies that the definition in the general has to be fixed somehow because it implies a dependency between the spec and the glossary. Or maybe each definition has a kind of unique identifier with a versioning of the definition? 1.2 If the definition is not satisfying and you will have to refine it for your own purpose, define your words as a refinement of a more general definition, but do not make it contradictory of the main glossary. 1.3 If the definition doesn't exist, use the markup defined by the general glossary to make it automatically extractible. So the general glossary can increase the numbers of words defined. Comment: At this stage, we could offer a templating system or a mini-glossary engine included in the bigger one to help people to create the right markup for their spec. 1.4 glossary legacy What will happen when we will start to create the glossary and have conflicting definition for the same word. I guess we should collect them but at a point recommend one definition on the others. 2. Translation of terms. 2.1 Differences of translations in time The translations are not normative because some translations are different depending on the translators. The goal of the glossary is to reduce the discrepancies between the different specification and the translated terms. There will be a need of a consensus at a point. What's happening when a first person translate a first term but a second translator comes to contradict it. 2.2 Differences of translations between family of languages It can happen that the translation varies depending on the version of languages, like in color/colour or differences between FR-fr, FR-ca, FR-ch, etc. 2.3 Definition Should we have also the translation of the definition. The rationale for this one is that sometimes it's very helpful to translate the definition to explain the meaning of a word and so to have a better translation of the context when inside a spec. -- Karl Dubost / W3C - Conformance Manager http://www.w3.org/QA/ --- Be Strict To Be Cool! ---
Received on Tuesday, 25 March 2003 17:52:50 UTC