Math and Nowiki
I see that you change <math> tags to <nowiki>, for example here: https://wiki.freecadweb.org/index.php?title=Sketcher_BSplineDecreaseKnotMultiplicity&diff=856101&oldid=854468 But this is not the intended usage. nowiki is typographically spoken verbatim. But math follow the myth typography guidelines (half spaces around operators, italic variables etc.). So math should be used for equations. nowiki only for text to be unformatted.
(For information, you can directly copy TeX code into <math> and this can be created even with Word or Libreoffice nowadays.)
- You are overlooking a very important issue. AFAIK nowhere in the wiki are math tags currently used. Incode is typically used instead. So what you are doing is introducing an inconsistency. IMO this should be avoided if in anyway possible.
- I don't understand your argument. The Wiki software we use provides the <math> tag for good reasons. That we don't already use it cannot be an argument. In contrary the opposite should be - it is time to use it now! For example we have a lot of pages where a proper formula would explain than long text. (Just imagine how one would write formulas like these.)
- And I don't understand why we should use a verbatim formatting for formulas. <incode> is intended is for programming code, which is indeed verbatim. But math is definitely not verbatim ;-). Please don't let us reinvent the wheel but use the available tools provided by MediaWiki.
- --uwestoehr (talk) 18:16, 22 February 2021 (UTC)
- I think you do understand. Let's not play a debating game. To ensure that the wiki is consistent it is important that editors follow the standard and examples set by previous editors. Introducing new features and tags that are not used by anybody else should be avoided. It is not about who knows best, it is about following a standard.
> I think you do understand. Let's not play a debating game.
No I do not understand you and you haven't told a concrete reason what problem you actually see or fear. And sorry, but I am not playing games, I debate and have valid arguments. Please don't debate by arguing the other should not debate.
> Introducing new features and tags that are not used by anybody else should be avoided.
So you tell me, "please stop any progress, we make a mistake for years. We cannot fix it, we must continue doing it wrong - consistently wrong." So again, what is a reasonable reason not to use a Wiki tag that is widely used for years in e.g. the Wikipedia and many other Wikis? And why should we continue to forbid users to write formulas? I cannot see any "bad" side effect. Please tell me. --uwestoehr (talk) 18:05, 23 February 2021 (UTC)
- How do you propose to make other editors aware of this 'standard' that they do not know? And if this is indeed progress then hundreds of pages will need to be fixed. And nobody is going to taken on that job anytime soon. So at the end of the day what you are doing is introducing an exception, an inconsistency. IMO this is not progress, for if there is one thing the wiki suffers from it is that: inconsistencies.
- "How do you propose to make other editors aware" -> We add it to WikiPages
- "then hundreds of pages will need to be fixed" -> No change is necessary. Over the time editors will use <math> when they think it is necessary or useful. Existing pages can stay as they are. I think that is the normal way progress is made. Take for example one from the C++ code of FC: std:unique_ptr was once a new pointer in C++ and we use a mixture of ui files using this pointer type and some with the old static pointer. Over the time the change is made - depending of the coder preferences and their time. The same with the Wiki. If an editor thinks <math> is a cool think for the page you wrote or maintain, use it, if not just do nothing. And last but not least, the Wikipedia does and did it the same way. --uwestoehr (talk) 14:41, 25 February 2021 (UTC)
You are correcting what you call typos in the Docnav of the Part WB pages. But the extra spaces you add actually create an inconsistency. Why not follow the existing system used within this WB? Command 'Part_TransformedCopy' results in 'TransformedCopy' in the Docnav. IMO there is nothing wrong with that system.
- Hi Roy, sorry, this was not clear to me. I was just wondering because in most of the WBs there is a space. However, I think I only added it for a few pages and I see you reverted it.--uwestoehr (talk) 22:10, 23 January 2021 (UTC)
Hi Uwe, I'm not sure if I'm handling this wiki talk thing correctly. I didn't find a quoting or answering mechanism. So we may better discuss this in the forum, where others can participate.
You wrote: User chrisb recently wrote: "The PartDesign patterns are not yet as optimized as their Draft counterparts. So for a bigger number of instances Draft array is currently the way to go." This is not the case since Draft array is designed to pattern everything, no matter if sketches or parts. The PartDesign pattern is only to pattern feature of a body. So as for all other PartDesign features, it is only working within a body and this works well. For future, user realthunder is working to extend that PartDesign can handle more than one body. However, for now the pattern feature is as powerful as it can be. You are definitely right, that the pattern feature is as powerful as it can be, but only from its concept. There are quite some forum posts where working on a model became unbearable, because computing times were too long. If you have hundreds of instances of non trivial features you have to do something else. This has nothing to do with realthunder's extensions. Draft array is much faster. I had added that section to the wiki after a corresponding forum discussion, so you may search the forum around the change date.
I know how PartDesign patterns work, and that they cannot be replaced without any further changes by Draft array. And reading my changes now, you are right that it can be read as if Draft array can be a simple replacement. I dare to say that it is possible in most if not all cases to use DraftArray together with booleans and avoid PartDesign patterns completely. So I propose to leave the hint to Draft array, and extend it with: This may require major changes to your model.