Xenharmonic Wiki talk:Conventions

List model

Can we talk about Xenharmonic Wiki:Conventions#Lists? Why is it discouraged to use standard Wikitext lists?? Can we have a vote or something? —Keenan Pepper (talk) 18:57, 30 September 2018 (UTC)

FREEZE used the truly standard list model. We should all trust FREEZE. PiotrGrochowski (talk) 19:00, 30 September 2018 (UTC)

I think FREEZE is simply wrong about this. It's just bullshit and has nothing to do with the wiki idea. (I hope you were just kidding, Piotr) --Xenwolf (talk) 19:06, 30 September 2018 (UTC)

Nope. The standard list model really is the most reliable. Ever heard of Internet Explorer 6? PiotrGrochowski (talk) 19:21, 30 September 2018 (UTC)

I literally don't understand this argument at all because the rendered Wikimedia page from a list with asterisks has exactly the form <ul><li>...</li><li>... So which one is used in the wikitext can't possibly have an effect on how it renders in IE6 or whatever. It's exactly the same once it's rendered and is only different when editing the source. —Keenan Pepper (talk) 14:42, 1 October 2018 (UTC)

Actually, due to several curses, not even IE8 can render the entire wiki. See https://i.imgur.com/QgCnKcX.png. I think it means "I don't like this webpage, leave me alone.". PiotrGrochowski (talk) 16:01, 1 October 2018 (UTC)

This proves nothing. Try to view normal Wikipedia pages (I just did) and you'll see the same effect. The problem seems to be caused by the https protocol that is not supported in IE before version 9 (just guessing). --Xenwolf (talk) 16:18, 1 October 2018 (UTC)

Absolutely yes (to Keenan): I love the "inoffical lists" and hate the <ul><li></li></ul> stuff. Why make it so complicated??? Wiki means fast. I don't see anythong faster than placing * at the beginning of the listed items. I'm not aware that this was being discussed somewhere. --Xenwolf (talk) 19:03, 30 September 2018 (UTC)

The "FREEZE" thing was just me and Tyler playing with this until we got it to work. We never intended for these conventions to become standardized, it was just the easiest way to parse. Mike Battaglia (talk) 19:36, 30 September 2018 (UTC)

In case it is relevant it is dead easy to turn lists in HTML format into wikitext using this online conversion tool [1] - it could also be useful if one wants to copy / paste a list one has already in that format into a wiki. Indeed it works pretty well for converting an entire page in html into wikitext - you need a bit of tidying up but it's a lot faster than doing the markup yourself.

The other way round, converting wikitext to html - they don't offer a conversion but don't need to - the wiki software does it for you, just use view source. Robertinventor (talk) 02:51, 2 October 2018 (UTC)

Informal poll

In favor of MediaWiki's built-in list feature (*,#) lists (4): User:Keenan Pepper, User:Xenwolf, User:Mike_Battaglia, User:Joemcmahon User:Robertinventor, User:ResonantFrequencies

In favor of HTML-style (<ul><li>...) lists (1): User:PiotrGrochowski

In favor of plaintext (•item<br>•...) lists (0):

In favor of defined ([[File:Listitem.png]]item<br>...) lists (0):

In favor of Template:List ({{List|item|...}}) lists (1): User:PiotrGrochowski

Should we imitate FREEZE artefacts?

