the language navbar, also, the language list

[Kuchigakatai]

I was having a quick look at the Dhekhnami page, when I noticed a link to its parent language Munkhâshi. Munkhâshi is not otherwise found in the navbar, so I would suggest adding it.

The navbar links to Uyseʔ and Lé are missing from most Ereláe pages (the exceptions being Verdurian and Barakhinei), and in non-Ereláe pages they're missing from the Western Family placeholder page. Also, both articles are missing the images at the beginning (Uytai.jpg and Be-map.jpg respectively).


Also, the Languages of Almea page, which is linked to from almost every page of the navbar, is several years out of date. I think it reflects the state of your conlangs circa 2008, when Old Skourene didn't have a grammar and Uyseʔ was still called Uytain.

[Raphael]

Bumping this thread just in case that zompist overlooked it.

[zompist]

Fixed the maps. I replaced the Languages page with a redirect to the more up-to-date Almeopedia page.

The navbar isn't touched for now, as it would require looking at a whole mess of pages. As it happens I expect to do that anyway, so I'll defer it till then.

[bradrn]

The navbar isn't touched for now, as it would require looking at a whole mess of pages. As it happens I expect to do that anyway, so I'll defer it till then.

I’m just wondering, how come you expect to do that anyway? Are you planning a big update to Virtual Verduria?

[Moose-tache]

The navbar isn't touched for now, as it would require looking at a whole mess of pages. As it happens I expect to do that anyway, so I'll defer it till then.

I’m just wondering, how come you expect to do that anyway? Are you planning a big update to Virtual Verduria?

He's researching his next book: "Mid-90s HTML And You." I'm excited about the chapter on frames.

[Kuchigakatai]

The navbar isn't touched for now, as it would require looking at a whole mess of pages. As it happens I expect to do that anyway, so I'll defer it till then.

I’m just wondering, how come you expect to do that anyway? Are you planning a big update to Virtual Verduria?

He's researching his next book: "Mid-90s HTML And You." I'm excited about the chapter on frames.

Let me go on a needless rant in this post. To be fair, even in 2019 there's no real adequate implementation of components. IMO in the HTML standard there should be an easy way of reusing components, precisely for things like navbars and footers which you only need one of, but there is not.

Frames were actually supposed to be something like that, but they suffered from 1) their default look with a fixed size and a vertical scrollbar when overflowing, 2) their default behaviour where it was easy to load other websites, and 3) the fact early web programmers abused them in terms of design by using them to load content, which made content difficult for users to bookmark and difficult for old search engines to traverse. Frames are not even part of the HTML standard now, although browsers retain some support for them for the sake of legacy websites. These problems could be fixed with a new HTML element that addresses problems #1 and #2 and by insisting, culturally, to avoid #3, but there's no intention of that so far.

Right now the recommendation is to either load HTML dynamically with Javascript AJAX (whether you use raw XMLHttpRequest objects, JQuery's load() function, or import() in Facebook's React) or use server-side rendering. Javascript has a garden variety of security issues so it continues to be a good idea to turn it off, which is why I consider it inadequate. Server-side rendering is a bit better, but needing to tweak Apache's Server-Side Includes while maintaining proper Linux file permissions (not possible if your server is on Windows) is not what I'd call "straightforward", and the other option of using an expensive webapp (in terms of server resources) in some language like PHP or Python is, well, expensive in terms of server resources (unless you're literally processing every single webpage served anyway, in which case there isn't much of an extra cost, but Zompist is not doing that).

[vegfarandi]

I’m just wondering, how come you expect to do that anyway? Are you planning a big update to Virtual Verduria?

He's researching his next book: "Mid-90s HTML And You." I'm excited about the chapter on frames.

Let me go on a needless rant in this post. To be fair, even in 2019 there's no real adequate implementation of components. IMO in the HTML standard there should be an easy way of reusing components, precisely for things like navbars and footers which you only need one of, but there is not.

