I did it for this topic 
does that work for you?
I can change the name or even make it a sub-category so it gets two colors, e.g. 
Dear Eric,
Many thanks for picking this up.
I am not really familiar with the message structure in the forum.
I would have thought a two colour approach where the first is for announcements
would work better. Personally I prefer Packs, to Packages.
Thanks again,
Nicos
There is no formal structure. About the only two categories that seem to be consistent is Release which is used almost exclusively by Jan and Wiki with Wiki Discussion where topics are created exclusively by me but others can ask.
I try to add some consistency to the other categories but with the exception of Help are not used very often.
Help is the most used and other than tags which are not used often enough is just unorganized with three subcategories; Predicate, Tools, and Algorithm
Your wish is my command. 
What I prefer to do is something like they do at SonarSource.
Where tags get a square before them but I would also like the category and subcategory to also get a square like 
It could probably be done as a Discourse Theme but I have more important things to do for now.
After posting in a question I decided that you are right and it should pack and not package as they are clearly different.
So I made the change.
For those not familiar with the differences there are packs and packages. If that confuses you, I use to be confused also. Just don’t ask me to explain the differences as I really can’t.
packs: are not bundled at compile time with any SWI-Prolog installation; must be installed afterwards by running pack_install/2.
packages: can be bundled at compile time with an SWI-Prolog installation (by choosing Cmake options)
1 Like
BTW, I think it would be a good idea to change the name packages to build-time extensions; change the name pack to add-on, providing a term_expansion from addon_install/[1,2] to pack_install/[1,2] and all the other related predicates.
The website also needs to use consistent naming, as it uses both add-ons (on the main menu) and packs on the page listing all the available packs.
NOTE: Perhaps we should break this to another topic called: Packs or Add-ons?
That is a good suggestion. I’m rather reluctant though. The name packages appears throughout the sources, git locations, etc. That is surely possible to modify, but it will result in a lot of issues with upgrades, builds, etc. for a long time. Considering the packages are mostly internal I don’t think that is worth the work and regression.
A bit easier might be to change the Packages page. That is probably limited to PlDoc changes and regression will be limited to the documentation rather than distribution and builds.
Especially if we get rid of Packages page I think I’d be more in favor of dropping add on as this is (I think?) a less common name and only used in a few places.
I certainly agree having “packages” and “packs” wasn’t a great idea 
Other opinions on how to get this improved?
I don’t think there is any need to change the name in the sources, git locations or other internal parts. Only the user-facing parts would need to be changed, such as the website and the documentation.
You mean to drop the name ‘add-on’ and use the name ‘pack’ consistently? That would clear the confusion if we change the name ‘packages’ to ‘build-time extensions’ (in the user-facing parts).
It took me a while to figure out a clear distinction between packs and packages, so I think this would be a great improvement and has little cost if we do the change only on the external user-facing parts.
1 Like
FYI
In installing a daily build just now saw
where they are called a component but SWI-Prolog ODBC Interface is a package. 
ODBC_Interface still bundled at compile time, but one can choose to install it or not.
I don’t see any problem with the name “components” since examples, documentation, Perl_regex are different types of things, so using the name components is okay because we are not just choosing what packages to install, but we are choosing other things too (e.g. examples and documentation)
1 Like