Terminology: "selecting" is not enough!

That's OK, too, for checkbox (tickbox?) items, and maybe radio buttons. I think our terminology list needs to be updated and reviewed for the preferred way/ways to express this for the different UI items. I doubt there's a one-size-fits-all solution, though for me select comes closest. I'll put something together. Until we've agreed on the way we want to go, I don't think there should be any blanket changes to the existing terminology.

Hi, :slight_smile:

I'll put something together. Until we've agreed on the way we want to go, I
don't think there should be any blanket changes to the existing terminology.

+1.

David Nelson

Activate/Deactivate works for me.

Barbara Duprey wrote:

I have another problem with the enabled/disabled terminology -- I think it
can easily be
misunderstood as modifiable/unmodifiable (available/"grayed out"). This
terminology is not in common
use and I think it would be more confusing than helpful. Often "click"
would be a reasonable
substitute, but I have no problem with "select" and definitely prefer it
for options in a list, for
example.

"select" is a synonym for "choose" and would be applicable for a drop-down
combo-box or a set of radio buttons. But for checking/unchecking a check
box, it is simply the wrong word. You are not selecting one option from all
of them on the page; you are individually turning each option on or off.

I agree, "disabled" is used for graying out a menu item, at least in the
Win32 API. Popular use is just "grayed out" though.

"clicking" a check box does not mean "ensure it is checked." The action of
clicking it will probably toggle it. It is correct to click a button,
though.

How about "check"? Well, as a verb it means "hinder or restrain" so
un-checking the Foo option will check the operation of Foo. Or it means
"inspect" which will find out what it is; so you want to check your margin
settings when setting up the page. So, don't use "check" to mean "mark" as
a verb, in this context.

The text in the document that you indicate by swiping the mouse is "The
Selection", and you select some text before hitting the "bold" tool, for
example. Selecting a named item from a combo-box is acceptable usage.

I think we should focus on explaining what the various options indicate,
rather than directing the user to click on them or saying that the effect
would happen if the user enabled them. That is to be understood: just
state the effect itself!

I just went to another program at random: the context help for the Options
page on Firefox reads, "When this option is enabled, Firefox will..."

On Notepad++, "Check the option to ..."

On XYplorer, some don't use a state or verb, just lists the meaning without
preamble. Others use check/uncheck.

7-zip: on the file manager options, most of the time doesn't use any
preamble. E.g. "Displays gridlines around items and subitems." Some uses
of "select". The rest use "enabled".

Foxit reader: on the printing help, "select" is followed by " from a list".
No preamble for options explanations, but they are mostly radio buttons.

So, I think there is lots of competition against "select" to mean "mark on".

--John

Good points, I'll incorporate this into the terminology document for us all to collaborate on. As I said, I don't expect a single answer here, it depends on the type of UI item involved, and sometimes on the behavior resulting from the choice.

What terms does the LibreOffice Help use? I thought that was our main
terminology selection criterion.

Hal

Hi :slight_smile:

Most documentation just confuses people so copying what they use probably wont
help us. If we are going to look at documentation then a community edited one
would be better, such as Ubuntu's but it would need to be regularly edited
bynoobs rather than by geeks so perhaps Ubuntu's might be the best one to look
at. Documentation for Windows apps tends to be the most confusing documentation
for most people.

"Greyed out" is a very geeky term. Admittedly low-level geeks but still not an
average user. "Check" is kinda American. In English it tends to mean a method
of payment or "to stop and look around" or as described. Tick the option might
be a good way to say it but "UNtick" confuses people. Select means to to choose
and that seems to make sense to people.

Regards from
Tom :slight_smile:

Yeah but it's a bit posh or sci-fi. I like it but then i also liked "Defying
Gravity" and that was so unpopular it only lasted 1 season. There are some
great suggestions in this thread so i think they should be in a glossary.
Perhaps we shouldn't try to be too consistent because people can always look
things up in the glossary. Activate might be good when there is an instant
highly visible spectacular result.

Regards from
Tom :slight_smile:

"Click" is good but it suggests toggling the value which is the original
problem at the beginning of this thread. "Mark" doesn't quite work (well he
does a huge amount like most of you). "Hit" is much like click but only covers
certain demographics. Although there are a lot of good options i don't think we
will find anything much more generic and useful than "select" as all the
alternatives also have problems. I also think this is a side-issue when there
are more important changes we need to focus on. It is great to have these
discussions early on before things get too established. The people in the
documentation team are great.

Regards from
Tom :slight_smile:

Hi Hal,

What terms does the LibreOffice Help use? I thought that was our main
terminology selection criterion.

I didn't read all the thread, what are the terms you're searching for?
- select
- mark
- check
- ??

are there others?

Kind regards
sophie

The things we're discussing here are, I think, too context-sensitive to be readily searchable.

There seems to have been a decision long ago to use US-English terminology and spelling in the English documents. "Tick" is not used in the USA, except when talking about the blood-sucking insect! I think "not available" is fine instead of "grayed out" but not often needed anyway.

Hi, :slight_smile:

Yes, we had the discussion about what variety of Engish to use a while
back. The consensus at the time was US spelling and terminology.

IMHO, one of the biggest aids to comprehensibility is careful and
thoughtful punctation.

But I also try not to be lazy in my English and to be careful about
relative pronouns [1] and subordinating conjunctions [2].

One good idea, as suggested by Barbara or Hal, is to build-up a
separate and brief glossary of terminology explaining our conventions.
It could be useful to end users but it would especially be an aid for
translators.

As I mentioned previously, "activate" and "deactivate" are terms I use
a lot, but I do tend to vary my vocabulary so that the style isn't too
stilted and wooden. I generally attribute two ha'porth of common sense
to the reader.

My 2 cents...

