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

[Ansa]

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

--- Comment #12 from Ansa <ansa.ansa at gmx.net> ---
What about this: In testing, parley provides the user with the possibility to
fill up to as many boxes as there are comma-and-semicolon separated substrings
of the translation. It is up to the user to fill only as many boxes as are
needed, using commas and semicolons inside boxes if appropriate. (The boxes
could initially be pretty small, only expanding when the user starts filling
them - this would avoid cluttering the screen with unnecessary boxes, which
could easily happen on smaller devices.) Parley then throws away the remaining
(empty) boxes, and reorders the used boxes on the screen to match the correct
solution - the correct solution is still shown in the order which is given in
the collection. If order is important, the user will either fill everything
into one box, or see that they gave wrong order and adjust the correct/false
mark accordingly.

Advantages:
- no changes in existing collections: the files stay the same (-> compatibility
with kvtml2 standard)
- works with lists of translation equivalents that are both comma and semicolon
separated
- works with commas and semicolons that are not translation equivalents
separators
- is also "forward compatible": if the new format allows for some unambiguous
way of specifying and storing translation equivalents, then
      - the practice interface does not have to change
      - the only limitation for the new format is not to use unescaped commas
and/or semicolons as the (unambiguous) separator
      - if the new format implements complex relationships between words in two
languages (where A, B, C in L1 and X, Y in L2 correspond as follows: A->X,Y;  
X -> A,B;   Y->A,C), users would be free to use either "the old way" of simply
listing a comma/semicolon separated list, or to use the new GUI (in which it
possibly could take more time to interlink the words as needed), and they could
even use them simultaneously

Generalisation:
- let the user list all possible separators as an option - if that is
compatible with the chosen solution in the new data format (e.g. if multiline
items are implemented, I can imagine that some users would like to list one
translation per line)

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