Frames were actually supposed to be something like that, but they suffered from 1) their default look with a fixed size and a vertical scrollbar when overflowing, 2) their default behaviour where it was easy to load other websites, and 3) the fact early web programmers abused them in terms of design by using them to load content, which made content difficult for users to bookmark and difficult for old search engines to traverse. Frames are not even part of the HTML standard now, although browsers retain some support for them for the sake of legacy websites. These problems could be fixed with a new HTML element that addresses problems #1 and #2 and by insisting, culturally, to avoid #3, but there's no intention of that so far.

Right now the recommendation is to either load HTML dynamically with Javascript AJAX (whether you use raw XMLHttpRequest objects, JQuery's load() function, or import() in Facebook's React) or use server-side rendering. Javascript has a garden variety of security issues so it continues to be a good idea to turn it off, which is why I consider it inadequate. Server-side rendering is a bit better, but needing to tweak Apache's Server-Side Includes while maintaining proper Linux file permissions (not possible if your server is on Windows) is not what I'd call "straightforward", and the other option of using an expensive webapp (in terms of server resources) in some language like PHP or Python is, well, expensive in terms of server resources (unless you're literally processing every single webpage served anyway, in which case there isn't much of an extra cost, but Zompist is not doing that).

100% agree. It should be possible to do something like <nav link="navbar.html"></nav> which would load a page-external HTML fragment/partial. It's very frustrating that this has not been implemented a long time ago and that website makers have to constantly write new and new static CMSs just to do this. This is a very basic function of the web. I don't get it.

[alynnidalar]

That's why God invented frameworks.

[Kuchigakatai]

That's why God invented frameworks.

No, because frameworks just put an extra processing layer on the crap.

[kadmii]

Can't you just use jquery to import the navigation bar content in?

[Kuchigakatai]

Can't you just use jquery to import the navigation bar content in?

Yes, I mentioned that above in my reply to Moose-tache. Ideally you shouldn't need Javascript to do this though.

[Pabappa]

what's the site running, anyway? is it php? php is capable of embedding HTML files within other HTML files .... and can even make images from text in case you wanted to have a different text label within the image on each page.

[Ares Land]

100% agree. It should be possible to do something like <nav link="navbar.html"></nav> which would load a page-external HTML fragment/partial. It's very frustrating that this has not been implemented a long time ago and that website makers have to constantly write new and new static CMSs just to do this. This is a very basic function of the web. I don't get it.

Well, they're out of fashion these days, but you can still do server-side includes. (zompist.com is entirely static html).

Oh, but the reason server-side includes are out of fashion is because, I believe, you need to enable these in the main Apache conf, which most providers won't let you do.

Maybe people on this board should pool resources and buy proper virtual machines which we could administer as we see fit. (I'd love to put up a Mediawiki instance with the Visual Editor for instance but you can't do that with standard hosting...)

[Kuchigakatai]

Well, they're out of fashion these days, but you can still do server-side includes. (zompist.com is entirely static html).

Oh, but the reason server-side includes are out of fashion is because, I believe, you need to enable these in the main Apache conf, which most providers won't let you do.

I also mentioned SSIs and the need to configure Apache for them in my post, but it looks like I'm an unclear writer and nobody's reading it.

Maybe people on this board should pool resources and buy proper virtual machines which we could administer as we see fit. (I'd love to put up a Mediawiki instance with the Visual Editor for instance but you can't do that with standard hosting...)

Eh, I have access to a cheap server where I can edit Apache's configuration. I could probably get a MediaWiki instance with Visual Editor up online today if I wanted to. Why do you want it though? Is it because FrathWiki forces the CC-SA license on you, while KneeQuickie enforces CC-NC-SA?

[Ares Land]

I also mentioned SSIs and the need to configure Apache for them in my post, but it looks like I'm an unclear writer and nobody's reading it.

Ah, sorry! I read your post yesterday, I think, and I'd just forgotten the part about SSIs

Eh, I have access to a cheap server where I can edit Apache's configuration. I could probably get a MediaWiki instance with Visual Editor up online today if I wanted to. Why do you want it though? Is it because FrathWiki forces the CC-SA license on you, while KneeQuickie enforces CC-NC-SA?

