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

[Ansa]

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

--- Comment #6 from Ansa <ansa.ansa at gmx.net> ---
I like the idea of storing the translation equivalent separator internally with
the help of some kind of escape sequence. I am not sure about how multiple
input fields would work in the editor - I prefer having everything really
compact. In the spirit of giving the user complete control over things (and the
developers some extra coding practice), what about this:

"Advanced settings" interface:
Use semicolon as a translation equivalent separator    By default/By default
not
    Show checkbox in the editor for changing the default meaning of semicolon  
 Yes/No
    Apply the default setting to all items in the collection that have not been
set yet      Go
Use comma as a translation equivalent separator        By default/By default
not
    Show checkbox in the editor for changing the default meaning of comma   
Yes/No
    Apply the default setting to all items in the collection that have not been
set yet      Go (after pressing Go, the user is asked to confirm that the
setting will be set to all items in the collection and it will only be possible
to reset it manually for each single item)


In the editor, if the checkbox option would be set to Yes, there would be a
small checkbox at the end of each input field (or two, one for commas and one
for semicolons), that would specify whether semicolons/commas should be
understood as translation equivalent separators FOR THAT ITEM. For items
present in the collection before this feature was implemented, the checkbox
would show a dashed check mark, meaning that the status of the item has not
been set manually and the default will apply to it during practice. For new
items, it would be preset to the default value.

In the data, there are three options for an item with respect to treating
semicolons, and similar three options for treating commas:
   - the value of "semicolon_is_separator" is not set; semicolon is treated as
described in the default option in the settings (if "By default" is selected,
then semicolon should be treated as translation equivalent separator for that
entry, otherwise not)
   - if the value of "semicolon_is_separator" is set to yes, then semicolon
should be treated as separator in both cases, "By default" as well as "By
default not"
   - similarly if the value of "semicolon_is_separator" is set to "no", the
semicolon should not be treated as separator in either case


While I think this would accommodate well to different kinds of users,
including users whose large existing collections already include semicolons and
commas of both kinds (punctuation as well as separators), I am not sure if
implementing it would be worth the effort.

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