When ‘errorColors’ was added in LT 2.8, its purpose was to add colours to types of error (CHANGES.txt). At the time, LanguageTool Options did not have tabs for different types of error.
Now, to keep all rules on one tab and to use errorColors correctly is not possible. For example, I have a set of rules which I want on one tab (the rules have names such as Rule 1.1, Rule 1.2, …). Some of those rules are style rules, and I would like to use type=“style”, but I cannot do this.
Proposal for a new optional category attribute called ‘tab’ to let a rule writer specify the tab name on which a rule appears: <category id="BLAH" name="MyRules1" type="xxx" tab="My Tab">
If a category element does not contain a tab attribute, the LT GUI puts the rules on a tab that is specified in the LT code. (This is the current behaviour in LT.)
If a category element contains a tab attribute, the LT GUI uses the tab value to create a tab on LanguageTool Options and put all the category rules on that tab.
This change would benefit primarily those rule writers who add customized rules to LT.
Are there other better ways to let a rule writer keep all rules on one tab and also use errorColors? What are the possible problems if my proposal were implemented?
I think, we have to discus the concept of the attribute “type”. Till now I thought a category is connected to a specific type (default: “grammar”) and all rules inside belong also to this type. So from my point of view all categories could be sorted in two very different kind of rules:
Real grammatic errors
Hints to make something better.
Let me give an example: There is a rule that marks words that are repeated two times consecutive. Usually this is a real error. But there are also rules that marks a word that is repeated in the next sentences. This is a not a grammatic error. It gives the author just a hint that the text would be better if he uses a synonym.
My aim was, to split the categories in this both kind of rules. Till now I identified the IssueTypes “style”, “register”, and “typography” as candidates for the second kind of rule.
If there is mixture of different types of rules inside of one category and this is allowed by the basic concept, we have to do something else.
I don’t like the idea of add an extra attribute. I think we should keep it easy. If the rules can’t be split by concept, we should leave them together. In this case the third tab in the option panel should contain only the rules which values can set by a user (There is not enough room at the other tabs to put them there).
Yes, there is a mixture. For example, in English, refer to category id=“TYPOS”, which has type=“misspelling”, and which contains these rules:
id=“YOUR_S”, which has type=“typographical”
id=“A_KNOW_BUG”, which has type=“grammar”
I don’t think it makes sense to have a category where type=X, and then have a rule in that category where type=Y. All rules of type=Y should be in a category where type=Y. (Unless we want to think of one type of rule as a subset of another type of rule.)
My proposal is not related to where LT puts the LT rules.It is a proposal to let a rule writer other than LT developers specify one or more new tabs on which the rule writer’s rules will appear. It has no effect on the LT rules.
First and foremost, thank you for creating this layout.
I agree with this, but this issue should be solved by recategorizing rules in grammar.xml. This is also the easiest way to do it.
The same idea can be made by adding duplicated ITStypes that are not recognized by the tab splitting logic. This allows all existing ITS types to fit in the grammar tab. It is easy for coders that wish to do so and it does not add extra semantics to LT metalanguage.
None but it takes time. You are requesting unpaid development time for an idea that other people don’t share.
Not quite. First, I must find out if there are objections or if there are better ways to do what I want. If there are no objections, the implementation (if it occurs) is done in one of these ways:
I did not mention the bounty, because I prefer not to pay. But, there will be a bounty in 3 weeks if nobody objects by then. This delay gives time to other people to reply to this proposal. (Sometimes, people are on vacation, or busy on other projects.) @danielnaber, is 3 weeks a sufficient time to wait for objections?
I noticed on the website moments ago that the highlight coloring is inconsistent with the rule splitting done on the dialog box.
Won’t it make sense to add the same logic to highlight color selection, i.e. have typography and register suggestions highlighted in blue/purple.
@Mike_Unwalla , it is not a question of get payed for me.
I see a problem if every rule developer can create not only a category but also a separate tab on which it appears in the option panel. LT is a grammar and style checker as the homepage says. My attention was to sort the rules by this two kinds and make it easier for a user to find the rules he is interested in (especially the ones that are not active by default). If there appears N tabs with only one or two categories on it, it is not very helpful, I think.
But I understand that you have the problem with categories that can’t be sorted clearly in one of the both tabs. If I understand it right this are especially categories that mix rules of both kinds.
I got the idea to add a third tab (I call it temporarily “Others rules”). Inside the option dialog has to be proved if there categories, that mix rules of different types. This rules are added to this third tab. Could this be a solution for your issue?
I could implement such a solution, but at the moment I am working on the problem to decrease checking time of the LO extension. The next two weeks I am on holidays. So it will take a few weeks.
@tiagosantos, I don’t know, where the highlight colors are set. Are that the errorColors in the Configuration? I did not use it, because in the LO extension highlighting can’t be shown.
Hello @Fred.Kruse. I accept that. My proposal has no effect on the default LT behaviour.
No. My primary problem is that rules from some categories are on one tab and rules from other categories are on a different tab.
Thank you, but no. A simpler solution is for me to change the category types such that rules for all categories are on the same tab. But, that solution is not ideal. (It would be nice to keep the semantics of the type.)
In my initial post, I gave the example of a set of rules that must be in numeric sequence. Although I can correct that problem, here are some things that I cannot do, and which I would like to do:
For the projects that I work on, each project has a different company-specific style guide. I would like to organize my rules by project and see on the GUI extra tabs for those projects:
General | Grammar Rules | Style Rules | Project X | Project Y | Project Z
For a project, I might want to organize the rules thus:
Project X, Mandatory
Project X, Optional
The type of the category is not important. Some style rules and some grammar rules might be mandatory, but other style rules and grammar rules might be optional.
OK. Here is an addition to my proposal to prevent that. Let a category have an optional attribute tab=“xxx” only if the rules are external (the category has external=“yes”) (Tips and Tricks - LanguageTool Wiki). Thus, the rules in LT cannot be on a separately named tab.
I have seen on the online tool, but I guess the question stands for all, as a principle, since you have patched LibreOffice to accept differently coloured highlights from 6.2 onwards.
On the standalone-tool they are set in languagetool/languagetool-standalone/src/main/java/org/languagetool/gui/HighlightPainter.java which I suppose also stands for the online tool.
The main question is, should the default colors be change to fit the new tab categorization? This can be worked on each tool separately.
The default of the underline color is now differentiated to fit the new tab categorization. For the style like categories I choose a green color, but this can be easily changed, if the community it wants.