Re: Glossary project

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