bug-gnu-pspp
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

PSPP-BUG: [bug #59697] Unintelligible strings in PSPP 1.4.1


From: Ben Pfaff
Subject: PSPP-BUG: [bug #59697] Unintelligible strings in PSPP 1.4.1
Date: Wed, 16 Dec 2020 13:12:55 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Follow-up Comment #4, bug #59697 (project pspp):

[comment #3 comment #3:]
> [comment #1 commentaire #1 :]
> > Thanks for bringing this up.
> > 
> > The first two are ones that users are meant to understand:
> > 
> > - "Text strings in the file dictionary that the previously listed
encodings interpret differently, along with the interpretations." 
> > 
> > This is about .sav files.  These files contain "dictionaries" of
meta-data.  The dictionaries have strings but they don't say what encoding
(e.g. ASCII, windows-1252, UTF-8) those strings are in.  The table below this
lists the strings that would have appear differently depending on the encoding
that was chosen, and how they would appear in each of those encodings.
> 
> I don't see where the verb is actually. The construction of the sentence is
weird. Do you mean:
> 
> "Text strings of this dictionnary can be interpreted differently depending
on the encoding displayed previously."
> 
> Is the user prompted for a choice or it's only a notice?

It's a caption for a table that lists the text strings.  I'll add a separate
comment with an example.

> > - "Codings" (not enough context)
> > 
> > I think this shows how a value of a variable is represented as part of the
output for the logistic regression.  I'll separately add an output example to
give context.
> 
> The previous reference text was "Encodings". I could think it was about
characters encodings, but now I doubt it.

This is not about character encoding.  My understanding of this case is
incomplete, so it's difficult for me to explain it fully.

> > 
> > The following aren't messages that users need to understand.  They are
reported if a .sav file is corrupt in a particular way.  I am not sure whether
it makes sense to translate them, because only a PSPP developer can do
anything about it.  Do you have an opinion?
> > 
> > - "Value label variable index %d refers to long string continuation."
> > 
> > - "Weight variable index %d refers to long string continuation.  Treating
file as unweighted." 
> 
> Indeed, I think that, if the audience is very small, and the subject very
specialized, and that this can have consequences on the correction of an
error, then there are many good reasons not to translate. In this case, it is
worth asking the question of removing it from the strings to be translated.
Anyway I don't understand "long string continuation"? Is this talking about a
series of long integers represented in strings?

This is about an internal representation in the .sav file format.  It can't
directly represent strings longer than 8 bytes, so it represents them
indirectly using an 8-byte string followed by some number of continuations of
8 bytes each.  Users are probably unaware of this.

I think that I will change PSPP to avoid translating these.  The only part
that is relevant to the user is "Treating file as unweighted."

> > 
> > This one I can explain:
> > 
> > - "%s function does not accept a minimum valid argument count." 
> > 
> > PSPP supports the concept of a "missing value": a placeholder for a value
whose true value is unknown.  PSPP has a bunch of mathematical functions like
SUM, MEAN, STDDEV, and so on. For some of them, you can add an option that
specifies how many of the arguments have to be valid (that is, not missing
values) before the result of the function itself is non-missing.  This message
says that the function in question doesn't accept such an option, even though
the user tried to specify one.
> 
> Ok, that could be rephrased like that?
> 
> %s function does not accept an argument by default.
> 
> %s function does not accept substitution arguments.
> 
> %s function does not accept placeholder arguments.

None of those is quite right.  Maybe "minimum number of valid arguments"
instead of "minimum valid argument count"?

Another way to look at it is that the way this is specified is through a
numerical suffix, e.g. "MEAN.5" for a minimum of 5 valid arguments.  The
message could be more specific, like: "%s function does not accept .%d
suffix."

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59697>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]