In my opinion this would be contra-productive. Every wiki syntax aims to be as simple as possible and obvious also in the wiki text. You get the idea of markup's purpose easily. Ans it's easy to adapt for people new to the wiki ho to achieve a goal. It's normally not necessary to know HTML tags for editing wiki content. That's why lists should be created the wiki way (using * and #).
--Xenwolf (talk) 19:22, 30 September 2018 (UTC)

I will always make lists with the proper, canonical syntax. What languages do various users know? is my page, therefore it is very clean, using the standard list model. PiotrGrochowski (talk) 19:25, 30 September 2018 (UTC)

No, we should not imitate "FREEZE artefacts." FREEZE artefacts are just things that I screwed up. We should make it right. Mike Battaglia (talk) 20:20, 30 September 2018 (UTC)

As a wiki author (as in, I've _written_ one of these), thepoint of wiki syntax at all is to permit you to write pages quickly without having to actually write syntactically-valid HTML. If there was no utility to adding wiki markup, it wouldn't have been added at all, and we'd just be opening edit boxes to paste in HTML. Which we would all have to always get right. Which we mostly would not, and would then spend time dorking with instead of writing about tunings. Wiki list markup, which is implemented in this wiki, is there to allow you to concentrate on providing content. Insisting on working against the tool, i.e., the wiki, by forcing HTML markup is counterproductive because it doesn't need to be done, and doing it is slower to write, and harder to update. And updating is the point of using a wiki at all. FREEZE is not a standard. It was a programming shortcut; insisting that it's a reason to hardcode HTML smacks of "I want to do this so I'm finding a reason" not "there is no other way to do this so I've adopted this workaround". There is no need for a workaround. Use the tools. Unless the markup cannot be done with wiki markup, it should not be there. Joemcmahon (talk)

As I said, I'm not using some old fashioned, rusty wikispaces syntax. PiotrGrochowski (talk) 05:28, 1 October 2018 (UTC)

This is definitely not "some old-fashioned wikispaces syntax". It's used by lots of simplified markup languages also used by Markdown. On the contrary, most wiki engines use it, please have a look at wikimatrix.org. Maybe it's time to give in now, isn't it?
Best --Xenwolf (talk) 10:37, 1 October 2018 (UTC)

Except that while wikispaces was an educational simplified markup language, wikitext (the system used by MediaWiki) shouldn't be treated as one. I think FREEZE was right, it turned the childish wikispaces syntax into the proper wikitext syntax that probably didn't work in wikispaces.

Here are a few more reasons to use wiki text The wikitext requires fewer charactrs to type, is easier for a newbie to use, is easier to read on the page, and also - it always gives syntactically correct htrml. If everyone used the html then the pages would be full of syntactical errors as few have the eye for detail to type syntactically correct html free hand unless they compose it in an external html editor and import it into the wiki text, which rather defeats the purpose. If we add a visual editor then it will generate wikitext rather than html. If you want to write your lists as html - I suggest you then convert them to wikitext using an html to wikitext conversion tool. The mediawiki software will then convert them back to syntatctically correct html when the page is presented. Sometimes the html tags are useful, for instance div tags, for doing things that are not possible within wikitext. However the usual approach is to wrap up all the html details into templates as those are the least error prone. Tags are still used in wikitext in places, e.g. the <math> and <ref> tags and indeed the <nowiki> tag and extensions introduce new tags such as the <poem> if you install the Poem extension, also <sup> and <sub> are often used for simple mathematical expressions in place of the Latex formulae, to take some examples. But it's usually to do things you can't do in wikitext. It's not the most syntactically elegant of systems I know, but it's one people are familiar with from Wikipedia and wikis generally, and far easier for newbies to use correctly, because it's almost impossible to make syntactically incorrect wikitext except with misplaced tags. Robertinventor (talk) 13:54, 2 October 2018 (UTC)

Best explanation I read so far. :) --Xenwolf (talk) 15:00, 2 October 2018 (UTC)

I'm smart and don't need the wikispaces style lists. They're actually one of the biggest mistakes of the wikitext format in my opinion. Wikitext allows all list models listed in List model, by the way. PiotrGrochowski (talk) 15:19, 4 October 2018 (UTC)

What is the "Xenharmonic Wiki" Namespace for?

When do we use this instead of making a regular page? Mike Battaglia (talk) 19:41, 30 September 2018 (UTC)

It's for meta stuff that is not in the Help namespace. Pages that describe the project, pages that are not itself about microtonal or xenharmonic topics. Sometimes it's hard to decide if something is help-only or not. --Xenwolf (talk) 19:59, 30 September 2018 (UTC)

Should there be a convention for indicating original research

As far as I know, Xenharmonic Wiki is a place for original research and subjective opinion; though it still seems important to say who the author is, so that people looking through the article know it's subjective/original. In this case. It seems like it might interrupt the flow of the article or seem irrelevant if one always includes "(my name) thinks that XYZ might be good as ABC tuning".

It might be sufficient that in a wiki, anybody can contribute, so if someone thinks some original research is wrong, xe can fix it; however, I worry that preexisting information is less likely to be challenged because usually there is indeed a good reason for why it's there are already; and there's still no sense of a consensus, i.e. if 500 people agree with a bit of OR and 1 person thinks it's questionable, that one person can't tell if xe should defer to the 500 people's views or if xe should change it in case someone agrees with him. I guess that's what the talk page would be for.Awelotta (talk) 16:48, 17 March 2021 (UTC)

For what it's worth, my rule of thumb regarding my own original research has been to assume that others have likely made similar observations from their own investigations and experimentation. If it turns out that I'm really the one who discovered something, or that I actually invented a concept that wasn't around before, then by all means credit me for it's invention, but make sure to dig around looking to see if someone else invented the same concept independently before giving me sole credit. I don't know how useful this idea is, but I figure it doesn't hurt to try and play it on the safe side. --Aura (talk) 18:05, 17 March 2021 (UTC)

EDO vs. edo (and MOS vs. mos)

I've been discussing with some people on XA Discord about the use of EDO/edo/TET/ET/etc. on the Wiki. While it seems relevant to include the main variants in page intros, especially on popular pages like 19-EDO, I believe that a convention should be chosen for consistent usage across the Wiki. In that regard, "edo" appeared to be the best choice. While "EDO" is indeed quite common, "edo" has gained a lot of traction in the community over the past years, not only in naming tunings like 19edo, but also in creating new terminology, like edostep and edomapping. Choosing "edo" over "EDO" would be a case of anacronym, like laser and radar.

Since I am working on improving the page EDO and eventually other related pages, I'd like to know if that convention is reasonable. The reason I ask is because I noticed some recent changes on the wiki, notably setting 19edo as a redirection to 19-EDO with an edit sumamry mentioning arguments in favour of "EDO" over "edo". I am aware that this is an old debate, but I think choosing the most common spelling is the right direction. At the end of the day, the objective is only to have a consistent spelling on the Wiki, and after that anyone can use the spelling of their choice.

Similarly, I would suggest "mos" instead of "MOS" for common usage on the Wiki, while preserving the main variants in strategic places like page intros. The page TAMNAMS is an example of a case where "mos" is used both as a standalone word and within new terms like mosstep. Fredg999 (talk) 20:35, 4 July 2021 (UTC)

Here is a short extract of arguments (I already sent it to FloraC via PM) that may add to the discussion:

* the XenWiki is open to the public so it should be maximally readable
* some people prefer 123EDO which obfuscates the number boundary
* in 12345edo the number is also much harder to read than in 12345-EDO
* the 123 EDO convention leads to lots of confusing line breaks
* 123edo is easier to type, maybe only this caused the old convention
* 123abe, the val notation, is optical close to it, bad for skimming

Yes, changing a convention causes a lot of work. But why should the old
convention stay, is it really that helpful?

Yes, the 123-EDO rule will complicate typing: you need the shift key.
But isn't easy-to-read text always hard to write?

Now I think we should not forget about the format "%d-edo" (number+hyphen+edo) which I could also live with and which I'd prefer to the current convention "%dedo" (number+edo). The reason why I like the hyphenated version(s) is that the parts can be distinguished easily and line breaks in the middle don't look too bad (in comparison to "%d edo" or "%d EDO"). On the EDO page itself (section EDO #Adding EDOs), we have n-edo MOS and m-edo MOS which reads much easier than nedo MOS and medo MOS. I think a writing convention should benefit the reader first and the writer second. In any case, this should apply to texts intended for publication: they are aimed at as many readers as possible, and thus the writing effort is well spent. --Xenwolf (talk) 16:31, 12 July 2021 (UTC)

Those are interesting points indeed. I agree with you that the convention should benefit the reader first. In that spirit, readers are more likely to recognize the spelling if they have seen it used elsewhere frequently, such as in the titles or descriptions of the music they listen to.

By the way, I updated the EDO page today. I'm using "edo" and "[math]n[/math]edo" for now, where the variable [math]n[/math] is written using the math tag, which makes it stand out better. As for numbered edos, I use "12edo" for now, which I think is not that hard to read since digits are taller than lowercase letters, and having no spaces or hyphens prevents any line breaking from happening. In any case, I'm willing to change it later if we decide on another convention. Fredg999 (talk) 03:18, 13 July 2021 (UTC)

I think multiple formats can coexist, each one used when most appropriate. For example, I generally prefer "19edo", but "n-edo" is clearer than "nedo", as you've brought up. I don't see the problem with using a hyphen in some cases and not others. I think "[math]n[/math]edo" is a bit visually jarring, and not as clear as using the hyphen.

Beyond article titles, I don't think there's a particular need for standardization of formats, as long as it's clear. Different writers have different preferences, and may write things differently in different contexts. I'll also add that lowercasing "edo" or "mos" doesn't inherently erase their meanings as acronyms. User:SupahstarSaga 2021-07-18

Yeah, "19th" and "i-th" co-exist perfectly and this style is very common in math textbooks. FloraC (talk) 16:33, 18 July 2021 (UTC)

On readability (I realized this when I tried unifying the style in the page Prime EDO): if you read a larger text block, you'll notice how the capital style break the flow of text and results in worse readability. You know why small capitals are common in novels? It's to avoid capital letters so as to ease reading. FloraC (talk) 16:33, 18 July 2021 (UTC)

I'm starting to think "edo" and "n-edo" represent a good compromise, especially considering FloraC's argument. I'm also thinking of a compromise: presenting "EDO or edo" in that order on the EDO page to insist on the fact that it's an acronym, but choosing "edo" and "n-edo" as a convention for readability on the Wiki. That might seem contradictory, but it allows one to pass from the full term to the acronym to the anacronym more smoothly, from my point of view. Fredg999 (talk) 18:10, 19 July 2021 (UTC)

Math conventions

There are currently no real conventions for mathematical notation. Since a lot of math pages involve linear algebra, I propose the following:

Open up any introductory linear algebra textbook. Follow the notation that is used there.

In practice this means:

• Matrices are uppercase Roman letters: [math]M[/math].
• Vectors (whether column or row) are usually lowercase Roman letters: [math]u[/math].
• When there is potential confusion with scalars, they can be made boldface: [math]\mathbf{u}[/math], or get an arrow: [math]\overrightarrow{u}[/math].
• Inner product can be notated: [math]u^\mathsf{T}v[/math] or [math]\left\langle u,v \right\rangle[/math].
• The p-norm is: [math]\| u \|_p[/math], when no p is given, 2-norm is assumed.
• When writing a column vector inside text, just transpose it: [math]w =\begin{bmatrix} w_1 & w_2 & w_3 \end{bmatrix}^{\mathsf{T}}[/math].

The wiki has Mathjax support, use it!

EDIT: This also means getting rid of bra-ket notation, by the way. They are used to denote quantum states in complex Hilbert spaces. We are not doing quantum physics here so let's stop pretending.

- Sintel (talk) 20:00, 18 December 2021 (UTC)

2 or 3 digits

Giving two options for the number of digits isn't really useful if we want consistency... I just changed the 15edo#Commas table's values to 3 digits because I had checked 17edo#Commas and that table used 3 digits, but apparently that one was the exception, not the reverse? Would it make sense to use 3 digits everywhere? Of course it's not urgent, but I'd rather stick to one standard rather than two, so that at least when we're making decisions, they're not arbitrary or random. --Fredg999 (talk) 02:25, 7 July 2023 (UTC)

I would be in favour of using 3 digits everywhere. --BudjarnLambeth (talk) 02:38, 7 July 2023 (UTC)