No, I just like the Visual Editor -- you don't have to mess with wiki formatting. And creating a table is extremely intuitive (much more so than with any the other CMSs I tried) - great for a conlanger, since writing a grammar means tables. Lots of tables.

The thing is, it requires setting up a non-php service -- IIRC, it's a small Node.js app; but providers won't let you install Node.

[Kuchigakatai]

No, I just like the Visual Editor -- you don't have to mess with wiki formatting. And creating a table is extremely intuitive (much more so than with any the other CMSs I tried) - great for a conlanger, since writing a grammar means tables. Lots of tables.

Oh, so it's the editor that you want. Yeah, I guess neither FrathWiki nor KneeQuickie use Visual Editor. I agree that a conlanger needs to make lots of tables, or at least my conlang files definitely tend to be full of them, especially at the beginning. I'll try to get it done today. If I don't make it to the end today, I believe I'll do so by Sunday (pacific standard time!).

We can try to figure out the money stuff later...

The thing is, it requires setting up a non-php service -- IIRC, it's a small Node.js app; but providers won't let you install Node.

My provider is actually most friendly to programmers (as opposed to businesses, which have fancy and expensive needs, or people setting up simple webpages, who hardly have any needs), so it does allow Node.

[Ares Land]

Oh, that's awfully kind of you. Honestly I'm not sure I can accept. I've got more ideas than time, I'm afraid and I'd hate to see you work for nothing if I end up not using it much.

[Kuchigakatai]

what's the site running, anyway? is it php? php is capable of embedding HTML files within other HTML files .... and can even make images from text in case you wanted to have a different text label within the image on each page.

Yes, that's using SSI (server-side rendering). What I'm saying is that there could be a stupidly good solution for the problem (both easy for web people to write and fast for website visitors), but the HTML powers-to-be have never implemented it.

Oh, so it's the editor that you want. Yeah, I guess neither FrathWiki nor KneeQuickie use Visual Editor. I agree that a conlanger needs to make lots of tables, or at least my conlang files definitely tend to be full of them, especially at the beginning. I'll try to get it done today. If I don't make it to the end today, I believe I'll do so by Sunday (pacific standard time!).

Ah, if only... Life has unfortunately gotten in the way as I'm swamped with work, so I've only been able to work on the MediaWiki setup for a couple hours. I'm hoping I'll have time this coming Sunday to get it done.

[Ares Land]

Ah, if only... Life has unfortunately gotten in the way as I'm swamped with work, so I've only been able to work on the MediaWiki setup for a couple hours. I'm hoping I'll have time this coming Sunday to get it done.

That's very kind of you. In any case, I'm swamped with work as well, so there's really no reason to hurry.

[Kuchigakatai]

Hey Zompist, I was just thinking: all three of the Blink engine (used by Chrome/Edge/Opera), the WebKit engine (used by Safari), and the Gecko and Quantum engines (used by Firefox) still support the <iframe> element, and I'm sure they will still do so for a long time because it was so popular in the past, and, honestly, it's still used to a little extent. You could use that to render the language navbar from a single file in all pages, even though <iframe> is officially deprecated. As discussed above, this was its original intended use after all!

(The next reasonable alternative would be to allow server-side includes (<!-- #include virtual=" " -->) by fiddling with the configuration of your server, if you're allowed to do that, but iframes would work right away.)

Ah, if only... Life has unfortunately gotten in the way as I'm swamped with work, so I've only been able to work on the MediaWiki setup for a couple hours. I'm hoping I'll have time this coming Sunday to get it done.

Wed Oct 30, 2019 12:30 am

That's very kind of you. In any case, I'm swamped with work as well, so there's really no reason to hurry.

Ah, c'mon, dammit. Well, I couldn't get it done on that day either, and then as time passed it's been placed lower and lower in the priorities... Plus, you (Ars Lande) posted a couple weeks after that you were now using some other thing (the Akana wiki? I don't remember).