Hi,
>
> sajolida:
> Then I could nitpicking on a bunch of terminology and phrasing issues
> but maybe you discussed them already so I don't know how to proceed.
>
Please do :)
>
> I think I'll raise some of the terminology issues here, submit patches
> for the typos and phrasing, and wait and see on others :)
>
> As a general rule, please refrain from changing or remixing terms or
> feature names that we are using elsewhere (for example in the doc); at
> least without checking with others outside of your threads. Because we
> want to use consistent terminology everywhere, and partial changes
> (unless well justified) are going to be problematic because changing
> terminology only in one place, would affect many other (documentation,
> possibly user support, other interfaces, etc.).
>
Will do. Keep in mind, though, that the goal is to have the most
accurate, and hopefully clear, text possible. This may often mean
rethinking what GNOME, or others, are doing/recommending.
>
> 1. "Keyboard Language" is an uncommon concept. GNOME talks about
> "layout" in the system settings. So I'd say "Keyboard Layout" (or
> "Keyboard" only if you prefer).
>
Keyboard layout is different from keyboard language, as there are many
layouts and many languages, all of which combine to form Voltron.
In a Language section, though "language" may be redundant, it might be
important to specify the task, especially when limited.
However, I am all for 'Keyboard' as a label for that setting type -
especially if we include more than just a language selection down the
road.
>
> 2. "Save XXX Changes" maybe I'd rather say "Save XXX Settings" as what
> we are saving here are the settings and not the changes. Especially
> when
> used with a *checkbox* which describes a *state* (and not a *change*).
>
People are saving the settings...but they are already saved by default.
People must be saving the changes made to the settings...but they are
still saving the settings.
Logic defends both seemingly equally; I was for either :)
However, when considering the 'Privacy' or 'Security' settings, people
are saving the setting types to the Greeter's first screen (Check & Go),
not saving changes to the setting types, like in 'Save Language xxx'; so
I am actually not sure :(
>
> 3. "Administrative Account". Here you're changing the way we're calling
> this everywhere else in the doc ("administration password") which is
> inconsistent.
>
This is okay; the only thing that stays the same is change :)
>
> Also, I think that "account" here is misleading because
> people don't interact with different accounts here (as is "account =
> login + password") and use this password through sudo and other access
> granting mechanisms which I don't associate with an "account".
>
Administrative accounts are all the same (presuming they have the same
privileges), all of which have a password and an account name.
Also, "regular folk" will find more comfort in a familiar concept, such
as an account to manage their computer, which is the way many experience
Windows and Mac.
>
> And
> regarding "administrative" vs "administration" I'm not convinced the
> change is worth it but maybe I missed some discussion.
>
Nope, nothing missed, I just made designations that seemed to make sense
to me :)
"Administration" is a noun, while, "administrative" is an adjective.
Because we need a word that answers a question, specifically, "what
kind?", it seems that we need an adjective here, e.g., "What kind of
account?" "An administrative account.".
>
> 4. "Encrypted Storage". when discussing this terminology again earlier
> this sprint we settled on saying "Persistent Storage" and, in some
> relevant places "Encrypted Persistent Storage". We didn't feel ready to
> drop the terminology "persistence" which is all over the place. In the
> case of the Greeter I propose to call this section "Persistent
> Storage".
> People who already have it set up should know it's encrypted. For
> people
> who don't we can still label the configure button as "Configure
> Encrypted Persistent Storage".
>
Yes, but "storage" already presumes shit ain't going anywhere.
'Persistent Storage' is redundant unless there is an accompanying
non-persistent storage labeled 'Storage' and the default presumption
about this 'Storage' is that shit disappears at some point. Since that
isn't the case here, I second tchou (if I remember correctly) in the
label of 'Encrypted Storage' for this section.
I do not agree with the conclusion drawn from the presumption that
"People who already have it set up should know it's encrypted" because
people would then already know that this partition is persistent if they
are setting it up, as Tail's default state is to forget, and would not
need the redundancy of the "persistent" label.
I feel that the word and concept of persistence this is best used in the
documentation to explicitly/verbosely detail the feature, but is
unneeded in the Greeter as a label (if there is descriptive text, it
would be fine there as that would offer an opportunity to expand on the
concept of "encrypted storage".
>
> 5. "Network Connection / Direct". I'm afraid people might think this is
> "direct" in opposition to "Tor" (which could be "indirect" in some
> mental models). But I'm ready to wait and see if this is indeed
> problematic. Also note that we're currently calling this "Network
> configuration", see the doc.
>
I agree although "Connect directly to the Tor network" uses it :/ The
problem will be with "regular folk" who are used to connecting directly
to the internet.
I inquired into what the other states would read and so far we think
that the bridge, firewall, proxy, or air-gap states will share the same
label.
We need terms for both of these opposing states, as 'Off' is our
placeholder for the third network state.
Let's keep the terminology stuff here *forever* (evil Halloween laugh)
:)
Wordlife,
Spencer
