User talk:Rominet

FFGo screenshots category

I have created a category, Category:FFGo screenshots, for screenshots of the FFGo FlightGear front-end.

I am not fully sure, but I think you will find it when you start typing "FFGo" in the category field when you upload more screenshots.

—Johan G (Talk | contribs) 19:35, 30 January 2016 (EST)

Hello Johan G,

Thank you for making this a bit tidier. I'll use the new category in the future. I would also be willing to remove obsolete screenshots (for instance, http://wiki.flightgear.org/File:Tools-menu.png has been superseded by http://wiki.flightgear.org/File:Tools-menu_1.9.0.png), but I am not sure it is feasible because of the wiki history. And I now realize (with these URLs) that the file names don't belong to any particular namespace inside the FG wiki, therefore I suppose I should prefix them with FFGo_ or something like that next time...

--Rominet (talk) 05:33, 31 January 2016 (EST)

The older files may make sense if someone uses an older version. Also, at some point in the future (or even now) it might be interesting to look back at how things looked a couple of years back.

More descriptive file names is never wrong. ;-)

—Johan G (Talk | contribs) 10:59, 31 January 2016 (EST)

Historians... I doubt someone is going to dig through wiki history just for that, but anyway. If uploading too many images is a problem one day (not what you said), I expect some wiki admin to tell me so we can discuss how to handle that. Concerning the other point, yes, I'll prepend FFGo_ or even FFGo_<version>_ to file names in future uploads. It's a bit cumbersome of course, but I really don't like the unqualified names in the global wiki context.

Thanks.

­­—Rominet (talk) 04:23, 1 February 2016 (EST)

Tip: User subpages

I noted that you use your userpage a bit like a draft for something you are working on. It is entirely ok, but if you want to have several drafts going on at once you could add them as subpages to your user page.

To add a subpage to your user page, add a wikilink to your userpage with a slash and the title of the subpage like this, [[User:Rominet/Article title]], then click on the red link to start editing the new subpage.

When you are ready to make the page available, move it to the main article namespace. (Though keep in mind that perfection is the enemy of productivity. ;-)

—Johan G (Talk | contribs) 07:56, 15 April 2019 (EDT)

Hello Johan_G,

Thank you for the suggestion. Indeed, I'd have adopted it if I had known this was possible beforehand. The intent is to move the material (or part of it) to the main article namespace, but I don't have the time for this right now (I'd need to check the already existing material on the destination page and update it where it is outdated, which adds to the required time). Besides, Torsten very recently mentioned mirrors of the FG repositories on GitLab which I wasn't aware of, and the one for FGData might offer a simpler solution for users who just need read-only access...

--Rominet (talk) 10:38, 15 April 2019 (EDT)

Linking to article sections

Hi Rominet,

I noted this edit Add an anchor for the “Using pip (generic method)” section to the FFGo article.

Please do not add separate anchors to headings, the headings are anchors in themselves.

To link to a section from another article on the wiki use:

• [[FFGo#Using pip (generic method)]] (renders as FFGo#Using pip (generic method)), or
• [[FFGo#Using pip (generic method)|Installing FFGo using pip]] (Installing FFGo using pip)

And when linking from other websites use:

• <a href="http://wiki.flightgear.org/FFGo#Using_pip_.28generic_method.29">Installing FFGo with pip</a> (Installing FFGo with pip) (Copy the link from the table of contents in the article).

Sometimes you might want to link specifically to the current revision of the page (in case it will alter later). For those instances there is a link on the left sidebar, "Permanent link" (under "Tools"), that you can copy and when linking to the specific section open that link and copy the link from the table of contents.

—Johan G (Talk | contribs) 16:15, 25 November 2019 (EST)

Hi Johan G,

Thanks for caring and taking the time to write all this, I won't re-add the id, but am not very happy with the change. In my opinion, such explicitly-declared ids/anchors are much better than automatically-created anchors based on the title, because the title can change for various reasons (wording, spelling...) and this would break links using automatic anchors. In fact, your edit broke a link I had just made on GitHub. I had to edit my comment there to fix the link.

When I declare an id for reference purposes, I carefully choose its name and never change it. This is like using \label in LaTeX. Automatic anchors sound stupid to me because 1) one can legitimately want to change a title without breaking all cross-references to it, and 2) one can very well have the exact same titles in different parts of the same page (e.g., two subtitles in different sections), and even if they get different automatic anchors (not even sure this is the case), relying on them is bound to be utterly fragile. For instance, imagine you have two sections Linux and macOS and a subsection Installation inside each of these. You rely on automatic anchors, so you have, in the best case, automatic anchors "Installation1" and "Installation2". Links to "Installation2" are for MacOS. At some later point, the page is modified and we insert section Windows between Linux and macOS. The automatic anchor "Installation2" now corresponds to the installation subsection for Windows. All existing links to the installation subsection for macOS are now broken. With explicit ids, this kind of breakage can't happen.

--Rominet (talk) 16:48, 25 November 2019 (EST)

I understand your problem. The risk of broken links, for example due to renamed (moved) articles and headings, is why on the forum I more or less always supplement links to the wiki with permanent links. If the regular link is broken, very likely the permanent link would not be. Unless you really do not want to refer to the article as it was written when you linked to it it might be a good idea to also have a permalink. For better or worse a wiki will typically have ever-changing content. It is one of their weaknesses, but also their strengths.

PS. Notifications does not work like that on a MediaWiki wiki. Typically only edits to someones discussion page will trigger a notification (for example wanting asking me on my discussion page to have a look here). I have not done that, but one can also change the preferences so that one get an email if there is changes in either ones discussion page or when pages on ones watchlist are changed.

—Johan G (Talk | contribs) 18:55, 25 November 2019 (EST)

Okay, thanks for the infos. I could probably have used a permalink, yeah. Too bad for the lack of notifications when a username is mentioned. I used them on wikiversity.org and they were handy. I'm a bit puzzled because the feature is mentioned here, which appears to be about MediaWiki (the specific place I'm referring to is where it reads “To mention another editor and trigger this notification for them, you need to (...)”).

--Rominet (talk) 04:08, 26 November 2019 (EST)

Ah. I think the reason we do not have that feature here yet (for a while?) is that the FlightGear wiki is running an old version of MediaWiki (see Special:Version#Installed software for this wiki versus the same for the MediaWiki Wiki, and MediaWiki version history to see just how old our one is in comparison).

—Johan G (Talk | contribs) 14:49, 28 November 2019 (EST)

Indeed, it's a bit oldish. Also, the lack of HTTPS support is not fantastic due to the facts that 1) the server receives credentials when one logs in and 2) the wiki provides a lot of links to repositories and upstream websites (AFAIK, doing a MITM attack on an HTTP connection is much easier with HTTP than with HTTPS). Not than I'm a fan of HTTPS, but that's essentially all we have for (relatively) safe browsing nowadays...

--Rominet (talk) 17:24, 28 November 2019 (EST)