Difference between revisions of "User talk:Kai Burghardt"

From Free Pascal wiki
m (Undo revision 136505 by FTurtle (talk): (unfortunately) unwelcome change; please don’t alter people’s statements (especially if they’ve signed it with their signature))
(Tag: Undo)
(Syntaxhighlight templates: new section)
Line 104: Line 104:
  
 
: Yeah, [[User:Jonas|Jonas]] has already [[Special:Diff/121352|changed it appropriately]]. [[User:Kai Burghardt|Kai Burghardt]] ([[User talk:Kai Burghardt|talk]]) 15:51, 27 November 2018 (CET)
 
: Yeah, [[User:Jonas|Jonas]] has already [[Special:Diff/121352|changed it appropriately]]. [[User:Kai Burghardt|Kai Burghardt]] ([[User talk:Kai Burghardt|talk]]) 15:51, 27 November 2018 (CET)
 +
 +
== Syntaxhighlight templates ==
 +
 +
Hi, this is Paul Robinson, User Rfc1394, responding to your comment on my talk page.
 +
 +
I'll explain what I am doing, why I understand your concerns, how your comment allowed me to understand a problem in what I was doing (and how to fix it), and more importantly why I am doing this. I know what I am saying here is a bit long, but I want you to be able to see the big picture.
 +
 +
I have been a longtime user of both the Pascal language and Free Pascal, going back more than 40 and 20 years, respectively. I will be 60 years old next month and have been progarmming since I was 16. I found one of the bugs - and the exact line in the code - in the DOS installer for Free Pascal back before there was a 32-bit windows version. As such I want to see the available documentation kept up to date and improved as needed. Currently, to mark an inline piece of code as being in Pascal, one has to either use the Wiki add-on <nowiki><syntaxhighlight></nowiki> or do what I did, examine the page source and determine what HTML this translates into. Now, for multi-line examples this is reasonable as the '''<nowiki><syntaxhighlight></nowiki>''' add-in does a lot of work. But, for small items, like one or a few characters the coding on the page can be so heavy the page becomes unreadable. My endeavor was to make the underlying wiki pages more readable so changes are easy to do. If the page is a huge mess of coding, people might decide it's too much trouble and stay away. Thus losing a potentially valuable resource from someone who might have been able to improve things.
 +
 +
