Enrico Forestieri wrote: > > I don't think we should setup our own rules, but do what most other > > applications do. Since the rules are surprisingly coherent in the HIGs I > > consulted, so I do not see a reason why we should diverge from that. > > Fine. However, I would take them as guidelines rather than strict rules.
I'd take them as standards, as the usual way applications on a given platform are designed. As long as no urgent reason is opposed to it, I'd like to conform to the given Standards. Currently, we do not do that. The style is simply a mess that does not show any standardness or coherence. So I think it's not a bad idea to be a bit more strict. > Indeed, it seems that you take them as such, too, because you use "AlignAt" > and "MultLine", as an example, instead of "Alignat" and "Multline". > Or is that also accounted for in some HIG? No, the HIGs do not regulate that, AFAICS. This is accounted to the status quo. The current menu already has Item "Aligned Environment|l" [...] Item "AlignedAt Environment|v" [...] I think the CamelCasing makes sense here, because AlignedAt is two words and Alignedat is more difficult to parse (as is alignedat). But I agree it is not very nice. An alternative would be something like AMS Multiline Environment AMS Aligned-at Environment etc. > In general, I would avoid > capitalizing command and environment names. The chapter example you > give is another case, as "chapter" is also an english word. and Chapter*? And Addchap? > Moreover, I don't see that much coherence between HIGs. For example, some > of the most used softwares (M$ ones, cough... cough...) use sentence casing > in menus. I did not mention the MS HIG anywhere, I just stated that the three HIGs I consulted were surprisingly coherent. Anyway, we can as well decide to follow the Windows User Experience Interaction Guidelines. As long as we follow _any_ Standard. Jürgen
