- From: Ossi Nykänen <onykane@butler.cc.tut.fi>
- Date: Tue, 30 Sep 2003 11:07:32 +0300 (EEST)
- To: Dominique Hazaël-Massieux <dom@w3.org>
- Cc: Ivan Herman <ivan@w3.org>, public-glossary@w3.org
Dear Dom et al, >> 4) In addition to the above, one might want to search _only_ the >> translations? (I.e. currently one gets always the English terms also...) >True, but this seems important since the only official terms are those in English. What would be your use case to have the results only in a given language different from English? > ...I personally would prefer having a functionality like this behind a switch. (And some people do get annoyed when seeing English everywhere. Not me, of course, but...) The use case I have in mind goes as follows: If I seek e.g. a Finnish definition of a (Finnish) term, wouldn't I then expect to have the results only in Finnish as well? When reading, say a Finnish translation of the WCAG 1.0, I might not really care about the fact that the official terms are indeed the English ones, I might simply like to find what a term in the spec means (i.e. the concept behind the buzzword). Another, perhaps a more subtle observation is that, when performing a (partial text) search "element" (as "*element*"), I would like to find e.g. terms "elementti" (element) and "elementin sisältö" (element content) but not "element" (in English). For instance, in Finnish, words have many inflexions, which means that you frequently seek data based on only partial keywords (and by default adding the English words to the result set adds a lot of unwanted data). I believe this linguistic property may be found in other languages as well. >> 6) When searching, what is the meaning of the "Reset" button? It seems to have no effect. (And even if it had, is the button needed at all?) >Reset is a standard button on a form which allows you to undo any change you may have done on a form; it's there because it's good to allow people to revert any action they would have done. > Yes. What I meant was rather that the form doesn't remember its state. In other words, after a search, it returns to the default state anyway. Thus, the button will be used very little, if at all. >> 8) The meaning of the phrase "definition" in the "Search in Term names and checkbox and [] definitions..." might seem a bit unclear. I assume that it means a free-text search within definitions but it came to me only in the second reading... >How did you understand it at first? What wording would you suggest instead? Since I anticipated that the system will (eventually) include e.g. CEO kind of concepts, and (I wish ;) perhaps examples, I though that the checkbox would _limit_ the search only to the actual definitions from the specs. In other words, when trying the system out without first reading the intro (ahem...), I assumed that by default, the system would search for all sorts of data. My suggestion for... "Search in Term names and definitions... " ...would be... "Search in Term names and TERM definitions... " ;) >> ... >> Having said this, what happens when a spec changes its term or becomes resigned? (This is obviously related to [*].) > to [*]? This is where markup languages with link syntax start to become useful ;) ... i.e. I used the "[*]" to refer a text segment above (just after the smiling chap with a propeller in his hat... me, perhaps): -----a copy from above----- > 7) In addition to searching for terms, one might also like to refer to the > terms and definitions (e.g. when talking about terms or translations...). > What if the application was added a feature for this (thus effectively > giving URI names to the W3C terms +[:-) [*])? Of course, in an ideal case, > one would obviously refer to the original specifications but due to e.g. > missing markup, it can't be done. (Well, not without some XPointer-style > fancy work.) -----a copy from above----- I.e. currently these things require manual work and a policy should be established how to deal with changes. (The URI names should be persistent, of course.) >> ... >> In addition, I might understand the strict sense of a glossary, but the >> possibility of adding examples and comments (e.g. from the Team, WGs, and >> the TAG) could make this a killer application. (Just imagine the n+1 >> courses, seminars and presentations around the globe teaching these things...) > I think this should be done using another way; annotations comes to my mind for instance. Yes, that would indeed provide a cleaner system. However, I feel that the practice is a bit behind the specs in this case. In other words, I wonder when the mainstream browsers will support (and/or people use) a standard way of making annotations. (If only more people used Amaya or HayStack... ;) Note: I really think the QA is doing a good job. And e.g. the glossary & i18n kind of work should gain more visibility and higher profile within W3C; considerably more people read, interpret & use specs than write them. And more often. To me, the glossary is a good example of a potentially valuable service that would be very hard to implement outside the W3C. A lesson to be learned, and transferred to member services ($), perhaps. A more general note: The archives seem to have censored Dom's good comments of the other half of my original murmur list (probably for a reason ;) I'm saying this just to point out that this might be an implication of a bug. In this case, this doesn't matter since both Dom and I have received all the relevant data. Best regards, --Ossi -- Ossi Nykänen Tel +358 3 3115 3544 Tampere University of Technology Fax +358 3 3115 3549 DMI / W3C Finnish Office Email ossi@w3.org P.O. Box 553, FIN-33101 Tampere, Finland Web www.w3c.tut.fi
Received on Tuesday, 30 September 2003 04:07:35 UTC