I am also a veteran Wikipedia editor with [https://en.wikipedia.org/wiki/User:Rfc1394 over 11,000 edits on over 6,000 pages]. I have even been granted the special "template editor" privilege to be permitted to edit protected templates on Wikipedia. I have written very complicated templates and am relatively familiar with how they work. One big reason for using templates is to make things easier to read, or to use.
 +
 +
Consider the following sentence:
 +
:The three comparison operators are < = > which can also be combined as <=, >=, <> and ><, depending on what is to be compared.
 +
If we want that to appear as Pascal format, so it looks like this:
 +
: The three comparison operators are {{HL|1=< = >}} which can also be combined as {{HL|1=<=}}, {{HL|1=>=}}, {{HL|<>}} and {{HL|><}}, depending on what is to be compared.
 +
Now, this is how it would have to be done originally:
 +
: The three comparison operators are <syntaxhighlight lang="pascal" enclose="none">< = ></syntaxhighlight> which can also be combined as <syntaxhighlight lang="pascal" inline><=</syntaxhighlight>, <syntaxhighlight lang="pascal" enclose="none">>=</syntaxhighlight>, <syntaxhighlight lang="pascal" enclose="none"><></syntaxhighlight> and <syntaxhighlight lang="pascal" enclose="none">><</syntaxhighlight>, depending on what is to be compared.
 +
Notice these look identical. But, internally, this is what the first one looks like:
 +
:<nowiki>: The three comparison operators are {{HL|1=< = >}} which can also be combined as {{HL|1=<=}}, {{HL|1=>=}}, {{HL|<>}} and {{HL|><}}, depending on what is to be compared.</nowiki>
 +
And this is what the second one looks like:
 +
:<nowiki>: The three comparison operators are <syntaxhighlight lang="pascal" enclose="none">< = ></syntaxhighlight> which can also be combined as <syntaxhighlight lang="pascal" inline><=</syntaxhighlight>, <syntaxhighlight lang="pascal" enclose="none">>=</syntaxhighlight>, <syntaxhighlight lang="pascal" enclose="none"><></syntaxhighlight> and <syntaxhighlight lang="pascal" enclose="none">><</syntaxhighlight>, depending on what is to be compared.</nowiki>
 +
Which of these would ''you'' want to have to edit?
 +
 +
If you had looked at the templates for [[Template:HL]], [[Template HLD]] or [[Template:HLC]] I have a note explaining that they replace the '''<nowiki><syntaxhighlight lang="pascal" enclose="none">, <syntaxhighlight lang="delphi" enclose="none"></nowiki>''' and '''<nowiki><syntaxhighlight lang="C" enclose="none"></nowiki>''' constructs, respectively. But, whoever wrote the '''<nowiki><syntaxhighlight></nowiki>''' add-in, did not consider it might be used inside a template and thus it does not support template parameters. This is why my template generates the direct HTML instead of using the '''<nowiki><syntaxhighlight></nowiki>''' add-in.
 +
 +
Now, as for the erroneous display of {{HL|{$mode ISO}|}} as {{HL|{$mode ISO}}} I admit, was a (small) mistake on my part. I have vision problems, and normally work in High Contrast Mode (Windows LEFT ALT-SHIFT-PRINT SCREEN key), and I sometimes miss small details. I didn't see it miss-rendering the item, because, frankly, I rarely have handled text containing } and had I seen it I would have fixed it. The correct fix is to use <nowiki>{{HL|{$mode ISO}|}}</nowiki> using an extra '''|''' after the parameter to signify the end of the parameter before the close of the template. I will try to fix it if I can find the page where it was. Frankly, I see the use of the template as easier to use and easier to read than either of '''<nowiki><syntaxhighlight lang="pascal" enclose="none"></nowiki>''' or '''<nowiki> <syntaxhighlight lang="pascal" inline></nowiki>''' (both of which do the same thing). I think what I will do is try to post a bug report to Wikimedia for the <nowiki><syntaxhighlight></nowiki> addin to inform the Wikimedia people and perhaps the developer that their <nowiki><syntaxhighlight></nowiki>  add-in does not handle template parameters correctly (or at all).
 +
 +
The whole idea here is to get the computer to do the hard work of formatting so people can do their creative work. I really don't see why using the long form as I have shown above makes things better or easier than the macro does, despite the two faults it has (the other fault I discovered was you can't have an = in a parameter to the template either, you have to code 1= before a parameter containing an = sign.
 +
 +
Still, if you can think of a good reason why using the longer and more complex '''<nowiki><syntaxhighlight></nowiki>''' code mode over a simple and shorter '''<nowiki>{{HL|</nowiki>''' template makes more sense, please feel free to explain. What I do doesn't stop someone from using the old method, any more than having '''{ '''stops someone from using '''(*''' for a Pascal comment.
 +
 +
I don't see where a couple of minor and correctable errors - especially since I know about them - detract from (what I see as) the vast improvement in readability and maintainability with this new method. I would prefer to be able to use the wiki code method over HTML inside of the template but until it supports template parameters I have to use that method. But I appreciate your concerns.
 +
 +
Thank you for reading,<br />
 +
Paul <br />
 +
[[User:Rfc1394|Rfc1394]] ([[User talk:Rfc1394|talk]]) 00:07, 19 October 2020 (CEST)

Revision as of 00:07, 19 October 2020

Heading levels

G'day. I reverted your demotion of the heading levels in my Accessing FreeBSD System Information‎‎ article. The first heading level should start at 1, not at 2. Starting at 2 unnecessarily removes the possibility of using a heading level in the future. Trev (talk) 05:25, 15 May 2020 (CEST)

I disagree, level 1 headings are page name level, it is not recommended and doesn’t make sense. You do want to put the contents hierarchically below the page name. Kai Burghardt (talk) 00:58, 16 May 2020 (CEST)
I've run into cases where there are insufficient levels of heading and so retaining level 1 headings makes sense. There is a vast difference between "not recommended" and "not allowed". MediaWiki allows it. Admittedly this is unlikely to occur for the page in question but, after 36 years in the law publishing industry as editor, writer, programmer and SGML publishing system creator, I like consistency. Trev (talk) 02:03, 16 May 2020 (CEST)
Well, then MediaWiki’s the wrong tool for writing highly structured articles. It’s just, even in publishing you won’t see in magazines multiple top-level-headings belonging to the same article/story.
Also, using h1-headings for sub-sectioning articles will prevent creating properly organized anthologies, like books or collections, by transcluding other pages. E.g. one could create a one-page article transcluding all pages of Tao Yue’s introduction to Object Pascal, but only as long as there are no confusing level-1 headings in their source codes.
We can always create more articles though. If an article needs more sectioning levels, it’s probably already too long and muddled, some contents need to be outsourced into dedicated pages.
And speaking of consistency: I think it’s probably the best to stick to the conventions used in major MediaWikis, such as WikiPedia. I’d like to welcome new editors here, who’ve already familiarized with the rules there. It’s already a terrible idea we’re sticking to those “translation templates” just to maintain uniform categorization, cf. the discussion below, that’s already a strange quirk.
Kai Burghardt (talk) 05:14, 16 May 2020 (CEST)

About redirects and renamings

Hello! You moved pade Inc to Inc and Dec and made redirect from Dec. Please be more careful when do renamings and redirects. You need remember three things when going to do things like these.
That three things are:

  • Templates
  • Languages
  • Categories

Try click on this links and see language bar and categories:

Try click English, see language bar and categories again and try return to Russian via language bar.

I think that better is to return all as it was before. Link to page Inc and Dec may be added to "See also" of English version of Inc and Dec.

FTurtle (talk) 22:31, 26 May 2018 (CEST)

Err, I don't quite understand your problem. Yes, you can navigate from the Russian to English page covering the same topic. The other way around (navigating from the English to the Russian page) does not work, since there's no page Inc and Dec/ru (yet). So?
You wanna tell me that once created structures are set in stone, or what? No, that's definitely not the case. You do agree with me, that duplicate contents are bad, don't you? Especially such things as inc and dec that are implemented by the same compiler code.
In general, the whole wiki – its multi-language “support” – is poorly maintained. The whole thing with (language bar) templates is/was an approach from 2005, but MediaWiki has evolved since and does have (with proper extensions/configuration enabled) sophisticated multi-language support. If we only were using it, the issue would, well, not disappear, but shift to other areas.
Kai Burghardt (talk) 01:04, 27 May 2018 (CEST)

There is a big difference between wiki.lazarus.freepascal.org and wikipedia.org
For understand it just see the lists of active users.
The current system of navigation may be better or worse, but it is such as it is.
When you do something you should not break existing navigation.
If your changes broke something, you should fix it. The result after your intruding should be workable.
You should not say: "Later someone will come who knows Japanese, Chinese, Korean, etc. and fix pages in appropriate languages".
In case with Inc/Dec this principle will be met if to change redirections to simple links.

FTurtle (talk) 16:59, 29 May 2018 (CEST)

I have difficulties understanding you. What am I supposed to deduce from Special:ActiveUsers?
I didn't break anything. A #REDIRECT always shows “Redirected from <lemma>” in the top line, whereas your see-…-link does not,
  • resulting in a worse user experience (since it requires a deliberate action [clicking/following the link]),
  • appears as “link” in Special:WhatLinksHere/Inc and Dec (that's sub-optimal)
  • and last but not least does not (really) promote the change, that Inc and Dec should be merged in one page.
It de facto is not possible to propagate any change following your policy. Take Wikipedia: The contents of various language pages associated with one WikiData entity do differ, and sometimes there's only a unidirectional language-link available.
Since it is possible and the current workflow (though I don't like it), I can (or you) simply edit/create the templates Inc, Dec and Inc and Dec setting up proper #switch-statements. But it's bothersome, prone to mistakes, and there are better approaches as I mentioned earlier.
The situation is pretty … unsatisfactory. Kai Burghardt (talk) 16:44, 30 May 2018 (CEST)

 I have difficulties understanding you. What am I supposed to deduce from Special:ActiveUsers? 

I thought it is obvious. I meant the number of users who can maintain orderliness in wiki. There are only few such people here.
wiki.org have much more people for every separate language then we have on whole our wiki. Thus, in particular, names of pages in our wiki should not be translated. And so on.

 I didn't break anything. A #REDIRECT always shows “Redirected from <lemma>” in the top line, whereas your see-…-link does not,

The behaviour should be predictable. If I open some page and see language menu, I estimate that I will change only language and after click I will see the same language menu.

 resulting in a worse user experience (since it requires a deliberate action [clicking/following the link]),

If I need other article, the clicking or not clicking will my own decision. I will know that I will open other page. Moreover, the English hierarhy is main. For example, I see "Inc" and want see how many translations it has. And what I will see? I will see single "Inc ad Dec". Why? I want see language menu for "Inc" and see pages in other languaages. Do you really think it is "nothing was broken"?

 and last but not least does not (really) promote the change, that Inc and Dec should be merged in one page.

Current state with links is suitable. May be it is not ideal but it suitable and not breaks navigation.

 It de facto is not possible to propagate any change following your policy.

I'm not agree.

 Take Wikipedia: The contents of various language pages associated with one WikiData entity do differ, and sometimes there's only a unidirectional language-link available. 
   Since it is possible and the current workflow (though I don't like it), I can (or you) simply edit/create the templates Inc, Dec and Inc and Dec setting up proper #switch-statements. But it's bothersome, prone to mistakes, and there are better approaches as I mentioned earlier. 

I think in our conditions the optimal way is keep same article in different languages with the same name (with language suffix) and language menu should used only for switch between these pages. Other pages on similar theme should form other family of pages. Redirects should be used in minimum necessary quantity but not more than. Mainly for saving workable links from outside after renaming of pages. It is my opinion. I did not invent anything new, I just came up with several ways how to better support the order that was adopted before me, but was very poorly maintained. In particular, you can see Template:Inc. Such templates are optimised for maintaining all languages by single person with knowing single language: English. You need once create single template for family of pages and forget about languages and categorues for all new pages with different languages. (There is some delay in updating information after creating new pages, but it is not a big problem)

 The situation is pretty … unsatisfactory.

At least it is much better than it was in 2014.

FTurtle (talk) 19:26, 30 May 2018 (CEST)

About language

Hi Kai,
Regarding the dynamic array pages. I made the classic mistake to write "who's" when in fact I meant "whose". The latter would have been OK according to https://dictionary.cambridge.org/grammar/british-grammar/question-words/whose
Anyhow you refrased the whole sentence now.
B.t.w. I'm not "persuing" you, I just tend to read the "recent changes" page and try to contribute (or discuss). --Bart (talk) 15:00, 27 November 2018 (CET)

Yeah, Jonas has already changed it appropriately. Kai Burghardt (talk) 15:51, 27 November 2018 (CET)

Syntaxhighlight templates

Hi, this is Paul Robinson, User Rfc1394, responding to your comment on my talk page.

I'll explain what I am doing, why I understand your concerns, how your comment allowed me to understand a problem in what I was doing (and how to fix it), and more importantly why I am doing this. I know what I am saying here is a bit long, but I want you to be able to see the big picture.

I have been a longtime user of both the Pascal language and Free Pascal, going back more than 40 and 20 years, respectively. I will be 60 years old next month and have been progarmming since I was 16. I found one of the bugs - and the exact line in the code - in the DOS installer for Free Pascal back before there was a 32-bit windows version. As such I want to see the available documentation kept up to date and improved as needed. Currently, to mark an inline piece of code as being in Pascal, one has to either use the Wiki add-on <syntaxhighlight> or do what I did, examine the page source and determine what HTML this translates into. Now, for multi-line examples this is reasonable as the <syntaxhighlight> add-in does a lot of work. But, for small items, like one or a few characters the coding on the page can be so heavy the page becomes unreadable. My endeavor was to make the underlying wiki pages more readable so changes are easy to do. If the page is a huge mess of coding, people might decide it's too much trouble and stay away. Thus losing a potentially valuable resource from someone who might have been able to improve things.

I am also a veteran Wikipedia editor with over 11,000 edits on over 6,000 pages. I have even been granted the special "template editor" privilege to be permitted to edit protected templates on Wikipedia. I have written very complicated templates and am relatively familiar with how they work. One big reason for using templates is to make things easier to read, or to use.

Consider the following sentence:

The three comparison operators are < = > which can also be combined as <=, >=, <> and ><, depending on what is to be compared.

If we want that to appear as Pascal format, so it looks like this:

The three comparison operators are < = > which can also be combined as <=, >=, <> and ><, depending on what is to be compared.

Now, this is how it would have to be done originally:

The three comparison operators are < = > which can also be combined as <=, >=, <> and ><, depending on what is to be compared.

Notice these look identical. But, internally, this is what the first one looks like:

: The three comparison operators are {{HL|1=< = >}} which can also be combined as {{HL|1=<=}}, {{HL|1=>=}}, {{HL|<>}} and {{HL|><}}, depending on what is to be compared.

And this is what the second one looks like:

: The three comparison operators are <syntaxhighlight lang="pascal" enclose="none">< = ></syntaxhighlight> which can also be combined as <syntaxhighlight lang="pascal" inline><=</syntaxhighlight>, <syntaxhighlight lang="pascal" enclose="none">>=</syntaxhighlight>, <syntaxhighlight lang="pascal" enclose="none"><></syntaxhighlight> and <syntaxhighlight lang="pascal" enclose="none">><</syntaxhighlight>, depending on what is to be compared.

Which of these would you want to have to edit?

If you had looked at the templates for Template:HL, Template HLD or Template:HLC I have a note explaining that they replace the <syntaxhighlight lang="pascal" enclose="none">, <syntaxhighlight lang="delphi" enclose="none"> and <syntaxhighlight lang="C" enclose="none"> constructs, respectively. But, whoever wrote the <syntaxhighlight> add-in, did not consider it might be used inside a template and thus it does not support template parameters. This is why my template generates the direct HTML instead of using the <syntaxhighlight> add-in.

Now, as for the erroneous display of {$mode ISO} as {$mode ISO} I admit, was a (small) mistake on my part. I have vision problems, and normally work in High Contrast Mode (Windows LEFT ALT-SHIFT-PRINT SCREEN key), and I sometimes miss small details. I didn't see it miss-rendering the item, because, frankly, I rarely have handled text containing } and had I seen it I would have fixed it. The correct fix is to use {{HL|{$mode ISO}|}} using an extra | after the parameter to signify the end of the parameter before the close of the template. I will try to fix it if I can find the page where it was. Frankly, I see the use of the template as easier to use and easier to read than either of <syntaxhighlight lang="pascal" enclose="none"> or <syntaxhighlight lang="pascal" inline> (both of which do the same thing). I think what I will do is try to post a bug report to Wikimedia for the <syntaxhighlight> addin to inform the Wikimedia people and perhaps the developer that their <syntaxhighlight> add-in does not handle template parameters correctly (or at all).

The whole idea here is to get the computer to do the hard work of formatting so people can do their creative work. I really don't see why using the long form as I have shown above makes things better or easier than the macro does, despite the two faults it has (the other fault I discovered was you can't have an = in a parameter to the template either, you have to code 1= before a parameter containing an = sign.

Still, if you can think of a good reason why using the longer and more complex <syntaxhighlight> code mode over a simple and shorter {{HL| template makes more sense, please feel free to explain. What I do doesn't stop someone from using the old method, any more than having { stops someone from using (* for a Pascal comment.

I don't see where a couple of minor and correctable errors - especially since I know about them - detract from (what I see as) the vast improvement in readability and maintainability with this new method. I would prefer to be able to use the wiki code method over HTML inside of the template but until it supports template parameters I have to use that method. But I appreciate your concerns.

Thank you for reading,
Paul
Rfc1394 (talk) 00:07, 19 October 2020 (CEST)