Website copy editing

[mechanarchy]

I fixed some typos, and made some wording changes that IMHO seem to read more smoothly.

Please feel free to comment if you object to any of these and I can improve/undo them.

[netlify[bot]]

✅ Deploy Preview for inventree-org-preview ready!

Name	Link
🔨 Latest commit	466e0dcaa8349b25a34c3e78f90503d0104b6de7
🔍 Latest deploy log	https://app.netlify.com/sites/inventree-org-preview/deploys/6563f866aa081e0008029f98
😎 Deploy Preview	https://deploy-preview-181--inventree-org-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 99 (no change from production) Accessibility: 94 (no change from production) Best Practices: 100 (no change from production) SEO: 75 (no change from production) PWA: - View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[mechanarchy]

I also note there's both a blog and a news section - at the moment it doesn't seem like there's enough differentiation between them for it to be worthwhile having two separate feeds.

Perhaps these would be better combined under the blog heading, since the majority of entries are there already.

[SchrodingersGat]

Thanks @mechanarchy these changes all look good to me.

Perhaps these would be better combined under the blog heading, since the majority of entries are there already.

Any major changes to site layout should be discussed over in https://github.com/inventree/inventree-website/pull/177

[matmair]

@mechanarchy the news section is used for creating a programmatic feed that is consumed by InvenTree instances and shown in the local interface, it is not targeted at human consumption.

[mechanarchy]

@mechanarchy the news section is used for creating a programmatic feed that is consumed by InvenTree instances and shown in the local interface, it is not targeted at human consumption.

Respectfully @matmair, if it's not targeted for human consumption, then it probably shouldn't be linked in the website footer.

I see the distinction now, thank you. Perhaps it would be easier for instances to load the newsfeed if it's stored in a YAML or JSON manifest on the server? This is how I have seen some other projects choose to approach this problem.

It also readily lets news entries age out gracefully, have conditional display (such as for dev/beta/stable release channels), and any other metadata that may become useful in the future.

[SchrodingersGat]

@mechanarchy I'm on board with this approach, the "news" being visible on the site is confusing. It should be blog only, with a news entry created for each blog post also

[matmair]

@mechanarchy no offense taken. I am trying to explain why decisions were made and what will break if things are changed. I designed the whole website/repo/news thing without major inputs out of Greenfield, so there are less than-optimal things. RSS was selected because it is a well-known standard, making it interoperable and easy to use in future iterations of the main code base. Building something custom means that the person maintaining it only has a few resources to pull from when things fail.

If you want to contribute these theoretically possible things that would be great - feel free, I have no attachment or commitment to this code base.