FlightGear wiki:Village pump: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(→‎Needing an extra pair of eyes: Having a problem with automatic categorization in Template:Autoflight Navigation)
Line 79: Line 79:


:: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 06:00, 9 September 2020 (EDT)
:: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 06:00, 9 September 2020 (EDT)
== Needing an extra pair of eyes ==
There is n problem with automatic categorization in {{tl|Autoflight Navigation}} that I can not seem to solve.
For details see [[Template talk:Autoflight Navigation#Automatic categorization seem broken]].
—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 10:26, 10 September 2020 (EDT)

Revision as of 14:27, 10 September 2020


Archives
2012, 2013
2014, 2015
2016, 2017
2018, 2019

Shortcut
FGW:VP

Welcome to the Village Pump. This page is used to discuss the technical issues, operations and guidelines of the FlightGear wiki.

Please add new topics to the bottom of this page.

Old discussions should be moved to a FlightGear wiki:Village pump/Archive YEAR. These discussions can then be moved to a relevant talk page if appropriate.

New Portal: Embedded or Hardware (02/2020)

Suggestion: Dedicated portal for articles relating to embedded/hardware topics (which would be in line with numerous threads on the forum, as well as existing articles on the wiki). - Hooray (talk) 11:59, 17 February 2020 (EST)

That is slightly less complicated than you might think. What you would do is to create a new page with the prefix Portal: and a suitable name, say for example Portal:Hardware development, Portal:Cockpit hardware or Portal:DIY cockpit hardware, or maybe Portal:Hardware if you would also like to see commercial hardware there, and then copy and modify the content from a similar portal.
Hint: There is actually not a portal namespace, it is just a prefix. The portal pages are actually in the main namespaces, and thus function just like any other article page on the wiki.
Johan G (Talk | contribs) 13:35, 10 March 2020 (EDT)
Though I think your Portal:Embedded might be more diffuse than Portal:Hardware for people that do not know what embedded software This is a link to a Wikipedia article is, I have still added it to the main page and added Category:Portals to it. It will get more use if people can find it. :-P
Johan G (Talk | contribs) 04:16, 14 March 2020 (EDT)

Use as few categories as possible

Always use as few categories as possible. Categories are a place in a structure rather than tags. Putting each page in a lot of categories will put a lot of of pages in each category. There is in particular no need to put a page in both a category and then in each category above that category.

Please see advice in Help:Your first article#Categories and maybe also Help:categories.

Johan G (Talk | contribs) 13:04, 15 March 2020 (EDT)

Meta template and templates for commonly used logotypes and icons

Through a placeholder page (ugh!) and a edit summary Hooray suggested making a template for commonly used logotypes.

Cquote1.png placeholder/stub for all sorts of wiki related logos that may need to be updated over time, but that are referenced on multiple pages - so that we don't need to edit each and every page here.
Cquote2.png
Cquote1.png @Johan: could use your help with this, unless I can write the heuristics in Php or JavaScript ;-)
— Hooray, 11 April 2020‎, 08:04
Cquote2.png

I would guess you also intend it to be used for icons as well, for example the ready icons? Logotype/icon templates might not be a bad idea. Less typing is almost always good.

{{logo}} should probably be a meta template, a template used by other templates in this case by logotype templates. Meta templates are pretty common on MediaWiki wikis.

Essentially, there could be a set of logotype and icon templates, for example {{Compositor logo}}, {{FGInterface logo}}, {{Air refueling ready icon}} etc, that pass the image for the logotype, an alt text (for accessibility and when the image is not shown, for example due to browser settings) and a link to a relevant wiki page to {{logo}}. Possibly also optional parameters like other sizes etc. The meta template would then add the boilerplate stuff around that and set the size.

I would advise that having a suffix indicating the type of template, for example logo, icon like mentioned above or navigation (for navigation boxes), in essence having less ambiguous names, is generally a good idea.

I should mention that I am generally against placeholder pages.

Johan G (Talk | contribs) 06:44, 12 April 2020 (EDT)

UTF-8 language pages cannot be edited (cont. from 2015)

While migrating my own unrelated MediaWiki instance, I may have stumbled upon "a" SQL issue blocking the creation of pages with non-latin characters in their titles. See:

If someone has access to the MySQL backend (command line or phpMyAdmin), could you check what the "Collation" of our database is set to? For example:

USE dbname;
SELECT @@character_set_database, @@collation_database;

Or in phpMyAdmin the collation is given in the database listing. My guess is that we are not using UTF-8. That can be changed (after a backup) with:

ALTER DATABASE dbname CHARACTER SET utf8 COLLATE utf8_general_ci;

Or in phpMyAdmin, select the databse of this wiki, click on the "Operations" tab, in the "Collation" box select "utf8_general_ci", and finally click on "Go". Hopefully this is the cause of this long standing and painful issue.

Bugman (talk) 03:33, 9 September 2020 (EDT)

Hi Edward,
I somehow missed all these previous reports :-( Sorry!
You're right. The database is in latin1. We're actually currently in the process of migrating some of our server work and updating. I will take care of setting the correct collation on that occasion.
Gijs (talk) 04:24, 9 September 2020 (EDT)
Great, that sounds exactly like this problem. Only pages with 'latin1' characters in their names can be edited. I really hope switching the collation to UTF-8 will fix the problem. There must have been a MySQL server migration many years ago where the old database was UTF-8 and the import automatically changed the language to the server default of 'latin1', as many pages were created on this wiki with non-latin1 characters in the past. I see this with my MySQL database too - I have to switch back to UTF-8 after import into the new SQL database.
Bugman (talk) 06:00, 9 September 2020 (EDT)

Needing an extra pair of eyes

There is n problem with automatic categorization in {{Autoflight Navigation}} that I can not seem to solve.

For details see Template talk:Autoflight Navigation#Automatic categorization seem broken.

Johan G (Talk | contribs) 10:26, 10 September 2020 (EDT)