Re: [Languagetool] Configuration redesign
On Donnerstag, 24. Mai 2012, Marcin Miłkowski wrote: > > For interactive use, we can probably assume that rules don't get > > disabled for performance reasons, so we could actually always run all > > rules and even display the number of matches for the "disabled" > > rules. > > I don't really get it. You mean we should only display the disabled > rules in the config dialog for OOo? We could display a text like this at the bottom: "+ 12 matches by 4 rules wich are disabled" This could be a link to a dialog which then shows these 4 rules and their matches and a checkbox to re-enable each rule. Regards Daniel -- http://www.danielnaber.de -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Languagetool-devel mailing list Languagetool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/languagetool-devel
Re: [Languagetool] Configuration redesign
W dniu 2012-05-24 00:29, Daniel Naber pisze: > On Mittwoch, 23. Mai 2012, Jan Schreiber wrote: > >> I agree with Daniel that that sounds suspiciously like too many clicks, >> but otoh the 1300+ German rules are very difficult to navigate through >> in the GUI without folding. The French ruleset is even larger. Any >> improvement in this area is very welcome. I don't think scrolling is less painful than clicking. For Polish, it's simply unreadable to have such a long list. To display a category, you would have to click one button, to close the dialog, again one button. The same number of clicks as with collapsing. > I think the best approach is to have context-aware configuration. For > example, it a rule matches, always display a link to disable that rule or > its category. This way the user does not need to visit the configuration > dialog at all. It would be also reusable when the user forgot about some rule but knows it was reacting to a sentence: simply enter the sentence and see what rule it activates, disable the offending rule. I like it. > The other use-case of re-enabling rules could be covered in a similar way: > at the bottom, display the rules which are disabled and offer a one-click > way to re-enable them. This is a good idea. We should also have a different GUI in the editor. I mean something more in the style of: http://www.inetsoftware.de/other-products/jortho The code is GPL but we only need to have squiggles that are clickable in Swing, so obviously we wouldn't reuse code from that project. But instead of a list of matches in the bottom window (which could be hidden in normal cases, as users usually don't need them), we could have a table in the style of CheckMate (http://languagetool.wdfiles.com/local--files/checking-translations-bilingual-texts/lt-checkmate.png), because it's simply easier to read and use. > For interactive use, we can probably assume that rules don't get disabled > for performance reasons, so we could actually always run all rules and even > display the number of matches for the "disabled" rules. I don't really get it. You mean we should only display the disabled rules in the config dialog for OOo? > > In a nutshell: most users should never have the need to visit the > configuration dialog. The trouble is, for example, that the HTTP Server has just been made sensitive to the GUI configuration, and without doubt, some simplistic interfaces to LT in other software won't allow to configure rules. So we cannot simply get rid of the dialog completely. It's not that I love it, it simply might have some use cases: for example, I want to build a list of rules for Chicago Manual of Style (I have to use it at times), and for Computational Linguistics - when you have a variation on the style guide like this, you might now the name of the rule rather than the actual sentence it matches. It would be then possible to configure it without knowing exactly how it works. But if it's hidden most of the time (like Mozilla's about:config), then it's really fine! Regards, Marcin -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Languagetool-devel mailing list Languagetool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/languagetool-devel
Re: [Languagetool] Configuration redesign
On Mittwoch, 23. Mai 2012, Jan Schreiber wrote: > I agree with Daniel that that sounds suspiciously like too many clicks, > but otoh the 1300+ German rules are very difficult to navigate through > in the GUI without folding. The French ruleset is even larger. Any > improvement in this area is very welcome. I think the best approach is to have context-aware configuration. For example, it a rule matches, always display a link to disable that rule or its category. This way the user does not need to visit the configuration dialog at all. The other use-case of re-enabling rules could be covered in a similar way: at the bottom, display the rules which are disabled and offer a one-click way to re-enable them. For interactive use, we can probably assume that rules don't get disabled for performance reasons, so we could actually always run all rules and even display the number of matches for the "disabled" rules. In a nutshell: most users should never have the need to visit the configuration dialog. Regards Daniel -- http://www.danielnaber.de -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Languagetool-devel mailing list Languagetool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/languagetool-devel
Re: [Languagetool] Configuration redesign
> By the way, just because collapsible checkboxes are hard to implement in > Swing, maybe we should have just a list of categories in the first > dialog, and open another dialog with a list of rules in the category chosen? I agree with Daniel that that sounds suspiciously like too many clicks, but otoh the 1300+ German rules are very difficult to navigate through in the GUI without folding. The French ruleset is even larger. Any improvement in this area is very welcome. --Jan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Languagetool-devel mailing list Languagetool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/languagetool-devel
Re: [Languagetool] Configuration redesign
On Mittwoch, 23. Mai 2012, Marcin Miłkowski wrote: > I propose the following scheme (for backwards compatibility): Sounds good. > By the way, just because collapsible checkboxes are hard to implement > in Swing, maybe we should have just a list of categories in the first > dialog, and open another dialog with a list of rules in the category > chosen? I'm not sure... it sounds like a lot of clicking and several small usbility issues that need to be addressed. But I cannot offer anything better for now, I'm afraid. Regards Daniel -- http://www.danielnaber.de -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Languagetool-devel mailing list Languagetool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/languagetool-devel
[Languagetool] Configuration redesign
Hi all, we need to slightly change the design of our configuration files because they do not store the disabled and enabled rules per language. As soon as we enable country variants, the problem will get more severe. I propose the following scheme (for backwards compatibility): * "disabled" / "enabled" property will be defined for all languages, but no longer used when saving * "disabled" + short language code - rules disabled / enabled per language, for example: disabled.en = HUNSPELL_RULE * "disabled" + short language code + _ + country variant - per language and country variant, for example: disabled.en_US = HUNSPELL_RULE this way you could have: enabled.en_UK = HUNSPELL_RULE Now, we need also options for rules. Even if options are basically key-value pairs, they are defined per rule, which might be configured differently for a language (and even for a language variant). This introduces a lot of complexity, which is inevitable, I guess, because you might want to use different rules in British and American English. We could have the following scheme: options = HUNSPELL_RULE.en_US.checknumbers.false, HUNSPELL_RULE.pl.nosuggestions.true The rule will get the key-value pairs ("checknumbers" = false) to be parsed. We should have a way to define value types in the rules themselves. I think we might have: - boolean for checkboxes - int for level-style settings (sliders?) - for example, severity of the error to be found - String (input box) for anything else? There would be a "Configure" button to the right of the rule name in the Configure dialog. There could be also another button "More..." that opens a link for rules with URLs defined. By the way, just because collapsible checkboxes are hard to implement in Swing, maybe we should have just a list of categories in the first dialog, and open another dialog with a list of rules in the category chosen? All answers and suggestions will be appreciated! Regards, Marcin -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Languagetool-devel mailing list Languagetool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/languagetool-devel