[00:07] <guiverc> :)
[00:58] <krytarik> https://git.launchpad.net/uwn?h=discourse - I just pushed what I got so far on the scripts to a WIP branch in the UWN repo.
[00:58] <guiverc> thank you krytarik !
[01:01] <krytarik> I'm pretty sure there will be more though due to the link mangling that Discourse does and which we've talked about earlier.
[01:01]  * guiverc is expecting that... 
[01:04] <Bashing-om> krytarik: ^ progress made - big step forward :D
[01:05] -SwissBot:#ubuntu-news- ::Fridge:: Ubuntu Weekly Newsletter Issue 776 @ https://fridge.ubuntu.com/2023/02/27/ubuntu-weekly-newsletter-issue-776/ (by guiverc)
[01:08] <krytarik> Technically we could do away with most of the bare URLs in the page anyway, which would have been possible on the wiki too, just that would be a problem for the mail.. but I'm starting to wonder if it was too inappropriate, in favor of better formatting, to just send a notice with the link via the mailing list instead of the whole thing which we used to do..
[01:09] <JackFrost> Do away with the URL bot you saw?  OK!
[01:09] <krytarik> Bashing-om: Well, most of that has been lingering about for a few weeks already, waiting for progress elsewhere!.. :P
[01:11] <krytarik> JackFrost: Your words confuse me a little.. I mean you just run your linter against whatever page anyway, no? >_<
[01:12] <JackFrost> krytarik: SwissBot. :P  But with regards to the wiki, yes I just `linkcheck wikiurl`
[01:13] <krytarik> I wouldn't call Swissy an URL bot though! XD
[01:23] <krytarik> aaronprisk[m]: Btw, would you be able to relay to the proper channels the issue that there is a double slash in every link from the Ubuntu blog feed (e.g.: https://ubuntu.com//blog/enabling-ubuntu-fips-140-in-air-gapped-environments) ?  I was hoping we weren't the only ones who notice this after their site reshuffle a while ago, but this doesn't seem to have turned out true.. >_<
[01:32] <krytarik> Anyway.. what I was going to detail here is, while the links under the individual summaries will have to stay bare, on all the links that occur in bullet-pointed lists the prefix text could just be used as the anchor text of the URL that follow it, possible prefixed with the site name to stay transparent on where the article comes from and the link leads to, like "[phoronix]" etc.
[01:34] <krytarik> This would make for way less text on the page and therefore make it much better readable.
[02:47] <aaronprisk[m]> <krytarik> "aaronprisk: Btw, would you be..." <- That is odd.. I will relay your findings. 
[02:48] <krytarik> Thanks!
[02:48]  * guiverc has no issues with ML post being just link to where posted... My preference is it being full/complete; but if that's problematic (too much hassle) I'm happy to just be reminder & link to where it's readable
[02:54] <krytarik> I mean when I sign up to a newsletter, I'd indeed expect and prefer the actual content by mail, but trying to keep it this way here would mean a) more hassle to keep it readable by mail or b) less nice look on the web page.
[02:55] <guiverc> ack & understood
[03:07] <krytarik> Or maybe I'm overthinking this a bit and markup-formatted links aren't that hard to read in plain text either.. like "[Ubuntu 22.04.2 LTS Released With Linux 5.19 HWE Stack Option](https://www.phoronix.com/news/Ubuntu-22.04.2-LTS-Released)" vs "Ubuntu 22.04.2 LTS Released With Linux 5.19 HWE Stack Option - https://www.phoronix.com/news/Ubuntu-22.04.2-LTS-Released".. maybe it's at least not ...
[03:07] <krytarik> ... bad enough to make us drop the complete newsletter by mail altogether.
[03:09] <guiverc> :)   As you're likley the one doing the work (coding), its ultimiately your decision as I see it krytarik   (my skill being in cobol/jcl & prehistoric stuff..)
[03:09] <krytarik> Well, except the first one as suggested would then be more like "[[phoronix] Ubuntu 22.04.2 LTS Released With Linux 5.19 HWE Stack Option]"
[03:13] <krytarik> I mean we could try and unfold the links from the lists, but things like "..please see: https://wiki.ubuntu.com/BugSquad" would end up like "..please see: [https://wiki.ubuntu.com/BugSquad](https://wiki.ubuntu.com/BugSquad)" too then.
[03:14] <krytarik> Same with the links under the individual summaries as mentioned.
[03:16] <guiverc> As I see it, once discourse is setup so we can post there, we continue as normal initially with gdoc setup for wiki posting, the current scripts are used & pasted as normal... except I take the final gdoc & massage it for pasting on discourse, noting what is changed ... we can then work on getting scripts right; and move to discourse only when we're convinced everything is looking good (then adjust our skeleton on gdoc so it matches 
[03:16] <guiverc> discourse not wiki)... My understanding of what we'll do, giving us time to decide what is best before discourse is used too.
[03:16] <krytarik> Oh, well I guess in these cases one could check if the anchor text is the same as the URL, and then just print the bare URL instead though.
[03:17] <krytarik> Yeah, that sounds about right.
[03:19] <guiverc> Bashing-om, ^ (my understanding; ie. gdoc is unaltered; all prep. during this 'transition' I'll do locally, though I could also create another gdoc so it's shared... locally allows easier `diff` type comparisons as for changes my reasoning for local..)
[03:23] <Bashing-om> guiverc: I presently see no alteration to our usage of Gdoc for prep - However, we play this transistion by ear and see what we need to change as we fly :D
[03:25] <krytarik> I think the only difference in the prep on the Google Doc will be the markup code, like "##" vs "==" and the outlined formatting for links.
[03:25] <krytarik> The latter of which isn't too hard to do in prep either.
[03:29] <Bashing-om> krytarik: Just take a bit longer to tranfer to the release medium. Not that big of a deal. Maybe faster to work from a "local" copy of Gdoc, for instance.
[03:33] <krytarik> Well, that's what I was afraid of too.. but if you think it through, then 1.) the links in the manually compiled lists are just formatted differently (like the example above), and 2.) the links under the summaries will need to be formatted accordingly too, and then 3.) the "##" vs "==" thing which is even more trivial.
[03:41] <Bashing-om> krytarik: Search and replace in a text editor will make short work of alterations of formats :D
[03:45] <krytarik> Why would you need to replace anything though when everybody starts out with using the new markup (for whatever issue that will be) to begin with?
[03:46] <Bashing-om> krytarik: Set up for both the WIKI and Discourse - yes ?
[03:49] <krytarik> No, the Google Doc will only ever be used for one of these formats.  Testing on Discourse is another story though, which will probably go as guiverc has envisioned.
[03:51] <krytarik> But if you look closely at the UWN repo, I did add a script that reformats a wiki page into a Discourse post.
[03:51] <krytarik> Which is meant to help in the testing.
[03:51] <Bashing-om> krytarik: Yeah - ^ I did notice :D
[03:56] <krytarik> And while I already added scripts for a potential Discourse workflow alongside the current ones, we will generally only follow one workflow or the other, rather than posting on both platforms simultanously on each issue.
[03:59]  * guiverc plans to give the new script a 'try' ; later though  (I'm yet to post 776 to fb which I'll do first... before i look ahead to next week etc..)
[04:06] <krytarik> guiverc: Btw, you may then notice that the images won't be carried over by the reformat script, but that will be solved once we got a template together that also includes the images as previously (this time I'd just link from the Fridge WP though rather than attach them manually and individually each time as until now on the wiki)
[04:08] <krytarik> Or if that's possible make one attachment on Discourse (per image, of course) and link that every time - which obviously would be better than linking from another platform.
[04:11] <guiverc> ack & thanks krytarik 
[04:15] <krytarik> But one thing I've noticed today to keep an eye on wrt images on Discourse is that it seems to do the Lightbox thing on all of them automatically..
[04:16] <krytarik> (Hover over an image there and you'll see at the bottom of it what I mean.)
[04:17] <krytarik> That would look exceptionally odd and unexpected on the header and license images in our case..
[04:25] <krytarik> And it does seem like re-use of attached images between posts is possible there.
[05:39] <guiverc[m]> UWN 766 pushed to fb.
[05:44] <Bashing-om> guiverc: FB --- \o/ :D
[05:45]  * guiverc turned the other box on earlier than is usual...
[05:47] <Bashing-om> guiverc: I can only imagine - how you make FB happen from a different box :)
[05:52] <guiverc> tor-browser still hasn't been fixed on ubuntu... I considered install via tarball (actually downloaded it earlier today, then thought no; by using the deb I can re-prod the bug report every so often..) ... I could easily 'stop' my blocks & do it from here too, but choose to use tor-browser to bypass my-blocks for fb...  the other box is in the kitchen & gets used at night to watch videos mainly... (b/c of its handy location)
[05:58] <Bashing-om> guiverc: We use the tools that work best for us :D
[05:59] <guiverc> :)   (or what's easy, or fits our 'crazy/pointless' ideas..)
[09:13] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: Top 10 robotics snaps in the Snap Store – Part 1 @ https://ubuntu.com//blog/top-10-robotics-snaps-p1
[13:00] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: What is real-time Linux? Part II @ https://ubuntu.com//blog/what-is-real-time-linux-ii
[14:36] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: Want to Create a Custom Ubuntu ISO? Try Cubic @ https://www.omgubuntu.co.uk/2023/02/cubic-is-a-custom-ubuntu-iso-creator (by Joey Sneddon)