[1] http://en.wikipedia.org/wiki/Relative_pronoun
[2] http://englishplus.com/grammar/00000377.htm

David Nelson

Hi David et al:

This is somewhat what I was wondering today. I thought that it would be useful if instead there were a "LibreOffice Style Manual" that we could all share between documentation, website, design and marketing. Such an example is the Google style manual pages[1]. All of the different NL groups could develop their own and these would be a point of reference for users and members when in search of usage, formatting or styling questions.

Cheers

Marc

[1] http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style

Hi Marc,

Hi, :slight_smile:

Yes, we had the discussion about what variety of Engish to use a while
back. The consensus at the time was US spelling and terminology.

IMHO, one of the biggest aids to comprehensibility is careful and
thoughtful punctation.

But I also try not to be lazy in my English and to be careful about
relative pronouns [1] and subordinating conjunctions [2].

One good idea, as suggested by Barbara or Hal, is to build-up a
separate and brief glossary of terminology explaining our conventions.
It could be useful to end users but it would especially be an aid for
translators.

As I mentioned previously, "activate" and "deactivate" are terms I use
a lot, but I do tend to vary my vocabulary so that the style isn't too
stilted and wooden. I generally attribute two ha'porth of common sense
to the reader.

My 2 cents...

[1] http://en.wikipedia.org/wiki/Relative_pronoun
[2] http://englishplus.com/grammar/00000377.htm

David Nelson

Hi David et al:

This is somewhat what I was wondering today. I thought that it would be
useful if instead there were a "LibreOffice Style Manual" that we could
all share between documentation, website, design and marketing. Such an
example is the Google style manual pages[1]. All of the different NL
groups could develop their own and these would be a point of reference
for users and members when in search of usage, formatting or styling
questions.

The l10n teams have already style guides, glossaries, terminology and TMX files. I can send you the French ones if you like (l10nFR section is not up so not available for LO currently, only for OOo).
They are available to the Documentation and Marketing teams but not used from what I've seen in the FR community, mostly because this is all oriented for localization when they create their own material.
There is also the fact that the more you bind people to rules or constraints, the less they are going to participate. The most important is the respect of the UI labels, if the rest is different it's not very important. Several communities have a lot of documentations, developed/written in very different ways and users seems to find what they need with that any way.

Kind regards
Sophie

Thanks Sophie for this information.

So, the point here it that there is no central location where we can find this information on our wiki. When people were with OOo, was this information posted publicly on the OOo wiki? Or is it just files that people pass on from one person to the next?

It would be interesting to have all that information (from all groups) just available on the wiki for public viewing and reference.

Cheers

Marc

Hi Marc,
[...]

Thanks Sophie for this information.

So, the point here it that there is no central location where we can
find this information on our wiki. When people were with OOo, was this
information posted publicly on the OOo wiki? Or is it just files that
people pass on from one person to the next?

It would be interesting to have all that information (from all groups)
just available on the wiki for public viewing and reference.

It is on the OOo FR site and will be on the LibO FR wiki. The l1on process was not organized yet so I didn't settle this part on the wiki (most of the time I'm alone to work on it, so the need is not under pressure :wink:
The central location for native language groups is their site and their wiki, the international things most of the time have no interest for them, this is not where they feel "at home".

Kind regards
Sophie

Ah. OK. So it will eventually be migrated onto our site. Thanks for all the work you do. We know that it takes a lot of time and that we are often a little impatient for the things we would like to have at our disposal. I can relate as I am trying to keep the Marketing section organized and it can often get really busy.

Maybe I'll check in on this later and if there is a need for any help in migrating the files from the OOo site I could help out.

Cheers and thanks

Marc

Hi Marc,

Hi Marc,
[...]

Thanks Sophie for this information.

So, the point here it that there is no central location where we can
find this information on our wiki. When people were with OOo, was this
information posted publicly on the OOo wiki? Or is it just files that
people pass on from one person to the next?

It would be interesting to have all that information (from all groups)
just available on the wiki for public viewing and reference.

It is on the OOo FR site and will be on the LibO FR wiki. The l1on
process was not organized yet so I didn't settle this part on the wiki
(most of the time I'm alone to work on it, so the need is not under
pressure :wink:
The central location for native language groups is their site and their
wiki, the international things most of the time have no interest for
them, this is not where they feel "at home".

Kind regards
Sophie

Ah. OK. So it will eventually be migrated onto our site.

It will be, it's just that the organization of the l10n teams is not finished yet, and the FR part is not set.

  Thanks for all

the work you do. We know that it takes a lot of time and that we are
often a little impatient for the things we would like to have at our
disposal. I can relate as I am trying to keep the Marketing section
organized and it can often get really busy.

Thanks for the work you do too :slight_smile:

Maybe I'll check in on this later and if there is a need for any help in
migrating the files from the OOo site I could help out.

Ok, thanks for your offer to help. The month is ending next week so I guess it will be online next month :wink:
The English guides will be there:
http://wiki.documentfoundation.org/TipsTricksl10n
The French one will be there:
http://wiki.documentfoundation.org/FR/L10n

Kind regards
Sophie

Be advised that standard US English is somewhat fussy--especially in legalese--in its "that/who/which" usage, whereas UK English is not. One tip is that "which" is typically preceded by a comma, but "that" is not. The reasons to use one or the other word simply will become better understood after seeing them employed in actual practice--assuming that the authors did them OK. "who" also employs declensions--whom, whose--as a remnant of English being originally derived from German.
/
The Chicago Manual of Style/ is a decent style guide for most US-publishing grammar and punctuation issues, in addition to US terminology. The current edition (15th) is its first version to address IT usage as it applies to publishing. Copies (new or used) can be purchased very cheaply via Amazon. [I got mine years ago for half price via a promotion at Amazon, plus no S&H costs.]

Gary