[Parley-devel] [parley] [Bug 205261] can't properly specify multiple translations

[ancow]

https://bugs.kde.org/show_bug.cgi?id=205261

--- Comment #11 from ancow <bugs at ancow.no-ip.org> ---
I'll have to answer inline, since there are too many points:

> --- Comment #10 from Andreas <andxav at zoho.com> ---
> As a change to the current version Parley should use , as the primary
> separator and ; as the secondary separator.  When Parley expects a list of
> answers it should scan the answers.  If the answers do not contain commas
> then it should expect commas as the separator in written answers.  If the
> expected answer items contain commas then it should expect semi-colons as
> the separator.

This assumes that parley has a list of possible answers. It doesn't, which is
what this bug/wish is about. Also, there should be no problem adding a
application-global option to define primary/secondary separators for now, until
this can be handled properly. So hardcoding comma and semicolon as separators
shouldn't be necessary.
In the answers, you don't even need this whole separator nonsense - just do
what KVocTrain did: offer an appropriate amount of input boxes for the possible
answers.

> For the future file format I have already proposed that we have two fields
> per language/subject: primary separator and secondary separator character. 

Why have a separator at all in the XML file? Why not "simply" make it possible
to link multiple translations?

As I mentioned before, the whole concept of viewing a translation as a
one-to-one relationship is flawed. If you're already reworking this, why not do
it properly this time?

> Lastly, I think that it would be useful to offer the option to
> generously/non-strictly interpret separators. Allow the student to use any
> list separator not included in a list item for the question they are
> currently answering.  For example, after pre-scanning the expected answers
> in the list, allow the user to use any non-alphanumeric character that is
> not in the answer.

This only works under the assumption that no incorrect alphanumeric character
will ever be entered in a test. It would deny parley the ability to properly
pinpoint and highlight mistakes. (Also, if parley just offered the appropriate
amount of input boxes for the answers, this wouldn't be necessary in the first
place.)

> Currently, Parley doesn't recognize a difference between ordered and
> unordered lists.  I think that for now, we should accept the answers in any
> order, but always show the answers in the order from the file, in case the
> order is significant.

In the context of multiple answers to a translation, I don't think there *can*
be ordered lists. Do you have a counterexample?

-- 
You are receiving this mail because:
You are the assignee for the bug.